Read Time 4 mins | Written by: Daoqi | Celeste Shao
Single Sign-On (SSO) is widely used in organizations and companies. In this article, we are going to talk about the best way to integrate SSO with EKS clusters, with the best EKS cluster authorization and security practices. AWS Identity and Access Management (IAM) and Kubernetes role-based access control (RBAC) provides the tools to build a strong least-privilege security posture. Single sign-on (SSO) as identity federation with a central identity provider (IdP) to improve security by allowing Devs and SecOps teams to manage a single set of credentials. When employees or contractors leave the organization, admins can disable a single account as well as associated k8s access. This can also simplify periodic compliance audits.
Best Practice
Create dedicated IAM policies and attach the policies to IAM roles through AWS CloudFormation or Terraform.
Why need this
Amazon EKS best practice suggests using IAM roles with Kubernetes RBAC to authorize users, however, in most production use cases companies use SSO with different identity providers. When users sign in through single sign-on, they’re essentially assuming the IAM role in the AWS account. If an IAM role is created to manage the Kubernetes cluster without any restrictions, then anyone that has access to the AWS account can assume that IAM role and has access to the cluster. This would cause many security issues. Let’s look at two examples using Okta and AWS SSO as identity providers.
Scenario 1 - SSO with Okta
AWS SSO with Okta is straightforward. We can create dedicated IAM roles for Amazon EKS and edit the trust policy to only allow users in Okta group to assume that IAM role. As shown in the following picture, the Okta identity provider is the only trust entity for the roles.
Scenario 2 - SSO with AWS SSO
AWS SSO with Azure AD is a bit more complicated. Users and groups are created in Azure AD and IAM permissions are assigned to users/groups through permission sets. A permission set is a template that you create and maintain that defines a collection of one or more IAM policies. Permission sets simplify the assignment of AWS account access for users and groups in your organization.
Specific IAM roles will be created with different permission sets and by assigning the permission set to different users/groups in the different accounts we can give the users the same access defined in the permission set. User signing in with SSO will have the ability to choose which role would like to use.
ASCENDING Approach
From the IAM role side, we will first create different EKS policies for different kinds of roles. For example - the EKS admin policy for cluster administrators allows almost all actions except creating new clusters(as we mentioned in previous best practice the best way to create a cluster is to use a specific role). Then we will attach the policies to different permission set that you want to give permissions to in IAM Identity Center or we can create new permission sets if needed.
From the k8s side, we will create different Roles/ClusterRoles and RoleBindings/ClusterRoleBindings to map the roles created in the AWS Identity center.
The IAM policies give permission to access Amazon EKS service. AWS permission sets attach the policies to roles. Kubernetes RABC gives the user access to the cluster’s internal elements.
In this way, only the AWS account Admin has the ability to assign EKS roles to users.
