AWS Study Group

Session policies trong Amazon EKS Pod Identity

Tác giả: Aditya Potdar, Ashok Srirama, và George John
Ngày phát hành: 24 MAR 2026
Chuyên mục: Amazon Elastic Kubernetes Service, Announcements, AWS Identity and Access Management (IAM), Containers

Hôm nay, chúng tôi công bố khả năng mới chính sách phiên (session policies) cho Amazon Elastic Kubernetes Service (Amazon EKS) Pod Identity. Với tính năng mới này, bạn có thể tự động giới hạn quyền AWS Identity and Access Management (IAM) cho các pod Kubernetes của mình mà không cần tạo thêm các vai trò IAM. Chính sách phiên cung cấp một giải pháp thay thế linh hoạt cho việc tạo các vai trò IAM riêng biệt cho từng biến thể quyền bằng cách chỉ định một chính sách IAM nội tuyến trong quá trình tạo liên kết Pod Identity. Điều này giúp bạn quản lý quyền ở quy mô lớn mà không làm tăng số lượng vai trò của mình. Điều này có nghĩa là các ứng dụng Kubernetes của bạn giờ đây có thể hoạt động với chính xác các quyền cần thiết, tuân thủ nguyên tắc đặc quyền tối thiểu, đồng thời tránh đạt đến giới hạn vai trò IAM trong các triển khai quy mô lớn.

Trong bài viết này, chúng tôi sẽ trình bày cách sử dụng chính sách phiên để tự động giới hạn quyền IAM cho các pod Kubernetes của bạn mà không cần tạo thêm các vai trò IAM, và thảo luận về những cân nhắc quan trọng khi áp dụng tính năng này. Tại re:Invent 2023, Amazon EKS đã giới thiệu tính năng EKS Pod Identity. Tính năng này giúp người dùng cấu hình các ứng dụng Kubernetes chạy trên Amazon EKS với các quyền IAM chi tiết để truy cập các tài nguyên AWS như Amazon Simple Storage Service (Amazon S3) buckets và Amazon DynamoDB tables. Tính năng này đã giải quyết nhiều thách thức hiện có của IAM Roles for Service Accounts (IRSA) bằng cách loại bỏ nhu cầu thiết lập các nhà cung cấp OpenID Connect (OIDC) cho các cụm EKS, hợp lý hóa các chính sách tin cậy IAM và hợp lý hóa trải nghiệm thông qua các API Amazon EKS. Hơn nữa, nó đã giới thiệu hỗ trợ cho IAM role session tags, để các quản trị viên IAM có thể tạo một chính sách quyền duy nhất 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 thẻ phù hợp.

Thông qua phản hồi liên tục từ người dùng, chúng tôi nhận thấy rằng khách hàng thường gặp thách thức khi họ cần các cấp độ quyền khác nhau cho các pod chạy cùng một ứng dụng. Các kịch bản phổ biến bao gồm:

  • Các nhóm Kỹ thuật Nền tảng quản lý các cụm EKS đa người thuê nơi các khối lượng công việc của khách hàng khác nhau cần các cấp độ truy cập khác nhau vào cùng các dịch vụ AWS. Ví dụ, một ứng dụng phần mềm dưới dạng dịch vụ (SaaS) trong đó mỗi pod hoạt động dựa trên các tài nguyên và dữ liệu cụ thể của người thuê và chỉ được giả định các vai trò cụ thể của người thuê đó.
  • Các nhóm chạy nhiều môi trường (dev, test, staging) trong cùng một cụm nơi các pod cần các phạm vi quyền khác nhau dựa trên môi trường của chúng mà không cần tạo các vai trò IAM riêng biệt cho mỗi môi trường.
  • Các khối lượng công việc xử lý dữ liệu nơi các pod cần truy cập vào các tập hợp con khác nhau của S3 buckets hoặc DynamoDB tables dựa trên chức năng cụ thể của chúng, nhưng việc tạo các vai trò IAM riêng lẻ cho mỗi biến thể sẽ vượt quá hạn ngạch 5.000 vai trò IAM trên mỗi tài khoản.

