CaOptions

Proto: ca_options.proto

Package: tls.security.policy.gloo.solo.io

Types:

AgentCertificateAuthority

Specify parameters for configuring the root certificate authority for a VirtualMesh.

Field Description
vault (VaultCA)

Use vault as the intermediate CA source

CertificateRotationCondition

CertificateRotationCondition represents a timesptamped snapshot of the certificate rotation workflow. This is used to keep track of the steps which have been completed thus far.

Field Description
timestamp (string)

The time at which this condition was recorded
state (CertificateRotationState)

The current state of the cert rotation
message (string)

A human readable message related to the current condition
errors (repeated string)

Any errors which occurred during the current rotation stage

CertificateRotationVerificationMethod

Field Description
none (google.protobuf.Empty)

Verification not enabled. NOTE: This setting is only recommended for testing. When enabled rotation will continue from step to step without any kind of verification. For information about the value format, see the Google protocol buffer documentation.
manual (google.protobuf.Empty)

Verification must be completed manually. This involves using our certificate verification endpoint when the certificates are in a VERIFYING state For information about the value format, see the Google protocol buffer documentation.

CommonCertOptions

Configuration for generating a self-signed root certificate. Uses the X.509 format, RFC5280.

Field Description
ttlDays (uint32)

Number of days before root cert expires. Defaults to 365.
rsaKeySizeBytes (uint32)

Size in bytes of the root cert's private key. Defaults to 4096.
orgName (string)

Root cert organization name. Defaults to “gloo-mesh”.
secretRotationGracePeriodRatio (float)

The ratio of the certificate lifetime to when Gloo starts the certificate rotation process. The ratio must be between 0 and 1 (exclusive). For example, if a certificate is valid for 1 day (or 24 hours), and you specify a ratio of 0.1, Gloo starts the certificate rotation process 2.4 hours before it expires (24x0.1).

CertificateRotationState

State of Certificate Rotation Possible states in which a CertificateRotation can exist.

Name Number Description
NOT_ROTATING 0 No Certificate rotation is currently happening
PREVIOUS_CA 1 Signing the certificate using the previously applied CA. This step is mostly used when ADDING_NEW_ROOT fails, and the rotation has to be ROLLED_BACK
ADDING_NEW_ROOT 2 The CertificateRotation is underway, both roots are set, and the new root is being propagated
PROPAGATING_NEW_INTERMEDIATE 3 The CertificateRotation is underway again. The initial verification is over, the traffic continues to work with both roots present. Now the old root is being removed, and the new root is being propagated alone to the data-plane clusters
DELETING_OLD_ROOT 4 The CertificateRotation is underway again. Removing the old-root from all data-plane clusters
VERIFYING 5 Verifying connectivity between workloads, the workflow will not progress until connectivity has been verified. This can either be manual or in the future automated
VERIFIED 6 The connectivity has been verified.
ROLLING_BACK 7 The connectivity has been deemed to not be functioning properly, rolling back to the last known good state.
FINISHED 8 The rotation has finished, the new root has been propagated to all data-plane clusters, and traffic has been verified successfully.
FAILED 9 Processing the certificate rotation workflow failed.

CertificateRotationStrategy

Name Number Description
MULTI_ROOT 0 The default certificate rotation strategy. This strategy involves three steps which ensure that traffic in the mesh will experience no downtime. For an in depth explination of how this strategy works in Istio see the following blog The steps are as follows: 1. ADDING_NEW_ROOT During this step the new root-cert will be appended to the old root-cert, and then distributed. The intermediate will continue to be signed by the original root. 2. PROPAGATING_NEW_INTERMEDIATE During this step both root-certs will still be distributed. In addition the intermediate will now be signed by the new root key. 3. DELETING_OLD_ROOT During this step the old root is no longer included, and the intermediate will continue to be signed by the new root key.
NONE 1 Do not use any rotation strategy. NOTE: This can lead to downtime while workloads transition from one root of trust to another