Identity and Access Management for secure EKS implementation

Ever accidentally leave your house door wide open? Yeah, not a great feeling. That's what weak IAM is like for your digital space. IAM is a smart lock that ensures only the right people can access your data. Let's get into the details of IAM.

What is Identity and Access Management (IAM)?

AWS Identity and Access Management (IAM) is a robust service that provides secure control over access to AWS resources. It mainly focuses on enabling centralized permissions management, allowing users to control who is authenticated and authorized to access specific AWS resources. Users can administer and utilize resources without sharing passwords or access keys. Granular permissions empower users to grant different access levels for different resources, ensuring a fine-tuned control mechanism. Identity Access Management also provides secure access to AWS resources for applications running on Amazon EC2 instances, facilitating the secure provision of credentials.

Why IAM for Amazon EKS?

Safeguarding your Amazon Elastic Kubernetes Service (EKS) ensures containerized applications and infrastructure security, availability, and compliance. Protection against unauthorized access, mitigation of security vulnerabilities, and adherence to compliance requirements are paramount. Employing robust security measures is crucial for ensuring the smooth functioning of EKS while mitigating potential risks and threats.

Building upon our previous blog that discussed the Ten simple steps to secure your Amazon EKS, this blog delves into IAM's significance and how it fortifies EKS clusters. IAM is the central authority for defining permissions, ensuring only authorized entities interact with EKS clusters and associated resources securely and competently. From access control policies for EKS clusters to Role-Based Access Control (RBAC) integration, worker node empowerment, adherence to best practices, and the pivotal role of AWS CloudTrail, IAM's capabilities contribute to crafting a robust security posture for Amazon EKS. Also, access to IAM is flexible. It lets users interact with IAM through the AWS Management Console, AWS Command Line Tools, AWS SDKs for multiple programming languages, and the IAM Query API for programmatic access.

How IAM helps secure Amazon Kubernetes Service (EKS)

Here's how IAM contributes to securing Amazon EKS:

Access control to EKS clusters: IAM allows administrators to define policies that specify which identities (users, groups, or roles) have permission to interact with EKS clusters. These policies are based on the principle of least privilege, ensuring that entities only have the minimum necessary permissions to perform their tasks.
Role-Based Access Control (RBAC) integration: EKS leverages Kubernetes-native RBAC to control access to the Kubernetes API server. IAM roles can be mapped to Kubernetes roles, providing a unified mechanism for managing permissions within AWS and the Kubernetes cluster. This integration ensures consistency in access controls across the entire EKS environment.Worker node
IAM roles: IAM roles can be associated with worker nodes to grant them specific AWS permissions. This allows worker nodes to interact securely with other AWS services, such as accessing Amazon S3 buckets or utilizing Amazon RDS databases based on the defined IAM roles.
Security best practices: IAM in EKS adheres to security best practices, including the principle of least privilege, regularly reviewing and updating access policies, and enforcing secure authentication mechanisms. This ensures a robust security posture for the EKS environment.
Logging and monitoring with CloudTrail: IAM activities within EKS are logged through AWS CloudTrail. CloudTrail provides detailed logs, including information about resource requests made by IAM identities. This auditing capability enhances security monitoring, compliance, and incident response.
Multi-Factor Authentication (MFA) support: It also supports multi-factor authentication (MFA), adding an extra layer of security by requiring users to provide a code from a configured device in addition to a password or access key.

Therefore, Identity and Access Management is the central authority for access control and security policies, ensuring that only authorized entities can interact with the EKS clusters and associated resources securely and competently.

IAM policy best practices for Amazon EKS (Elastic Kubernetes Service):

Begin with AWS-managed policies for everyday use cases, as they provide predefined permissions and are available in your AWS account.
Move to least-privilege permissions and define customer-managed policies specific to your use cases for reduced permissions.
Apply for least-privilege permissions and grant only necessary permissions for tasks while defining actions on specific resources under specific conditions.
Use conditions in IAM policies to further restrict access. For example, Specify conditions like SSL usage or grant access to service actions only through specific AWS services (e.g., AWS CloudFormation).
Leverage IAM access analyzer to validate policies and ensure policies adhere to IAM policy language (JSON) and align with IAM best practices.
Add MFA conditions to policies if IAM users or the root user requires it.

These best practices will optimize security, minimize unnecessary permissions, and ensure adherence to AWS IAM policy language and guidelines.

Understanding AWS managed policies for IAM

