Compatibility with Kubernetes Platform Providers

Below you will find details on various compatibility issues and quirks that you may be affected by when deploying cert-manager. If you believe we’ve missed something please feel free to raise an issue or a pull request with the details!


When Google configure the control plane for private clusters, they automatically configure VPC peering between your Kubernetes cluster’s network and a separate Google-managed project.

In order to restrict what Google are able to access within your cluster, the firewall rules configured restrict access to your Kubernetes pods. This means that the webhook won’t work, and you’ll see errors such as Internal error occurred: failed calling admission webhook ... the server is currently unable to handle the request.

In order to use the webhook component with a GKE private cluster, you must configure an additional firewall rule to allow the GKE control plane access to your webhook pod.

You can read more information on how to add firewall rules for the GKE control plane nodes in the GKE docs.

GKE Autopilot

GKE Autopilot mode with Kubernetes < 1.21 does not support cert-manager, due to a restriction on mutating admission webhooks.

As of October 2021, only the “rapid” Autopilot release channel has rolled out version 1.21 for Kubernetes masters. Installation via the helm chart may end in an error message but cert-manager is reported to be working by some users. Feedback and PRs are welcome.


When using a custom CNI (such as Weave or Calico) on EKS, the webhook cannot be reached by cert-manager. This happens because the control plane cannot be configured to run on a custom CNI on EKS, so the CNIs differ between control plane and worker nodes.

To address this, the webhook can be run in the host network so it can be reached by cert-manager, by setting the webhook.hostNetwork key to true on your deployment, or, if using Helm, configuring it in your values.yaml file.

Note that running on the host network will necessitate changing the webhook’s port; see the warning at the top of the page for details.

AWS Fargate

It’s worth noting that using AWS Fargate doesn’t allow much network configuration and will cause the webhook’s port to clash with the kubelet running on port 10250, as seen in #3237.

When deploying cert-manager on Fargate, you must change the port on which the webhook listens. See the warning at the top of this page for more details.

Because Fargate forces you to use its networking, you cannot manually set the networking type and options such as webhook.hostNetwork on the helm chart will cause your cert-manager deployment to fail in surprising ways.