This article from 2018 states (emphasis mine):

It is common practices for Kubernetes clusters to self-signed their digital certificates. I often get from Security Practictioners the hairy eyeball when this fact is discussed. Why not use “real” certificates, that are signed by trusted CAs. Well, some people do that, but for the rest of us, you are simply not gaining any signficant security benefits, and you are creating more work for yourself. You see, Kubernetes clusters use many digital certificates in all aspects of managaging a cluster. For example, each node has its own digital certificate to verify its authenticity.'[1]

Is it still the correct approach to just allow EKS managed Kubernetes to create and deploy its own certificates?

[1] https://www.nickaws.net/aws/2018/08/16/Verifying-digital-certificates.html

  • What is using the certificates?
    – schroeder
    Jul 19, 2019 at 22:07
  • I believe it's for the nodes to communicate with each other.
    – Prime
    Jul 20, 2019 at 17:05
  • 2
    So, it's to protect internal connections with each other in a segregated network space? From this risk profile, it does not appear to be necessary to require 3rd party verification of a container. Your infrastructure does that for you.
    – schroeder
    Jul 21, 2019 at 19:41

1 Answer 1


With Kubernetes in general, the certificates aren't actually "self-signed" so much as they're signed by an internally managed certificate authority.

Typically, one of the main points of signing a certificate is to ensure that the clients of that service can ensure the certificates validity. In the Kubernetes case this is handled by ensuring that the client has the CA cert on setup. So for example a kubelet on a cluster node will be given the CA cert file as part of setup so it can validate the certificate of an API server that it connects to.

For end users this certificate authority data is generally passed out as part of the kubeconfig file used to log in to the cluster.

So really complaints about "self-signed" certificates don't apply, either in general Kubernetes or EKS. There are other problems with how Kubernetes manages certificates (e.g. lack of revocation support) but those aren't specifically related to this issue.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .