Secure Kubernetes with AWS Private CA
Kubernetes containers and applications use digital certificates to provide secure
authentication and encryption over TLS. A widely adopted solution for TLS certificate
life-cycle management in Kubernetes is cert-manager
AWS Private CA provides an open-source plug-in to cert-manager, aws-privateca-issuer
The diagram below shows some of the options available for using TLS in an Amazon EKS cluster. This example cluster, containing various resources, is situated behind a load balancer. The numbers identify possible end-points for TLS-secured communications, including the external load balancer, the ingress controller, an individual pod within a service, and a pair of pods communicating securely with each other.
-
Termination at the load balancer.
Elastic Load Balancing (ELB) is an AWS Certificate Manager integrated service, which means that you can provision ACM with a private CA, sign a certificate with it, and install it using using the ELB console. This solution provides encrypted communication between a remote client and the load balancer. Data is passed unencrypted to the EKS cluster. Alternatively, you could provide a private certificate to a non-AWS load balancer to terminate TLS.
-
Termination at the Kubernetes ingress controller.
The ingress controller resides inside the EKS cluster as a native load balancer and router. If you have installed both cert-manager and aws-privateca-issuer, and provisioned the cluster with a private CA, Kubernetes can install a signed TLS certificate on the controller, allowing it to serve as the cluster's end-point for external communications. Communications between the load balancer and the ingress controller are encrypted, and after ingress, data passes unencrypted to the cluster's resources.
-
Termination at a pod.
Each pod is a group of one or more containers that shares storage and network resources. If you have installed both cert-manager and aws-privateca-issuer, and provisioned the cluster with a private CA, Kubernetes can install a signed TLS certificates on pods as needed. A TLS connection terminating at a pod is unavailable by default to other pods in the cluster.
-
Secure communications between pods.
You can also provision multiple pods with certificates that allow them to communicate with one another. The following scenarios are possible:
-
Provisioning with Kubernetes-generated, self-signed certificates. This secures communications between pods, but self-signed certificates do not satisfy HIPAA or FIPS requirements.
-
Provisioning with certificates signed by a private CA. As in numbers 2 and 3 above, this requires installing both cert-manager and aws-privateca-issuer, and provision the cluster with a private CA. Kubernetes can then install signed TLS certificates on the pods as needed.
-
Cross-account use of the cert-manager
Administrators with cross-account access to a CA can use cert-manager to provision a Kubernetes cluster. For more information, see Security best practices for Cross-account access to private CAs.
Note
Only certain AWS Private CA certificate templates can be used in cross-account scenarios. See Supported certificate templates for a list of available templates.
Supported certificate templates
The following table lists AWS Private CA templates that can be used with cert-manager to provision a Kubernetes cluster.
Templates supported for Kubernetes | Support for cross-account use |
---|---|
BlankEndEntityCertificate_CSRPassthrough/V1 definition | |
CodeSigningCertificate/V1 definition | |
EndEntityCertificate/V1 definition | ✓ |
EndEntityClientAuthCertificate/V1 definition | ✓ |
EndEntityServerAuthCertificate/V1 definition | ✓ |
OCSPSigningCertificate/V1 definition |
Example solutions
The following integration solutions show how to configure access to AWS Private CA on an Amazon EKS cluster.