Trước đây, bạn phải lựa chọn giữa việc tạo các vai trò IAM riêng biệt (đạt đến giới hạn hạn ngạch), cấp quyền quá rộng (rủi ro bảo mật), hoặc sử dụng thẻ phiên (không được tất cả các dịch vụ AWS hỗ trợ) để xử lý các kịch bản này. Để giải quyết những thách thức này và hỗ trợ kiểm soát quyền chi tiết, chúng tôi đang ra mắt chính sách phiên cho EKS Pod Identity. Bạn có thể sử dụng chính sách phiên để áp dụng các chính sách IAM nội tuyến khi EKS Pod Identity giả định một vai trò IAM thay mặt cho các pod của bạn. Các chính sách này tạo ra một giao thoa giữa các quyền được cấp bởi vai trò IAM và chính sách phiên. Điều này giúp hạn chế quyền một cách hiệu quả chỉ đối với những gì được cho phép rõ ràng trong cả hai chính sách. Tính năng này hoạt động cho cả các kịch bản cùng tài khoản và các mẫu truy cập liên tài khoản bằng cách sử dụng chuỗi vai trò IAM. Để biết logic đánh giá chính sách chuyên sâu, hãy tham khảo đánh giá chính sách IAM cho các kịch bản tài khoản đơn và liên tài khoản.

Những thay đổi trong API EKS Pod Identity

Các API sau đây được cập nhật để giới thiệu các yếu tố yêu cầu và phản hồi mới để truyền các chính sách phiên:

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

Tham số yêu cầu:

  • clusterName: Tên của cụm để tạo liên kết.
  • namespace: Tên của Kubernetes namespace bên trong cụm để tạo liên kết.
  • serviceAccount: Tên của Kubernetes service account bên trong cụm để liên kết với thông tin xác thực IAM.
  • roleArn: Amazon Resource Name (ARN) của vai trò IAM để liên kết với tài khoản dịch vụ.
  • targetRoleArn: ARN của một vai trò IAM đích trong một tài khoản AWS khác. Khi được chỉ định, EKS Pod Identity thực hiện chuỗi vai trò IAM: nó trước tiên giả định roleArn, sau đó sử dụng thông tin xác thực đó để giả định targetRoleArn. Khi bạn chỉ định một chính sách phiên, EKS Pod Identity áp dụng nó khi giả định vai trò đích, không phải vai trò nguồn.
  • policy (mới): Một chính sách IAM ở định dạng JSON mà bạn muốn sử dụng làm chính sách phiên nội tuyến. Tham số này là tùy chọn. Các quyền của phiên kết quả là giao thoa của chính sách dựa trên danh tính của vai trò và chính sách phiên. Chính sách văn bản thuần túy không được vượt quá 2.048 ký tự.
  • disableSessionTags: Mặc định là false (thẻ phiên được bật) khi không được chỉ định. Thẻ phiên không thể được sử dụng kết hợp với chính sách phiên do hạn ngạch kích thước chính sách của AWS Security Token Service (AWS STS).

UpdatePodIdentityAssociation: API để cập nhật một liên kết pod identity hiện có. Sử dụng điều này để cập nhật các thuộc tính IAM role, target IAM role, session policy hoặc disableSessionTags của liên kết.

Tham số yêu cầu:

  • clusterName: Tên của cụm nơi liên kết tồn tại
  • associationId: ID của liên kết cần được cập nhật
  • roleArn: Vai trò IAM mới để liên kết với tài khoản dịch vụ (tùy chọn)
  • targetRoleArn: Vai trò IAM đích mới để liên kết với tài khoản dịch vụ
  • policy (mới): Chính sách phiên mới để liên kết với tài khoản dịch vụ (tùy chọn)
  • disableSessionTags: Cờ Boolean để bật hoặc tắt thẻ phiên (tùy chọn, nhưng phải là true khi policy được chỉ định)

Cách bắt đầu