AWS-managed policies are a cornerstone of AWS Identity and Access Management (IAM) and are purpose-built by AWS to streamline access control. These standalone policies are tailored to accommodate a wide array of everyday use cases, allowing users to swiftly allocate permissions to various entities such as users, groups, and roles within the AWS ecosystem. However, it's essential to note that while these policies offer a convenient starting point, they may not always align precisely with the specific security requirements of individual use cases. To address this, AWS recommends further refining permissions by defining customer-managed policies tailored to specific needs.

Several AWS-managed policies cater specifically to IAM Access Analyzer, a service designed to help users identify resources shared with external entities or publicly accessible. For instance, IAMReadOnlyAccess grants read-only access to IAM resources, IAMUserChangePassword facilitates IAM users in changing their passwords, and IAMAccessAnalyzerFullAccess enables administrators to access IAM Access Analyzer comprehensively. Additionally, IAMAccessAnalyzerReadOnlyAccess offers read-only access, while the AccessAnalyzerServiceRolePolicy is attached to a service-linked role, allowing IAM Access Analyzer to perform actions on behalf of users.

IAM Roles for Service Accounts

IAM roles for service accounts offer a means to manage credentials for applications, just like how Amazon EC2 instance profiles furnish credentials to EC2 instances. Rather than distributing AWS credentials to containers or relying on an Amazon EC2 instance's role, you can link an IAM role with a Kubernetes service account and configure your Pods accordingly. The containers within a Pod's applications have the option to utilize either an AWS SDK or the AWS CLI for making API requests to AWS services, all while adhering to AWS Identity and Access Management (IAM) permissions. It is imperative that applications properly authenticate their AWS API requests using AWS credentials. However, it's important to note that IAM roles for service accounts cannot be utilized with local clusters for Amazon EKS on AWS Outposts.

How to enable IAM Roles for Service Accounts (IRSA) on your EKS

To enable IAM Roles for Service Accounts (IRSA) on your EKS cluster, ensure that your cluster is running Amazon EKS version 1.14 or later. If your cluster was updated to version 1.13 or later after September 3rd, 2019, it should support this feature. You can confirm this by checking the OpenID Connect issuer URL associated with your cluster, which can be found in the Amazon EKS console or retrieved using the AWS CLI.

Step 1: To set up IAM roles for service accounts, you must create an OIDC identity provider for your cluster. You can do this using either eksctl or the AWS Management Console.

If using eksctl:

Check your eksctl version (must be 0.32.0 or later).
Create the OIDC identity provider for your cluster with the appropriate eksctl command, replacing "cluster_name" with your cluster's name.

If using the AWS Management Console:

Open the IAM console.
Navigate to Identity Providers and choose Create Provider.
Choose OpenID Connect as the provider type.
Paste the OIDC issuer URL for your cluster as the Provider URL.
Set the Audience to "sts.amazonaws.com" and proceed with the creation.

Step 2: To enable Pods within a Kubernetes cluster to access AWS services using IAM roles, you can configure a Kubernetes service account to assume an IAM role. Once configured, any Pods that are associated with this service account will inherit the permissions granted by the IAM role, allowing them to access any AWS service authorized by the role's permissions.

Step 3: To grant Pods access to AWS services, you need to configure them with a Kubernetes service account that is linked to an AWS Identity and Access Management (IAM) role. This IAM role should be configured with the necessary permissions to access the required AWS services.

Step 4: To use IAM roles for service accounts in Kubernetes Pods, ensure your containers utilize a compatible AWS SDK version. This allows automatic access to AWS services using IAM role credentials. Supported by various Kubernetes add-ons, this setup seamlessly integrates with the default credential chain, automatically exchanging OIDC tokens for temporary AWS credentials. The SDK facilitates rotation of these credentials to ensure uninterrupted access.

Advantages of IAM roles for service accounts

Least privilege: IAM permissions can be tailored to a specific service account, ensuring that only Pods associated with that service account possess access to those permissions. Consequently, there's no need for external solutions like kiam or kube2iam.
Credential isolation: Containers within a Pod are restricted to retrieving credentials solely for the IAM role linked with the service account they use. Each container remains isolated from credentials used by other containers in different Pods. When employing IAM roles for service accounts, containers within Pods also inherit permissions from the Amazon EKS node IAM role, unless access to the Amazon EC2 Instance Metadata Service (IMDS) is restricted. Additional details on this can be found in the documentation on restricting access to the instance profile assigned to the worker node.
Auditability: AWS CloudTrail facilitates access and event logging, enhancing retrospective auditing capabilities.

Secure your EKS with IAM

We've seen Identity and Access Management's (IAM) role in security and compliance. Your EKS environment deserves the fortification that IAM provides. Though complicated, proper guidance will help you implement IAM. Opcito's seasoned experts are just an email away. Write to us at contact@opcito.com, and we'll pave the way for your EKS security confidence.