Add a backend that requests Cert-Manager certificates

CHANGELOG.md

@@ -7,12 +7,14 @@ All notable changes to this project will be documented in this file.
 ### Added
 
 - Active Directory's `samAccountName` generation can now be customized ([#454]).
+- Added experimental cert-manager backend ([#482]).
 
 ### Fixed
 
 - Fixed Kerberos keytab provisioning reusing its credential cache ([#490]).
 
 [#454]: https://github.com/stackabletech/secret-operator/pull/454
+[#482]: https://github.com/stackabletech/secret-operator/pull/482
 [#490]: https://github.com/stackabletech/secret-operator/pull/490
 
 ## [24.7.0] - 2024-07-24

deploy/helm/secret-operator/crds/crds.yaml

@@ -31,6 +31,8 @@ spec:
                         - k8sSearch
                     - required:
                         - autoTls
+                    - required:
+                        - experimentalCertManager
                     - required:
                         - kerberosKeytab
                   properties:
@@ -79,6 +81,41 @@ spec:
                       required:
                         - ca
                       type: object
+                    experimentalCertManager:
+                      description: |-
+                        The [`experimentalCertManager` backend](https://docs.stackable.tech/home/nightly/secret-operator/secretclass#backend-certmanager) injects a TLS certificate issued by [cert-manager](https://cert-manager.io/).
+
+                        A new certificate will be requested the first time it is used by a Pod, it will be reused after that (subject to cert-manager renewal rules).
+                      properties:
+                        defaultCertificateLifetime:
+                          default: 1d
+                          description: |-
+                            The default lifetime of certificates.
+
+                            Defaults to 1 day. This may need to be increased for external issuers that impose rate limits (such as Let's Encrypt).
+                          type: string
+                        issuer:
+                          description: A reference to the cert-manager issuer that the certificates should be requested from.
+                          properties:
+                            kind:
+                              description: |-
+                                The kind of the issuer, Issuer or ClusterIssuer.
+
+                                If Issuer then it must be in the same namespace as the Pods using it.
+                              enum:
+                                - Issuer
+                                - ClusterIssuer
+                              type: string
+                            name:
+                              description: The name of the issuer.
+                              type: string
+                          required:
+                            - kind
+                            - name
+                          type: object
+                      required:
+                        - issuer
+                      type: object
                     k8sSearch:
                       description: The [`k8sSearch` backend](https://docs.stackable.tech/home/nightly/secret-operator/secretclass#backend-k8ssearch) can be used to mount Secrets across namespaces into Pods.
                       properties:

deploy/helm/secret-operator/templates/roles.yaml

@@ -68,10 +68,18 @@ rules:
     verbs:
       - get
   - apiGroups:
-    - security.openshift.io
+      - cert-manager.io
+    resources:
+      - certificates
+    verbs:
+      - get
+      - patch
+      - create
+  - apiGroups:
+      - security.openshift.io
     resourceNames:
-    - privileged
+      - privileged
     resources:
-    - securitycontextconstraints
+      - securitycontextconstraints
     verbs:
-    - use
+      - use

docs/modules/secret-operator/examples/cert-manager/pod.yaml

@@ -31,7 +31,7 @@ spec:
               metadata:
                 annotations:
                   secrets.stackable.tech/class: tls-cert-manager # <2>
-                  secrets.stackable.tech/scope: service=my-app # <3>
+                  secrets.stackable.tech/scope: node,service=my-app # <3>
               spec:
                 storageClassName: secrets.stackable.tech
                 accessModes:

docs/modules/secret-operator/examples/cert-manager/secretclass.yaml

@@ -5,6 +5,7 @@ metadata:
   name: tls-cert-manager # <1>
 spec:
   backend:
-    k8sSearch:
-      searchNamespace:
-        pod: {} # <2>
+    experimentalCertManager:
+      issuer:
+        kind: Issuer # <2>
+        name: secret-operator-demonstration # <3>

docs/modules/secret-operator/pages/cert-manager.adoc

@@ -1,9 +1,11 @@
 = Cert-Manager Integration
 
+WARNING: The Cert-Manager backend is experimental, and subject to change.
+
 https://cert-manager.io/[Cert-Manager] is a common tool to manage certificates in Kubernetes, especially when backed by an external
 Certificate Authority (CA) such as https://letsencrypt.org/[Let\'s Encrypt].
 
-The Stackable Secret Operator does not currently support managing Cert-Manager certificates directly, but it can be configured to consume certificates generated by it.
+The Stackable Secret Operator supports requesting certificates from Cert-Manager.
 
 [#caveats]
 == Caveats
@@ -37,46 +39,28 @@ include::example$cert-manager/issuer.yaml[]
 [#secretclass]
 == Creating a SecretClass
 
-The Stackable Secret Operator needs to know how to find the certificates created by Cert-Manager. We do this by creating
-a xref:secretclass.adoc[] using the xref:secretclass.adoc#backend-k8ssearch[`k8sSearch` backend], which can find arbitrary
-Kubernetes Secret objects that have the correct labels.
+The Stackable Secret Operator needs to know how to request the certificates from Cert-Manager. We do this by creating
+a xref:secretclass.adoc[] using the xref:secretclass.adoc#backend-certmanager[`experimentalCertManager` backend].
 
 [source,yaml]
 ----
 include::example$cert-manager/secretclass.yaml[]
 ----
 <1> Both certificates and Pods will reference this name, to ensure that the correct certificates are found
-<2> This informs the Secret Operator that certificates will be found in the same namespace as the Pod using it
-
-[#certificate]
-== Requesting a certificate
-
-You can now use Cert-Manager to provision your first certificate. Use labels to inform the Stackable Secret Operator
-about which xref:scope.adoc[scopes] the certificate fulfills. Which scopes must be provisioned is going to depend
-on the design of the workload. This guide assumes the xref:scope.adoc#service[service] scope.
-
-[source,yaml]
-----
-include::example$cert-manager/certificate.yaml[]
-----
-<1> The Certificate name is irrelevant for the Stackable Secret Operator's, but must be unique (within the Namespace)
-<2> The Secret name must also be unique within the Namespace
-<3> This tells the Stackable Secret Operator that this secret corresponds to the SecretClass created xref:#secretclass[before]
-<4> This secret fulfils the xref:scope.adoc#service[service] scope for `my-app`
-<5> The list of DNS names that this certificate should apply to.
-<6> The Cert-Manager Issuer that should sign this certificate, as created xref:#issuer[before]
+<2> This guide uses a namespaced Issuer, rather than a cluster-scoped ClusterIssuer
+<3> The Cert-Manager Issuer that should sign these certificates, as created xref:#issuer[before]
 
 [#pod]
 == Using the certificate
 
-Finally, we can create and expose a Pod that consumes the certificate!
+Finally, we can create and expose a Pod that requests and uses the certificate!
 
 [source,yaml]
 ----
 include::example$cert-manager/pod.yaml[]
 ----
 <1> A secret xref:volume.adoc[volume] is created, where the certificate will be exposed to the app
 <2> The volume references the SecretClass defined xref:#secretclass[before]
-<3> The app is designated the scope xref:scope#service[`service=my-app`], matching the xref:#certificate[certificate's scope]
+<3> The app requires the certificate to be valid for the scopes xref:scope.adoc#node[`node`] and xref:scope.adoc#service[`service=my-app`]
 <4> nginx is configured to use the mounted certificate
 <5> nginx is exposed as a Kubernetes Service

docs/modules/secret-operator/pages/secretclass.adoc

@@ -94,6 +94,40 @@ spec:
 `autoTls.ca.caCertificateLifetime` :: The lifetime of the certificate authority's root certificate.
 `autoTls.maxCertificateLifetime`:: 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.
 
+[#backend-certmanager]
+=== `experimentalCertManager`
+
+*Format*: xref:#format-tls-pem[]
+
+Injects a TLS certificate issued by https://cert-manager.io/[Cert-Manager].
+
+WARNING: This backend is experimental, and subject to change.
+
+NOTE: This backend requires https://cert-manager.io/[Cert-Manager] to already be installed and configured.
+
+A new certificate will be requested the first time it is used by a Pod, it will be reused after that (subject to Cert-Manager's renewal rules).
+
+Node-scoped requests will cause a Pod to become "sticky" to the Node that it was first scheduled to (like xref:#backend-k8ssearch[], but unlike xref:#backend-autotls[]).
+
+==== Reference
+
+[source,yaml]
+----
+spec:
+  backend:
+    experimentalCertManager:
+      issuer:
+        kind: Issuer
+        name: secret-operator-demonstration
+      defaultCertificateLifetime: 1d
+----
+
+`experimentalCertManager`:: Declares that the `experimentalCertManager` backend is used.
+`experimentalCertManager.issuer`:: The reference to the Cert-Manager issuer that should issue the certificates.
+`experimentalCertManager.issuer.kind`:: The kind of the Cert-Manager issuer, either Issuer or ClusterIssuer. Note that Issuer must be in the same namespace as the Pod requesting the secret.
+`experimentalCertManager.issuer.name`:: The name of the Issuer or ClusterIssuer to be used.
+`experimentalCertManager.defaultCertificateLifetime`:: The default duration of the certificates. This may need to be increased for backends that impose stricter rate limits, such as https://letsencrypt.org/[Let's Encrypt].
+
 [#backend-kerberoskeytab]
 === `kerberosKeytab`
 

docs/modules/secret-operator/pages/volume.adoc

@@ -97,6 +97,18 @@ shortened by a random amount between 0 and 4.8 hours, leaving a certificate that
 
 Jittering may be disabled by setting the jitter factor to 0.
 
+=== `secrets.stackable.tech/backend.cert-manager.cert.lifetime`
+
+*Required*: false
+
+*Default value*: `1d` (configured by xref:secretclass.adoc#backend-certmanager[the backend])
+
+*Backends*: xref:secretclass.adoc#backend-autotls[]
+
+The lifetime of the created certificate.
+
+The format is documented in xref:concepts:duration.adoc[].
+
 === `secrets.stackable.tech/kerberos.service.names`
 
 *Required*: false

rust/operator-binary/build.rs

@@ -6,7 +6,7 @@ fn main() {
     let out_dir = PathBuf::from(std::env::var("OUT_DIR").expect("OUT_DIR is required"));
     tonic_build::configure()
         .file_descriptor_set_path(out_dir.join("file_descriptor_set.bin"))
-        .compile(&["csi.proto"], &["vendor/csi"])
+        .compile(&["vendor/csi/csi.proto"], &["vendor/csi"])
         .unwrap();
     built::write_built_file().unwrap();
 }