Chúng tôi trình bày cách sử dụng chính sách phiên để hạn chế quyền của một pod Kubernetes chỉ để liệt kê các S3 buckets, mặc dù vai trò IAM cơ bản có các quyền S3 rộng hơn bao gồm khả năng tạo buckets.

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

Các điều kiện tiên quyết sau đây là cần thiết để hoàn thành giải pháp này:

  • Một tài khoản AWS
  • Phiên bản mới nhất của AWS Command Line Interface (AWS CLI) được cấu hình trên thiết bị của bạn hoặc AWS CloudShell
  • CLI cho Amazon EKS (eksctl) để tạo và quản lý các cụm EKS
  • kubectl, một công cụ CLI để tương tác với máy chủ API Kubernetes

Thiết lập

export AWS_REGION=us-west-2  # Replace with your AWS Region
export CLUSTER_NAME=session-policy-demo  # Replace with your EKS cluster name
export NAMESPACE=demo-ns
export AWS_ACCOUNT=$(aws sts get-caller-identity --query Account --output text) # Replace with your AWS Account number
export SERVICE_ACCOUNT=s3-demo-sa

Bước 1: Tạo cụm EKS với tiện ích bổ sung Pod Identity

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

cat << EOF > cluster.yaml 
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_REGION}
  version: "1.35"
addons:
  - name: vpc-cni
  - name: coredns
  - name: kube-proxy
  - name: eks-pod-identity-agent 
    
managedNodeGroups:
  - name: ${CLUSTER_NAME}-mng
    privateNetworking: true
    minSize: 1
    desiredCapacity: 1
    maxSize: 1
EOF
eksctl create cluster -f cluster.yaml

Mất khoảng 15 phút để tạo cơ sở hạ tầng cụm, bạn có thể xác minh trạng thái bằng cách sử dụng lệnh sau hoặc bảng điều khiển Amazon EKS.

aws eks describe-cluster --name ${CLUSTER_NAME} --region ${AWS_REGION} --query 'cluster.status'

Đầu ra của lệnh này phải là ACTIVE.

Sau khi tạo cụm hoàn tất, hãy xác nhận rằng tiện ích bổ sung 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.3.10-eksbuild.2",
        "NewerVersion": "",
        "IAMRole": "",
        "Status": "ACTIVE",
        "ConfigurationValues": "",
        "Issues": null
    }

Bước 2: Tạo vai trò IAM với quyền S3 rộng

Tạo một vai trò IAM với các quyền để thực hiện nhiều hoạt động S3, bao gồm liệt kê và tạo buckets.

cat << EOF > role_trust_policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF
cat << EOF > role_permission_policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:CreateBucket",
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "*"
        }
    ]
}
EOF
aws iam create-role --role-name session-policy-demo-role \
&nbsp;&nbsp; &nbsp;--assume-role-policy-document file://role_trust_policy.json
aws iam put-role-policy --role-name session-policy-demo-role \
&nbsp;&nbsp; &nbsp;--policy-name S3BroadAccess \
&nbsp;&nbsp; &nbsp;--policy-document file://role_permission_policy.json

Bước 3: Tạo liên kết Pod Identity không có chính sách phiên

Tạo một Kubernetes namespace và service account, sau đó liên kết chúng với vai trò IAM.


kubectl create namespace ${NAMESPACE}
kubectl create serviceaccount ${SERVICE_ACCOUNT} -n ${NAMESPACE}

aws eks create-pod-identity-association \
    --cluster-name ${CLUSTER_NAME} \
    --namespace ${NAMESPACE} \
    --service-account ${SERVICE_ACCOUNT} \
    --role-arn arn:aws:iam::${AWS_ACCOUNT}:role/session-policy-demo-role \
    --region ${AWS_REGION}

Bước 4: Kiểm tra pod với đầy đủ quyền của vai trò IAM

Triển khai một pod thử nghiệm và xác minh nó có thể thực hiện nhiều hoạt động S3.

kubectl run s3-test --image=amazon/aws-cli:latest \
    --namespace=${NAMESPACE} --rm -it --restart=Never \
    --overrides='{"spec":{"serviceAccountName":"'${SERVICE_ACCOUNT}'"}}' \
    -- s3 ls
