A quick path to Amazon EKS single sign-on using Amazon SSO

{"value":"With the rapid growth of software as a service (SaaS) and cloud adoption, identity is the new security perimeter. [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM) and [Kubernetes role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) provide the tools to build a strong least-privilege security posture. Single sign-on (SSO) uses federation with a central identity provider (IdP) to improve security by allowing users and SecOps teams to manage a single set of credentials. When employees or contractors leave the organization, admins can disable a single account to remove all system and application access. This can also simplify periodic compliance audits.\n\nIn this blog, we demonstrate a quick and direct procedure to implement single sign-on to access Kubernetes resources running on your [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) (Amazon EKS) clusters. You can use [AWS Single Sign-On](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) (AWS SSO) in combination with Kubernetes RBAC to manage access using [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) (AWS CLI) and other Kubernetes CLI tools. You can follow the steps below to get up and running quickly, based on AWS best practices, and you can customize them according to your specific needs. There are good references available that describe specific aspects of SSO and IdP federation, and we recommend those at the end of this post to provide deep dives for specific use cases and challenges.\n\n### **Prerequisites:**\n- An AWS account\n- Access to the email address associated with the AWS account\n- A command-line shell with the following:\n[aws cli v2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) – configured with your admin-level [access key credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)\n[eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) – EKS cluster management utility\n[kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) – Kubernetes management CLI utility\n[jq](https://stedolan.github.io/jq/download/) – JSON query utility\n\n*Lines in italics describe the purpose of the code blocks that you will copy and enter in the AWS CLI shell.*\n\n### **What you’ll build:**\n- [AWS Organizations](https://aws.amazon.com/organizations/) root account\n- AWS Organizations member account\n- [AWS SSO](https://aws.amazon.com/single-sign-on/) using Twilio Authy for multi-factor authentication (MFA)\n- [Amazon EKS](https://aws.amazon.com/eks/) cluster with a two-node managed nodegroup\n\n#### **Security contexts matrix**\n\nDuring the setup process, you will switch between these identities to issue commands against different components.\n\n\n\n### **AWS Organizations and AWS SSO**\nAs the administrator of your AWS environment, you will enable AWS Organizations, create a member account to host your EKS cluster, enable AWS SSO, and create users and groups aligned with your organization’s roles and responsibilities.\n\n#### **Enable AWS Organizations**\nAWS SSO requires AWS Organizations, two no-cost services for managing multiple AWS accounts. With AWS Organizations, AWS SSO can provide authentication and authorization across all accounts in an organization through a single login portal. AWS Organizations can simplify management and security through centralized security guardrails, cross-account administrative access, resource sharing, and organization-wide billing.\n\nYou can deploy AWS Organizations using a single AWS CLI command. The account where you issue this command will become the AWS Organizations root account. Your AWS user or role should have the [AdministratorAccess managed IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) attached.\n\n**Note:** The root account of an AWS Organizations deployment has administrative access privileges across the entire organization and should be reserved for cross-account security and financial tasks. Avoid running application workloads on the root account.\n\n**Create a new organization from your existing, non-organization-joined account**\n\n```\naws organizations create-organization\n```\n\n\nIt will take a few minutes for AWS Organizations to provision.\n\n**Check the provisioning status**\n\n```\naws organizations describe-organization\n```\n\n\nWhen AWS Organizations provisioning completes, the original account email address will receive an email verification request. Open the email and select the **Verify your email address** button. That step enables you to create or invite additional AWS accounts into your new organization.\n\nNow we’ll provision a new member account to host the EKS cluster. Provide a unique name and create an email address in your mail domain by replacing “youralias” and “yourdomain” in the command below. (If your email provider supports it, you can create multiple unique email aliases that go to the same mailbox by appending “+” and a unique string to an existing mail alias). The ${RANDOM} variable will generate a random 5-digit number. While the new account provisions, you can continue to enabling AWS SSO.\n\n**Create a member account that will host your EKS cluster**\n\n```\naws organizations create-account --email youralias+ekscluster@yourdomain.com --account-name \"EKS-Account-${RANDOM}\"\n```\n**Enable AWS SSO**\n\n\n\nIn the AWS Management Console, use the **Services** dropdown or type “SSO” in the search bar to open AWS SSO. Select **Enable AWS SSO**.\n\n\n\nOnce the initial setup completes, you’ll be returned to the AWS SSO configuration pages. Notice that your AWS SSO login portal has already been provisioned. The URL may be further customized by adding a unique host name to the “awsapps.com” parent domain. For now, copy the “User portal URL” from the SSO dashboard and paste it to a text editor for use in later steps below.\n\n\n\nAWS SSO gets you up and running quickly by giving you the option of using the AWS SSO built-in identity store or your own IdP, such as AWS Managed Microsoft AD or an external SAML 2.0 compliant IdP. We will use the AWS SSO built-in identity store. The identity source can be changed later on as your requirements change.\n\nBefore we create an identity in AWS SSO, we’ll turn on multi-factor authentication, which supports both security keys and mobile authenticator apps.\n\n**How to turn on multi-factor authentication:**\n\n1. Select **Settings**, and in the Multi-factor authentication section, select **Configure**.\n2. Under the Users should be prompted for MFA section, select **Every time they sign in (always-on)**.\n3. Under Users can authenticate with these MFA types, make sure the check box for **Authenticator apps** is selected.\n4. Lastly, in the section titled If a user does not yet have a registered MFA device, select the option **Require them to register an MFA device at sign in**.\n5. Select **Save changes**.\n\n\n\n**AWS SSO user configuration**\n\nNow we’ll create a group for EKS cluster administration, associate the group with our member account **EKS-Account-…**, grant permissions, and add a new user to the group. Using groups in AWS SSO simplifies role-based access control (RBAC). In the steps below, we create a least-privilege IAM policy that grants view-only for key AWS resources, full access to EKS resources, and the ability to assume a special role we will use to create the cluster.\n\n1) Select **Groups** and then the **Create group** button. Type “EKS_Cluster_Admins“ and select **Create**.\n\n2) Select **AWS accounts**, then **EKS-Account-…**, and **Assign Users**. Select the **Groups** tab, select **EKS_Cluster_Admins**, and select **Next: Permission sets**.\n\n3) Select Create new permission set, which will open a new browser tab.\n\n4) In the Create new permission set window, select Create a custom permission set, then Next: Details.\n\n- In the **Create a custom permission set** window, create a permission set called “EKSClusterAdminAccess.”\n- Enter **Relay state** “[https://console.aws.amazon.com/eks](https://console.aws.amazon.com/eks)” to redirect SSO users associated with this permission set to the EKS console (optional).\n- Select both **Attach AWS managed policies** and **Create a custom permissions policy**.\n- Search for and select the “ViewOnlyAccess” AWS managed policy.\n- Paste the JSON code block below into the **Create a custom permissions policy** window (as demonstrated in the next screenshot).\n- Select **Next: Tags**, then **Next: Review** and **Create**.\n\n\n```\n{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"eks:*\",\n \"sts:AssumeRole\"\n ],\n \"Resource\": \"*\"\n }\n ]\n}\n```\n\n\n\n5) Back on the **Select permission sets** window, select the refresh arrows, and select the new **EKSClusterAdminAccess** permission set, and select **Finish**. Once your account is configured, select **Proceed to AWS Accounts**.\n\n6) Select **Users**, then **Add User**, and type “eksadmin”.\n\n- In the **Password** section, select **Send an email to the user…**, enter and confirm your email address, and then enter first, last, and display names.\n- Select **Next: Groups**. Select **EKS_Cluster_Admins** and select **Add User**.\n- Note that your username is case-sensitive.\n\n\n\n\nWhen you receive the Invitation to *join AWS Single Sign-On* message in your inbox, select the Accept Invitation button, which brings you to the **New user sign up** window.\n\n\n\nEnter and confirm your new password. As you type, password length and complexity requirements appear to the right, providing guidance as you satisfy those requirements. Once you select **Set new password**, you’ll be redirected to the AWS SSO sign-in page.\n\n**Note:** If you have an existing AWS SSO session, make sure to sign out before continuing.\n\nSign in with your new credentials, and you’ll be prompted to set up multi-factor authentication. We are using Twilio Authy, but [AWS SSO supports several popular physical security key and smartphone authenticator apps](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-types-apps.html) such as Google Authenticator and Yubikey. Open or install your desired authentication app on your smartphone. Go back to the MFA setup on the SSO sign-in page, select **Authenticator app**, select **Next**, and select **Show QR code**. Scan the QR code with your phone and enter the numeric code from your app to complete the new user setup.\n\n\n\n\n\n\n\nOnce you select **Done**, you will be redirected to the SSO account selection page, which will include the “EKS-Account-…” account you associated with the EKS_Cluster_Admins group earlier. Expand that account, select the **EKSClusterAdminAccess** role, and you are directed to the EKS service page of the AWS Management Console.\n\nSo far, we’ve created an organization and added an additional account with only two lines of code. Then we set up AWS Single Sign-on, created a group, and assigned that group to the new account with a least-privilege permission set related to the group’s job role. Finally, we added a new user to that group, set up MFA, and signed in to SSO as that user. If you wanted to use AWS Managed Active Directory or a third-party IdP such as Okta, you could federate those identity providers with AWS Single Sign-on and use those providers’ user identities instead of creating AWS SSO users such as “eksadmin.” All other steps would remain the same.\n\n### **Set up CLI with SSO access to EKS**\nTo simplify using SSO with the AWS CLI, AWS Single Sign-on provides an aws sso login command that integrates with AWS configuration profiles. To set that up, open your command-line terminal with the latest version of the AWS CLI installed and configured.\n\n**Automatically create a named SSO profile**\n\n```aws configure sso```\n\n\nSupply the following values:\n\n- ```sso_start_url``` – “User portal URL” you copied earlier from the [SSO management dashboard](https://console.aws.amazon.com/singlesignon)\n- ```sso_region``` – the Region where SSO was originally deployed and is currently managed\n\n\nWhen the browser window opens requesting your authorization, select Allow, and return to the CLI, which will guide you through selecting an account, a role, a default region for issuing commands, and output format. Assuming your browser has an authenticated AWS SSO session for the “eksadmin“ SSO user, you will only be offered accounts and roles associated with that user. When creating a profile name, select a name that you can easily remember for future reference since you must include ```--profile {profile_name}``` to issue CLI commands under that profile. In this example, we’re naming the profile “EKSClusterAdminAccess-EKSAccount1”.\n\nYour SSO configuration session will resemble the following sample output.\n\n```\n$ aws configure sso\nSSO start URL [None]: https://{hostname}.awsapps.com/start \nSSO Region [None]: us-east-1 \nThe only AWS account available to you is: 111222333444\nUsing the account ID 111222333444\nThe only role available to you is: EKSClusterAdminAccess\nUsing the role name \"EKSClusterAdminAccess\"\nCLI default client Region [None]: us-east-1 \nCLI default output format [None]: json \nCLI profile name [EKSClusterAdminAccess-111222333444]: EKSClusterAdminAccess-EKSAccount1\n```\n\nOnce you create the SSO profile, you can use the command ```aws sso login``` in the future, which will open a browser window prompting you for credentials. Before proceeding, check your current identity:\n\n```\naws sts get-caller-identity --profile EKSClusterAdminAccess-EKSAccount1\n```\n\nYou should encounter something like:\n\n```\n{\n \"UserId\": \"AZORYH847HJYD98SU:eksadmin\",\n \"Account\": \"111222333444\",\n \"Arn\": \"arn:aws:sts::111222333444:assumed-role/AWSReservedSSO_EKSClusterAdminAccess_4ffa4321e413c0b0/eksadmin\"\n}\n```\n\nBefore we create an EKS cluster in our new account and associate your AWS SSO identity with a Kubernetes cluster role, we’ll create a special IAM role for the creation of your new EKS cluster. (As a trade-off between security and simplicity, this role permits all actions for a limited set of AWS services directly involved in cluster creation. For more stringent least-privilege scenarios, you may use services such as AWS IAM Access Analyzer to [build a role based on actual CloudTrail access logs](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/).)\n\n#### **Create IAM EKSClusterCreator role**\nWhen you create an EKS cluster, the user or role you use will inherit cluster administrator permissions. This identity principal retains cluster admin permissions for the life of the cluster and should be kept secure. It is best practice to create additional roles to delegate routine operational tasks while keeping the cluster creator role separate and secure. If you forget the name of that principal, it can be retrieved or changed by AWS Support for a limited time, or you can recreate the IAM principal if you remember the user or role name.\n\nIn the CLI code snippets below, your account number and SSO role name are extracted from your current SSO session and used to grant access to your AWS SSO group to assume the new EKSClusterCreator role. You will use that role to create a new EKS cluster using the eksctl command line tool.\n\n**Get current role and account to create the cluster creator policy**\n\n```\nssorole=$(aws sts get-caller-identity --query Arn --output text --profile EKSClusterAdminAccess-EKSAccount1 | cut -d/ -f2)\naccount=$(aws sts get-caller-identity --query Account --output text --profile EKSClusterAdminAccess-EKSAccount1)\necho $ssorole $account\n```\n\n**Create a JSON file for the IAM cluster creator role trust policy**\n\n```\ncat <<EOF > assume-role.json\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"AWS\": \"arn:aws:iam::${account}:role/aws-reserved/sso.amazonaws.com/${ssorole}\"\n },\n \"Action\": \"sts:AssumeRole\",\n \"Condition\": {}\n }\n ]\n}\nEOF\n```\n\n**Note:** If you configure SSO in a Region other than us-east-1, add the Region after “sso.amazonaws.com”. For example, for us-east-2, “…/[sso.amazonaws.com/us-east-2/…](http://sso.amazoznaws.com/us-east-2/...)”.\n\n**Create a JSON file for the IAM cluster creator role permissions policy**\n\n```\ncat <<EOF > clustercreator-policy.json\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"eks:*\",\n \"iam:*\",\n \"cloudformation:*\",\n \"ec2:*\",\n \"autoscaling:*\",\n \"ssm:*\",\n \"kms:*\",\n \"sts:GetCallerIdentity\"\n ],\n \"Resource\": \"*\"\n }\n ]\n}\nEOF\n```\n\nEven though the cluster creator role requires elevated permissions to create all of the EKS cluster resources, those permissions are only a subset of full AWS AdministratorAccess policy permissions. For simplicity, we will create a policy that allows all API actions for only the AWS services involved in cluster creation.\n\nTo create the IAM policy and role in the EKS-Account, we will temporarily assume the OrganizationAccountAccessRole that is created for all AWS Organizations member accounts. This feature of AWS Organizations offers a customizable level of centralized administrator access across the organization.\n\n**Assume the OrganizationAccountAccessRole to create the EKSClusterCreator role**\n\n```\nadminrolearn=\"arn:aws:iam::${account}:role/OrganizationAccountAccessRole\"\ncreds=$(aws sts assume-role --role-arn ${adminrolearn} --role-session-name \"adminSession-CreateEKSCreatorRole\" --query 'Credentials.[{AWS_ACCESS_KEY_ID: AccessKeyId}, {AWS_SESSION_TOKEN: SessionToken}, {AWS_SECRET_ACCESS_KEY: SecretAccessKey}]' | jq -r .[] | sed 's/{//;s/}//;s/\"//g;s/ AWS_ACCESS_KEY_ID: /export AWS_ACCESS_KEY_ID=/;s/ AWS_SESSION_TOKEN: /export AWS_SESSION_TOKEN=/;s/ AWS_SECRET_ACCESS_KEY: /export AWS_SECRET_ACCESS_KEY=/')\neval ${creds}\n```\n\nNow when you enter ```aws sts get-caller-identity```, you will see that we’ve assumed the OrganizationalAccountAccessRole. The previous script assumes that role and creates environment variables that set your default AWS CLI credentials until you change or unset the AWS_ACCESS_KEY_ID variable or specify an AWS configuration profile.\n\n**Create a cluster creator role and attach the policy**\n\n```\naws iam create-role --role-name EKSClusterCreator --assume-role-policy-document file://assume-role.json\naws iam create-policy --policy-name EKSClusterCreatorPolicy --policy-document file://clustercreator-policy.json\naws iam attach-role-policy --policy-arn arn:aws:iam::${account}:policy/EKSClusterCreatorPolicy --role-name EKSClusterCreator\n```\n\n\n**Assume the role and apply new temporary credentials**\n\n```\nrolearn=\"arn:aws:iam::${account}:role/EKSClusterCreator\"\n\ncreds=$(aws sts assume-role --role-arn ${rolearn} \\\n --role-session-name \"create-eks-cluster\" \\\n --query 'Credentials.[{AWS_ACCESS_KEY_ID: AccessKeyId}, {AWS_SESSION_TOKEN: SessionToken}, {AWS_SECRET_ACCESS_KEY: SecretAccessKey}]' \\\n --profile EKSClusterAdminAccess-EKSAccount1 | jq -r .[] | sed 's/{//;s/}//;s/\"//g;s/ AWS_ACCESS_KEY_ID: /export AWS_ACCESS_KEY_ID=/;s/ AWS_SESSION_TOKEN: /export AWS_SESSION_TOKEN=/;s/ AWS_SECRET_ACCESS_KEY: /export AWS_SECRET_ACCESS_KEY=/')\n\neval ${creds}\n```\n\nNow that we have created our special EKSClusterCreator role, assumed that role in our command-line interface, and reset our environment variables, we are now ready to create our EKS cluster. Once created, we’ll use the eksctl utility to grant access to our EKSClusterAdminAccess role to the new EKS cluster.\n\n#### **Create EKS cluster**\n**Create a new EKS cluster and managed nodegroup in a new VPC with default settings**\n\n```eksctl create cluster```\n\n**Note:** By default, EKS will update the active kubeconfig file. You can specify another kube config file by setting the KUBECONFIG environment variable as follows:\n\nexport KUBECONFIG=~/.kube/config-ekssso-EKSClusterAdmin \nDoing so will preserve your existing kube config file and create a new one when eksctl create cluster finishes.\n\nCluster creation will take about 15–20 minutes. While you wait, you might read the eksctl documentation to see what happens behind the scenes and learn about additional configuration options. To build the cluster and related infrastructure, eksctl uses AWS CloudFormation. Note the cluster name and continue to the next section when cluster creation completes.\n\n### **Kubernetes RBAC and IAM federation**\nEKS provides multiple methods for controlling access to clusters, including webhook token authentication, service account tokens, and OIDC authentication. AWS CLI version 2.x and later transparently generates bearer tokens for authenticating ```kubectl``` commands. The kube-apiserver uses an authentication webhook to validate the token signature and forward the token for authentication with AWS Security Token Service (AWS STS). Once authenticated, kube-apiserver looks for an IAM to Kubernetes RBAC identity mapping in the aws-auth ConfigMap, created by default in all EKS clusters. We will use the already-assumed EKSClusterCreator role to delegate EKS cluster admin rights to our EKSClusterAdminAccess role. First, we’ll grant access to the AWS SSO EKSClusterAdminAccess role using the Kubernetes default ```cluster-admin``` role. If you only have one EKS cluster in the Region you’re using for this exercise, you can enter the full code block shown below. Otherwise, manually set the “cluster” variable with the command ```export cluster={cluster-name}```, using the cluster name shown in the last line of your ```eksctl``` cluster creation process, or by issuing the CLI command ```aws eks list-clusters```.\n\n**Create aws-auth identity mapping for EKSClusterAdminAccess role**\n\n```\ncluster=$(aws eks list-clusters –query clusters –output text)\n\neksctl create iamidentitymapping \\\n --cluster ${cluster} \\\n --arn “arn:aws:iam::${account}:role/${ssorole}” \\\n --username cluster-admin \\\n --group system:masters \n```\n\n**View the new IAM to Kubernetes RBAC mapping by viewing\nthe ```aws-auth``` ConfigMap in your EKS cluster**\n\n```\nkubectl get configmap -n kube-system aws-auth -o yaml \n```\n\nYour output will resemble the following:\n\n```\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: aws-auth\n namespace: kube-system\ndata:\n mapRoles: |\n - groups:\n - system:bootstrappers\n - system:nodes\n rolearn: arn:aws:iam::111222333444:role/eksctl-fabulous-wardrobe-16446157-NodeInstanceRole-L7A7NXU3DSJS\n username: system:node:{{EC2PrivateDNSName}}\n - groups:\n - system:masters\n rolearn: arn:aws:iam::111222333444:role/AWSReservedSSO_EKSClusterAdminAccess_6a316cc66d154241\n username: cluster-admin\n```\n\nBy running the ```eksctl create iamidentitymapping``` command, we mapped our SSO permission set “EKSClusterAdminAccess” to the Kubernetes default ```cluster-admin``` role. The other entry, ```system:node:{{EC2PrivateDNSName}}```, is mapped to the EKS nodegroup instance profile role ```eksctl-fabulous-wardrobe-16446157-NodeInstanceRole-L7A7NXU3DSJS```, which grants each node’s kubelet ```system:bootstrappers``` and ```system:nodes``` permission inside the cluster. This nodegroup mapping is created each time a new nodegroup is created. Notice that there is no mention of the EKSClusterCreator role in the aws-auth ConfigMap. This identity principal retains cluster admin permissions for the life of the cluster and should be kept secure per the [EKS Security Best Practices Guide](https://aws.github.io/aws-eks-best-practices/).\n\nKubectl requires a configuration file entry to define the cluster, Region, identity, and authentication method for ```kubectl``` commands. You can generate that configuration for your EKSClusterAdminAccess role as follows.\n\n**Create kubeconfig to begin using the EKSClusterAdminAccess role**\n\n```\naws eks update-kubeconfig --name ${cluster} \\\n--profile EKSClusterAdminAccess-EKSAccount1\n```\n\n**Note:** If you receive a “No cluster found for name” error, append ```--region {cluster region}``` to the above code block, where ```{cluster region}``` is the Region where you created your EKS cluster.\n\nLet’s test access to our EKS cluster. The output will list your worker nodes.\n\n```kubectl get nodes```\n\nNow that we have an AWS SSO role for EKS cluster admins mapped to a native Kubernetes ```cluster-admin``` role, we can create additional least-privilege roles (scoped by Kubernetes namespace) or cluster-wide ```clusterroles``` mapped to new AWS SSO permission sets using ```eksctl``` IAM identity mappings in the ```aws-auth``` ConfigMap.\n\n### **Conclusion**\nIn this blog, we walked you through setting up an organization and AWS Single Sign-on. We created a user, group, and role (also called permission set) associated with a new account for our EKS cluster. We also created a special role for creating our new EKS cluster, and we used that special role to map our AWS SSO role to a Kubernetes native RBAC ```cluster-admin``` role. With the exception of the AWS SSO configuration, all other tasks were completed using AWS CLI commands, an example of repeatable infrastructure as code.\n\n**Related blogs and documentation**\n\n- [Using Kubernetes Role-based Access Control Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\n- [Manage AWS Single Sign-on identity source](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)\n- [Enabling IAM user and role access to your cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)\n- [Authenticating users for your cluster from an OpenID Connect identity provider](https://docs.aws.amazon.com/eks/latest/userguide/authenticate-oidc-identity-provider.html)\n\n\n\n\n**Juan Lamadrid**\n\nJuan Lamadrid is a New York-based Solutions Architect for AWS. He works with numerous enterprise customers helping them achieve their digital innovation and modernization goals.\n\n\n\n**Rob Solomon**\n\nRob Solomon is a Solutions Architect at Amazon Web Services helping ISV companies leverage AWS to accelerate growth and innovation. In previous roles, he experienced firsthand the challenges SaaS companies face making the transition from datacenter to cloud architecture and operations. Joining AWS has been a great opportunity to help companies be successful on their cloud journey.","render":"<p>With the rapid growth of software as a service (SaaS) and cloud adoption, identity is the new security perimeter. <a href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html\" target=\"_blank\">AWS Identity and Access Management</a> (IAM) and <a href=\"https://kubernetes.io/docs/reference/access-authn-authz/rbac/\" target=\"_blank\">Kubernetes role-based access control</a> (RBAC) provide the tools to build a strong least-privilege security posture. Single sign-on (SSO) uses federation with a central identity provider (IdP) to improve security by allowing users and SecOps teams to manage a single set of credentials. When employees or contractors leave the organization, admins can disable a single account to remove all system and application access. This can also simplify periodic compliance audits.</p>\n<p>In this blog, we demonstrate a quick and direct procedure to implement single sign-on to access Kubernetes resources running on your <a href=\"https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html\" target=\"_blank\">Amazon Elastic Kubernetes Service</a> (Amazon EKS) clusters. You can use <a href=\"https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html\" target=\"_blank\">AWS Single Sign-On</a> (AWS SSO) in combination with Kubernetes RBAC to manage access using <a href=\"https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html\" target=\"_blank\">AWS Command Line Interface</a> (AWS CLI) and other Kubernetes CLI tools. You can follow the steps below to get up and running quickly, based on AWS best practices, and you can customize them according to your specific needs. There are good references available that describe specific aspects of SSO and IdP federation, and we recommend those at the end of this post to provide deep dives for specific use cases and challenges.</p>\n<h3><a id=\"Prerequisites_4\"></a><strong>Prerequisites:</strong></h3>\n<ul>\n<li>An AWS account</li>\n<li>Access to the email address associated with the AWS account</li>\n<li>A command-line shell with the following:<br />\n<a href=\"https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html\" target=\"_blank\">aws cli v2</a> – configured with your admin-level <a href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html\" target=\"_blank\">access key credentials</a><br />\n<a href=\"https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html\" target=\"_blank\">eksctl</a> – EKS cluster management utility<br />\n<a href=\"https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html\" target=\"_blank\">kubectl</a> – Kubernetes management CLI utility<br />\n<a href=\"https://stedolan.github.io/jq/download/\" target=\"_blank\">jq</a> – JSON query utility</li>\n</ul>\n<p><em>Lines in italics describe the purpose of the code blocks that you will copy and enter in the AWS CLI shell.</em></p>\n<h3><a id=\"What_youll_build_15\"></a><strong>What you’ll build:</strong></h3>\n<ul>\n<li><a href=\"https://aws.amazon.com/organizations/\" target=\"_blank\">AWS Organizations</a> root account</li>\n<li>AWS Organizations member account</li>\n<li><a href=\"https://aws.amazon.com/single-sign-on/\" target=\"_blank\">AWS SSO</a> using Twilio Authy for multi-factor authentication (MFA)</li>\n<li><a href=\"https://aws.amazon.com/eks/\" target=\"_blank\">Amazon EKS</a> cluster with a two-node managed nodegroup</li>\n</ul>\n<h4><a id=\"Security_contexts_matrix_21\"></a><strong>Security contexts matrix</strong></h4>\n<p>During the setup process, you will switch between these identities to issue commands against different components.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/a0f448846cb441ba827b7faada1d430e_image.png\" alt=\"image.png\" /></p>\n<h3><a id=\"AWS_Organizations_and_AWS_SSO_27\"></a><strong>AWS Organizations and AWS SSO</strong></h3>\n<p>As the administrator of your AWS environment, you will enable AWS Organizations, create a member account to host your EKS cluster, enable AWS SSO, and create users and groups aligned with your organization’s roles and responsibilities.</p>\n<h4><a id=\"Enable_AWS_Organizations_30\"></a><strong>Enable AWS Organizations</strong></h4>\n<p>AWS SSO requires AWS Organizations, two no-cost services for managing multiple AWS accounts. With AWS Organizations, AWS SSO can provide authentication and authorization across all accounts in an organization through a single login portal. AWS Organizations can simplify management and security through centralized security guardrails, cross-account administrative access, resource sharing, and organization-wide billing.</p>\n<p>You can deploy AWS Organizations using a single AWS CLI command. The account where you issue this command will become the AWS Organizations root account. Your AWS user or role should have the <a href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html\" target=\"_blank\">AdministratorAccess managed IAM policy</a> attached.</p>\n<p><strong>Note:</strong> The root account of an AWS Organizations deployment has administrative access privileges across the entire organization and should be reserved for cross-account security and financial tasks. Avoid running application workloads on the root account.</p>\n<p><strong>Create a new organization from your existing, non-organization-joined account</strong></p>\n<pre><code class=\"lang-\">aws organizations create-organization\n</code></pre>\n<p>It will take a few minutes for AWS Organizations to provision.</p>\n<p><strong>Check the provisioning status</strong></p>\n<pre><code class=\"lang-\">aws organizations describe-organization\n</code></pre>\n<p>When AWS Organizations provisioning completes, the original account email address will receive an email verification request. Open the email and select the <strong>Verify your email address</strong> button. That step enables you to create or invite additional AWS accounts into your new organization.</p>\n<p>Now we’ll provision a new member account to host the EKS cluster. Provide a unique name and create an email address in your mail domain by replacing “youralias” and “yourdomain” in the command below. (If your email provider supports it, you can create multiple unique email aliases that go to the same mailbox by appending “+” and a unique string to an existing mail alias). The ${RANDOM} variable will generate a random 5-digit number. While the new account provisions, you can continue to enabling AWS SSO.</p>\n<p><strong>Create a member account that will host your EKS cluster</strong></p>\n<pre><code class=\"lang-\">aws organizations create-account --email youralias+ekscluster@yourdomain.com --account-name &quot;EKS-Account-${RANDOM}&quot;\n</code></pre>\n<p><strong>Enable AWS SSO</strong></p>\n<p>In the AWS Management Console, use the <strong>Services</strong> dropdown or type “SSO” in the search bar to open AWS SSO. Select <strong>Enable AWS SSO</strong>.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/5dc8e0a90bb940809b3aa3237465ab35_image.png\" alt=\"image.png\" /></p>\n<p>Once the initial setup completes, you’ll be returned to the AWS SSO configuration pages. Notice that your AWS SSO login portal has already been provisioned. The URL may be further customized by adding a unique host name to the “awsapps.com” parent domain. For now, copy the “User portal URL” from the SSO dashboard and paste it to a text editor for use in later steps below.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/5e494439895d4e91971af1454617f06b_image.png\" alt=\"image.png\" /></p>\n<p>AWS SSO gets you up and running quickly by giving you the option of using the AWS SSO built-in identity store or your own IdP, such as AWS Managed Microsoft AD or an external SAML 2.0 compliant IdP. We will use the AWS SSO built-in identity store. The identity source can be changed later on as your requirements change.</p>\n<p>Before we create an identity in AWS SSO, we’ll turn on multi-factor authentication, which supports both security keys and mobile authenticator apps.</p>\n<p><strong>How to turn on multi-factor authentication:</strong></p>\n<ol>\n<li>Select <strong>Settings</strong>, and in the Multi-factor authentication section, select <strong>Configure</strong>.</li>\n<li>Under the Users should be prompted for MFA section, select <strong>Every time they sign in (always-on)</strong>.</li>\n<li>Under Users can authenticate with these MFA types, make sure the check box for <strong>Authenticator apps</strong> is selected.</li>\n<li>Lastly, in the section titled If a user does not yet have a registered MFA device, select the option <strong>Require them to register an MFA device at sign in</strong>.</li>\n<li>Select <strong>Save changes</strong>.</li>\n</ol>\n<p><img src=\"https://dev-media.amazoncloud.cn/29d6ec8b74e34e2dbbf395f975913552_image.png\" alt=\"image.png\" /></p>\n<p><strong>AWS SSO user configuration</strong></p>\n<p>Now we’ll create a group for EKS cluster administration, associate the group with our member account <strong>EKS-Account-…</strong>, grant permissions, and add a new user to the group. Using groups in AWS SSO simplifies role-based access control (RBAC). In the steps below, we create a least-privilege IAM policy that grants view-only for key AWS resources, full access to EKS resources, and the ability to assume a special role we will use to create the cluster.</p>\n<ol>\n<li>\n<p>Select <strong>Groups</strong> and then the <strong>Create group</strong> button. Type “EKS_Cluster_Admins“ and select <strong>Create</strong>.</p>\n</li>\n<li>\n<p>Select <strong>AWS accounts</strong>, then <strong>EKS-Account-…</strong>, and <strong>Assign Users</strong>. Select the <strong>Groups</strong> tab, select <strong>EKS_Cluster_Admins</strong>, and select <strong>Next: Permission sets</strong>.</p>\n</li>\n<li>\n<p>Select Create new permission set, which will open a new browser tab.</p>\n</li>\n<li>\n<p>In the Create new permission set window, select Create a custom permission set, then Next: Details.</p>\n</li>\n</ol>\n<ul>\n<li>In the <strong>Create a custom permission set</strong> window, create a permission set called “EKSClusterAdminAccess.”</li>\n<li>Enter <strong>Relay state</strong> “<a href=\"https://console.aws.amazon.com/eks\" target=\"_blank\">https://console.aws.amazon.com/eks</a>” to redirect SSO users associated with this permission set to the EKS console (optional).</li>\n<li>Select both <strong>Attach AWS managed policies</strong> and <strong>Create a custom permissions policy</strong>.</li>\n<li>Search for and select the “ViewOnlyAccess” AWS managed policy.</li>\n<li>Paste the JSON code block below into the <strong>Create a custom permissions policy</strong> window (as demonstrated in the next screenshot).</li>\n<li>Select <strong>Next: Tags</strong>, then <strong>Next: Review</strong> and <strong>Create</strong>.</li>\n</ul>\n<pre><code class=\"lang-\">{\n&quot;Version&quot;: &quot;2012-10-17&quot;,\n&quot;Statement&quot;: [\n {\n &quot;Effect&quot;: &quot;Allow&quot;,\n &quot;Action&quot;: [\n &quot;eks:*&quot;,\n &quot;sts:AssumeRole&quot;\n ],\n &quot;Resource&quot;: &quot;*&quot;\n }\n ]\n}\n</code></pre>\n<p><img src=\"https://dev-media.amazoncloud.cn/f3ee1432c6be47c6a599cffff9fd68fc_image.png\" alt=\"image.png\" /></p>\n<ol start=\"5\">\n<li>\n<p>Back on the <strong>Select permission sets</strong> window, select the refresh arrows, and select the new <strong>EKSClusterAdminAccess</strong> permission set, and select <strong>Finish</strong>. Once your account is configured, select <strong>Proceed to AWS Accounts</strong>.</p>\n</li>\n<li>\n<p>Select <strong>Users</strong>, then <strong>Add User</strong>, and type “eksadmin”.</p>\n</li>\n</ol>\n<ul>\n<li>In the <strong>Password</strong> section, select <strong>Send an email to the user…</strong>, enter and confirm your email address, and then enter first, last, and display names.</li>\n<li>Select <strong>Next: Groups</strong>. Select <strong>EKS_Cluster_Admins</strong> and select <strong>Add User</strong>.</li>\n<li>Note that your username is case-sensitive.</li>\n</ul>\n<p><img src=\"https://dev-media.amazoncloud.cn/e8c2fedaf37d4503b809ce81990d3a7e_image.png\" alt=\"image.png\" /></p>\n<p>When you receive the Invitation to <em>join AWS Single Sign-On</em> message in your inbox, select the Accept Invitation button, which brings you to the <strong>New user sign up</strong> window.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/0e09e4df1f414b5dbfcbdc932a7368b4_image.png\" alt=\"image.png\" /></p>\n<p>Enter and confirm your new password. As you type, password length and complexity requirements appear to the right, providing guidance as you satisfy those requirements. Once you select <strong>Set new password</strong>, you’ll be redirected to the AWS SSO sign-in page.</p>\n<p><strong>Note:</strong> If you have an existing AWS SSO session, make sure to sign out before continuing.</p>\n<p>Sign in with your new credentials, and you’ll be prompted to set up multi-factor authentication. We are using Twilio Authy, but <a href=\"https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-types-apps.html\" target=\"_blank\">AWS SSO supports several popular physical security key and smartphone authenticator apps</a> such as Google Authenticator and Yubikey. Open or install your desired authentication app on your smartphone. Go back to the MFA setup on the SSO sign-in page, select <strong>Authenticator app</strong>, select <strong>Next</strong>, and select <strong>Show QR code</strong>. Scan the QR code with your phone and enter the numeric code from your app to complete the new user setup.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/7e5b6758b7f5498ca9cc06e4d068c702_image.png\" alt=\"image.png\" /></p>\n<p><img src=\"https://dev-media.amazoncloud.cn/fa22e21b38594f66bc84bbfd83a9efc8_image.png\" alt=\"image.png\" /></p>\n<p><img src=\"https://dev-media.amazoncloud.cn/0d03fac6a6ab4ceca391bbf7ff36acb2_image.png\" alt=\"image.png\" /></p>\n<p>Once you select <strong>Done</strong>, you will be redirected to the SSO account selection page, which will include the “EKS-Account-…” account you associated with the EKS_Cluster_Admins group earlier. Expand that account, select the <strong>EKSClusterAdminAccess</strong> role, and you are directed to the EKS service page of the AWS Management Console.</p>\n<p>So far, we’ve created an organization and added an additional account with only two lines of code. Then we set up AWS Single Sign-on, created a group, and assigned that group to the new account with a least-privilege permission set related to the group’s job role. Finally, we added a new user to that group, set up MFA, and signed in to SSO as that user. If you wanted to use AWS Managed Active Directory or a third-party IdP such as Okta, you could federate those identity providers with AWS Single Sign-on and use those providers’ user identities instead of creating AWS SSO users such as “eksadmin.” All other steps would remain the same.</p>\n<h3><a id=\"Set_up_CLI_with_SSO_access_to_EKS_157\"></a><strong>Set up CLI with SSO access to EKS</strong></h3>\n<p>To simplify using SSO with the AWS CLI, AWS Single Sign-on provides an aws sso login command that integrates with AWS configuration profiles. To set that up, open your command-line terminal with the latest version of the AWS CLI installed and configured.</p>\n<p><strong>Automatically create a named SSO profile</strong></p>\n<p><code>aws configure sso</code></p>\n<p>Supply the following values:</p>\n<ul>\n<li><code>sso_start_url</code> – “User portal URL” you copied earlier from the <a href=\"https://console.aws.amazon.com/singlesignon\" target=\"_blank\">SSO management dashboard</a></li>\n<li><code>sso_region</code> – the Region where SSO was originally deployed and is currently managed</li>\n</ul>\n<p>When the browser window opens requesting your authorization, select Allow, and return to the CLI, which will guide you through selecting an account, a role, a default region for issuing commands, and output format. Assuming your browser has an authenticated AWS SSO session for the “eksadmin“ SSO user, you will only be offered accounts and roles associated with that user. When creating a profile name, select a name that you can easily remember for future reference since you must include <code>--profile {profile_name}</code> to issue CLI commands under that profile. In this example, we’re naming the profile “EKSClusterAdminAccess-EKSAccount1”.</p>\n<p>Your SSO configuration session will resemble the following sample output.</p>\n<pre><code class=\"lang-\">$ aws configure sso\nSSO start URL [None]: https://{hostname}.awsapps.com/start \nSSO Region [None]: us-east-1 \nThe only AWS account available to you is: 111222333444\nUsing the account ID 111222333444\nThe only role available to you is: EKSClusterAdminAccess\nUsing the role name &quot;EKSClusterAdminAccess&quot;\nCLI default client Region [None]: us-east-1 \nCLI default output format [None]: json \nCLI profile name [EKSClusterAdminAccess-111222333444]: EKSClusterAdminAccess-EKSAccount1\n</code></pre>\n<p>Once you create the SSO profile, you can use the command <code>aws sso login</code> in the future, which will open a browser window prompting you for credentials. Before proceeding, check your current identity:</p>\n<pre><code class=\"lang-\">aws sts get-caller-identity --profile EKSClusterAdminAccess-EKSAccount1\n</code></pre>\n<p>You should encounter something like:</p>\n<pre><code class=\"lang-\">{\n &quot;UserId&quot;: &quot;AZORYH847HJYD98SU:eksadmin&quot;,\n &quot;Account&quot;: &quot;111222333444&quot;,\n &quot;Arn&quot;: &quot;arn:aws:sts::111222333444:assumed-role/AWSReservedSSO_EKSClusterAdminAccess_4ffa4321e413c0b0/eksadmin&quot;\n}\n</code></pre>\n<p>Before we create an EKS cluster in our new account and associate your AWS SSO identity with a Kubernetes cluster role, we’ll create a special IAM role for the creation of your new EKS cluster. (As a trade-off between security and simplicity, this role permits all actions for a limited set of AWS services directly involved in cluster creation. For more stringent least-privilege scenarios, you may use services such as AWS IAM Access Analyzer to <a href=\"https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/\" target=\"_blank\">build a role based on actual CloudTrail access logs</a>.)</p>\n<h4><a id=\"Create_IAM_EKSClusterCreator_role_206\"></a><strong>Create IAM EKSClusterCreator role</strong></h4>\n<p>When you create an EKS cluster, the user or role you use will inherit cluster administrator permissions. This identity principal retains cluster admin permissions for the life of the cluster and should be kept secure. It is best practice to create additional roles to delegate routine operational tasks while keeping the cluster creator role separate and secure. If you forget the name of that principal, it can be retrieved or changed by AWS Support for a limited time, or you can recreate the IAM principal if you remember the user or role name.</p>\n<p>In the CLI code snippets below, your account number and SSO role name are extracted from your current SSO session and used to grant access to your AWS SSO group to assume the new EKSClusterCreator role. You will use that role to create a new EKS cluster using the eksctl command line tool.</p>\n<p><strong>Get current role and account to create the cluster creator policy</strong></p>\n<pre><code class=\"lang-\">ssorole=$(aws sts get-caller-identity --query Arn --output text --profile EKSClusterAdminAccess-EKSAccount1 | cut -d/ -f2)\naccount=$(aws sts get-caller-identity --query Account --output text --profile EKSClusterAdminAccess-EKSAccount1)\necho $ssorole $account\n</code></pre>\n<p><strong>Create a JSON file for the IAM cluster creator role trust policy</strong></p>\n<pre><code class=\"lang-\">cat &lt;&lt;EOF &gt; assume-role.json\n{\n &quot;Version&quot;: &quot;2012-10-17&quot;,\n &quot;Statement&quot;: [\n {\n &quot;Effect&quot;: &quot;Allow&quot;,\n &quot;Principal&quot;: {\n &quot;AWS&quot;: &quot;arn:aws:iam::${account}:role/aws-reserved/sso.amazonaws.com/${ssorole}&quot;\n },\n &quot;Action&quot;: &quot;sts:AssumeRole&quot;,\n &quot;Condition&quot;: {}\n }\n ]\n}\nEOF\n</code></pre>\n<p><strong>Note:</strong> If you configure SSO in a Region other than us-east-1, add the Region after “sso.amazonaws.com”. For example, for us-east-2, “…/<a href=\"http://sso.amazoznaws.com/us-east-2/...\" target=\"_blank\">sso.amazonaws.com/us-east-2/…</a>”.</p>\n<p><strong>Create a JSON file for the IAM cluster creator role permissions policy</strong></p>\n<pre><code class=\"lang-\">cat &lt;&lt;EOF &gt; clustercreator-policy.json\n{\n &quot;Version&quot;: &quot;2012-10-17&quot;,\n &quot;Statement&quot;: [\n {\n &quot;Effect&quot;: &quot;Allow&quot;,\n &quot;Action&quot;: [\n &quot;eks:*&quot;,\n &quot;iam:*&quot;,\n &quot;cloudformation:*&quot;,\n &quot;ec2:*&quot;,\n &quot;autoscaling:*&quot;,\n &quot;ssm:*&quot;,\n &quot;kms:*&quot;,\n &quot;sts:GetCallerIdentity&quot;\n ],\n &quot;Resource&quot;: &quot;*&quot;\n }\n ]\n}\nEOF\n</code></pre>\n<p>Even though the cluster creator role requires elevated permissions to create all of the EKS cluster resources, those permissions are only a subset of full AWS AdministratorAccess policy permissions. For simplicity, we will create a policy that allows all API actions for only the AWS services involved in cluster creation.</p>\n<p>To create the IAM policy and role in the EKS-Account, we will temporarily assume the OrganizationAccountAccessRole that is created for all AWS Organizations member accounts. This feature of AWS Organizations offers a customizable level of centralized administrator access across the organization.</p>\n<p><strong>Assume the OrganizationAccountAccessRole to create the EKSClusterCreator role</strong></p>\n<pre><code class=\"lang-\">adminrolearn=&quot;arn:aws:iam::${account}:role/OrganizationAccountAccessRole&quot;\ncreds=$(aws sts assume-role --role-arn ${adminrolearn} --role-session-name &quot;adminSession-CreateEKSCreatorRole&quot; --query 'Credentials.[{AWS_ACCESS_KEY_ID: AccessKeyId}, {AWS_SESSION_TOKEN: SessionToken}, {AWS_SECRET_ACCESS_KEY: SecretAccessKey}]' | jq -r .[] | sed 's/{//;s/}//;s/&quot;//g;s/ AWS_ACCESS_KEY_ID: /export AWS_ACCESS_KEY_ID=/;s/ AWS_SESSION_TOKEN: /export AWS_SESSION_TOKEN=/;s/ AWS_SECRET_ACCESS_KEY: /export AWS_SECRET_ACCESS_KEY=/')\neval ${creds}\n</code></pre>\n<p>Now when you enter <code>aws sts get-caller-identity</code>, you will see that we’ve assumed the OrganizationalAccountAccessRole. The previous script assumes that role and creates environment variables that set your default AWS CLI credentials until you change or unset the AWS_ACCESS_KEY_ID variable or specify an AWS configuration profile.</p>\n<p><strong>Create a cluster creator role and attach the policy</strong></p>\n<pre><code class=\"lang-\">aws iam create-role --role-name EKSClusterCreator --assume-role-policy-document file://assume-role.json\naws iam create-policy --policy-name EKSClusterCreatorPolicy --policy-document file://clustercreator-policy.json\naws iam attach-role-policy --policy-arn arn:aws:iam::${account}:policy/EKSClusterCreatorPolicy --role-name EKSClusterCreator\n</code></pre>\n<p><strong>Assume the role and apply new temporary credentials</strong></p>\n<pre><code class=\"lang-\">rolearn=&quot;arn:aws:iam::${account}:role/EKSClusterCreator&quot;\n\ncreds=$(aws sts assume-role --role-arn ${rolearn} \\\n --role-session-name &quot;create-eks-cluster&quot; \\\n --query 'Credentials.[{AWS_ACCESS_KEY_ID: AccessKeyId}, {AWS_SESSION_TOKEN: SessionToken}, {AWS_SECRET_ACCESS_KEY: SecretAccessKey}]' \\\n --profile EKSClusterAdminAccess-EKSAccount1 | jq -r .[] | sed 's/{//;s/}//;s/&quot;//g;s/ AWS_ACCESS_KEY_ID: /export AWS_ACCESS_KEY_ID=/;s/ AWS_SESSION_TOKEN: /export AWS_SESSION_TOKEN=/;s/ AWS_SECRET_ACCESS_KEY: /export AWS_SECRET_ACCESS_KEY=/')\n\neval ${creds}\n</code></pre>\n<p>Now that we have created our special EKSClusterCreator role, assumed that role in our command-line interface, and reset our environment variables, we are now ready to create our EKS cluster. Once created, we’ll use the eksctl utility to grant access to our EKSClusterAdminAccess role to the new EKS cluster.</p>\n<h4><a id=\"Create_EKS_cluster_305\"></a><strong>Create EKS cluster</strong></h4>\n<p><strong>Create a new EKS cluster and managed nodegroup in a new VPC with default settings</strong></p>\n<p><code>eksctl create cluster</code></p>\n<p><strong>Note:</strong> By default, EKS will update the active kubeconfig file. You can specify another kube config file by setting the KUBECONFIG environment variable as follows:</p>\n<p>export KUBECONFIG=~/.kube/config-ekssso-EKSClusterAdmin<br />\nDoing so will preserve your existing kube config file and create a new one when eksctl create cluster finishes.</p>\n<p>Cluster creation will take about 15–20 minutes. While you wait, you might read the eksctl documentation to see what happens behind the scenes and learn about additional configuration options. To build the cluster and related infrastructure, eksctl uses AWS CloudFormation. Note the cluster name and continue to the next section when cluster creation completes.</p>\n<h3><a id=\"Kubernetes_RBAC_and_IAM_federation_317\"></a><strong>Kubernetes RBAC and IAM federation</strong></h3>\n<p>EKS provides multiple methods for controlling access to clusters, including webhook token authentication, service account tokens, and OIDC authentication. AWS CLI version 2.x and later transparently generates bearer tokens for authenticating <code>kubectl</code> commands. The kube-apiserver uses an authentication webhook to validate the token signature and forward the token for authentication with AWS Security Token Service (AWS STS). Once authenticated, kube-apiserver looks for an IAM to Kubernetes RBAC identity mapping in the aws-auth ConfigMap, created by default in all EKS clusters. We will use the already-assumed EKSClusterCreator role to delegate EKS cluster admin rights to our EKSClusterAdminAccess role. First, we’ll grant access to the AWS SSO EKSClusterAdminAccess role using the Kubernetes default <code>cluster-admin</code> role. If you only have one EKS cluster in the Region you’re using for this exercise, you can enter the full code block shown below. Otherwise, manually set the “cluster” variable with the command <code>export cluster={cluster-name}</code>, using the cluster name shown in the last line of your <code>eksctl</code> cluster creation process, or by issuing the CLI command <code>aws eks list-clusters</code>.</p>\n<p><strong>Create aws-auth identity mapping for EKSClusterAdminAccess role</strong></p>\n<pre><code class=\"lang-\">cluster=$(aws eks list-clusters –query clusters –output text)\n\neksctl create iamidentitymapping \\\n --cluster ${cluster} \\\n --arn “arn:aws:iam::${account}:role/${ssorole}” \\\n --username cluster-admin \\\n --group system:masters \n</code></pre>\n<p><strong>View the new IAM to Kubernetes RBAC mapping by viewing<br />\nthe <code>aws-auth</code> ConfigMap in your EKS cluster</strong></p>\n<pre><code class=\"lang-\">kubectl get configmap -n kube-system aws-auth -o yaml \n</code></pre>\n<p>Your output will resemble the following:</p>\n<pre><code class=\"lang-\">apiVersion: v1\nkind: ConfigMap\nmetadata:\n name: aws-auth\n namespace: kube-system\ndata:\n mapRoles: |\n - groups:\n - system:bootstrappers\n - system:nodes\n rolearn: arn:aws:iam::111222333444:role/eksctl-fabulous-wardrobe-16446157-NodeInstanceRole-L7A7NXU3DSJS\n username: system:node:{{EC2PrivateDNSName}}\n - groups:\n - system:masters\n rolearn: arn:aws:iam::111222333444:role/AWSReservedSSO_EKSClusterAdminAccess_6a316cc66d154241\n username: cluster-admin\n</code></pre>\n<p>By running the <code>eksctl create iamidentitymapping</code> command, we mapped our SSO permission set “EKSClusterAdminAccess” to the Kubernetes default <code>cluster-admin</code> role. The other entry, <code>system:node:{{EC2PrivateDNSName}}</code>, is mapped to the EKS nodegroup instance profile role <code>eksctl-fabulous-wardrobe-16446157-NodeInstanceRole-L7A7NXU3DSJS</code>, which grants each node’s kubelet <code>system:bootstrappers</code> and <code>system:nodes</code> permission inside the cluster. This nodegroup mapping is created each time a new nodegroup is created. Notice that there is no mention of the EKSClusterCreator role in the aws-auth ConfigMap. This identity principal retains cluster admin permissions for the life of the cluster and should be kept secure per the <a href=\"https://aws.github.io/aws-eks-best-practices/\" target=\"_blank\">EKS Security Best Practices Guide</a>.</p>\n<p>Kubectl requires a configuration file entry to define the cluster, Region, identity, and authentication method for <code>kubectl</code> commands. You can generate that configuration for your EKSClusterAdminAccess role as follows.</p>\n<p><strong>Create kubeconfig to begin using the EKSClusterAdminAccess role</strong></p>\n<pre><code class=\"lang-\">aws eks update-kubeconfig --name ${cluster} \\\n--profile EKSClusterAdminAccess-EKSAccount1\n</code></pre>\n<p><strong>Note:</strong> If you receive a “No cluster found for name” error, append <code>--region {cluster region}</code> to the above code block, where <code>{cluster region}</code> is the Region where you created your EKS cluster.</p>\n<p>Let’s test access to our EKS cluster. The output will list your worker nodes.</p>\n<p><code>kubectl get nodes</code></p>\n<p>Now that we have an AWS SSO role for EKS cluster admins mapped to a native Kubernetes <code>cluster-admin</code> role, we can create additional least-privilege roles (scoped by Kubernetes namespace) or cluster-wide <code>clusterroles</code> mapped to new AWS SSO permission sets using <code>eksctl</code> IAM identity mappings in the <code>aws-auth</code> ConfigMap.</p>\n<h3><a id=\"Conclusion_379\"></a><strong>Conclusion</strong></h3>\n<p>In this blog, we walked you through setting up an organization and AWS Single Sign-on. We created a user, group, and role (also called permission set) associated with a new account for our EKS cluster. We also created a special role for creating our new EKS cluster, and we used that special role to map our AWS SSO role to a Kubernetes native RBAC <code>cluster-admin</code> role. With the exception of the AWS SSO configuration, all other tasks were completed using AWS CLI commands, an example of repeatable infrastructure as code.</p>\n<p><strong>Related blogs and documentation</strong></p>\n<ul>\n<li><a href=\"https://kubernetes.io/docs/reference/access-authn-authz/rbac/\" target=\"_blank\">Using Kubernetes Role-based Access Control Authorization</a></li>\n<li><a href=\"https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html\" target=\"_blank\">Manage AWS Single Sign-on identity source</a></li>\n<li><a href=\"https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html\" target=\"_blank\">Enabling IAM user and role access to your cluster</a></li>\n<li><a href=\"https://docs.aws.amazon.com/eks/latest/userguide/authenticate-oidc-identity-provider.html\" target=\"_blank\">Authenticating users for your cluster from an OpenID Connect identity provider</a></li>\n</ul>\n<p><img src=\"https://dev-media.amazoncloud.cn/12dd6c9c4881463e840c9d7084c14918_image.png\" alt=\"image.png\" /></p>\n<p><strong>Juan Lamadrid</strong></p>\n<p>Juan Lamadrid is a New York-based Solutions Architect for AWS. He works with numerous enterprise customers helping them achieve their digital innovation and modernization goals.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/9b62e548916f447298e1b6ed8a47d4ae_image.png\" alt=\"image.png\" /></p>\n<p><strong>Rob Solomon</strong></p>\n<p>Rob Solomon is a Solutions Architect at Amazon Web Services helping ISV companies leverage AWS to accelerate growth and innovation. In previous roles, he experienced firsthand the challenges SaaS companies face making the transition from datacenter to cloud architecture and operations. Joining AWS has been a great opportunity to help companies be successful on their cloud journey.</p>\n"}