|
| 1 | += Cert-Manager Integration |
| 2 | + |
| 3 | +https://cert-manager.io/[Cert-Manager] is a common tool to manage certificates in Kubernetes, especially when backed by an external |
| 4 | +Certificate Authority (CA) such as https://letsencrypt.org/[Let\'s Encrypt]. |
| 5 | +
|
| 6 | +The Stackable Secret Operator does not currently support managing Cert-Manager certificates directly, but it can be configured to consume certificates generated by it. |
| 7 | +
|
| 8 | +[#caveats] |
| 9 | +== Caveats |
| 10 | +
|
| 11 | +Cert-Manager is designed to manage relatively long-lived certificates that are stored in Kubernetes Secrets. By contrast, |
| 12 | +the Stackable Secret Operator is designed to generate temporary short-lived certificates. |
| 13 | +
|
| 14 | +This has a couple of repercussions: |
| 15 | +
|
| 16 | +- Longer-lived certificates mean that a leaked certificate has potential to be abused for longer. |
| 17 | +- Application teams may have access to read Secrets in their respective applications' Namespaces. |
| 18 | + |
| 19 | +Where possible, we recommend using the xref:secretclass.adoc#backend-autotls[`autoTls` backend] instead. |
| 20 | + |
| 21 | +[#issuer] |
| 22 | +== Configuring Cert-Manager |
| 23 | + |
| 24 | +NOTE: We recommend using the xref:secretclass.adoc#backend-autotls[`autoTls` backend] instead for self-signed PKIs. We use Cert-Manager's CA issuer here to show the broader concepts. |
| 25 | + |
| 26 | +To do this, you will first need to teach Cert-Manager how to create your certificates. |
| 27 | + |
| 28 | +In a production setup this will likely use an external CA such as ACME or OpenBao/Vault. However, to make this guide self-contained, Cert-Manager will create |
| 29 | +a self-signed CA certificate instead. |
| 30 | + |
| 31 | +[source,yaml] |
| 32 | +---- |
| 33 | +include::example$cert-manager/issuer.yaml[] |
| 34 | +---- |
| 35 | +<1> This is the Issuer that our created certificates will reference later |
| 36 | + |
| 37 | +[#secretclass] |
| 38 | +== Creating a SecretClass |
| 39 | + |
| 40 | +The Stackable Secret Operator needs to know how to find the certificates created by Cert-Manager. We do this by creating |
| 41 | +a xref:secretclass.adoc[] using the xref:secretclass.adoc#backend-k8ssearch[`k8sSearch` backend], which can find arbitrary |
| 42 | +Kubernetes Secret objects that have the correct labels. |
| 43 | + |
| 44 | +[source,yaml] |
| 45 | +---- |
| 46 | +include::example$cert-manager/secretclass.yaml[] |
| 47 | +---- |
| 48 | +<1> Both certificates and Pods will reference this name, to ensure that the correct certificates are found |
| 49 | +<2> This informs the Secret Operator that certificates will be found in the same namespace as the Pod using it |
| 50 | + |
| 51 | +[#certificate] |
| 52 | +== Requesting a certificate |
| 53 | + |
| 54 | +You can now use Cert-Manager to provision your first certificate. Use labels to inform the Stackable Secret Operator |
| 55 | +about which xref:scope.adoc[scopes] the certificate fulfills. Which scopes must be provisioned is going to depend |
| 56 | +on the design of the workload. This guide assumes the xref:scope.adoc#service[service] scope. |
| 57 | + |
| 58 | +[source,yaml] |
| 59 | +---- |
| 60 | +include::example$cert-manager/certificate.yaml[] |
| 61 | +---- |
| 62 | +<1> The Certificate name is irrelevant for the Stackable Secret Operator's, but must be unique (within the Namespace) |
| 63 | +<2> The Secret name must also be unique within the Namespace |
| 64 | +<3> This tells the Stackable Secret Operator that this secret corresponds to the SecretClass created xref:#secretclass[before] |
| 65 | +<4> This secret fulfils the xref:scope.adoc#service[service] scope for `my-app` |
| 66 | +<5> The list of DNS names that this certificate should apply to. |
| 67 | +<6> The Cert-Manager Issuer that should sign this certificate, as created xref:#issuer[before] |
| 68 | + |
| 69 | +[#pod] |
| 70 | +== Using the certificate |
| 71 | + |
| 72 | +Finally, we can create and expose a Pod that consumes the certificate! |
| 73 | + |
| 74 | +[source,yaml] |
| 75 | +---- |
| 76 | +include::example$cert-manager/pod.yaml[] |
| 77 | +---- |
| 78 | +<1> A secret xref:volume.adoc[volume] is created, where the certificate will be exposed to the app |
| 79 | +<2> The volume references the SecretClass defined xref:#secretclass[before] |
| 80 | +<3> The app is designated the scope xref:scope#service[`service=my-app`], matching the xref:#certificate[certificate's scope] |
| 81 | +<4> nginx is configured to use the mounted certificate |
| 82 | +<5> nginx is exposed as a Kubernetes Service |
0 commit comments