bởi George John, Ashok Srirama, và Hemanth AVS | vào ngày 28 tháng 12 năm 2023 |

Giới thiệu

Tại AWS, chúng tôi liên tục cố gắng cải thiện trải nghiệm của khách hàng. Ví dụ, chúng tôi đã ra mắt IAM Roles for Service Accounts (IRSA) vào năm 2019, cho phép khách hàng cấu hình ứng dụng Kubernetes (k8s) chạy trên AWS với quyền quản lý AWS Identity and Access Management (AWS IAM) để truy cập các tài nguyên khác của AWS như Amazon Simple Storage Service (Amazon S3), bảng Amazon DynamoDB, và nhiều hơn nữa. Điều này cho phép khách hàng chạy nhiều ứng dụng trong cùng một cụm dịch vụ Amazon Elastic Kubernetes Service (Amazon EKS), đồng thời đảm bảo mỗi ứng dụng tuân theo nguyên tắc của tối thiểu quyền. IRSA được xây dựng để hỗ trợ các tùy chọn triển khai Kubernetes khác nhau được hỗ trợ bởi AWS như Amazon EKS trên điện toán đám mây, Amazon EKS Anywhere, Red Hat OpenShift Service trên AWS (ROSA), và các cụm tự quản lý trên các máy ảo Amazon Elastic Compute Cloud (Amazon EC2). Chúng tôi đã xây dựng IRSA sử dụng các khái niệm cơ bản được cung cấp bởi AWS IAM như OpenID Connect (OIDC) identity providers và IAM trust policy để thiết lập sự tin cậy giữa vai trò IAM và cụm dịch vụ Amazon EKS. Điều này đảm bảo IRSA có thể hoạt động trên môi trường mà không phụ thuộc trực tiếp vào dịch vụ hoặc API của Amazon EKS.

IRSA được sử dụng rộng rãi bởi khách hàng AWS, và chúng tôi dự định tiếp tục đầu tư và hỗ trợ IRSA. Nhưng chúng tôi đã nghe được từ khách hàng sử dụng Amazon EKS trên điện toán đám mây rằng họ mong muốn một trải nghiệm thiết lập quyền IAM cho ứng dụng của họ một cách thuận tiện hơn. Hầu hết những khách hàng này, thường là quản trị viên cụm, thường không có quyền quản trị IAM để tạo các OIDC providers hoặc cập nhật IAM trust policy, đó là các điều kiện tiên quyết cho IRSA. Họ phải phối hợp với quản trị viên IAM trong công ty của họ để thực hiện các bước cấu hình IRSA, điều này làm cho quá trình trở nên dài dòng và khó tự động hóa. Hơn nữa, quản trị viên cụm phải cập nhật IAM role trust policy mỗi khi vai trò được sử dụng trong một cụm mới trong các tình huống như nâng cấp blue-green hoặc kiểm thử chuyển đổi. Ngoài ra, khi khách hàng mở rộng phạm vi cụm EKS của họ, do yêu cầu cung cấp OIDC provider cho mỗi cụm trong IRSA, khách hàng gặp vấn đề với giới hạn OIDC provider cho mỗi tài khoản. Tương tự, khi họ mở rộng số lượng cụm hoặc các không gian tên Kubernetes mà một vai trò IAM được sử dụng, họ gặp vấn đề với giới hạn kích thước IAM trust policy, điều này khiến họ phải nhân bản các vai trò IAM để vượt qua giới hạn kích thước của IAM trust policy.

Tại sự kiện AWS reInvent 2023, chúng tôi đã ra mắt Amazon EKS Pod Identity để giải quyết những thách thức này. Amazon EKS Pod Identity sẽ hoạt động song song với IRSA và cung cấp cho khách hàng một giải pháp bổ sung để có được quyền IAM. Trong khi IRSA hoạt động trên các tùy chọn triển khai Kubernetes khác nhau bao gồm EKS trên điện toán đám mây, EKS Anywhere, cụm tự quản lý trên Amazon EC2, và ROSA. EKS Pod Identity được xây dựng đặc biệt cho EKS trên điện toán đám mây, được thiết kế để mang đến một trải nghiệm đơn giản hóa để có được quyền IAM cho khách hàng EKS. Trải nghiệm đơn giản hóa này là kết quả của việc giới thiệu một nguyên tắc dịch vụ EKS mới có thể được sử dụng để thiết lập sự tin cậy giữa các vai trò IAM và dịch vụ EKS, và giới thiệu các API mới trên EKS cho phép bạn thiết lập quyền mà không cần thực hiện các hoạt động IAM đặc quyền như thiết lập một OIDC identity provider. EKS Pod Identity cho phép chúng tôi triển khai các tính năng bổ sung không được hỗ trợ trong IRSA như hỗ trợ cho IAM role session tags. Role session tags cho phép quản trị viên IAM tạo một chính sách quyền đơn giản có thể hoạt động trên nhiều vai trò bằng cách cho phép truy cập vào các tài nguyên AWS dựa trên các nhãn khớp. Role session tags làm cho quyền truy cập trở nên trực quan và đơn giản hóa quản lý truy cập cho quản trị viên.

Hướng dẫn

Trong phần tiếp theo, chúng ta sẽ xem xét quy trình cấp cao của việc sử dụng Amazon EKS Pod Identity để cấu hình một vai trò AWS IAM để cấp quyền IAM cho các ứng dụng đang chạy trong cụm của bạn.

Tạo Vai Trò IAM:

1. Quản trị viên cụm Amazon EKS/IAM tạo một vai trò IAM có thể được giả định bởi các pod sử dụng nguyên tắc dịch vụ EKS mới được giới thiệu pods.eks.amazonaws.com. Chính sách tin cậy cho vai trò IAM sẽ giống như chính sách dưới đây. Theo tùy chọn, bạn có thể hạn chế việc sử dụng vai trò cho một số cụm EKS cụ thể bằng cách sử dụng một chuỗi điều kiện như được hiển thị dưới đây.

