Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Asosiasi Identitas EKS Pod AWS EKS telah memperkenalkan mekanisme baru yang disempurnakan yang disebut Pod Identity Association bagi administrator klaster untuk mengonfigurasi aplikasi Kubernetes agar menerima izin IAM yang diperlukan untuk terhubung dengan layanan AWS di luar klaster. Pod Identity Association memanfaatkan IRSA, namun membuatnya dapat dikonfigurasi secara langsung melalui EKS API, menghilangkan kebutuhan untuk menggunakan IAM API sama sekali. Akibatnya, peran IAM tidak perlu lagi mereferensikan [penyedia OIDC](iamserviceaccounts.md#iam-how-works) dan karenanya tidak akan terikat pada satu cluster lagi. Ini berarti, peran IAM sekarang dapat digunakan di beberapa kluster EKS tanpa perlu memperbarui kebijakan kepercayaan peran setiap kali cluster baru dibuat. Ini pada gilirannya, menghilangkan kebutuhan akan duplikasi peran dan menyederhanakan proses otomatisasi IRSA sama sekali. ## Prasyarat Di balik layar, implementasi asosiasi identitas pod menjalankan agen sebagai daemonset pada node pekerja. Untuk menjalankan agen pra-syarat di cluster, EKS menyediakan add-on baru yang disebut EKS Pod Identity Agent. Oleh karena itu, membuat asosiasi identitas pod (secara umum, dan dengan`eksctl`) memerlukan `eks-pod-identity-agent` addon yang sudah diinstal sebelumnya pada cluster. Addon ini dapat dibuat menggunakan dengan `eksctl` cara yang sama addon lain yang didukung. ``` eksctl create addon --cluster my-cluster --name eks-pod-identity-agent ``` Selain itu, jika menggunakan peran IAM yang sudah ada sebelumnya saat membuat asosiasi identitas pod, Anda harus mengonfigurasi peran tersebut untuk mempercayai prinsip layanan EKS () `pods.eks.amazonaws.com` yang baru diperkenalkan. Contoh kebijakan kepercayaan IAM dapat ditemukan di bawah ini: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` Jika sebaliknya Anda tidak memberikan ARN dari peran yang ada ke perintah create, `eksctl` akan membuat satu di belakang layar dan mengkonfigurasi kebijakan kepercayaan di atas. ## Membuat Asosiasi Identitas Pod Untuk memanipulasi asosiasi identitas pod, `eksctl` telah menambahkan bidang baru di bawah`iam.podIdentityAssociations`, mis. ``` iam: podIdentityAssociations: - namespace: #required serviceAccountName: #required createServiceAccount: true #optional, default is false roleARN: #required if none of permissionPolicyARNs, permissionPolicy and wellKnownPolicies is specified. Also, cannot be used together with any of the three other referenced fields. roleName: #optional, generated automatically if not provided, ignored if roleARN is provided permissionPolicy: {} #optional permissionPolicyARNs: [] #optional wellKnownPolicies: {} #optional permissionsBoundaryARN: #optional tags: {} #optional ``` Untuk contoh lengkap, lihat [pod-identity-associations.yaml.](https://github.com/eksctl-io/eksctl/blob/main/examples/39-pod-identity-association.yaml) **catatan** Selain `permissionPolicy` yang digunakan sebagai dokumen kebijakan inline, semua bidang lainnya memiliki mitra bendera CLI. Membuat asosiasi identitas pod dapat dicapai dengan cara-cara berikut. Selama pembuatan klaster, dengan menentukan asosiasi identitas pod yang diinginkan sebagai bagian dari file konfigurasi dan menjalankan: ``` eksctl create cluster -f config.yaml ``` Posting pembuatan cluster, menggunakan salah satu file konfigurasi mis. ``` eksctl create podidentityassociation -f config.yaml ``` ATAU menggunakan bendera CLI mis. ``` eksctl create podidentityassociation \ --cluster my-cluster \ --namespace default \ --service-account-name s3-reader \ --permission-policy-arns="arn:aws:iam::111122223333:policy/permission-policy-1, arn:aws:iam::111122223333:policy/permission-policy-2" \ --well-known-policies="autoScaler,externalDNS" \ --permissions-boundary-arn arn:aws:iam::111122223333:policy/permissions-boundary ``` **catatan** Hanya satu peran IAM yang dapat dikaitkan dengan akun layanan pada satu waktu. Oleh karena itu, mencoba membuat asosiasi identitas pod kedua untuk akun layanan yang sama akan menghasilkan kesalahan. ## Mengambil Asosiasi Identitas Pod Untuk mengambil semua asosiasi identitas pod untuk klaster tertentu, jalankan salah satu perintah berikut: ``` eksctl get podidentityassociation -f config.yaml ``` ATAU ``` eksctl get podidentityassociation --cluster my-cluster ``` Selain itu, untuk mengambil hanya asosiasi identitas pod dalam namespace tertentu, gunakan flag, mis. `--namespace` ``` eksctl get podidentityassociation --cluster my-cluster --namespace default ``` Akhirnya, untuk mengambil satu asosiasi, sesuai dengan akun layanan K8s tertentu, juga termasuk `--service-account-name` ke perintah di atas, mis. ``` eksctl get podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Memperbarui Asosiasi Identitas Pod Untuk memperbarui peran IAM dari satu atau beberapa asosiasi identitas pod, teruskan yang baru `roleARN(s)` ke file konfigurasi misalnya ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader roleARN: new-role-arn-1 - namespace: dev serviceAccountName: app-cache-access roleARN: new-role-arn-2 ``` dan jalankan: ``` eksctl update podidentityassociation -f config.yaml ``` ATAU (untuk memperbarui satu asosiasi) meneruskan yang baru `--role-arn` melalui flag CLI: ``` eksctl update podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader --role-arn new-role-arn ``` ## Menghapus Asosiasi Identitas Pod Untuk menghapus satu atau beberapa asosiasi identitas pod, teruskan `namespace(s)` dan `serviceAccountName(s)` ke file konfigurasi misalnya ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader - namespace: dev serviceAccountName: app-cache-access ``` dan jalankan: ``` eksctl delete podidentityassociation -f config.yaml ``` ATAU (untuk menghapus satu asosiasi) meneruskan `--namespace` dan `--service-account-name` melalui flag CLI: ``` eksctl delete podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## EKS Dukungan add-on untuk asosiasi identitas pod Pengaya EKS juga mendukung penerimaan izin IAM melalui Asosiasi Identitas Pod EKS. File konfigurasi mengekspos tiga bidang yang memungkinkan konfigurasi ini:`addon.podIdentityAssociations`, dan. `addonsConfig.autoApplyPodIdentityAssociations` `addon.useDefaultPodIdentityAssociations` Anda dapat secara eksplisit mengonfigurasi asosiasi identitas pod yang diinginkan, menggunakan`addon.podIdentityAssociations`, atau `eksctl` secara otomatis menyelesaikan (dan menerapkan) konfigurasi identitas pod yang direkomendasikan, menggunakan salah satu atau`addonsConfig.autoApplyPodIdentityAssociations`. `addon.useDefaultPodIdentityAssociations` **catatan** Tidak semua Pengaya EKS akan mendukung asosiasi identitas pod saat peluncuran. Untuk kasus ini, izin IAM yang diperlukan akan terus diberikan menggunakan pengaturan [IRSA](addons.md#addons-create). ### Membuat addons dengan izin IAM Saat membuat addon yang memerlukan izin IAM, pertama-tama `eksctl` akan memeriksa apakah asosiasi identitas pod atau pengaturan IRSA sedang dikonfigurasi secara eksplisit sebagai bagian dari file konfigurasi, dan jika demikian, gunakan salah satunya untuk mengonfigurasi izin untuk addon. misalnya ``` addons: - name: vpc-cni podIdentityAssociations: - serviceAccountName: aws-node permissionPolicyARNs: ["arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"] ``` dan lari ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] pod identity associations are set for "vpc-cni" addon; will use these to configure required IAM permissions ``` **catatan** Menyetel identitas pod dan IRSA secara bersamaan tidak diperbolehkan, dan akan menghasilkan kesalahan validasi. Untuk Eks Add-on yang mendukung identitas pod, `eksctl` menawarkan opsi untuk secara otomatis mengonfigurasi izin IAM yang direkomendasikan, pada pembuatan addon. Ini dapat dicapai hanya dengan menyetel `addonsConfig.autoApplyPodIdentityAssociations: true` di file konfigurasi. misalnya ``` addonsConfig: autoApplyPodIdentityAssociations: true # bear in mind that if either pod identity or IRSA configuration is explicitly set in the config file, # or if the addon does not support pod identities, # addonsConfig.autoApplyPodIdentityAssociations won't have any effect. addons: - name: vpc-cni ``` dan lari ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] "addonsConfig.autoApplyPodIdentityAssociations" is set to true; will lookup recommended pod identity configuration for "vpc-cni" addon ``` Secara setara, hal yang sama dapat dilakukan melalui flag CLI misalnya ``` eksctl create addon --cluster my-cluster --name vpc-cni --auto-apply-pod-identity-associations ``` Untuk memigrasikan addon yang ada untuk menggunakan identitas pod dengan kebijakan IAM yang direkomendasikan, gunakan ``` addons: - name: vpc-cni useDefaultPodIdentityAssociations: true ``` ``` eksctl update addon -f config.yaml ``` ### Memperbarui addons dengan izin IAM Saat memperbarui addon, menentukan `addon.PodIdentityAssociations` akan mewakili satu sumber kebenaran untuk status yang akan dimiliki addon, setelah operasi pembaruan selesai. Di belakang layar, berbagai jenis operasi dilakukan untuk mencapai keadaan yang diinginkan yaitu + buat identitas pod yang ada di file konfigurasi, tetapi tidak ada di cluster + hapus identitas pod yang ada yang telah dihapus dari file konfigurasi, bersama dengan sumber daya IAM terkait + perbarui identitas pod yang ada yang juga ada di file konfigurasi, dan set izin IAM telah berubah **catatan** Siklus hidup asosiasi identitas pod yang dimiliki oleh Eks Add-on ditangani langsung oleh EKS Addons API. Anda tidak dapat menggunakan `eksctl update podidentityassociation` (untuk memperbarui izin IAM) atau `eksctl delete podidentityassociations` (untuk menghapus asosiasi) untuk asosiasi yang digunakan dengan Add-on Amazon EKS. Sebaliknya, `eksctl update addon` atau `eksctl delete addon` akan digunakan. Mari kita lihat contoh di atas, dimulai dengan menganalisis konfigurasi identitas pod awal untuk addon: ``` eksctl get podidentityassociation --cluster my-cluster --namespace opentelemetry-operator-system --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-JwrGA4mn1Ny8", # OwnerARN is populated when the pod identity lifecycle is handled by the EKS Addons API "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-Xc7qVg5fgCqr", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" } ] ``` Sekarang gunakan konfigurasi di bawah ini: ``` addons: - name: adot podIdentityAssociations: # For the first association, the permissions policy of the role will be updated - serviceAccountName: adot-col-prom-metrics permissionPolicyARNs: #- arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy # The second association will be deleted, as it's been removed from the config file #- serviceAccountName: adot-col-otlp-ingest # permissionPolicyARNs: # - arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess # The third association will be created, as it's been added to the config file - serviceAccountName: adot-col-container-logs permissionPolicyARNs: - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy ``` dan lari ``` eksctl update addon -f config.yaml ... # updating the permission policy for the first association 2024-05-14 13:27:43 [ℹ] updating IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for pod identity association "a-reaxk2uz1iknwazwj" 2024-05-14 13:27:44 [ℹ] waiting for CloudFormation changeset "eksctl-opentelemetry-operator-system-adot-col-prom-metrics-update-1715682463" for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] updated IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for "a-reaxk2uz1iknwazwj" # creating the IAM role for the second association 2024-05-14 13:28:48 [ℹ] deploying stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:28:48 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:29:19 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" # updating the addon, which handles the pod identity config changes behind the scenes 2024-05-14 13:29:19 [ℹ] updating addon # deleting the IAM role for the third association 2024-05-14 13:29:19 [ℹ] deleting IAM resources for pod identity service account adot-col-otlp-ingest 2024-05-14 13:29:20 [ℹ] will delete stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:20 [ℹ] waiting for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" to get deleted 2024-05-14 13:29:51 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:51 [ℹ] deleted IAM resources for addon adot ``` sekarang periksa apakah konfigurasi identitas pod telah diperbarui dengan benar ``` eksctl get podidentityassociation --cluster my-cluster --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-nQAlp0KktS2A", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-1k1XhAdziGzX", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" } ] ``` Untuk menghapus semua asosiasi identitas pod dari addon, `addon.PodIdentityAssociations` harus disetel secara eksplisit ke, mis. `[]` ``` addons: - name: vpc-cni # omitting the `podIdentityAssociations` field from the config file, # instead of explicitly setting it to [], will result in a validation error podIdentityAssociations: [] ``` dan lari ``` eksctl update addon -f config.yaml ``` ### Menghapus addons dengan izin IAM Menghapus addon juga akan menghapus semua identitas pod yang terkait dengan addon. Menghapus cluster akan mencapai efek yang sama, untuk semua addons. Setiap peran IAM untuk identitas pod, yang dibuat oleh`eksctl`, akan dihapus juga. ## Migrasi iamserviceaccounts dan addons yang ada ke asosiasi identitas pod Ada perintah `eksctl` utils untuk memigrasi Peran IAM yang ada untuk akun layanan ke asosiasi identitas pod, yaitu ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve ``` Di belakang layar, perintah akan menerapkan langkah-langkah berikut: + instal `eks-pod-identity-agent` addon jika belum aktif di cluster + mengidentifikasi semua Peran IAM yang terkait dengan iamserviceaccounts + mengidentifikasi semua Peran IAM yang terkait dengan addon EKS yang mendukung asosiasi identitas pod + memperbarui kebijakan kepercayaan IAM dari semua peran yang diidentifikasi, dengan entitas tepercaya tambahan, menunjuk ke prinsip Layanan EKS yang baru (dan, secara opsional, menghapus hubungan kepercayaan penyedia OIDC yang keluar) + buat asosiasi identitas pod untuk peran yang difilter yang terkait dengan iamserviceaccounts + perbarui addons EKS dengan identitas pod (EKS API akan membuat identitas pod di belakang layar) Menjalankan perintah tanpa `--approve` bendera hanya akan menampilkan rencana yang terdiri dari serangkaian tugas yang mencerminkan langkah-langkah di atas, mis. ``` [ℹ] (plan) would migrate 2 iamserviceaccount(s) and 2 addon(s) to pod identity association(s) by executing the following tasks [ℹ] (plan) 3 sequential tasks: { install eks-pod-identity-agent addon, ## tasks for migrating the addons 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-DDuMLoeZ8weD", migrate addon aws-ebs-csi-driver to pod identity, }, 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-xYiPFOVp1aeI", migrate addon vpc-cni to pod identity, }, }, ## tasks for migrating the iamserviceaccounts 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-QLXqHcq9O1AR", create pod identity association for service account "default/sa1", }, 2 sequential sub-tasks: { update trust policy for unowned role "Unowned-Role1", create pod identity association for service account "default/sa2", }, } } [ℹ] all tasks were skipped [!] no changes were applied, run again with '--approve' to apply the changes ``` Hubungan kepercayaan penyedia OIDC yang ada selalu dihapus dari Peran IAM yang terkait dengan Pengaya EKS. Selain itu, untuk menghapus hubungan kepercayaan penyedia OIDC yang ada dari Peran IAM yang terkait dengan iamserviceaccounts, jalankan perintah dengan flag, mis. `--remove-oidc-provider-trust-relationship` ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve --remove-oidc-provider-trust-relationship ``` ## Dukungan Identitas Pod Lintas Akun eksctl mendukung akses lintas akun [EKS Pod Identity](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html). Fitur ini memungkinkan pod yang berjalan di kluster EKS Anda untuk mengakses sumber daya AWS di akun AWS yang berbeda. ### Penggunaan Untuk membuat asosiasi identitas pod dengan akses lintas akun, pertama-tama siapkan Peran dan Kebijakan IAM yang memungkinkan akses dari akun AWS sumber (dengan klaster) ke akun AWS target (dengan sumber daya yang dapat diakses klaster). Untuk contoh ini, lihat [“Amazon EKS Pod Identity merampingkan akses lintas akun.”](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-streamlines-cross-account-access/) Setelah Peran IAM dikonfigurasi di setiap akun, gunakan eksctl untuk membuat asosiasi identitas pod: ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: # The cluster name and service account name should match the target # account policy's trust relationship. name: my-cluster region: us-west-2 version: "1.32" addons: - name: vpc-cni - name: coredns - name: kube-proxy - name: eks-pod-identity-agent iam: podIdentityAssociations: - namespace: default serviceAccountName: demo-app-sa createServiceAccount: true # The source role in the same account as the cluster roleARN: arn:aws:iam::1111111111:role/account-a-role # The target role in a different account targetRoleARN: arn:aws:iam::2222222222:role/account-b-role # Optional: Disable session tags disableSessionTags: false managedNodeGroups: - name: my-cluster instanceType: m6a.large privateNetworking: true minSize: 2 desiredCapacity: 2 maxSize: 3 ``` ## Referensi lebih lanjut [AWS Userdocs resmi untuk EKS Dukungan Add-on untuk identitas pod](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-iam.html) [Posting Blog AWS Resmi di Asosiasi Identitas Pod](https://aws.amazon.com/blogs/aws/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/) [Dokumen pengguna AWS resmi untuk Asosiasi Identitas Pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)