Managing access to Amazon Elastic Kubernetes Service clusters with X.509 certificates
Currently, customers are given two main options for end users to access Amazon Elastic Kubernetes Service (Amazon EKS) clusters when using utilities like
kubectl – AWS Identity and Access Management (AWS IAM), or OpenID Connect (OIDC). However, some customers leverage X.509 certificates to authenticate their end-users for access to Amazon EKS clusters, especially those migrating from self-managed Kubernetes where they can have more flexibility over the authentication and authorization configuration of the Kubernetes control plane.
Amazon EKS uses IAM to provide authentication to your Kubernetes cluster. Amazon EKS uses the
aws eks get-token command, available in version AWS CLI version 1.16.156 or later of the AWS Command Line Interface (AWS CLI) or the AWS IAM Authenticator for Kubernetes with
kubectl for cluster authentication.
With the release of IAM Roles Anywhere, customers now have a new option to bridge between the use of X.509 certificates and AWS IAM for controlling access to Amazon EKS clusters. This unlocks several use cases:
- Services and machines outside of AWS that cannot use capabilities, like IAM instance profiles, can authenticate by using the same.
- End-users can access clusters by authenticating with X.509.
These use cases can both be met without vending IAM user accounts or credentials for each user and machine that needs to access Amazon EKS.
In this post, we’ll walk through how to use X.509 certificates as the root of trust for obtaining temporary AWS credentials to access resources in the Amazon EKS Cluster.
(1) IAM Roles Anywhere relies on public key infrastructure (PKI) to establish trust between your AWS account and certificate authority (CA) that issues end entity certificate. A user wanting to access the cluster resources presents X.509 certificates to IAM Roles Anywhere. The certificates are issued by a CA that you register as a trust anchor (root of trust) in IAM Roles Anywhere. The CA can be part of your existing PKI system, or can be a CA that you created with AWS Certificate Manager Private Certificate Authority (ACM PCA).
(2) IAM Roles Anywhere trust model bridges between the IAM Role with the PKI that it already trusted as the trust anchor and the identities encoded in the end entity certificates. Upon a successful authentication, it calls AWS Security Token Service (STS) to fetch temporary credentials for the assumed role . Temporary credentials are presented back for authenticating with the Amazon EKS Cluster.
(3) Amazon EKS Cluster uses
aws-auth configmap to appropriately map an AWS IAM Role against a specific Kubernetes permission. The STS token that’s presented as a result of previous step can be used to access the Amazon EKS Cluster with the permissions as defined in the
Let’s now implement this solution step-by-step. The goal that we want to achieve is to use a X.509 certificate to get read-only access to Amazon EKS Cluster.
For this walkthrough, you need to have the following requirements in place:
- AWS CLI (version 1.6.3 or above), kubectl, eksctl, and openssl installed and configured.
- AWS Credentials Helper tool installed.
- To use this solution, following minimum access is required:
- Minimum IAM policies as described for using eksctl, as described in this document
High-level steps for implementing the solution are as follows:
- Create a Private Certificate Authority (PCA) with AWS certificate Manager. This step is typically executed by administrators.
- Generate an end user certificate singed with AWS PCA. This step is typically executed by end users trying to access the EKS Cluster using X.509 certificate.
- Create an IAM Role Anywhere with Trust Anchor as AWS PCA. This step is typically executed by administrators.
- Create Amazon EKS Cluster and mapping the IAM Role. This step is typically executed by administrators.
Step 1: Create a Private Certificate Authority (PCA) with AWS Certificate Manager
NOTE : The steps described below to create a PCA with AWS Certificate Manager are for illustration purposes only. We strongly recommend reviewing AWS Private CA user guide for planning, securing, administration and best practices guidance.
1. Switch to working directory, modify name of the
CommonName before running the following command to create the CA configuration file as
cat <<EoF> ./ca_config.json
"Organization": "Example Corp",