On this page
CaOptions
CaOptions API reference.
Proto: ca_options.proto
Package: tls.security.policy.gloo.solo.io
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 timestamped 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 intermediate or root certificate. Uses the X.509 format, RFC5280.
| Field | Description |
|---|---|
ttlDays | (uint32)Number of days before the certificate expires. Defaults to 365. |
rsaKeySizeBytes | (uint32)Size in bytes of the certificate’s private key. Defaults to 4096. |
orgName | (string)The organization name of the certificate. 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 |