{

    “Version”: “2012-10-17”,

    “Statement”: [

        {

            “Effect”: “Allow”,

            “Principal”: {

                “Service”: “pods.eks.amazonaws.com”

            },

            “Action”: [

                “sts:AssumeRole”,

                “sts:TagSession”

            ],

            “Condition”: {

                “StringEquals”: {

                          “aws:SourceAccount”: “my-account-number”

                     },

                       “ArnEquals”: {

                         “aws:SourceArn”: “arn-of-my-eks-cluster”

                   }

                 }

           }

]

} 

2. Sau khi vai trò IAM AWS được tạo, quản trị viên cụm Amazon EKS tạo một liên kết giữa vai trò IAM và tài khoản dịch vụ Kubernetes. Bạn có thể tạo liên kết này bằng cách sử dụng API CreatePodIdentityAssociation mới. Chúng ta sẽ xem xét tất cả các API của EKS Pod Identity sau trong bài viết.

3. Sau khi vai trò IAM AWS được liên kết với tài khoản dịch vụ, bất kỳ pod mới nào được tạo bằng tài khoản dịch vụ đó sẽ bị chặn bởi webhook EKS Pod Identity. Webhook này chạy trên bảng điều khiển của cụm Amazon EKS và được quản lý đầy đủ bởi EKS. Webhook sửa đổi pod spec như được hiển thị dưới đây với các biến môi trường được in đậm. Tất cả các Software Development Kits (SDKs) của AWS có một loạt các vị trí (hoặc nguồn) mà nó kiểm tra để tìm thông tin xác thực hợp lệ để sử dụng trong việc gửi yêu cầu đến một dịch vụ AWS. Sau khi tìm thấy thông tin xác thực, quá trình tìm kiếm sẽ dừng lại. Quá trình tìm kiếm hệ thống này được gọi là chuỗi nguồn thông tin xác thực. Đối với EKS Pod Identity, chúng tôi tận dụng cơ chế cung cấp thông tin xác thực HTTP đã được tích hợp sẵn trong SDK và CLI của AWS để lấy thông tin xác thực từ một điểm cuối HTTP được chỉ định trong biến môi trường AWS_CONTAINER_CREDENTIALS_FULL_URI. Điểm cuối này được cung cấp bởi EKS Pod Identity Agent chạy trên nút worker, chúng ta sẽ thảo luận thêm về điều này trong bước tiếp theo. Địa điểm của token JWT được chiếu để đổi lấy thông tin xác thực IAM được chỉ định trong biến môi trường AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE.

• LƯU Ý: Ứng dụng của bạn nên sử dụng phiên bản mới hơn của AWS SDK hỗ trợ Amazon EKS Pod Identity. Vui lòng xem tài liệu EKS tại đây để biết danh sách các phiên bản SDK/CLI hỗ trợ EKS Pod Identity.

…

    env:

    – name: AWS_STS_REGIONAL_ENDPOINTS

      value: regional

    – name: AWS_DEFAULT_REGION

      value: us-west-2

    – name: AWS_REGION

      value: us-west-2

    – name: AWS_CONTAINER_CREDENTIALS_FULL_URI

      value: http://169.254.170.23/v1/credentials

    – name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE

      value: /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

   …

    volumeMounts:

    – mountPath: /var/run/secrets/pods.eks.amazonaws.com/serviceaccount 

      name: eks-pod-identity-token 

      readOnly: true

  volumes:

  – name: eks-pod-identity-token 

    projected:

      defaultMode: 420

      sources:

      – serviceAccountToken:

          audience: pods.eks.amazonaws.com

          expirationSeconds: 86400

          path: eks-pod-identity-token

…

4. AWS SDK/CLI gọi đến điểm cuối của Amazon EKS Pod Identity Agent để lấy thông tin xác thực IAM tạm thời. EKS Pod Identity Agent chạy như một pod DaemonSet trên mỗi nút worker đủ điều kiện. Điều này là một Add-on của EKS và là một điều kiện tiên quyết để sử dụng tính năng EKS Pod Identity.

• EKS Pod Identity agent sẽ thực hiện ký SigV4 và thực hiện cuộc gọi đến EKS Auth API mới AssumeRoleForPodIdentity để đổi token được chiếu lấy được từ IAM credentials tạm thời, sau đó chúng được cung cấp cho pod.

• EKS Auth API (AssumeRoleForPodIdentity) giải mã token JWT và xác minh các liên kết vai trò với tài khoản dịch vụ. Sau khi xác minh thành công, EKS Auth API sẽ trả lại thông tin xác thực AWS tạm thời. Nó cũng sẽ thiết lập các nhãn phiên như kubernetes-namespace, kubernetes-service-account, eks-cluster-arn, eks-cluster-name, kubernetes-pod-name, kubernetes-pod-uid.

5. AWS SDKs sẽ sử dụng thông tin xác thực tạm thời đã được cung cấp để truy cập các tài nguyên AWS khác.

LƯU Ý: Amazon EKS Pod Identity agent chạy trong chế độ mạng máy chủ và nhận quyền từ chính sách quản lý arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy được gắn vào các nút worker.

Hình 1: Kiến trúc Amazon EKS Pod Identity cấp cao.

Các API của Amazon EKS Pod Identity

Dưới đây là danh sách các API mới được giới thiệu:

API Quản lý

CreatePodIdentityAssociation – Cuộc gọi API để tạo liên kết Amazon EKS Pod Identity giữa một tài khoản dịch vụ trong một cụm Amazon EKS và một vai trò IAM với EKS Pod Identity.

Các thông số bắt buộc:

• name – Tên của cụm để tạo liên kết.
• namespace – Tên của không gian tên Kubernetes bên trong cụm để tạo liên kết. Tài khoản dịch vụ Kubernetes và các pod sử dụng tài khoản dịch vụ này phải ở trong không gian tên này.
• roleArn – Amazon Resource Name (ARN) của vai trò AWS IAM để liên kết với tài khoản dịch vụ. EKS Pod Identity agent quản lý thông tin xác thực để giả định vai trò này cho ứng dụng trong các container trong các pod sử dụng tài khoản dịch vụ này.
• serviceAccount – Tên của tài khoản dịch vụ Kubernetes bên trong cụm để liên kết thông tin xác thực IAM với.

