PolicyPreview

cert-manager CertificateRequests must be approved before the issuer can issue the certificate. By default cert-manager itself approves all CertificateRequests, but a best practices installation should restrict what certificates can be issued. For an installation that does not use the TLS Protect for Kubernetes Operator, users can do that by disabling the default approval mechanism, deploying cert-manager/approver-policy and creating CertificateRequestPolicys for the issuers in the cluster.

TLS Protect for Kubernetes Operator always disables cert-manager's default approval mechanism, deploys approver-policy and creates a CertificateRequestPolicy and the necessary RBAC for each Issuer and ClusterIssuer created by the operator. By default this policy is an 'allow all', so it does not define any constraints as to what certificates can be requested from the issuer. It is meant to make it easier for users to start applying custom policy rules.

The CertificateRequestPolicy for a operator-managed issuer can be customized via installation.spec.issuers[x].policy field which is a wrapper around the CertificateRequestPolicy's spec.

Configure access to the enterprise registry

For the example below, we assume you created the following Kubernetes Secret: namespace: jetstack-secure name: jse-gcr-creds

Create an example Installation with an issuer and a custom policy

Apply Installation resource:

kubectl apply -f - <<EOF
apiVersion: operator.jetstack.io/v1alpha1
kind: Installation
metadata:
  name: policy-example
spec:
  certManager: {}
  approverPolicy: {}
  images:
    secret: jse-gcr-creds # see https://platform.jetstack.io/documentation/configuration/js-operator/quickstart
  issuers:
  - name: foo-self-signed
    clusterScope: true
    selfSigned: {}
    policy:
      allowed:
        dnsNames:
          values:
          - "*.foo.com"
      constraints:
        maxDuration: 1h
      subjects:
        certManager: true
EOF

For this Installation TLS Protect for Kubernetes Operator will create:

• cert-manager installation in jetstack-secure Namespace with the default approver disabled

• approver-policy installation in jetstack-secure Namespace

• a self-signed [1] cert-manager ClusterIssuer 'foo-self-signed'

• a CertificateRequestPolicy for the issuer that restricts that only certificates for \*foo.com DNS names can be requested from this issuer, the minimum key size is 2048 bits and the maximum duration is 1 hour

• RBAC that allows cert-manager ServiceAccount to use the created CertificateRequestPolicy

Wait for the Installation to become ready:

kubectl wait --for=condition=Ready installation/policy-example

This should not take more than a minute or a few.

Observe information about the created components and resources on Installation spec:

kubectl get installation policy-example -ojsonpath='{range .status.conditions[*]}{"type:"}{.type}{" status:"}{.status}{" reason:"}{.reason}{" message:"}{.message}{"\n"}{end}'

Observe created ClusterIssuer and CertificateRequestPolicy:

kubectl get clusterissuer,certificaterequestpolicy -oyaml

Create some Certificate resources:

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: foo-allowed
spec:
  secretName: foo-allowed
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
  dnsNames:
  - "thing.foo.com"
  duration: 1h
  issuerRef:
    name: foo-self-signed
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: foo-denied
spec:
  secretName: foo-denied
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
  dnsNames:
  - "thing.foo.com"
  duration: 2h
  issuerRef:
    name: foo-self-signed
    kind: ClusterIssuer
    group: cert-manager.io
EOF

Wait for CertificateRequest for 'foo-allowed' Certificate to get approved and for CertificateRequest for foo-denied Certificate to get denied. This should happen within seconds:

kubectl get certificaterequests

Next steps

• View full API documentation