Kubernetes CertificateSigningRequests
Kubernetes has an in-built CertificateSigningRequest resource. This resource is similar to the cert-manager CertificateRequest in that it is used to request an X.509 signed certificate from a referenced Certificate Authority (CA).
Using this resource may be useful for users who are using an application that supports this resource, and not the cert-manager CertificateRequest resource, but they still wish for certificates to be signed through cert-manager.
Feature State
This feature is currently in an experimental state, and its behavior is subject to change in further releases.
⛔️ This feature is only enabled by adding it to the --feature-gates
flag on
the cert-manager controller:
--feature-gates=ExperimentalCertificateSigningRequestControllers=true
Which can be added using Helm:
$ helm install \cert-manager jetstack/cert-manager \--namespace cert-manager \--create-namespace \--set featureGates="ExperimentalCertificateSigningRequestControllers=true" \# --set installCRDs=true
Note: cert-manager currently only supports signing CertificateSigningRequests using the CA issuer.
Note: cert-manager does not automatically approve CertificateSigningRequests that reference a cert-manager Issuer. Please refer to the Kubernetes documentation for the request process of CertificateSigningRequests.
Signer Name
CertificateSigningRequests contain a
spec.signerName
field to reference a CA to sign the request. cert-manager Issuers or
ClusterIssuers are referenced in the following form:
<resource type>.cert-manager.io/<signer namespace (if namespaced)>.<signer name>
For example, a namespaced Issuer in the namespace sandbox
with the name
my-issuer
would be referenced via:
signerName: issuers.cert-manager.io/sandbox.my-issuer
A ClusterIssuer with the name my-cluster-issuer
would be referenced via:
signerName: clusterissuers.cert-manager.io/my-cluster-issuer
Referencing Namespaced Issuers
Unlike CertificateRequests, CertificateSigningRequests are cluster scoped
resources. To prevent users from requesting certificates from a namespaced
Issuer in a namespace that they otherwise would not have access to, cert-manager
performs a
SubjectAccessReview.
This review ensures that the requesting user has the permission to reference
the signers
resource in the given namespace. The name should be either the
name of the Issuer, or "*"
to reference all Issuers in that namespace.
An example Role to give permissions to reference Issuers in the sandbox
namespace would look like the following:
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: cert-manager-referencer:my-issuernamespace: sandboxrules:- apiGroups: ["cert-manager.io"]resources: ["signers"]verbs: ["reference"]resourceNames:- "my-issuer" # To give permission to _only_ reference Issuers with the name 'my-issuer'- "*" # To give permission to reference Issuers with any name in this namespace
Annotations
To keep feature parity with CertificateRequests, annotations are used to store
values that do not exist as spec
or status
fields on the
CertificateSigningRequest resource. These fields are either set by the
requester or by the signer as labelled below.
-
experimental.cert-manager.io/request-duration
: Set by the requester. Accepts a Go time duration string specifying the requested certificate duration. Defaults to 90 days. -
experimental.cert-manager.io/request-is-ca
: Set by the requester. If set to"true"
, will request for a CA certificate. -
experimental.cert-manager.io/ca
: Set by the signer. Once signed, the signer will populate this annotation with the base 64 encode CA certificate of the signing chain.