How to use AWS Federated Identities with Amazon EKS

Identity and Access Management is a crucial component of Amazon Web Services. It handles the management of user identities and credentials throughout Amazon’s cloud ecosystem. IAM isn’t just useful for managing access to EC2 instances. It can actually be integrated to control access to other Amazon services, including specific tools like Amazon Elastic Kubernetes Service (Amazon EKS) and CloudWatch.

IAM’s support for external identity providers is one of its strongest suits. It turns AWS IAM into a comprehensive tool for managing access to all the AWS resources and services that you leverage. It also means you can create federated identities for use with a wide range of AWS services.

About AWS Federated Identities

Before we get to federated identities, it is important to understand why IAM supporting external identity providers is a big thing. A lot of organizations already use external tools to manage their user identities. Identity Providers, or IdP, that are already integrated into existing systems often hamper the transition to cloud apps, especially when manual identity creation is needed.

You may also enjoy: An Introduction to AWS IAM

External identities used across multiple systems are also more practical. Forcing users to create a separate identity for managing AWS resources in the organization’s account would be a big mistake for Amazon, hence the support for external identities.

There are two primary IdPs supported by IAM: OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) 2.0. OIDC is an identity layer running on top of OAuth 2.0 protocol. It is a refinement of OpenID 2.0 with improved support for APIs and better identity management features.

SAML 2.0, on the other hand, governs a more specific set of security requirements for identities, including details such as metadata clarifications and authentication procedures. As a standard backed by OASIS, SAML 2.0 is used by many organizations.

The two external identity standards have different characteristics, but both work seamlessly with IAM. Instead of creating new users for those with OIDC or SAML IDs, you can have AWS IAM confirm identities and automatically create federated users.

Temporary Security Credentials

Keep in mind that, in principle, federated users are still seen as temporary users. Access to AWS features and resources are granted to external identities on a temporary basis, although you maintain the option to allow users access for a longer period of time.

Identities are granted access based on the policies assigned to them. When used with services like Amazon EKS, this is the only approach available; resource-based policies are not supported by Amazon EKS at the moment.

That’s not a bad thing though. Using identity-based policies, you can be very detailed in how you grant access to EKS resources. Not only will you be able to define when to allow (or deny) access to resources, you can also specify actions to take when access is granted or denied.

Federated Users for EKS

Let’s not forget that Kubernetes also use service accounts as part of its internal identity system. ProjectedServiceAccountToken adds support for OIDC JSON web tokens and is very configurable. Combine it with the integration of IAM with EKS, and you have an extensive set of features, nonetheless.

To configure federated users for EKS, you want to begin with creating an IAM role for the cluster you want to manage. Attaching the IAM policy to the service account or an entire namespace depending on what you want to achieve.

Once the OIDC provider is configured and policies are set, you can continue adding service account configurations to the cluster. The  kind: ServiceAccount argument paired with the role-arn annotation should do the trick.

The configurations let you set access to service accounts all the way to individual pods.  AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME added to the environment variables of your pods completes the process.

In most cases, you also need to update the ConfigMap of your Kubernetes instance. You need to configure the ConfigMap to allow access to IAM users and roles for security purposes. Once this is completed, you can manage user and service access from IAM or as a variable to be added to the cluster.

Amazon EKS IAM Roles at Work

When configured properly, Amazon EKS instances can store user tokens collected from identity brokers. When users access an API or try to gain access to EKS resources, a security token is automatically generated and stored. The same tokens are used to verify API calls from inside and outside the cluster.

Of course, there are things you can do to sufficiently secure the cloud environment when federated users are actively using the system. First, always remember that users who created an EKS instance—including federated users—are always granted system:masters permissions for that system. Further modifications to user roles and policies are usually required.

You can still benefit from AWS Managed Policies when managing federated users. The policies are defined based on cloud security best practices, giving you a solid starting point. Managed Policies are easier to maintain too since AWS does most of the heavy lifting for you.

Granting privileges is an approach that still needs to be enforced when managing federated users. When custom policies are created, the least amount of privileges needs to be the standard to aim for. Granting permissions for actions and resources that are not absolutely necessary adds security risks.

Policy conditions are also useful for enhancing the security of your EKS instance. At the same time, you can use actions like  iam:GetUserPolicy and iam:ListUserPolicies to provide better transparency to users. The goal here is to keep user credentials functional without granting too much access.

That is the last tip to keep in mind. Now that you know how to integrate federated users and fully utilize AWS IAM with Amazon EKS, you can be more meticulous with how you manage access to services and resources.

Further Reading

The IAM Conundrum