You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: deploy/helm/secret-operator/crds/crds.yaml
+13-1Lines changed: 13 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -96,6 +96,13 @@ spec:
96
96
97
97
If `autoGenerate: true` then the Secret Operator will prepare a new CA certificate the old CA approaches expiration. If `autoGenerate: false` then the Secret Operator will log a warning instead.
98
98
type: string
99
+
caCertificateRetirementDuration:
100
+
default: 1h
101
+
description: |-
102
+
Duration at the end of the CA certificate lifetime where no signed certificate will exist.
103
+
104
+
Retired (or expired) CA certificates will not be published.
105
+
type: string
99
106
keyGeneration:
100
107
default:
101
108
rsa:
@@ -136,7 +143,12 @@ spec:
136
143
type: object
137
144
maxCertificateLifetime:
138
145
default: 15d
139
-
description: Maximum lifetime the created certificates are allowed to have. In case consumers request a longer lifetime than allowed by this setting, the lifetime will be the minimum of both, so this setting takes precedence. The default value is 15 days.
146
+
description: |-
147
+
Maximum lifetime the created certificates are allowed to have. In case consumers request a longer lifetime than allowed by this setting, the lifetime will be the minimum of both, so this setting takes precedence. The default value is 15 days.
148
+
149
+
The maximum lifetime must be less than a quarter of the active CA certificate lifetime where the active CA certificate lifetime is `ca.ca_certificate_lifetime - ca.ca_certificate_retirement_duration` to ensure that two subjects always have a common CA certificate in their trust stores – assuming that CAs are rotated at half of their active lifetimes.
150
+
151
+
For instance, if a pod is created right before half of the active CA lifetime has passed, then it is signed by this CA but it does not know yet the new CA certificate which is created right afterwards. If another pod is created so that its certificate lifetime ends right after the first active CA lifetime then it is signed by the new CA. The `max_certificate_lifetime` must be chosen so that these two pods have no overlapping lifetimes, otherwise the first pod would see the second one signed by an unknown CA certificate. This can be achieved by the mentioned formula.
Copy file name to clipboardExpand all lines: docs/modules/secret-operator/pages/secretclass.adoc
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,6 +92,7 @@ Native support for customizing certificate lifetimes in Stacklet CRDs might be a
92
92
93
93
Certificate authorities also have a limited lifetime, and need to be rotated before they expire to avoid cluster disruption.
94
94
95
+
// TODO Adapt this section
95
96
If configured to provision its own CA (`autoTls.ca.autoGenerate`), the Secret Operator will create CA certificates that are valid for 365 days (≃ 1 year, configurable via `autoTls.ca.caCertificateLifetime`), and initiate rotation once less than half of that time remains.
96
97
97
98
To avoid disruption and let the new CA propagate through the cluster, the Secret Operator will prefer using the oldest CA that will last for the entire lifetime of the issued certificate.
0 commit comments