kubectl run s3-test --image=amazon/aws-cli:latest \
    --namespace=${NAMESPACE} --rm -it --restart=Never \
    --overrides='{"spec":{"serviceAccountName":"'${SERVICE_ACCOUNT}'"}}' \
    -- s3 mb s3://session-policy-test-bucket-$(date +%s)

Cả hai lệnh sẽ thành công, chứng tỏ rằng pod có đầy đủ quyền được cấp bởi vai trò IAM.

Bước 5: Thêm chính sách phiên để hạn chế quyền

Bây giờ, hãy cập nhật liên kết Pod Identity để bao gồm một chính sách phiên chỉ cho phép liệt kê các S3 buckets.

ASSOCIATION_ID=$(aws eks list-pod-identity-associations \
    --cluster-name ${CLUSTER_NAME} \
    --namespace ${NAMESPACE} \
    --service-account ${SERVICE_ACCOUNT} \
    --region ${AWS_REGION} \
    --query 'associations[0].associationId' \
    --output text)
aws eks update-pod-identity-association \
    --cluster-name ${CLUSTER_NAME} \
    --association-id ${ASSOCIATION_ID} \
    --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:ListAllMyBuckets","Resource":"*"}]}' \
    --disable-session-tags \
    --region ${AWS_REGION}

Quan trọng: Cờ --disable-session-tags là bắt buộc khi sử dụng chính sách phiên. Thẻ phiên và chính sách phiên không thể được sử dụng cùng nhau do giới hạn kích thước chính sách đóng gói được AWS STS thực thi. Nếu bạn cố gắng tạo hoặc cập nhật một liên kết pod identity với cả chính sách và thẻ phiên được bật (hoặc bỏ qua cờ --disable-session-tags), bạn sẽ nhận được lỗi xác thực PackedPolicyTooLarge trong quá trình gọi API.

Bước 6: Xác minh các quyền bị hạn chế

Do tính chất nhất quán cuối cùng của API EKS Pod Identity, có thể mất vài giây để cập nhật được lan truyền. Chạy các lệnh sau để kiểm tra lại kịch bản.

Lưu ý bảo mật: Trong cửa sổ lan truyền (tối đa 10 giây), các pod tiếp tục nhận thông tin xác thực với các quyền trước đó. Lập kế hoạch thay đổi quyền phù hợp và giám sát AWS CloudTrail để phát hiện bất kỳ nỗ lực truy cập trái phép nào trong cửa sổ chuyển đổi.

kubectl run s3-test --image=amazon/aws-cli:latest \
    --namespace=${NAMESPACE} --rm -it --restart=Never \
    --overrides='{"spec":{"serviceAccountName":"'${SERVICE_ACCOUNT}'"}}' \
    -- s3 ls
kubectl run s3-test --image=amazon/aws-cli:latest \
    --namespace=${NAMESPACE} --rm -it --restart=Never \
    --overrides='{"spec":{"serviceAccountName":"'${SERVICE_ACCOUNT}'"}}' \
    -- s3 mb s3://session-policy-test-bucket-2-$(date +%s)

Lệnh đầu tiên thành công vì s3:ListAllMyBuckets được cho phép bởi cả vai trò IAM và chính sách phiên. Lệnh thứ hai thất bại với lỗi “Access Denied” vì s3:CreateBucket không được bao gồm trong chính sách phiên, mặc dù vai trò IAM cho phép nó.

Bước 7: Mở rộng chính sách phiên

Bạn có thể cập nhật chính sách phiên bất cứ lúc nào để cấp thêm quyền (tối đa những gì vai trò IAM cho phép).

aws eks update-pod-identity-association \
    --cluster-name ${CLUSTER_NAME} \
    --association-id ${ASSOCIATION_ID} \
    --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:ListAllMyBuckets","s3:CreateBucket"],"Resource":"*"}]}' \
    --region ${AWS_REGION}