ListPodIdentityAssociations – Cuộc gọi API để liệt kê các liên kết Amazon EKS Pod Identity trong một cụm. Bạn có thể lọc danh sách theo không gian tên mà liên kết đó ở trong hoặc tài khoản dịch vụ mà liên kết đó sử dụng.

Các thông số bắt buộc:

• name – Tên của cụm mà các liên kết nằm trong đó.

DescribePodIdentityAssociation – Cuộc gọi API để trả về thông tin mô tả về một liên kết EKS Pod Identity.

Các thông số bắt buộc:

• name – Tên của cụm mà liên kết đó nằm trong đó.
• associationId – ID của liên kết mà bạn muốn mô tả.

DeletePodIdentityAssociation – API để xóa một liên kết danh tính pod hiện tại.

Các thông số bắt buộc:

• name – Tên của cụm mà liên kết đó nằm trong đó.
• associationId – ID của liên kết mà bạn muốn mô tả.

UpdatePodIdentityAssociation – API để cập nhật một liên kết danh tính pod hiện tại. Chỉ có thể thay đổi IAM role; liên kết không thể được di chuyển giữa các cụm, không gian tên hoặc tài khoản dịch vụ. Nếu bạn cần chỉnh sửa không gian tên hoặc tài khoản dịch vụ, bạn cần xóa liên kết sau đó tạo liên kết mới với cài đặt mong muốn của bạn.

Các thông số bắt buộc:

• name – Tên của cụm mà liên kết đó nằm trong đó.
• associationId – ID của liên kết mà bạn muốn mô tả.
• roleArn – Vai trò IAM mới để liên kết với tài khoản dịch vụ

DataPlane API

AssumeRoleForPodIdentity – API được pod DaemonSet eks-pod-identity-agent sử dụng để trao đổi token tài khoản dịch vụ để có thông tin xác thực IAM liên quan. Token này là một JSON Web Token, trong đó có chứa không gian tên, pod và tài khoản dịch vụ.

Làm thế nào để bắt đầu

Trong hướng dẫn này, chúng ta sẽ thực hiện hai trường hợp sử dụng:

• Một ứng dụng Python Flask mẫu sử dụng tính năng EKS Pod Identity để truy cập các bucket Amazon S3.
• Cách sử dụng IAM Session tags để tạo chính sách IAM tinh tế để truy cập bí mật quản lý AWS Secrets Manager.

Điều kiện tiên quyết

• Một tài khoản AWS
• Phiên bản mới nhất của AWS CLI được cấu hình trên thiết bị của bạn hoặc AWS CloudShell
• eksctl – một công cụ CLI đơn giản để tạo và quản lý cụm Amazon EKS (v0.165.0 hoặc cao hơn)

Setup

export AWS_REGION=us-west-2 #Replace with your AWS Region

export AWS_ACCOUNT=111122223333 #Replace with your AWS Account number

export CLUSTER_NAME=eks-pod-identity-demo #Replace with your EKS cluster name

git clone https://github.com/aws-samples/amazon-eks-pod-identity-demo.git

cd amazon-eks-pod-identity-demo

Hãy bắt đầu bằng cách tạo một Cụm Amazon EKS bằng eksctl với tiện ích thêm mới eks-pod-identity-agent.

LƯU Ý: Amazon EKS Pod Identity được hỗ trợ trên phiên bản EKS 1.24 trở lên.

cat << EOF > cluster.yaml 

apiVersion: eksctl.io/v1alpha5

kind: ClusterConfig

metadata:

  name: ${CLUSTER_NAME}

  region: ${AWS_REGION}

  version: “1.28”

addons:

  – name: vpc-cni

  – name: coredns

  – name: kube-proxy

  – name: eks-pod-identity-agent

managedNodeGroups:

  – name: ${CLUSTER_NAME}-mng

    instanceType: m6a.large

    privateNetworking: true

    minSize: 2

    desiredCapacity: 2

    maxSize: 5

EOF

eksctl create cluster -f cluster.yaml

YAML

Bạn cũng có thể sử dụng tệp cấu hình hoặc các cờ CLI để triển khai tiện ích thêm sau khi đã tạo cụm, như được thể hiện dưới đây:

eksctl create addon –config-file=cluster.yaml

Bash

hoặc

eksctl create addon –name eks-pod-identity-agent –version 1.0.0

Bash

Chờ đợi quá trình tạo cụm hoàn tất và đảm bảo rằng tiện ích thêm eks-pod-identity-agent đang chạy trong cụm.

eksctl get addon –cluster ${CLUSTER_NAME} –region ${AWS_REGION} –name eks-pod-identity-agent -o json 

[

    {

        “Name”: “eks-pod-identity-agent”,

        “Version”: “v1.0.0-eksbuild.1”,

        “NewerVersion”: “”,

        “IAMRole”: “”,

        “Status”: “ACTIVE”,

        “ConfigurationValues”: “”,

        “Issues”: null

    }

]

kubectl get pods -n kube-system -l app.kubernetes.io/instance=eks-pod-identity-agent

NAME                           READY   STATUS    RESTARTS   AGE

eks-pod-identity-agent-tkxb4   1/1     Running   0          79m

eks-pod-identity-agent-zq9k2   1/1    Running   0          79m

Hình 2: Giao diện Amazon EKS – Tiện ích thêm EKS Pod Identity Agent

Tiếp theo, chúng ta sẽ sử dụng tính năng Amazon EKS Pod Identity để liên kết một vai trò AWS IAM với tài khoản dịch vụ Kubernetes sẽ được sử dụng bởi triển khai của chúng ta. Trong ví dụ này, eksctl được sử dụng để đơn giản hóa quá trình tạo và liên kết vai trò IAM, lệnh dưới đây sẽ tự động tạo vai trò IAM s3-app-eks-pod-identity-role, gán chính sách quyền AmazonS3ReadOnlyAccess cho nó, và liên kết nó với tài khoản dịch vụ s3-app-sa trong không gian tên s3-app-ns.

