Cert Manager Issuer

Follow the instructions here to configure a machine identity in Infisical with Universal Auth.

By the end of this step, you should have a Client ID and Client Secret on hand as part of the Universal Auth configuration for the Infisical PKI Issuer to authenticate with Infisical; this will be useful in steps 4 and 5.

Install cert-manager into your Kubernetes cluster by following the instructions here or by running the following command:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml

Install the Infisical PKI Issuer controller into your Kubernetes cluster using one of the following methods:

helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
helm install infisical-pki-issuer infisical-helm-charts/infisical-pki-issuer

helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
helm install infisical-pki-issuer infisical-helm-charts/infisical-pki-issuer

kubectl apply -f https://raw.githubusercontent.com/Infisical/infisical-issuer/main/build/install.yaml

Start by creating a Kubernetes Secret containing the Client Secret from step 1. As mentioned previously, this will be used by the Infisical PKI issuer to authenticate with Infisical.

kubectl create secret generic issuer-infisical-client-secret \
    --namespace <namespace_you_want_to_issue_certificates_in> \
    --from-literal=clientSecret=<client_secret>

kubectl create secret generic issuer-infisical-client-secret \
    --namespace <namespace_you_want_to_issue_certificates_in> \
    --from-literal=clientSecret=<client_secret>

apiVersion: v1
kind: Secret
metadata:
    name: issuer-infisical-client-secret
    namespace: <namespace_you_want_to_issue_certificates_in>
data:
    clientSecret: <client_secret>

kubectl apply -f secret-issuer.yaml

Next, create the Infisical PKI Issuer by filling out url, clientId, projectId or certificateTemplateName, and applying the following configuration file for the Issuer resource. This configuration file specifies the connection details to your Infisical PKI CA to be used for issuing certificates.

apiVersion: infisical-issuer.infisical.com/v1alpha1
kind: Issuer
metadata:
    name: issuer-infisical
    namespace: <namespace_you_want_to_issue_certificates_in>
spec:
    url: "https://app.infisical.com" # the URL of your Infisical instance
    projectId: <project_id> # the ID of the project you want to use to issue certificates
    certificateTemplateName: <certificate_template_name> # the name of the certificate template you want to use to issue certificates against
    authentication:
        universalAuth:
            clientId: <client_id> # the Client ID from step 1
            secretRef: # reference to the Secret created in step 4
                name: "issuer-infisical-client-secret"
                key: "clientSecret"

kubectl apply -f infisical-issuer.yaml

You can check that the issuer was created successfully by running the following command:

kubectl get issuers.infisical-issuer.infisical.com -n <namespace_of_issuer> -o wide

NAME               AGE
issuer-infisical   21h

If you create a CertificateRequest now, you’ll notice it’s neither approved nor denied. This is expected because by default cert-manager approver controller requires an approver-policy.

To enable approval, create the following YAML file and apply it:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: infisical-issuer-approver
rules:
 # Permission to approve or deny CertificateRequests for signers in cert-manager.io API group
 - apiGroups: ['cert-manager.io']
   resources: ['signers']
   verbs: ['approve']
   resourceNames:
     # Grant approval permissions for namespaced issuers
     - "issuers.infisical-issuer.infisical.com/default.issuer-infisical"
     # Grant approval permissions for cluster-scoped issuers
     - "clusterissuers.infisical-issuer.infisical.com/clusterissuer-infisical"
---
# Bind the cert-manager service account to the new role
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: infisical-issuer-approver-binding
subjects:
 - kind: ServiceAccount
   name: cert-manager
   namespace: cert-manager
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: infisical-issuer-approver

kubectl apply -f infisical-approver-policy.yaml

This configuration creates a ClusterRole named infisical-issuer-approver that grants approval permissions for specific Infisical issuer types. It then binds this role to the cert-manager service account, allowing it to approve certificate requests from your Infisical issuers.

For information, check out cert manager approval policy doc.

Finally, create a Certificate by applying the following configuration file. This configuration file specifies the details of the (end-entity/leaf) certificate to be issued.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
    name: certificate-by-issuer
    namespace: <namespace_you_want_to_issue_certificates_in>
spec:
    commonName: certificate-by-issuer.example.com # the common name for the certificate
    secretName: certificate-by-issuer # the name of the Kubernetes Secret to create and store the certificate and private key in
    issuerRef:
        name: issuer-infisical
        group: infisical-issuer.infisical.com
        kind: Issuer
    privateKey: # the algorithm and key size to use
        algorithm: ECDSA
        size: 256
    duration: 48h # the ttl for the certificate
    renewBefore: 12h # the time before the certificate expiry that the certificate should be automatically renewed

The above sample configuration file specifies a certificate to be issued with the common name certificate-by-issuer.example.com and ECDSA private key using the P-256 curve, valid for 48 hours; the certificate will be automatically renewed by cert-manager 12 hours before expiry. The certificate is issued by the issuer issuer-infisical created in the previous step and the resulting certificate and private key will be stored in a secret named certificate-by-issuer.

Note that the full list of the fields supported on the Certificate resource can be found in the API reference documentation here.

You can check that the certificate was created successfully by running the following command:

kubectl get certificates -n <namespace_of_your_certificate> -o wide

NAME                    READY   SECRET                  ISSUER             STATUS                                          AGE
certificate-by-issuer   True    certificate-by-issuer   issuer-infisical   Certificate is up to date and has not expired   20h

Since the actual certificate and private key are stored in a Kubernetes secret, we can check that the secret was created successfully by running the following command:

kubectl get secret certificate-by-issuer -n <namespace_of_your_certificate>

NAME                    TYPE                DATA   AGE
certificate-by-issuer   kubernetes.io/tls   2      26h

We can describe the secret to get more information about it:

kubectl describe secret certificate-by-issuer -n default

Name:         certificate-by-issuer
Namespace:    default
Labels:       controller.cert-manager.io/fao=true
Annotations:  cert-manager.io/alt-names:
            cert-manager.io/certificate-name: certificate-by-issuer
            cert-manager.io/common-name: certificate-by-issuer.example.com
            cert-manager.io/ip-sans:
            cert-manager.io/issuer-group: infisical-issuer.infisical.com
            cert-manager.io/issuer-kind: Issuer
            cert-manager.io/issuer-name: issuer-infisical
            cert-manager.io/uri-sans:

Type:  kubernetes.io/tls

Data
====
ca.crt: 1306 bytes
tls.crt: 2380 bytes
tls.key:  227 bytes

Here, ca.crt is the Root CA certificate, tls.crt is the requested certificate followed by the certificate chain, and tls.key is the private key for the certificate.

We can decode the certificate and print it out using openssl:

kubectl get secret certificate-by-issuer -n default -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -text -noout

In any case, the certificate is ready to be used as Kubernetes Secret by your Kubernetes resources.