Skip to content

Commit d6a2dc1

Browse files
committed
docs: document how the certificate is handled
1 parent 42208ea commit d6a2dc1

File tree

2 files changed

+18
-0
lines changed

2 files changed

+18
-0
lines changed
80.7 KB
Loading

docs/content/addons/registry.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,24 @@ spec:
3131
registry: {}
3232
```
3333
34+
## Registry Certificate
35+
36+
1. A root CA Certificate is deployed in the provider's namespace.
37+
2. cert-manager generates a 10-year self-signed root Certificate
38+
and creates a Secret `registry-addon-root-ca` in the provider's namespace.
39+
3. BCC handler copies `ca.crt` from the `registry-addon-root-ca` Secret
40+
to a new cluster Secret `<cluster-name>-registry-addon-ca`.
41+
A client pushing to the registry can use either the root CA Secret or the cluster Secret to trust the registry.
42+
4. The cluster CA Secret contents (`ca.crt`) is written out as files on the Nodes
43+
and used by Containerd to trust the registry addon.
44+
5. During the initial cluster creation, the ACPI handler uses the root CA to create a new 2-year server certificate
45+
for the registry and creates a Secret `registry-tls` on the remote cluster.
46+
6. During cluster upgrades, the BCU handler renews the server certificate
47+
and updates the Secret `registry-tls` on the remote cluster with the new certificate.
48+
It is expected that clusters will be upgraded at least once every 2 years to avoid certificate expiration.
49+
50+
![registry-certificate.png](registry-certificate.png)
51+
3452
[Distribution]: https://github.com/distribution/distribution
3553
[Cluster API Add-on Provider for Helm]: https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm
3654
[Regsync]: https://regclient.org/usage/regsync/

0 commit comments

Comments
 (0)