Installing on Kubernetes

cert-manager runs within your Kubernetes cluster as a series of deployment resources. It utilises CustomResourceDefinitions to configure Certificate Authorities and request certificates.

It is deployed using regular YAML manifests, like any other applications on Kubernetes.

Once cert-manager has been deployed, you must configure Issuer or ClusterIssuer resources which represent certificate authorities. More information on configuring different Issuer types can be found in the respective setup guides.


From cert-manager v0.11.0 onwards, the minimum supported version of Kubernetes is v1.11.0. Users still running Kubernetes v1.10 or below should upgrade to a supported version before installing cert-manager.


You should not install multiple instances of cert-manager on a single cluster. This will lead to undefined behaviour and you may be banned from providers such as Let’s Encrypt.

Installing with regular manifests

In order to install cert-manager, we must first create a namespace to run it within. This guide will install cert-manager into the cert-manager namespace. It is possible to run cert-manager in a different namespace, although you will need to make modifications to the deployment manifests.

# Create a namespace to run cert-manager in
kubectl create namespace cert-manager

As part of the installation, cert-manager also deploys a webhook deployment as an APIService. This can cause issues when uninstalling cert-manager if the API service still exists but the webhook is no longer running as the API server is unable to reach the validating webhook. Ensure to follow the documentation when uninstalling cert-manager.

The webhook enables cert-manager to implement validation and mutating webhooks on cert-manager resources. A ValidatingWebhookConfiguration resource is deployed to validate cert-manager resources we will create after installation. No mutating webhooks are currently implemented.

You can read more about the webhook on the webhook document.

We can now go ahead and install cert-manager. All resources (the CustomResourceDefinitions, cert-manager, and the webhook component) are included in a single YAML manifest file:

# Install the CustomResourceDefinitions and cert-manager itself
kubectl apply -f


If you are running Kubernetes v1.15 or below, you will need to add the --validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in our CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation.


When running on GKE (Google Kubernetes Engine), you may encounter a ‘permission denied’ error when creating some of these resources. This is a nuance of the way GKE handles RBAC and IAM permissions, and as such you should ‘elevate’ your own privileges to that of a ‘cluster-admin’ before running the above command. If you have already run the above command, you should run them again after elevating your permissions:

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user=$(gcloud config get-value core/account)

Installing with Helm

As an alternative to the YAML manifests referenced above, we also provide an official Helm chart for installing cert-manager.



Before deploying cert-manager with Helm, you must ensure Tiller is up and running in your cluster. Tiller is the server side component to Helm.

Your cluster administrator may have already setup and configured Helm for you, in which case you can skip this step.

Full documentation on installing Helm can be found in the Installing helm docs.

If your cluster has RBAC (Role Based Access Control) enabled (default in GKE v1.7+), you will need to take special care when deploying Tiller, to ensure Tiller has permission to create resources as a cluster administrator. More information on deploying Helm with RBAC can be found in the Helm RBAC docs.


In order to install the Helm chart, you must run:

# Install the CustomResourceDefinition resources separately
kubectl apply --validate=false -f

# Create the namespace for cert-manager
kubectl create namespace cert-manager

# Add the Jetstack Helm repository
helm repo add jetstack

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install \
  --name cert-manager \
  --namespace cert-manager \
  --version v0.11.1 \

The default cert-manager configuration is good for the majority of users, but a full list of the available options can be found in the Helm chart README.

Verifying the installation

Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:

kubectl get pods --namespace cert-manager

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m

You should see the cert-manager, cert-manager-cainjector and cert-manager-webhook pod in a Running state. It may take a minute or so for the TLS assets required for the webhook to function to be provisioned. This may cause the webhook to take a while longer to start for the first time than other pods. If you experience problems, please check the troubleshooting guide.

The following steps will confirm that cert-manager is set up correctly and able to issue basic certificate types:

# Create a ClusterIssuer to test the webhook works okay
cat <<EOF > test-resources.yaml
apiVersion: v1
kind: Namespace
  name: cert-manager-test
kind: Issuer
  name: test-selfsigned
  namespace: cert-manager-test
  selfSigned: {}
kind: Certificate
  name: selfsigned-cert
  namespace: cert-manager-test
  secretName: selfsigned-cert-tls
    name: test-selfsigned

# Create the test resources
kubectl apply -f test-resources.yaml

# Check the status of the newly created certificate
# You may need to wait a few seconds before cert-manager processes the
# certificate request
kubectl describe certificate -n cert-manager-test
  Common Name:
  Issuer Ref:
    Name:       test-selfsigned
  Secret Name:  selfsigned-cert-tls
    Last Transition Time:  2019-01-29T17:34:30Z
    Message:               Certificate is up to date and has not expired
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2019-04-29T17:34:29Z
  Type    Reason      Age   From          Message
  ----    ------      ----  ----          -------
  Normal  CertIssued  4s    cert-manager  Certificate issued successfully

# Clean up the test resources
kubectl delete -f test-resources.yaml

If all the above steps have completed without error, you are good to go!

If you experience problems, please check the troubleshooting guide.

Configuring your first Issuer

Before you can begin issuing certificates, you must configure at least one Issuer or ClusterIssuer resource in your cluster.

You should read the Setting up Issuers guide to learn how to configure cert-manager to issue certificates from one of the supported backends.

Alternative installation methods


Helmfile is a declarative spec for deploying helm charts.

‘cert-manager-installer’: It’s an easy and automated way to install cert-manager.

Note: This is an external link and it’s not officially maintained by cert-manager but by the community.

git clone
cd cert-manager-installer
helmfile sync


Bitnami Kubernetes Production Runtime (BKPR, kubeprod) is a curated collection of the services you would need to deploy on top of your Kubernetes cluster to enable logging, monitoring, certificate management, automatic discovery of Kubernetes resources via public DNS servers and other common infrastructure needs.

It depends on cert-manager for certificate management, and it is regularly tested so the components are known to work together for GKE and AKS clusters (EKS to be added soon). For its ingress stack it creates a DNS entry in the configured DNS zone and requests a TLS certificate from the Let’s Encrypt staging server.

BKPR can be deployed using the kubeprod install command, which will deploy cert-manager as part of it. Details available in the BKPR installation guide.

Debugging installation issues

If you have any issues with your installation, please refer to the troubleshooting guide.