AWS mới release một tính năng mới cho EKS: Pod Identity, vậy tính năng này có điểm gì nổi bật ?
Trước khi bắt đầu, ta cùng nhắc lại một chút về cách ta tương tác với các AWS services từ trong EKS Pod:
- Cách 1: tạo static user và lấy access/secret key -> Cách này nhanh nhất, đơn giản nhất, tuy nhiên có các vấn đề về security nghiêm trọng: Token longlive, nếu bị lộ ra ai cũng có thể sử dụng được. Nếu distribute trong nhiều hệ thống, việc replace/rotate là cực hình
- Cách 2: assign role vào worker node: theo cách này bạn tạo policy/role và attach vào worker template, như vậy sẽ tận dụng được AWS STS Endpoint và get về temporary token mỗi lần call, fix được lỗ hổng so với cách đầu tiên (không cần longlived token). Tuy nhiên lại có nhược điểm khác: vì role được gán cho worker node -> toàn bộ các Pod khác cùng nằm trên worker node đó đều có thể sử dụng role đó và có đủ quyền tương tác với các AWS services
- Cách 3: IAM Roles for Service Accounts (IRSA): EKS cần enable OIDC Provider và trusted trong AWS IdP, sau đó các IAM role sẽ cần tạo trusted condition tới EKS serviceaccount, cuối cùng là đánh thêm annotation cho service account và gán serviceaccount cho Pod. Bằng cách chúng ta fine grained control access của IAM Role tới Pod level. Tuy nhiên, nhược điểm là việc setup khá phức tạp, ngoài các thay đổi ở ngoài EKS cluster (roles, trusted OIDC Provider,…) chúng ta còn cần sửa đổi annotation của các serviceaccount. Đồng thời, khi nhiều EKS cluster tồn tại trong cùng 1 account sẽ ngày càng phức tạp và có giới hạn từ phía AWS
| Phương pháp | Cơ chế hoạt động | Ưu điểm | Nhược điểm & Rủi ro |
| Cách 1: Static User | Tạo IAM User, lấy Access Key & Secret Key và cấu hình trực tiếp vào ứng dụng/container. | • Nhanh nhất.
• Đơn giản, dễ thực hiện. | • Bảo mật kém: Sử dụng Long-lived token (nếu lộ key, ai cũng dùng được).
• Khó vận hành: Việc thay thế (rotate) key khi phân phối trên nhiều hệ thống rất phức tạp và tốn công. |
| Cách 2: IAM Role cho Worker Node | Tạo IAM Role/Policy và gắn (attach) vào Worker Node (EC2 Instance Profile). Sử dụng AWS STS để lấy token. | • An toàn hơn Cách 1: Sử dụng Temporary token (token tạm thời), không còn lo ngại về long-lived credential. | • Vi phạm nguyên tắc đặc quyền tối thiểu (Least Privilege): Vì role gắn vào Node, nên tất cả các Pod chạy trên Node đó đều có quyền sử dụng Role này, dẫn đến rủi ro bảo mật lớn nếu một Pod bị xâm nhập. |
| Cách 3: IRSA (IAM Roles for Service Accounts) | Kết hợp OIDC Provider, AWS IAM Trust Policy và Kubernetes Service Account (thông qua Annotation). | • Bảo mật cao nhất: Kiểm soát quyền truy cập chi tiết đến cấp độ Pod (Fine-grained control).
• Tuân thủ nguyên tắc Least Privilege. | • Cấu hình phức tạp: Cần thiết lập nhiều thành phần (OIDC, Trust relationship, K8s Service Account…).
• Khó mở rộng: Phức tạp khi quản lý nhiều cluster trong cùng 1 account, có thể chạm giới hạn (limits) từ phía AWS. |
Và đó là lý do AWS cho ra mắt EKS Pod Identity
- Bên trên là mô hình hoạt động của Pod Identity, để có thể enable Pod Identity cho EKS cluster của bạn, cần cài đặt Pod Identity Agent addon:
- Lúc này một Daemonset Pod Identity sẽ setup pod running ở toàn bộ các worker VÀ inject thêm Pod Identity Webhook
- Sau đó bạn cần tạo PodIdentity Associcate (qua console, api…) attach vào service account: example
aws eks create-pod-identity-association \ --cluster-name your-cluster \ --namespace default \ --service-account pod-service-account \ --role-arn arn:aws:iam::012345678901:role/YourPodRole{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": ["sts:AssumeRole","sts:TagSession"] }] } - Khi một Pod được khởi tạo, Pod Identity Webhook sẽ sửa đổi spec của Pod bằng cách inject thêm các biến env
<span>env: - name: AWS_STS_REGIONAL_ENDPOINTS value: regional - name: AWS_DEFAULT_REGION value: us-east-1 - name: AWS_REGION value: us-east-1 - name: AWS_CONTAINER_CREDENTIALS_FULL_URI value: http://169.254.170.23/v1/credentials #local-link interface - pod-identity-agent listen ở hostNetwork - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE value: /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-id</span> - Khi đó AWS SDK chạy trong Pod sẽ detect được và call sang PodIdentity Agent, PodIdentityAgent sẽ call tới EKS Auth API để validate và trả lại temporary token
- Cuối cùng, SDK sẽ sử dụng token vừa lấy được access vào các AWS Services
Bổ sung, sự khác nhau giữa Pod Identity và IRSA:
| Feature | EKS Pod Identity | IRSA |
|---|---|---|
| Role Extensibility | No need to update the role’s trust policy for each new cluster. | Need to update role’s trust policy with new EKS cluster OIDC provider endpoint. |
| Cluster Scalability | No need to setup IAM OIDC provider. | Need to setup IAM OIDC provider. Default global limit of 100 OIDC providers for AWS account applies. |
| Role Scalability | No need to define trust relationship between IAM role and service account in the trust policy. | Need to define trust relationship between IAM role and service account in the trust policy. Max of 8 trust relationships within a single trust policy applies due to limit on trust policy size. |
| Role Reusability | AWS STS temporary credentials supplied by EKS Pod Identity include role session tags, such as cluster name, namespace, service account name. | AWS STS session tags are not supported. You can reuse a role between clusters but every pod receives all of the permissions of the role. |
| Environments Supported | Only available on Amazon EKS. | IRSA can be used with Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS, and self-managed Kubernetes clusters on Amazon EC2 instances. |
| EKS Versions Supported | EKS Kubernetes versions 1.24 or later. | All of the supported EKS cluster versions. |