Sau khi chờ cho bộ nhớ đệm thông tin xác thực hết hạn, pod giờ đây sẽ có thể liệt kê và tạo S3 buckets. AWS CloudTrail ghi lại tất cả các sự kiện, vì vậy bạn có thể kiểm tra và giám sát tất cả hoạt động của vai trò IAM, bao gồm cả chính sách phiên, cho mục đích bảo mật và tuân thủ.

Hiểu về xác thực chính sách phiên

EKS Pod Identity xác thực chính sách phiên khi bạn tạo hoặc cập nhật một liên kết pod identity, cung cấp phản hồi ngay lập tức nếu có bất kỳ vấn đề nào. Quá trình xác thực bao gồm:

  1. Xác thực định dạng JSON: EKS Pod Identity xác thực rằng chính sách là JSON hợp lệ
  2. Xác thực ký tự: EKS Pod Identity xác minh rằng chính sách của bạn chỉ chứa các ký tự hợp lệ
  3. Xác thực kích thước: EKS Pod Identity xác nhận rằng chính sách không vượt quá 2.048 ký tự
  4. Xác thực lược đồ chính sách IAM: EKS Pod Identity xác thực theo các yêu cầu cấu trúc chính sách IAM bằng cách thực hiện một lệnh gọi thử nghiệm đến AWS STS
  5. Xác thực kích thước chính sách đóng gói: EKS Pod Identity đảm bảo rằng chính sách phiên không vượt quá giới hạn STS sau khi nén

Những cân nhắc quan trọng

Phần này phác thảo các ràng buộc và yêu cầu chính trước khi áp dụng chính sách phiên với EKS Pod Identity. Nó bao gồm sự tương tác của chúng với thẻ phiên, các quy tắc đánh giá quyền và cách các chính sách được áp dụng trong các kịch bản cùng tài khoản và liên tài khoản.

Thẻ phiên và chính sách phiên

Thẻ phiên không thể được sử dụng với chính sách phiên. Khi bạn chỉ định một chính sách phiên, bạn phải đặt --disable-session-tags thành true. Đây là một yêu cầu, không phải là một tối ưu hóa tùy chọn.

Giao thoa quyền

Chính sách phiên chỉ có thể hạn chế quyền, không thể mở rộng chúng. Các quyền hiệu quả luôn là giao thoa của:

  1. Các chính sách dựa trên danh tính của vai trò IAM
  2. Chính sách phiên (nếu được cung cấp)

Điều này đảm bảo rằng chính sách phiên duy trì các ranh giới bảo mật và không thể được sử dụng để leo thang đặc quyền vượt quá những gì vai trò IAM cho phép.

Áp dụng chính sách phiên

Chính sách phiên được áp dụng khác nhau tùy thuộc vào việc bạn có đang sử dụng vai trò đích hay không. Vai trò đích cho phép các kịch bản truy cập liên tài khoản nơi các pod của bạn phải giả định một vai trò IAM trong một tài khoản AWS khác. Khi bạn chỉ định một vai trò đích, EKS Pod Identity thực hiện chuỗi vai trò IAM: nó trước tiên giả định vai trò nguồn (roleArn) trong tài khoản của bạn, sau đó sử dụng thông tin xác thực đó để giả định vai trò đích (targetRoleArn) trong một tài khoản khác.

Khi targetRoleArn được chỉ định (kịch bản liên tài khoản):

  • Chính sách phiên được áp dụng khi giả định vai trò đích, không phải vai trò nguồn ban đầu
  • Vai trò nguồn (roleArn) cần quyền để giả định vai trò đích bằng cách sử dụng các hành động sts:AssumeRole và sts:TagSession
  • Chính sách phiên hạn chế quyền của vai trò đích thông qua chuỗi vai trò IAM

Khi targetRoleArn không được chỉ định (kịch bản cùng tài khoản):

  • EKS Pod Identity áp dụng chính sách phiên trực tiếp cho roleArn khi nó giả định vai trò
  • Các quyền hiệu quả là giao thoa của các chính sách dựa trên danh tính của vai trò và chính sách phiên

Các cân nhắc khác