eksctl create podidentityassociation \

–cluster $CLUSTER_NAME \

–namespace s3-app-ns \

–service-account-name s3-app-sa \

–role-name s3-app-eks-pod-identity-role \

–permission-policy-arns arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \

–region $AWS_REGION

Bash

Hình 3: Giao diện Amazon EKS – Liên kết danh tính Pod

API CreatePodIdentityAssociation được sử dụng để tạo liên kết danh tính pod cho một vai trò IAM và tài khoản dịch vụ. EKS Pod Identity cho phép bạn tái sử dụng cùng một vai trò IAM để liên kết với nhiều tài khoản dịch vụ qua các không gian tên trong một cụm, hoặc qua các cụm EKS trong một AWS Account.

Bây giờ, sau khi chúng ta đã tạo một cụm Amazon EKS với các tiền đề cần thiết để sử dụng tính năng EKS Pod Identity, hãy triển khai một ứng dụng mẫu Python Flask sử dụng SDK boto3 để tương tác với các bucket Amazon S3. Ứng dụng Python đã được cập nhật để sử dụng phiên bản mới nhất của SDK boto3 hỗ trợ EKS Pod Identity. Ứng dụng này được triển khai trong không gian tên s3-app-ns và với tài khoản dịch vụ s3-app-sa.

kubectl apply -f s3-app.yaml

namespace/s3-app-ns created

serviceaccount/s3-app-sa created

deployment.apps/s3-app-deployment created

service/s3-app-svc created

Bash

Chờ đợi cho các pod và dịch vụ LoadBalancer trở nên sẵn sàng, và lấy địa chỉ URL của LoadBalancer bằng lệnh dưới đây:

kubectl get all -n s3-app-ns

NAME                                          READY   STATUS       RESTARTS   AGE

pod/s3-app-deployment-79c7c5c696-nrfsb        1/1       Running      0          29s

pod/s3-app-deployment-79c7c5c696-rt562        1/1       Running      0          22s

NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP                                                                                            PORT(S)        AGE

service/s3-app-svc         LoadBalancer   172.20.10.54   a3c4874577a65486aa23c5508ee3c3f7-1a804a21e2f25d95.elb.us-west-2.amazonaws.com    80:31118/TCP   5s

NAME                                READY   UP-TO-DATE     AVAILABLE   AGE

deployment.apps/s3-app-deployment   2/2     2              2           42m

NAME                                                    DESIRED   CURRENT   READY   AGE

replicaset.apps/s3-app-deployment-79c7c5c696            2         2         2       29s

