Amazon Web Services has announced session policies for Amazon EKS Pod Identity, enabling fine-grained permission scoping without requiring the creation of additional IAM roles. The new capability addresses critical operational challenges for teams running multi-tenant workloads on Kubernetes, providing a flexible solution to permission management that respects AWS service quotas.
The Permission Challenge
Platform engineering teams managing multi-tenant EKS clusters often face difficult permission trade-offs that impact both security and operational efficiency. Common scenarios driving these challenges include software-as-a-service applications requiring tenant-specific access to resources, multiple environments (development, staging, production) running in shared clusters requiring isolation, or data processing workloads needing different S3 or DynamoDB permissions based on their specific function.
Historically, teams had to choose between creating separate IAM roles (risking account-wide quota limits at 5,000 roles), granting overly broad permissions that violate security principles and compliance requirements, or using session tags which remain unsupported by all AWS services. Session policies provide an elegant solution by allowing teams to specify inline IAM policies during Pod Identity association creation, dynamically scoping permissions to precisely what each pod requires.
How Session Policies Work
Session policies create a logical intersection between the permissions granted by an IAM role’s identity-based policy and the session policy itself. This restricts effective permissions to only what is explicitly allowed in both policies, strictly following the principle of least privilege without compromising operational agility.
The CreatePodIdentityAssociation and UpdatePodIdentityAssociation APIs now accept an optional policy parameter containing an IAM policy in JSON format, up to 2,048 characters in size. When specified, EKS Pod Identity applies this inline policy when assuming the role on behalf of pods, limiting effective permissions accordingly.
Implementation Architecture
Session policies support both same-account and cross-account access scenarios through role chaining. For cross-account access using role chaining with the targetRoleArn parameter, the session policy applies when assuming the target role rather than the initial source role. The source role requires appropriate sts:AssumeRole and sts:TagSession permissions to facilitate the chain.
Important constraints developers should note include the requirement to disable session tags when using session policies, a limitation stemming from AWS Security Token Service packed policy size restrictions. Session policies and session tags cannot be used in combination, requiring teams to choose the approach that best fits their specific use case.
Validation and Security Controls
EKS Pod Identity validates session policies during association creation and updates, providing immediate feedback on potential issues. Validation steps include JSON format verification, character validation for policy content, size limit enforcement at 2,048 characters, IAM policy schema validation through dry-run STS calls, and packed policy size verification against STS limits.
All session policy activity is recorded in AWS CloudTrail for comprehensive auditing and monitoring, maintaining security and compliance visibility across the organization. Security teams can track policy changes, identify potential privilege escalations, and generate reports for compliance purposes.
Availability and Tooling Support
Session policies are available in AWS Commercial regions, Mainland China regions, and GovCloud regions where Amazon EKS operates. The feature is compatible with all supported Kubernetes versions. Tooling support includes AWS CloudFormation templates, eksctl CLI integration, AWS CLI commands, and direct Amazon EKS API access.