Sau đây là các cân nhắc bổ sung về tính khả dụng của dịch vụ và AWS Region, phiên bản Kubernetes và các yêu cầu về cơ sở hạ tầng dưới dạng mã (IaC).

  • Hỗ trợ phiên bản Kubernetes: Tính năng chính sách phiên EKS Pod Identity được hỗ trợ trên các phiên bản Kubernetes được hỗ trợ trong Amazon EKS.
  • Tính khả dụng của Region: Chính sách phiên có sẵn ở các AWS Commercial, Mainland China và AWS GovCloud (US) Regions nơi Amazon EKS được hỗ trợ.
  • Giới hạn liên kết vai trò: Bạn chỉ có thể liên kết một vai trò IAM với một tài khoản dịch vụ Kubernetes bằng cách sử dụng EKS Pod Identity. Tuy nhiên, bạn có thể cập nhật vai trò, vai trò đích và chính sách phiên sau này.
  • Hỗ trợ công cụ: Bạn có thể sử dụng AWS CloudFormation, eksctl, AWS CLI và Amazon EKS API để tạo liên kết pod identity với chính sách phiên.

Dọn dẹp

Quan trọng: Hoàn thành các bước dọn dẹp này để tránh các khoản phí liên tục cho các tài nguyên được tạo trong hướng dẫn này:

aws eks delete-pod-identity-association \
    --cluster-name ${CLUSTER_NAME} \
    --association-id ${ASSOCIATION_ID} \
    --region ${AWS_REGION}
kubectl delete serviceaccount ${SERVICE_ACCOUNT} -n ${NAMESPACE}
kubectl delete namespace ${NAMESPACE}
eksctl delete cluster -f cluster.yaml
aws iam delete-role-policy --role-name session-policy-demo-role --policy-name S3BroadAccess
aws iam delete-role --role-name session-policy-demo-role

Kết luận

Trong bài viết này, chúng tôi đã trình bày khả năng chính sách phiên mới của Amazon EKS Pod Identity, cho phép kiểm soát quyền chi tiết cho các khối lượng công việc Kubernetes mà không phải chịu gánh nặng quản lý hàng nghìn vai trò IAM. Với việc giới hạn quyền động ở cấp độ Pod Identity, tính năng này giúp bạn xây dựng các ứng dụng an toàn hơn, có khả năng mở rộng và dễ bảo trì hơn trên Amazon EKS trong khi tuân thủ nguyên tắc đặc quyền tối thiểu. Chúng tôi khuyến khích bạn bắt đầu sử dụng tính năng này và chia sẻ phản hồi của mình tại AWS Containers Roadmap.

Tài nguyên bổ sung

Về tác giả


Aditya Potdar là Kỹ sư Phần mềm trong nhóm Amazon EKS tại Amazon Web Services. Với kinh nghiệm làm việc tại nhiều công ty công nghệ hàng đầu, anh chuyên về kiến trúc và cung cấp cơ sở hạ tầng dựa trên container hỗ trợ các hệ thống sản xuất quy mô lớn và khối lượng công việc học máy.


Ashok Srirama là Kiến trúc sư Giải pháp Chính tại Amazon Web Services, có trụ sở tại Washington Crossing, PA. Anh chuyên về các ứng dụng serverless, container và kiến trúc các hệ thống phân tán. Khi không dành thời gian cho gia đình, anh thích xem cricket và lái chiếc bimmer của mình.


George John là Giám đốc Sản phẩm Cấp cao cho Amazon Elastic Kubernetes Service (EKS) tại AWS, nơi anh thúc đẩy chiến lược sản phẩm và đổi mới cho một trong những nền tảng Kubernetes được quản lý hàng đầu trong ngành. Trong vai trò của mình, George làm việc chặt chẽ với khách hàng, đối tác và cộng đồng cloud-native rộng lớn hơn để định hình tương lai của điều phối container trên AWS. Khi không xây dựng sản phẩm, anh thích khám phá vùng Tây Bắc Thái Bình Dương cùng gia đình.

←
→

Leave a comment