export LB_URL=$(kubectl get svc -n s3-app-ns s3-app-svc -o jsonpath='{.status.loadBalancer.ingress[0].hostname}’)

Bash

Bây giờ, sử dụng lệnh curl sau để xác minh xem pod Kubernetes có thể truy cập các bucket Amazon S3 không. Nếu cuộc gọi thành công, bạn sẽ thấy danh sách tên bucket.

curl http://$LB_URL/list-buckets

[ LIST OF BUCKETS ]

Bash

Điều này thể hiện cách các khối công việc Amazon EKS có thể sử dụng tính năng mới EKS Pod Identity để an toàn truy cập các nguồn tài nguyên AWS khác bằng cách sử dụng thông tin xác thực tạm thời AWS IAM.

Bạn cũng có thể xem sự kiện AWS CloudTrail cho AssumeRoleForPodIdentity; eks-pod-identity-agent thực hiện cuộc gọi này khi AWS SDK yêu cầu thông tin xác thực IAM tạm thời.

{ 

….

    “eventSource”: “eks-auth.amazonaws.com”,

    “eventName”: “AssumeRoleForPodIdentity”,

    “awsRegion”: “us-west-2”,

    “userAgent”: “aws-sdk-go-v2/1.21.2 os/linux lang/go#1.19.13 md/GOOS#linux md/GOARCH#amd64 api/eksauth#1.0.0-zeta.e49712bf27d5”,

    “eventType”: “AwsApiCall”,

    “managementEvent”: true,

    “eventCategory”: “Management”,

…..

}

Hỗ trợ cho các nhãn phiên

Nhãn phiên là cặp thuộc tính key-value bạn truyền khi giả định một vai trò IAM hoặc liên kết một người dùng trong Dịch vụ Token Bảo mật AWS (AWS STS). Với Amazon EKS Pod Identity, bạn có khả năng sử dụng nhãn phiên để kiểm soát quyền truy cập vào các nguồn tài nguyên AWS từ các pod k8s của bạn. Nhãn phiên của vai trò IAM cũng cho phép bạn tạo chính sách quyền IAM tinh tế dựa trên các nhãn như eks-cluster-arn, eks-cluster-name, kubernetes-namespace, kubernetes-service-account, kubernetes-pod-name, và kubernetes-pod-uid.

Điều này cho phép bạn sử dụng kiểm soát truy cập dựa trên thuộc tính (ABAC) trong các chính sách quyền IAM với EKS. ABAC là một chiến lược ủy quyền xác định quyền dựa trên thuộc tính/nhãn. Bằng cách thêm hỗ trợ cho Nhãn phiên IAM, bạn có thể thực hiện ranh giới an ninh chặt chẽ hơn giữa các cụm và khối công việc bên trong cụm, trong khi vẫn tái sử dụng các vai trò IAM và chính sách IAM. Ví dụ dưới đây cho phép hành động secretsmanager:GetSecretValue chỉ khi secret được gắn nhãn với các giá trị kubernetes-namespace và eks-cluster-name phù hợp.

{

    “Version”: “2012-10-17”,

    “Statement”: [

        {

            “Sid”: “AuthorizetoGetSecretValue”,

            “Effect”: “Allow”,

            “Action”: [

                “secretsmanager:GetSecretValue”,

                “secretsmanager:DescribeSecret”

            ],

            “Resource”: “*”,

            “Condition”: {

                “StringEquals”: {

                    “secretsmanager:ResourceTag/kubernetes-namespace”: “${aws:PrincipalTag/kubernetes-namespace}”,

                    “secretsmanager:ResourceTag/eks-cluster-name”: “${aws:PrincipalTag/eks-cluster-name}”

                }

            }

        }

    ]

}

JSON

Trong tình huống này, chúng ta sẽ triển khai một ứng dụng awscli trong hai không gian tên khác nhau bằng cách sử dụng các tài khoản dịch vụ khác nhau. Cả hai tài khoản dịch vụ này đều được liên kết với cùng một vai trò IAM AWS, cho phép truy cập vào các bí mật của AWS Secrets Manager dựa trên các nhãn phiên kubernetes-namespace và eks-cluster-name của chúng.

Bắt đầu bằng cách tạo một chính sách IAM tùy chỉnh với tài liệu chính sách như trên.

export SECRETMGR_APP_POLICY_ARN=$(aws iam create-policy –policy-name sm-pod-identity-demo \

–policy-document file://aws-secretmgr-policy.json \

–output text –query ‘Policy.Arn’)

Bash

Bây giờ, hãy tạo hai bí mật AWS Secrets Manager, một được gắn nhãn với kubernetes-namespace=dev-ns và cái kia với kubernetes-namespace=qa-ns. Chúng ta đang sử dụng các nhãn phiên kubernetes-namespace, eks-cluster-name được định trước để hạn chế quyền truy cập vào các bí mật tương ứng.

aws secretsmanager create-secret –region $AWS_REGION –name dev-secret \

–tags Key=kubernetes-namespace,Value=dev-ns Key=eks-cluster-name,Value=$CLUSTER_NAME \

–secret-string “This is super secret in dev ns”

aws secretsmanager create-secret –region $AWS_REGION –name qa-secret \

–tags Key=kubernetes-namespace,Value=qa-ns Key=eks-cluster-name,Value=$CLUSTER_NAME \

–secret-string “This is super secret in qa ns”

Bash

Chạy các lệnh sau để tạo vai trò IAM AWS với chính sách IAM tùy chỉnh được tạo ở trên và liên kết nó với hai tài khoản dịch vụ (secretmgr-app-sa) trong các không gian tên dev-ns và qa-ns.

eksctl create podidentityassociation \

–cluster $CLUSTER_NAME \

–namespace dev-ns \

–service-account-name secretmgr-app-sa \

–role-name secretmgr-app-eks-pod-identity-role \

–permission-policy-arns $SECRETMGR_APP_POLICY_ARN \

–region $AWS_REGION

eksctl create podidentityassociation \

–cluster $CLUSTER_NAME \

–namespace qa-ns \

–service-account-name secretmgr-app-sa \

–role-arn “arn:aws:iam::${AWS_ACCOUNT}:role/secretmgr-app-eks-pod-identity-role” \

–region $AWS_REGION

Bash

Bạn có thể xem xét liên kết danh tính Pod trongAmazon EKS Console → Access tab như được thể hiện trong sơ đồ dưới đây:

Hình 4: Bảng điều khiển Amazon EKS – Liên kết danh tính Pod

Triển khai ứng dụng mẫu trong cả hai không gian tên bằng cách sử dụng tài khoản dịch vụ secretmgr-app-sa.

kubectl create ns dev-ns

kubectl create ns qa-ns

kubectl apply -f secretmgr-app-pod.yaml -n dev-ns

kubectl apply -f secretmgr-app-pod.yaml -n qa-ns

Bash

Hãy kiểm tra quyền truy cập quản lý bí mật bằng cách sử dụng các lệnh sau:

kubectl exec -it -n dev-ns secretmgr-app-pod — aws secretsmanager get-secret-value –secret-id dev-secret –region $AWS_REGION –query ‘SecretString’

> “This is super secret in dev ns”

kubectl exec -it -n qa-ns secretmgr-app-pod — aws secretsmanager get-secret-value –secret-id qa-secret –region $AWS_REGION –query ‘SecretString’

> “This is super secret in qa ns”

kubectl exec -it -n dev-ns secretmgr-app-pod — aws secretsmanager get-secret-value –secret-id qa-secret –region $AWS_REGION –query ‘SecretString’

> An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::123456789012:assumed-role/secretmgr-app-eks-pod-identity-role/eks-eks-pod-identity-secretmgr–b3b1e9d7-4521-4764-8f63-0928a6e6546b is not authorized to perform: secretsmanager:GetSecretValue on resource: qa-secret because no identity-based policy allows the secretsmanager:GetSecretValue action

kubectl exec -it -n qa-ns secretmgr-app-pod — aws secretsmanager get-secret-value –secret-id dev-secret –region $AWS_REGION –query ‘SecretString’

> An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::123456789012:assumed-role/secretmgr-app-eks-pod-identity-role/eks-eks-pod-identity-secretmgr–24690dab-4c88-462f-89cc-3b77432e51ba is not authorized to perform: secretsmanager:GetSecretValue on resource: dev-secret because no identity-based policy allows the secretsmanager:GetSecretValue action

Bash

Từ các đầu ra trên, bạn có thể nhận thấy cuộc gọi GetSecretValue thành công chỉ khi điều kiện nhãn tài nguyên được đáp ứng dựa trên các giá trị nhãn kubernetes-namespace và eks-cluster-name. Truy cập bị từ chối nếu cả hai giá trị nhãn không khớp hoặc thiếu nhãn trên các nguồn tài nguyên. Tóm lại, pod chạy trong dev-ns có thể truy cập dev-secret nhưng không thể truy cập qa-secret và ngược lại.

Từ nhật ký sự kiện AWS CloudTrail, bạn cũng có thể xem xét các nhãn phiên được chuyển trong AssumeRole API.

…

    “requestParameters”: {

        “roleArn”: “arn:aws:iam::123456789012:role/secretmgr-app-eks-pod-identity-role”,

        “roleSessionName”: “eks-eks-pod-identity-secretmgr–24690dab-4c88-462f-89cc-3b77432e51ba”,

        “durationSeconds”: 21600,

        “tags”: [

            {

                “key”: “eks-cluster-arn”,

                “value”: “arn:aws:eks:us-west-2:123456789012:cluster/eks-pod-identity-demo”

            },

            {

                “key”: “eks-cluster-name”,

                “value”: “eks-pod-identity-demo”

            },

            {

                “key”: “kubernetes-namespace”,

                “value”: “qa-ns”

            },

Làm thế nào để thực hiện truy cập giữa các tài khoản với Amazon EKS Pod Identity

Có những tình huống trong đó cụm Amazon EKS của bạn có thể chạy trong một tài khoản AWS và các nguồn tài nguyên AWS đang được truy cập từ ứng dụng của bạn chạy trong một tài khoản khác. Bạn có thể truy cập các nguồn tài nguyên giữa các tài khoản bằng cách sử dụng một trong những phương pháp sau khi sử dụng tính năng EKS Pod Identity.

Phương pháp 1: Truy cập dựa trên chính sách tài nguyên

Một chính sách tài nguyên có thể được sử dụng để cấp quyền truy cập giữa các tài khoản bằng cách chỉ định các chủ thể trong các tài khoản AWS khác có thể truy cập nguồn tài nguyên. Cả vai trò IAM và ứng dụng đều tồn tại trong Tài khoản A và chính sách tài nguyên phù hợp được đính kèm vào các nguồn tài nguyên trong Tài khoản B để cho phép truy cập vào vai trò IAM của ứng dụng. Tham khảo tài liệu IAM về Truy cập giữa các tài khoản bằng cách sử dụng chính sách dựa trên tài nguyên để biết chi tiết và Dịch vụ tương thích với IAM để xem danh sách các dịch vụ hỗ trợ chính sách dựa trên tài nguyên.

Hình 5: Truy cập giữa các tài khoản bằng chính sách dựa trên tài nguyên

Phương pháp 2: Chaining vai trò trong ứng dụng

Trong phương pháp này, Tài khoản B tạo một vai trò IAM với các chính sách quyền hợp lý và tạo mối quan hệ tin cậy cho phép quyền AssumeRole tới Tài khoản A. Trong Tài khoản A, một vai trò IAM được tạo với quyền AssumeRole để giả định vai trò IAM trong Tài khoản B và được liên kết với pod Kubernetes của bạn. Khi pod nhận được thông tin xác thực IAM tạm thời từ EKS Pod Identity, ứng dụng của bạn có thể thực hiện hành động STS AssumeRole để giả định vai trò IAM trong Tài khoản B và truy cập vào các nguồn tài nguyên giữa các tài khoản. Đọc hướng dẫn chi tiết Cross-account access using roles để biết chi tiết.

Hình 6: Truy cập giữa các tài khoản bằng cách sử dụng chuỗi vai trò IAM

Phương pháp 3: Chuỗi vai trò sử dụng AWS Config

Đây tương tự như Phương pháp 2, thay vì thực hiện cuộc gọi STS AssumeRole trong mã ứng dụng, SDK AWS cung cấp cách xác định chuỗi vai trò trong tệp ~/.aws/config. SDK AWS sẽ tự động phân tích tệp cấu hình và truy xuất thông tin xác thực cho vai trò đích. Bạn có thể tạo một tệp cấu hình như được hiển thị dưới đây với cả hai vai trò của Tài khoản A và B và chỉ định các biến môi trường AWS_CONFIG_FILE và AWS_PROFILE trong mô tả pod của bạn. Webhook danh tính pod không ghi đè nếu các biến môi trường đã tồn tại trong mô tả pod. Phương pháp này đòi hỏi sự có sẵn của các tiện ích curl, jq trong hình ảnh container.

# Snippet of the PodSpec

containers: 

  – name: container-name

    image: container-image:version

    env:

    – name: AWS_CONFIG_FILE

      value: path-to-customer-provided-aws-config-file

    – name: AWS_PROFILE

      value: account_b_role

# Content of the AWS Config file

[profile account_b_role] 

source_profile = account_a_role 

role_arn=arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role] 

credential_process = /eks-credential-processrole.sh

# Content of the eks-credential-processrole.sh

curl -H “Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)” $AWS_CONTAINER_CREDENTIALS_FULL_URI | jq -c ‘{AccessKeyId: .AccessKeyId, SecretAccessKey: .SecretAccessKey, SessionToken: .Token, Expiration: .Expiration, Version: 1}’

So sánh giữa Amazon EKS Pod Identity và IRSA

Ở mức cao, cả Amazon EKS Pod Identity và IRSA đều cho phép bạn cấp quyền IAM AWS cho các ứng dụng chạy trên các cụm EKS. Nhưng chúng khác nhau cơ bản trong cách bạn cấu hình chúng, các giới hạn được hỗ trợ và các tính năng được kích hoạt. Dưới đây, chúng ta so sánh một số khía cạnh quan trọng của cả hai giải pháp.

	IRSA	EKS Pod Identity
Khả năng mở rộng vai trò	Bạn phải cập nhật chính sách tin cậy của vai trò IAM với điểm cuối OIDC mới của nhà cung cấp EKS mỗi khi bạn muốn sử dụng vai trò trong một cụm mới.	Bạn phải thiết lập vai trò một lần, để thiết lập sự tin cậy với nguyên lý dịch vụ EKS mới được giới thiệu “pods.eks.amazonaws.com”. Sau bước này một lần, bạn không cần phải cập nhật chính sách tin cậy của vai trò mỗi khi nó được sử dụng trong một cụm mới.
Khả năng mở rộng tài khoản	Cụm EKS có một URL cấp phát OpenID Connect (OIDC) liên quan đến nó. Để sử dụng IRSA, một nhà cung cấp OpenID Connect duy nhất cần phải được tạo trong IAM cho mỗi cụm EKS. Nhà cung cấp OIDC IAM có một giới hạn toàn cầu mặc định là 100 cho mỗi tài khoản AWS. Hãy cân nhắc đến giới hạn này khi bạn tăng số lượng cụm EKS trên mỗi tài khoản.	EKS Pod Identity không đòi hỏi người dùng thiết lập nhà cung cấp OIDC IAM, vì vậy giới hạn này không áp dụng.
Khả năng mở rộng vai trò	Trong IRSA, bạn xác định mối quan hệ tin cậy giữa một vai trò IAM và tài khoản dịch vụ trong chính sách tin cậy của vai trò. Theo mặc định, chiều dài của chính sách tin cậy là 2048. Điều này có nghĩa là bạn thường có thể xác định bốn mối quan hệ tin cậy trong một chính sách duy nhất. Mặc dù bạn có thể tăng giới hạn chiều dài chính sách tin cậy, nhưng thông thường bạn bị hạn chế đối với tối đa tám mối quan hệ tin cậy trong một chính sách duy nhất.	EKS Pod Identity không yêu cầu người dùng xác định mối quan hệ tin cậy giữa vai trò IAM và tài khoản dịch vụ trong chính sách tin cậy IAM, vì vậy giới hạn này không áp dụng.
Khả năng tái sử dụng vai trò	Thẻ phiên của vai trò IAM	Chứng chỉ IAM được cung cấp bởi EKS Pod Identity bao gồm hỗ trợ cho các thẻ phiên của vai trò. Các thẻ phiên của vai trò cho phép quản trị viên tạo một vai trò IAM duy nhất có thể được sử dụng với nhiều tài khoản dịch vụ, với các quyền hiệu quả khác nhau, bằng cách cho phép truy cập vào các nguồn tài nguyên AWS dựa trên các thẻ được gắn liền với chúng.
Sự sẵn sàng của cụm	Các vai trò IAM được sử dụng trong IRSA cần phải chờ cụm ở trạng thái “Sẵn sàng” để lấy URL nhà cung cấp OpenID Connect của cụm để hoàn thành cấu hình chính sách tin cậy của vai trò IAM.	Các vai trò IAM được sử dụng trong Pod Identity có thể được tạo trước thời điểm.
Môi trường được hỗ trợ	IRSA có thể được sử dụng trong EKS, EKS-A, ROSA, cụm Kubernetes tự quản lý trên Amazon EC2.	EKS Pod Identity được xây dựng đặc biệt cho EKS.
Các phiên bản EKS được hỗ trợ	Tất cả các phiên bản EKS được hỗ trợ	Phiên bản EKS 1.24 trở lên. Xem hướng dẫn người dùng EKS để biết chi tiết.
Truy cập giữa các tài khoản	Ở đây, truy cập giữa các tài khoản đề cập đến tình huống trong đó cụm EKS của bạn nằm trong một tài khoản AWS và các nguồn tài nguyên AWS được ứng dụng của bạn truy cập lại nằm trong một tài khoản AWS khác. Trong IRSA, bạn có thể cấu hình quyền IAM giữa các tài khoản bằng cách tạo một nhà cung cấp danh tính IAM trong tài khoản nơi nguồn tài nguyên AWS của bạn đang tồn tại hoặc bằng cách sử dụng hoạt động AssumeRole được chuỗi. Xem hướng dẫn người dùng EKS về quyền IAM chuyển tài khoản trong IRSA để biết chi tiết.	EKS Pod Identity hỗ trợ truy cập giữa các tài khoản thông qua chính sách nguồn và hoạt động AssumeRole được chuỗi. Xem phần trước “Cách thực hiện truy cập giữa các tài khoản với EKS Pod Identity” để biết chi tiết.
Ánh xạ kho lưu trữ	Bạn có thể tìm thấy ánh xạ của các vai trò IAM đến các tài khoản dịch vụ bằng cách phân tích cú pháp của chính sách tin cậy của từng vai trò IAM hoặc bằng cách kiểm tra các chú thích được thêm vào các tài khoản dịch vụ.	EKS Pod Identity cung cấp một API mới là ListPodIdentityAssociations để xem trung tâm ánh xạ của các vai trò đến các tài khoản dịch vụ.

Làm thế nào để di chuyển từ IRSA sang EKS Pod Identity

Bạn có thể di chuyển các vai trò IRSA hiện có để tận dụng EKS Pod Identity bằng cách đầu tiên đảm bảo đạt được các điều kiện tiên quyết để nâng cấp phiên bản cụm EKS của bạn lên phiên bản 1.24 và cao hơn. Hơn nữa, bạn cần cài đặt Tiện ích Bổ sung EKS Pod Identity yêu cầu trước trên cụm của bạn. Bạn cũng cần cập nhật ứng dụng của mình để sử dụng một trong những phiên bản SDK AWS được hỗ trợ được nêu ra trong tài liệu EKS tại đây. Khi các điều kiện tiên quyết này được đáp ứng, bạn có thể cập nhật chính sách tin cậy của vai trò IAM của mình với nguyên lý dịch vụ EKS mới pods.eks.amazonaws.com. Tuỳ chọn, để đảm bảo một quá trình di chuyển mượt mà, bạn có thể cập nhật vai trò IAM hiện có của mình để tin tưởng cả vào nguyên lý dịch vụ EKS mới cũng như điểm cuối nhà cung cấp OIDC được hỗ trợ bởi IRSA như được hiển thị trong sơ đồ dưới đây.

Hình 7: Chính sách tin cậy IAM Role đã được cập nhật để tin cậy cả EKS Service Principal và OIDC Provider

Webhook của EKS Pod Identity ưu tiên EKS Pod Identity hơn IRSA khi nó phát hiện vai trò được thiết lập với cả hai thực thể được tin tưởng. Sau đó, bạn có thể tạo liên kết EKS Pod Identity bằng cách gọi API mới CreatePodIdentityAssociation để kết hợp vai trò IAM với tài khoản dịch vụ. Khi liên kết đã được thiết lập, tất cả các pod mới/khởi động lại sẽ có thông số cụ thể của chúng được biến đổi với các biến môi trường mới được hỗ trợ bởi EKS Pod Identity. SDK AWS được sử dụng trong ứng dụng của bạn sau đó sẽ sử dụng biến môi trường mới để trao đổi mã thông báo JWT được dự đoán để đổi lấy chứng chỉ IAM tạm thời. Sau khi bạn đã xác minh rằng mọi thứ đều hoạt động như mong đợi, bạn có thể xóa liên kết tin tưởng cũ của bạn từ nhà cung cấp OIDC từ vai trò IAM của bạn như được hiển thị dưới đây.

Hình 8: Chính sách tin cậy IAM Role để tin tưởng EKS Service Principal

Các xem xét cho Amazon EKS Pod Identity

• Amazon EKS Pod Identity hỗ trợ Kubernetes chạy phiên bản 1.24 và cao hơn trên Amazon EKS. Vui lòng tham khảo tài liệu EKS tại đây để biết chi tiết về các phiên bản Nền được hỗ trợ trên các phiên bản Kubernetes này.
• Tính năng Amazon EKS Pod Identity yêu cầu bạn nâng cấp lên các AWS SDK mới nhất và cài đặt eks-pod-identity-agent Add-on trên cụm. Xem tài liệu EKS tại đây để biết danh sách chính xác các phiên bản được hỗ trợ.
• EKS Pod Identity có sẵn trong tất cả các Khu vực AWS được hỗ trợ bởi Amazon EKS, trừ các Khu vực AWS GovCloud (US), Trung Quốc (Bắc Kinh, do Sinnet vận hành), và Trung Quốc (Ningxia, do NWCD vận hành) tại thời điểm viết bài này.
• Khi ra mắt, EKS Pod Identity hỗ trợ một bộ quy định trước của các nhãn phiên của vai trò IAM, tham khảo danh sách các nhãn được thêm bởi EKS Pod Identity để biết các nhãn được hỗ trợ.
• Các Add-on của EKS và Add-on tự quản lý hoạt động với EKS Pod Identity. Bạn phải đảm bảo trước hết rằng bạn đang sử dụng một phiên bản của Add-on được xây dựng bằng một phiên bản được hỗ trợ của AWS SDK. Bạn có thể gọi API EKS Pod Identity để tạo liên kết danh tính pod giữa vai trò IAM cần thiết bởi add-on với tài khoản dịch vụ thích hợp. Khi liên kết danh tính pod từ vai trò IAM đến tài khoản dịch vụ đã được thiết lập, bạn có thể cài đặt add-on để đảm bảo nó nhận các quyền IAM cần thiết. Trong tương lai, EKS sẽ thêm tích hợp chính thức giữa EKS add-on và các API Identity Identity, vì vậy các API Identity Identity không cần phải được gọi một cách riêng biệt như bước tiên quyết.
• Bạn chỉ có thể kết hợp một vai trò IAM với một tài khoản dịch vụ Kubernetes bằng tính năng EKS Pod Identity. Tuy nhiên, bạn có thể cập nhật các liên kết vai trò bất kỳ lúc nào.
• EKS Pod Identity là một lựa chọn khác cho bạn cùng với IRSA để cấp quyền IAM cho các ứng dụng chạy trên cụm EKS. IRSA hoạt động với EKS, EKS-A, ROSA và các cụm k8s tự quản lý trên EC2. EKS Pod Identity được xây dựng đặc biệt cho EKS, và do đó đơn giản hóa trải nghiệm để có được quyền IAM cho khách hàng EKS. Bạn có thể sử dụng cả hai tính năng này đồng thời trên một cụm. Bạn có thể sử dụng phương pháp này cho đến khi tất cả các ứng dụng và Add-on chạy trên cụm được nâng cấp để sử dụng một phiên bản mới của AWS SDK hỗ trợ EKS Pod Identity. Xem phần trước “Làm thế nào để di chuyển từ IRSA sang EKS Pod Identity” để biết chi tiết.

Dọn dẹp

Để tránh các chi phí tiếp tục, hãy đảm bảo xóa các tài nguyên cụm Amazon EKS được tạo trong tài khoản AWS của bạn.

# Delete EKS cluster resources

eksctl delete cluster -f cluster.yaml

# Delete AWS Secrets Manager Secrets

aws secretsmanager delete-secret –region $AWS_REGION –secret-id dev-secret 

aws secretsmanager delete-secret –region $AWS_REGION –secret-id qa-secret

# Delete IAM Resources

aws iam detach-role-policy –role-name secretmgr-app-eks-pod-identity-role –policy-arn $SECRETMGR_APP_POLICY_ARN

aws iam delete-role –role-name secretmgr-app-eks-pod-identity-role

aws iam delete-policy –policy-arn $SECRETMGR_APP_POLICY_ARN

aws iam detach-role-policy –role-name s3-app-eks-pod-identity-role –policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

aws iam delete-role –role-name s3-app-eks-pod-identity-role

Bash

Kết luận

Trong bài viết này, chúng tôi đã hướng dẫn bạn cách sử dụng tính năng Amazon EKS Pod Identity để an toàn cấp quyền IAM cho các ứng dụng Kubernetes chạy trong các cụm EKS của bạn. Chúng tôi cũng thảo luận về cách sử dụng IAM Session tags để tạo chính sách quyền IAM tinh vi dựa trên các nhãn, quyền truy cập tài nguyên giữa các tài khoản và các bước di chuyển từ IRSA sang tính năng mới EKS Pod Identity. Chúng tôi khuyến khích bạn bắt đầu sử dụng tính năng này và để lại phản hồi cho chúng tôi tại AWS Continers Roadmap.

George John

George John là một Quản lý Sản phẩm Cao cấp với đội ngũ Kubernetes của AWS. Khi ông không xây dựng sản phẩm, ông thích khám phá Thái Bình Dương Northwest cùng gia đình của mình.

Ashok Srirama

Ashok là Kiến trúc sư chuyên gia về Containers tại Amazon Web Services, đặt trụ sở tại Washington Crossing, PA. Anh chuyên sâu về ứng dụng không máy chủ, container, và kiến trúc hệ thống phân tán. Khi không dành thời gian với gia đình, anh thích xem cricket và lái xe.

Hemanth AVS

Hemanth là Kiến trúc sư chuyên gia về Containers tại AWS. Anh giúp khách hàng hiện đại hóa ứng dụng của họ và xây dựng nền tảng ứng dụng sử dụng các dịch vụ container của AWS. Anh đam mê về công nghệ đám mây và công nghệ native của đám mây.