**Bantu tingkatkan halaman ini**
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih **Edit halaman ini pada GitHub** tautan yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pelajari cara kerja kontrol akses di Amazon EKS
Pelajari cara mengelola akses ke klaster Amazon EKS Anda. Menggunakan Amazon EKS membutuhkan pengetahuan tentang bagaimana Kubernetes dan AWS Identity and Access Management (AWS IAM) menangani kontrol akses.
**Bagian ini meliputi:**
**[Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md)**— Pelajari cara mengaktifkan aplikasi atau pengguna untuk melakukan autentikasi ke Kubernetes API. Anda dapat menggunakan entri akses, aws-auth ConfigMap, atau penyedia OIDC eksternal.
**[Lihat sumber daya Kubernetes di Konsol Manajemen AWS](view-kubernetes-resources.md)**— Pelajari cara mengonfigurasi Konsol Manajemen AWS untuk berkomunikasi dengan kluster Amazon EKS Anda. Gunakan konsol untuk melihat sumber daya Kubernetes di klaster, seperti namespace, node, dan Pod.
**[AWS Layanan hibah akses tulis ke Kubernetes APIs](mutate-kubernetes-resources.md)**— Pelajari tentang izin yang diperlukan untuk memodifikasi sumber daya Kubernetes.
**[Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md)**— Pelajari cara mengonfigurasi kubectl untuk berkomunikasi dengan cluster Amazon EKS Anda. Gunakan AWS CLI untuk membuat file kubeconfig.
**[Berikan akses beban kerja Kubernetes untuk AWS menggunakan Akun Layanan Kubernetes](service-accounts.md)**— Pelajari cara mengaitkan akun layanan Kubernetes dengan AWS Peran IAM. Anda dapat menggunakan Pod Identity atau IAM Roles for Service Accounts (IRSA).
## Tugas Umum
+ Beri pengembang akses ke API Kubernetes. Lihat sumber daya Kubernetes di file. Konsol Manajemen AWS
+ Solusi: [Gunakan entri akses](access-entries.md) untuk mengaitkan izin RBAC Kubernetes dengan Pengguna atau Peran IAM. AWS
+ Konfigurasikan kubectl untuk berbicara dengan klaster Amazon EKS menggunakan Credentials. AWS
+ Solusi: Gunakan AWS CLI untuk [membuat file kubeconfig](create-kubeconfig.md).
+ Gunakan penyedia identitas eksternal, seperti Ping Identity, untuk mengautentikasi pengguna ke Kubernetes API.
+ Solusi: [Tautkan penyedia OIDC eksternal](authenticate-oidc-identity-provider.md).
+ Berikan beban kerja pada klaster Kubernetes Anda kemampuan untuk menelepon. AWS APIs
+ Solusi: [Gunakan Pod Identity](pod-identities.md) untuk mengaitkan Peran AWS IAM ke Akun Layanan Kubernetes.
## Latar Belakang
+ [Pelajari cara kerja Akun Layanan Kubernetes.](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Tinjau Model Kubernetes Role Based Access Control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ Untuk informasi selengkapnya tentang mengelola akses ke AWS sumber daya, lihat [Panduan Pengguna AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html). Atau, ikuti [pelatihan pengantar gratis tentang penggunaan AWS IAM](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam).
## Pertimbangan untuk Mode Otomatis EKS
Mode Otomatis EKS terintegrasi dengan entri akses EKS Pod Identity dan EKS EKS.
+ Mode Otomatis EKS menggunakan entri akses untuk memberikan izin pada bidang kontrol EKS Kubernetes. Misalnya, kebijakan akses mengaktifkan Mode Otomatis EKS untuk membaca informasi tentang titik akhir dan layanan jaringan.
+ Anda tidak dapat menonaktifkan entri akses pada kluster Mode Otomatis EKS.
+ Anda dapat secara opsional mengaktifkan. `aws-auth` `ConfigMap`
+ Entri akses untuk Mode Otomatis EKS dikonfigurasi secara otomatis. Anda dapat melihat entri akses ini, tetapi Anda tidak dapat memodifikasinya.
+ Jika Anda menggunakan NodeClass untuk membuat Peran IAM Node kustom, Anda perlu membuat entri akses untuk peran tersebut menggunakan kebijakan EKSAuto NodePolicy akses Amazon.
+ Jika Anda ingin memberikan izin beban kerja untuk AWS layanan, gunakan EKS Pod Identity.
+ Anda tidak perlu menginstal agen Pod Identity pada kluster Mode Otomatis EKS.
# Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs
Cluster Anda memiliki endpoint API Kubernetes. Kubectl menggunakan API ini. Anda dapat mengautentikasi ke API ini menggunakan dua jenis identitas:
+ ***Prinsip AWS * Identity and Access Management (IAM) and Access Management (peran atau pengguna) - Jenis ini memerlukan otentikasi ke IAM**. Pengguna dapat masuk AWS sebagai pengguna [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) atau dengan [identitas federasi](https://aws.amazon.com/identity/federation/) dengan menggunakan kredensyal yang disediakan melalui sumber identitas. Pengguna hanya dapat masuk dengan identitas federasi jika administrator Anda sebelumnya menyiapkan federasi identitas menggunakan peran IAM. Ketika pengguna mengakses AWS dengan menggunakan federasi, mereka secara tidak langsung [mengambil peran](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole). Saat pengguna menggunakan jenis identitas ini, Anda:
+ Dapat menetapkan mereka izin Kubernetes sehingga mereka dapat bekerja dengan objek Kubernetes di klaster Anda. Untuk informasi selengkapnya tentang cara menetapkan izin ke prinsipal IAM Anda sehingga mereka dapat mengakses objek Kubernetes di klaster Anda, lihat. [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md)
+ Dapat menetapkan mereka izin IAM sehingga mereka dapat bekerja dengan kluster Amazon EKS Anda dan sumber dayanya menggunakan Amazon EKS API, AWS CLI,,, atau. AWS CloudFormation Konsol Manajemen AWS`eksctl` Untuk informasi selengkapnya, lihat [Tindakan yang ditentukan oleh Amazon Elastic Kubernetes Service di Referensi Otorisasi Layanan.](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)
+ Node bergabung dengan cluster Anda dengan mengasumsikan peran IAM. Kemampuan untuk mengakses klaster Anda menggunakan prinsipal IAM disediakan oleh [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), yang berjalan di bidang kontrol Amazon EKS.
+ **Pengguna di penyedia OpenID Connect (OIDC) Anda sendiri — Jenis ini memerlukan otentikasi ke penyedia** [OIDC Anda.](https://openid.net/connect/) Untuk informasi selengkapnya tentang menyiapkan penyedia OIDC Anda sendiri dengan klaster Amazon EKS Anda, lihat. [Beri pengguna akses ke Kubernetes dengan penyedia OIDC eksternal](authenticate-oidc-identity-provider.md) Saat pengguna menggunakan jenis identitas ini, Anda:
+ Dapat menetapkan mereka izin Kubernetes sehingga mereka dapat bekerja dengan objek Kubernetes di klaster Anda.
+ Tidak dapat menetapkan mereka izin IAM sehingga mereka dapat bekerja dengan kluster Amazon EKS Anda dan sumber dayanya menggunakan Amazon EKS API, AWS CLI,,, atau. AWS CloudFormation Konsol Manajemen AWS`eksctl`
Anda dapat menggunakan kedua jenis identitas dengan cluster Anda. Metode otentikasi IAM tidak dapat dinonaktifkan. Metode otentikasi OIDC adalah opsional.
## Kaitkan Identitas IAM dengan Izin Kubernetes
[AWS IAM Authenticator untuk Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) diinstal pada control plane cluster Anda. Ini memungkinkan prinsipal (peran [dan pengguna)AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM) yang Anda izinkan untuk mengakses sumber daya Kubernetes di klaster Anda. Anda dapat mengizinkan prinsipal IAM untuk mengakses objek Kubernetes di klaster Anda menggunakan salah satu metode berikut:
+ **Membuat entri akses** — Jika klaster Anda berada pada atau lebih lambat dari versi platform yang tercantum di bagian [Prasyarat](access-entries.md) untuk versi Kubernetes klaster Anda, kami sarankan Anda menggunakan opsi ini.
Gunakan *entri akses* untuk mengelola izin Kubernetes dari prinsipal IAM dari luar klaster. Anda dapat menambahkan dan mengelola akses ke cluster dengan menggunakan EKS API, AWS Command Line Interface AWS SDKs, AWS CloudFormation, dan Konsol Manajemen AWS. Ini berarti Anda dapat mengelola pengguna dengan alat yang sama dengan yang Anda buat dengan cluster.
Untuk memulai, ikuti [Ubah mode autentikasi untuk menggunakan entri akses, lalu Memigrasi entri ConfigMap ](setting-up-access-entries.md) [aws-auth yang ada untuk](migrating-access-entries.md) mengakses entri.
+ **Menambahkan entri ke `aws-auth` `ConfigMap`** — Jika versi platform cluster Anda lebih awal dari versi yang tercantum di bagian [Prasyarat](access-entries.md), maka Anda harus menggunakan opsi ini. Jika versi platform klaster Anda pada atau lebih lambat dari versi platform yang tercantum di bagian [Prasyarat](access-entries.md) untuk versi Kubernetes klaster Anda, dan Anda telah menambahkan entri ke`ConfigMap`, maka sebaiknya Anda memigrasikan entri tersebut untuk mengakses entri. `ConfigMap`Namun, Anda tidak dapat memigrasikan entri yang ditambahkan Amazon EKS, seperti entri untuk peran IAM yang digunakan dengan grup node terkelola atau profil Fargate. Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](#grant-k8s-access).
+ Jika Anda harus menggunakan `aws-auth` `ConfigMap` opsi, Anda dapat menambahkan entri ke `ConfigMap` menggunakan `eksctl create iamidentitymapping` perintah. Untuk informasi selengkapnya, lihat [Mengelola pengguna dan peran IAM](https://eksctl.io/usage/iam-identity-mappings/) dalam `eksctl` dokumentasi.
## Mengatur Mode Autentikasi Klaster
Setiap cluster memiliki *mode otentikasi*. Mode otentikasi menentukan metode mana yang dapat Anda gunakan untuk mengizinkan prinsipal IAM mengakses objek Kubernetes di klaster Anda. Ada tiga mode otentikasi.
**penting**
Setelah metode entri akses diaktifkan, itu tidak dapat dinonaktifkan.
Jika `ConfigMap` metode ini tidak diaktifkan selama pembuatan cluster, itu tidak dapat diaktifkan nanti. Semua cluster yang dibuat sebelum pengenalan entri akses memiliki `ConfigMap` metode yang diaktifkan.
Jika Anda menggunakan node hybrid dengan cluster Anda, Anda harus menggunakan mode otentikasi `API` atau `API_AND_CONFIG_MAP` cluster.
**Bagian `aws-auth` `ConfigMap` dalam cluster**
Ini adalah mode otentikasi asli untuk cluster Amazon EKS. Prinsipal IAM yang menciptakan cluster adalah pengguna awal yang dapat mengakses cluster dengan menggunakan`kubectl`. Pengguna awal harus menambahkan pengguna lain ke daftar di `aws-auth` `ConfigMap` dan menetapkan izin yang memengaruhi pengguna lain dalam cluster. Pengguna lain ini tidak dapat mengelola atau menghapus pengguna awal, karena tidak ada entri di `ConfigMap` to manage.
**Baik entri `ConfigMap` dan akses**
Dengan mode otentikasi ini, Anda dapat menggunakan kedua metode untuk menambahkan prinsip IAM ke cluster. Perhatikan bahwa setiap metode menyimpan entri terpisah; misalnya, jika Anda menambahkan entri akses dari AWS CLI, tidak `aws-auth` `ConfigMap` diperbarui.
**Akses entri saja**
Dengan mode otentikasi ini, Anda dapat menggunakan EKS API, AWS Command Line Interface, AWS SDKs, AWS CloudFormation, dan Konsol Manajemen AWS untuk mengelola akses ke cluster untuk prinsipal IAM.
Setiap entri akses memiliki *tipe* dan Anda dapat menggunakan kombinasi *cakupan akses* untuk membatasi prinsipal ke namespace tertentu dan *kebijakan akses untuk menetapkan kebijakan* izin yang dapat digunakan kembali yang telah dikonfigurasi sebelumnya. Atau, Anda dapat menggunakan tipe STANDARD dan grup RBAC Kubernetes untuk menetapkan izin khusus.
| Mode autentikasi | Metode |
| --- | --- |
| `ConfigMap`hanya (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| EKS API dan `ConfigMap` (`API_AND_CONFIG_MAP`) | mengakses entri di EKS API, Antarmuka Baris AWS Perintah AWS SDKs, AWS CloudFormation, dan Konsol Manajemen AWS `aws-auth` `ConfigMap` |
| EKS API saja (`API`) | mengakses entri di EKS API, Antarmuka Baris AWS Perintah, AWS SDKs AWS CloudFormation, dan Konsol Manajemen AWS |
**catatan**
Mode Otomatis Amazon EKS memerlukan entri Akses.
# Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS
Bagian ini dirancang untuk menunjukkan kepada Anda cara mengelola akses utama IAM ke klaster Kubernetes di Amazon Elastic Kubernetes Service (EKS) menggunakan entri akses dan kebijakan. Anda akan menemukan detail tentang mengubah mode autentikasi, bermigrasi dari `aws-auth` ConfigMap entri lama, membuat, memperbarui, dan menghapus entri akses, mengaitkan kebijakan dengan entri, meninjau izin kebijakan yang telah ditentukan sebelumnya, serta prasyarat dan pertimbangan utama untuk manajemen akses yang aman.
## Gambaran Umum
Entri akses EKS adalah cara terbaik untuk memberikan pengguna akses ke Kubernetes API. Misalnya, Anda dapat menggunakan entri akses untuk memberi pengembang akses untuk menggunakan kubectl. Pada dasarnya, entri akses EKS mengaitkan satu set izin Kubernetes dengan identitas IAM, seperti peran IAM. Misalnya, pengembang dapat mengambil peran IAM dan menggunakannya untuk mengautentikasi ke Kluster EKS.
## Fitur
+ **Otentikasi dan Otorisasi Terpusat**: Mengontrol akses ke klaster Kubernetes secara langsung melalui Amazon APIs EKS, menghilangkan kebutuhan untuk beralih AWS antara dan Kubernetes untuk izin pengguna. APIs
+ **Manajemen Izin Granular: Menggunakan entri akses dan kebijakan untuk menentukan izin** berbutir halus untuk prinsipal AWS IAM, termasuk memodifikasi atau mencabut akses cluster-admin dari pembuatnya.
+ **Integrasi Alat IAC**: Mendukung infrastruktur sebagai alat kode seperti AWS CloudFormation, Terraform, dan AWS CDK untuk menentukan konfigurasi akses selama pembuatan cluster.
+ **Misconfiguration Recovery**: Memungkinkan pemulihan akses klaster melalui Amazon EKS API tanpa akses API Kubernetes langsung.
+ **Pengurangan Overhead dan Keamanan yang Ditingkatkan**: Memusatkan operasi untuk menurunkan overhead sambil memanfaatkan fitur AWS IAM seperti pencatatan CloudTrail audit dan otentikasi multi-faktor.
## Cara melampirkan izin
Anda dapat melampirkan izin Kubernetes untuk mengakses entri dengan dua cara:
+ Gunakan kebijakan akses. Kebijakan akses adalah templat izin Kubernetes yang telah ditentukan sebelumnya yang dikelola oleh. AWS Untuk informasi selengkapnya, lihat [Tinjau izin kebijakan akses](access-policy-permissions.md).
+ Referensi grup Kubernetes. Jika Anda mengaitkan Identitas IAM dengan grup Kubernetes, Anda dapat membuat sumber daya Kubernetes yang memberikan izin grup. Untuk informasi selengkapnya, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dalam dokumentasi Kubernetes.
## Pertimbangan
Saat mengaktifkan entri akses EKS pada kluster yang ada, ingatlah hal berikut:
+ **Perilaku Cluster Legacy**: Untuk kluster yang dibuat sebelum pengenalan entri akses (yang memiliki versi platform awal lebih awal dari yang ditentukan dalam [persyaratan versi Platform](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)), EKS secara otomatis membuat entri akses yang mencerminkan izin yang sudah ada sebelumnya. Entri ini mencakup identitas IAM yang awalnya membuat cluster dan izin administratif yang diberikan kepada identitas tersebut selama pembuatan klaster.
+ **Menangani Legacy `aws-auth` ConfigMap**: Jika klaster Anda bergantung pada warisan `aws-auth` ConfigMap untuk manajemen akses, hanya entri akses untuk pembuat klaster asli yang dibuat secara otomatis setelah mengaktifkan entri akses. Peran atau izin tambahan yang ditambahkan ke ConfigMap (misalnya, peran IAM khusus untuk pengembang atau layanan) tidak dimigrasikan secara otomatis. Untuk mengatasinya, buat entri akses yang sesuai secara manual.
## Memulai
1. Tentukan kebijakan Identitas dan Akses IAM yang ingin Anda gunakan.
+ [Tinjau izin kebijakan akses](access-policy-permissions.md)
1. Aktifkan Entri Akses EKS di klaster Anda. Konfirmasikan bahwa Anda memiliki versi platform yang didukung.
+ [Ubah mode otentikasi untuk menggunakan entri akses](setting-up-access-entries.md)
1. Buat entri akses yang mengaitkan Identitas IAM dengan izin Kubernetes.
+ [Buat entri akses](creating-access-entries.md)
1. Otentikasi ke cluster menggunakan identitas IAM.
+ [Mengatur AWS CLI](install-awscli.md)
+ [Mengatur `kubectl` dan `eksctl`](install-kubectl.md)
# Mengaitkan kebijakan akses dengan entri akses
*Anda dapat menetapkan satu atau beberapa kebijakan akses untuk *mengakses jenis entri*.* `STANDARD` Amazon EKS secara otomatis memberikan jenis entri akses lainnya izin yang diperlukan agar berfungsi dengan baik di klaster Anda. Kebijakan akses Amazon EKS mencakup izin Kubernetes, bukan izin IAM. Sebelum mengaitkan kebijakan akses ke entri akses, pastikan Anda sudah terbiasa dengan izin Kubernetes yang disertakan dalam setiap kebijakan akses. Untuk informasi selengkapnya, lihat [Tinjau izin kebijakan akses](access-policy-permissions.md). Jika tidak ada kebijakan akses yang memenuhi persyaratan Anda, maka jangan kaitkan kebijakan akses ke entri akses. Sebagai gantinya, tentukan satu atau beberapa *nama grup* untuk entri akses dan buat serta kelola objek kontrol akses berbasis peran Kubernetes. Untuk informasi selengkapnya, lihat [Buat entri akses](creating-access-entries.md).
+ Entri akses yang ada. Untuk membuatnya, lihat [Buat entri akses](creating-access-entries.md).
+ Peran AWS Identity and Access Management atau pengguna dengan izin berikut:`ListAccessEntries`,`DescribeAccessEntry`,`UpdateAccessEntry`,, `ListAccessPolicies``AssociateAccessPolicy`, dan`DisassociateAccessPolicy`. *Untuk informasi selengkapnya, lihat [Tindakan yang ditentukan oleh Amazon Elastic Kubernetes Service di Referensi Otorisasi Layanan.](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)*
Sebelum mengaitkan kebijakan akses dengan entri akses, pertimbangkan persyaratan berikut:
+ Anda dapat mengaitkan beberapa kebijakan akses ke setiap entri akses, tetapi Anda hanya dapat mengaitkan setiap kebijakan ke entri akses satu kali. Jika Anda mengaitkan beberapa kebijakan akses, prinsipal IAM entri akses memiliki semua izin yang disertakan dalam semua kebijakan akses terkait.
+ Anda dapat membuat cakupan kebijakan akses ke semua sumber daya di klaster atau dengan menentukan nama satu atau beberapa ruang nama Kubernetes. Anda dapat menggunakan karakter wildcard untuk nama namespace. Misalnya, jika Anda ingin membuat cakupan kebijakan akses ke semua ruang nama yang dimulai`dev-`, Anda dapat menentukan `dev-*` sebagai nama namespace. Pastikan bahwa namespace ada di cluster Anda dan ejaan Anda cocok dengan nama namespace yang sebenarnya di cluster. Amazon EKS tidak mengonfirmasi ejaan atau keberadaan ruang nama di cluster Anda.
+ Anda dapat mengubah *cakupan akses* untuk kebijakan akses setelah Anda mengaitkannya ke entri akses. Jika Anda telah mencakup kebijakan akses ke ruang nama Kubernetes, Anda dapat menambahkan dan menghapus namespace untuk asosiasi tersebut, jika diperlukan.
+ Jika Anda mengaitkan kebijakan akses ke entri akses yang juga memiliki *nama grup* yang ditentukan, maka prinsipal IAM memiliki semua izin di semua kebijakan akses terkait. Ia juga memiliki semua izin di Kubernetes `Role` atau `ClusterRole` objek apa pun yang ditentukan dalam Kubernetes `Role` dan `RoleBinding` objek apa pun yang menentukan nama grup.
+ Jika Anda menjalankan `kubectl auth can-i --list` perintah, Anda tidak akan melihat izin Kubernetes yang ditetapkan oleh kebijakan akses yang terkait dengan entri akses untuk prinsipal IAM yang Anda gunakan saat menjalankan perintah. Perintah hanya menampilkan izin Kubernetes jika Anda telah memberikannya di Kubernetes `Role` atau `ClusterRole` objek yang telah Anda ikat ke nama grup atau nama pengguna yang Anda tentukan untuk entri akses.
+ Jika Anda meniru pengguna atau grup Kubernetes saat berinteraksi dengan objek Kubernetes di klaster Anda, seperti menggunakan `kubectl` perintah dengan `--as username ` atau`--as-group group-name `, Anda memaksa penggunaan otorisasi Kubernetes RBAC. Akibatnya, prinsipal IAM tidak memiliki izin yang ditetapkan oleh kebijakan akses apa pun yang terkait dengan entri akses. Satu-satunya izin Kubernetes yang dimiliki pengguna atau grup yang ditiru oleh kepala sekolah IAM adalah izin Kubernetes yang Anda berikan kepada mereka di Kubernetes `Role` atau objek yang Anda ikat ke nama grup atau nama pengguna. `ClusterRole` Agar prinsipal IAM Anda memiliki izin dalam kebijakan akses terkait, jangan menyamar sebagai pengguna atau grup Kubernetes. Prinsipal IAM juga akan tetap memiliki izin apa pun yang Anda berikan di Kubernetes `Role` atau `ClusterRole` objek yang telah Anda ikat ke nama grup atau nama pengguna yang Anda tentukan untuk entri akses. Untuk informasi selengkapnya, lihat [Peniruan identitas pengguna di dokumentasi](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) Kubernetes.
Anda dapat mengaitkan kebijakan akses ke entri akses menggunakan Konsol Manajemen AWS atau AWS CLI.
## Konsol Manajemen AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama klaster yang memiliki entri akses yang ingin Anda kaitkan dengan kebijakan akses.
1. Pilih tab **Access**.
1. Jika jenis entri akses adalah **Standar**, Anda dapat mengaitkan atau memisahkan **kebijakan akses** Amazon EKS. Jika jenis entri akses Anda adalah apa pun selain **Standar**, maka opsi ini tidak tersedia.
1. Pilih **Kebijakan akses asosiasi**.
1. Untuk **nama Kebijakan**, pilih kebijakan dengan izin yang Anda inginkan untuk memiliki kepala sekolah IAM. Untuk melihat izin yang disertakan dalam setiap kebijakan, lihat[Tinjau izin kebijakan akses](access-policy-permissions.md).
1. Untuk **cakupan Access**, pilih cakupan akses. Jika Anda memilih **Cluster**, izin dalam kebijakan akses diberikan kepada prinsipal IAM untuk sumber daya di semua ruang nama Kubernetes. **Jika Anda memilih namespace **Kubernetes, Anda dapat memilih Add new namespace**.** Di bidang **Namespace** yang muncul, Anda dapat memasukkan nama namespace Kubernetes di klaster Anda. Jika Anda ingin prinsipal IAM memiliki izin di beberapa ruang nama, maka Anda dapat memasukkan beberapa ruang nama.
1. Pilih **Tambahkan kebijakan akses**.
## AWS CLI
1. Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
1. Lihat kebijakan akses yang tersedia.
```
aws eks list-access-policies --output table
```
Contoh output adalah sebagai berikut.
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
Untuk melihat izin yang disertakan dalam setiap kebijakan, lihat[Tinjau izin kebijakan akses](access-policy-permissions.md).
1. Lihat entri akses yang ada. Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks list-access-entries --cluster-name my-cluster
```
Contoh output adalah sebagai berikut.
```
{
"accessEntries": [
"arn:aws: iam::111122223333:role/my-role",
"arn:aws: iam::111122223333:user/my-user"
]
}
```
1. Kaitkan kebijakan akses ke entri akses. Contoh berikut mengaitkan kebijakan `AmazonEKSViewPolicy` akses ke entri akses. Setiap kali peran *my-role* IAM mencoba mengakses objek Kubernetes di klaster, Amazon EKS akan mengotorisasi peran tersebut untuk menggunakan izin dalam kebijakan untuk mengakses objek Kubernetes di ruang nama dan Kubernetes saja. *my-namespace1* *my-namespace2* Ganti *my-cluster* dengan nama klaster Anda, *111122223333* dengan ID AWS akun Anda, dan *my-role* dengan nama peran IAM yang Anda inginkan Amazon EKS untuk mengotorisasi akses ke objek cluster Kubernetes.
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
Jika Anda ingin kepala sekolah IAM memiliki izin di seluruh klaster, ganti dengan. `type=namespace,namespaces=my-namespace1,my-namespace2 ` `type=cluster` Jika Anda ingin mengaitkan beberapa kebijakan akses ke entri akses, jalankan perintah beberapa kali, masing-masing dengan kebijakan akses unik. Setiap kebijakan akses terkait memiliki ruang lingkupnya sendiri.
**catatan**
Jika nanti Anda ingin mengubah cakupan kebijakan akses terkait, jalankan perintah sebelumnya lagi dengan cakupan baru. Misalnya, jika Anda ingin menghapus*my-namespace2*, Anda akan menjalankan perintah lagi `type=namespace,namespaces=my-namespace1 ` hanya dengan menggunakan. Jika Anda ingin mengubah cakupan dari `namespace` ke`cluster`, Anda akan menjalankan perintah lagi menggunakan`type=cluster`, menghapus`type=namespace,namespaces=my-namespace1,my-namespace2 `.
1. Tentukan kebijakan akses mana yang terkait dengan entri akses.
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/my-role
```
Contoh output adalah sebagai berikut.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
Pada contoh sebelumnya, prinsipal IAM untuk entri akses ini memiliki izin tampilan di semua ruang nama di klaster, dan izin administrator ke dua ruang nama Kubernetes.
1. Memutuskan kebijakan akses dari entri akses. Dalam contoh ini, `AmazonEKSAdminPolicy` kebijakan dilepaskan dari entri akses. Prinsipal IAM mempertahankan izin dalam kebijakan `AmazonEKSViewPolicy` akses untuk objek di *my-namespace1* dan *my-namespace2* ruang nama, karena kebijakan akses tersebut tidak terlepas dari entri akses.
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/my-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
Untuk mencantumkan kebijakan akses yang tersedia, lihat[Tinjau izin kebijakan akses](access-policy-permissions.md).
# Migrasi entri yang ada untuk `aws-auth ConfigMap` mengakses entri
Jika Anda telah menambahkan entri ke `aws-auth` `ConfigMap` pada klaster Anda, kami sarankan Anda membuat entri akses untuk entri yang ada di Anda. `aws-auth` `ConfigMap` Setelah membuat entri akses, Anda dapat menghapus entri dari entri Anda. `ConfigMap` Anda tidak dapat mengaitkan [kebijakan akses](access-policies.md) ke entri di. `aws-auth` `ConfigMap` Jika Anda ingin mengaitkan kebijakan akses ke prinsipal IAM Anda, buat entri akses.
**penting**
Saat cluster berada dalam mode `API_AND_CONFIGMAP` otentikasi dan ada pemetaan untuk peran IAM yang sama di entri akses `aws-auth` `ConfigMap` dan dalam entri akses, peran tersebut akan menggunakan pemetaan entri akses untuk otentikasi. Entri akses lebih diutamakan daripada `ConfigMap` entri untuk prinsipal IAM yang sama.
Sebelum menghapus `aws-auth` `ConfigMap` entri yang ada yang dibuat oleh Amazon EKS untuk [grup node terkelola](managed-node-groups.md) atau profil [Fargate](fargate-profile.md) ke klaster Anda, periksa kembali apakah entri akses yang benar untuk sumber daya spesifik tersebut ada di klaster Amazon EKS Anda. Jika Anda menghapus entri yang dibuat Amazon EKS `ConfigMap` tanpa memiliki entri akses yang setara, klaster Anda tidak akan berfungsi dengan baik.
## Prasyarat
+ Keakraban dengan entri akses dan kebijakan akses. Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md) dan [Mengaitkan kebijakan akses dengan entri akses](access-policies.md).
+ Cluster yang ada dengan versi platform yang pada atau lebih lambat dari versi yang tercantum dalam Prasyarat topik. [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md)
+ Versi `0.215.0` atau yang lebih baru dari alat baris `eksctl` perintah yang diinstal pada perangkat Anda atau AWS CloudShell. Untuk menginstal atau memperbarui`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
+ Izin Kubernetes untuk memodifikasi di `aws-auth` `ConfigMap` namespace. `kube-system`
+ Peran AWS Identity and Access Management atau pengguna dengan izin berikut: `CreateAccessEntry` dan`ListAccessEntries`. Untuk informasi selengkapnya, lihat [Tindakan yang ditentukan oleh Amazon Elastic Kubernetes Service di Referensi Otorisasi Layanan.](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)
## `eksctl`
1. Lihat entri yang ada di Anda`aws-auth ConfigMap`. Ganti *my-cluster* dengan nama klaster Anda.
```
eksctl get iamidentitymapping --cluster my-cluster
```
Contoh output adalah sebagai berikut.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws: iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:user/my-user my-user
arn:aws: iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws: iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. [Buat entri akses](creating-access-entries.md)untuk salah satu `ConfigMap` entri yang Anda buat kembali di output sebelumnya. Saat membuat entri akses, pastikan untuk menentukan nilai yang sama untuk`ARN`,, `USERNAME``GROUPS`, dan `ACCOUNT` dikembalikan dalam output Anda. Dalam contoh keluaran, Anda akan membuat entri akses untuk semua entri kecuali dua entri terakhir, karena entri tersebut dibuat oleh Amazon EKS untuk profil Fargate dan grup node terkelola.
1. Hapus entri dari entri akses apa pun yang Anda `ConfigMap` buat. Jika Anda tidak menghapus entri dari`ConfigMap`, pengaturan untuk entri akses untuk ARN utama IAM akan menggantikan `ConfigMap` entri. Ganti *111122223333* dengan ID AWS akun Anda dan *EKS-my-cluster-my-namespace-Viewers* dengan nama peran dalam entri di akun Anda`ConfigMap`. Jika entri yang Anda hapus adalah untuk pengguna IAM, bukan peran IAM, ganti `role` dengan `user` dan *EKS-my-cluster-my-namespace-Viewers* dengan nama pengguna.
```
eksctl delete iamidentitymapping --arn arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# Tinjau izin kebijakan akses
Kebijakan akses termasuk `rules` yang berisi Kubernetes `verbs` (izin) dan. `resources` Kebijakan akses tidak menyertakan izin atau sumber daya IAM. Mirip dengan Kubernetes `Role` dan `ClusterRole` objek, kebijakan akses hanya menyertakan. `allow` `rules` Anda tidak dapat mengubah konten kebijakan akses. Anda tidak dapat membuat kebijakan akses Anda sendiri. Jika izin dalam kebijakan akses tidak memenuhi kebutuhan Anda, buat objek Kubernetes RBAC dan tentukan nama *grup* untuk entri akses Anda. Untuk informasi selengkapnya, lihat [Buat entri akses](creating-access-entries.md). Izin yang terdapat dalam kebijakan akses mirip dengan izin di peran klaster yang dihadapi pengguna Kubernetes. Untuk informasi selengkapnya, lihat [Peran yang dihadapi pengguna dalam dokumentasi](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) Kubernetes.
## Daftar semua kebijakan
Gunakan salah satu kebijakan akses yang tercantum di halaman ini, atau ambil daftar semua kebijakan akses yang tersedia menggunakan AWS CLI:
```
aws eks list-access-policies
```
Output yang diharapkan akan terlihat seperti ini (disingkat singkatnya):
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## EKSAdminKebijakan Amazon
Kebijakan akses ini mencakup izin yang memberikan izin utama IAM untuk sumber daya. Ketika dikaitkan dengan entri akses, cakupan aksesnya biasanya satu atau beberapa ruang nama Kubernetes. Jika Anda ingin prinsipal IAM memiliki akses administrator ke semua sumber daya di klaster Anda, kaitkan kebijakan [Amazon EKSCluster AdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) akses ke entri akses Anda.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## Amazon EKSCluster AdminPolicy
Kebijakan akses ini mencakup izin yang memberikan akses administrator utama IAM ke klaster. Ketika dikaitkan dengan entri akses, cakupan aksesnya biasanya adalah klaster, bukan namespace Kubernetes. Jika Anda ingin kepala sekolah IAM memiliki ruang lingkup administratif yang lebih terbatas, pertimbangkan untuk mengaitkan kebijakan [EKSAdminKebijakan Amazon](#access-policy-permissions-amazoneksadminpolicy) akses ke entri akses Anda.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Grup API Kubernetes | Kubernetes NonSumber Daya URLs | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## Amazon EKSAdmin ViewPolicy
Kebijakan akses ini mencakup izin yang memberikan akses utama IAM ke list/view semua sumber daya dalam klaster. Perhatikan bahwa ini termasuk Rahasia [Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/).
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## EKSEditKebijakan Amazon
Kebijakan akses ini mencakup izin yang memungkinkan prinsipal IAM untuk mengedit sebagian besar sumber daya Kubernetes.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## EKSViewKebijakan Amazon
Kebijakan akses ini mencakup izin yang memungkinkan prinsipal IAM untuk melihat sebagian besar sumber daya Kubernetes.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`,`events`,`limitranges`,`namespaces/status`,`pods/log`,`pods/status`,`replicationcontrollers/status`,`resourcequotas`, r `esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## Amazon EKSSecret ReaderPolicy
Kebijakan akses ini mencakup izin yang memungkinkan kepala sekolah IAM membaca Rahasia [Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/).
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## Amazon EKSAuto NodePolicy
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
Kebijakan ini mencakup izin berikut yang memungkinkan komponen Amazon EKS menyelesaikan tugas-tugas berikut:
+ `kube-proxy`— Pantau titik akhir dan layanan jaringan, dan kelola acara terkait. Ini memungkinkan fungsionalitas proxy jaringan di seluruh cluster.
+ `ipamd`— Kelola sumber daya jaringan AWS VPC dan antarmuka jaringan kontainer (CNI). Hal ini memungkinkan daemon manajemen alamat IP untuk menangani jaringan pod.
+ `coredns`— Akses sumber daya penemuan layanan seperti titik akhir dan layanan. Ini memungkinkan resolusi DNS dalam cluster.
+ `ebs-csi-driver`— Bekerja dengan sumber daya terkait penyimpanan untuk volume Amazon EBS. Hal ini memungkinkan penyediaan dinamis dan lampiran volume persisten.
+ `neuron`— Pantau node dan pod untuk perangkat AWS Neuron. Hal ini memungkinkan pengelolaan AWS akselerator Inferentia dan Trainium.
+ `node-monitoring-agent`— Akses diagnostik dan acara node. Hal ini memungkinkan pemantauan kesehatan cluster dan pengumpulan diagnostik.
Setiap komponen menggunakan akun layanan khusus dan dibatasi hanya untuk izin yang diperlukan untuk fungsi spesifiknya.
Jika Anda secara manual menentukan peran IAM Node dalam a NodeClass, Anda perlu membuat Entri Akses yang mengaitkan peran IAM Node baru dengan Kebijakan Akses ini.
## Amazon EKSBlock StoragePolicy
**catatan**
Kebijakan ini ditujukan hanya untuk peran AWS terkait layanan dan tidak dapat digunakan dengan peran yang dikelola pelanggan.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS mengelola pemilihan pemimpin dan sumber daya koordinasi untuk operasi penyimpanan:
+ `coordination.k8s.io`— Membuat dan mengelola objek sewa untuk pemilihan pemimpin. Hal ini memungkinkan komponen penyimpanan EKS untuk mengoordinasikan kegiatan mereka di seluruh cluster melalui mekanisme pemilihan pemimpin.
Kebijakan ini mencakup sumber daya sewa khusus yang digunakan oleh komponen penyimpanan EKS untuk mencegah akses yang bertentangan ke sumber daya koordinasi lain di cluster.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan penyimpanan blok berfungsi dengan baik.
## Amazon EKSLoad BalancingPolicy
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS mengelola sumber daya pemilihan pemimpin untuk penyeimbangan beban:
+ `coordination.k8s.io`— Membuat dan mengelola objek sewa untuk pemilihan pemimpin. Hal ini memungkinkan komponen penyeimbang beban EKS untuk mengoordinasikan aktivitas di beberapa replika dengan memilih pemimpin.
Kebijakan ini dicakup secara khusus untuk memuat penyeimbangan sumber daya sewa untuk memastikan koordinasi yang tepat sekaligus mencegah akses ke sumber daya sewa lainnya di cluster.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan jaringan berfungsi dengan baik.
## EKSNetworkingKebijakan Amazon
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS mengelola sumber daya pemilihan pemimpin untuk jaringan:
+ `coordination.k8s.io`— Membuat dan mengelola objek sewa untuk pemilihan pemimpin. Hal ini memungkinkan komponen jaringan EKS untuk mengoordinasikan aktivitas alokasi alamat IP dengan memilih pemimpin.
Kebijakan ini dicakup secara khusus untuk jaringan sumber daya sewa untuk memastikan koordinasi yang tepat sambil mencegah akses ke sumber daya sewa lainnya di cluster.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan jaringan berfungsi dengan baik.
## EKSComputeKebijakan Amazon
**catatan**
Kebijakan ini ditujukan hanya untuk peran AWS terkait layanan dan tidak dapat digunakan dengan peran yang dikelola pelanggan.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS mengelola sumber daya pemilihan pemimpin untuk operasi komputasi:
+ `coordination.k8s.io`— Membuat dan mengelola objek sewa untuk pemilihan pemimpin. Hal ini memungkinkan komponen komputasi EKS untuk mengoordinasikan aktivitas penskalaan node dengan memilih pemimpin.
Kebijakan ini dicakup secara khusus untuk menghitung sumber daya sewa manajemen sambil memungkinkan akses baca dasar (`get`,`watch`) ke semua sumber daya sewa di cluster.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan jaringan berfungsi dengan baik.
## Amazon EKSBlock StorageClusterPolicy
**catatan**
Kebijakan ini ditujukan hanya untuk peran AWS terkait layanan dan tidak dapat digunakan dengan peran yang dikelola pelanggan.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
Kebijakan ini memberikan izin yang diperlukan untuk kemampuan penyimpanan blok Mode Otomatis Amazon EKS. Ini memungkinkan pengelolaan sumber daya penyimpanan blok yang efisien dalam kluster Amazon EKS. Kebijakan ini mencakup izin berikut:
Manajemen Driver CSI:
+ Buat, baca, perbarui, dan hapus driver CSI, khusus untuk penyimpanan blok.
Manajemen Volume:
+ Buat daftar, tonton, buat, perbarui, tambal, dan hapus volume persisten.
+ Buat daftar, tonton, dan perbarui klaim volume persisten.
+ Patch status klaim volume persisten.
Interaksi Node dan Pod:
+ Baca informasi node dan pod.
+ Kelola acara yang terkait dengan operasi penyimpanan.
Kelas dan Atribut Penyimpanan:
+ Baca kelas penyimpanan dan node CSI.
+ Baca kelas atribut volume.
Lampiran Volume:
+ Buat daftar, tonton, dan ubah lampiran volume dan statusnya.
Operasi Snapshot:
+ Kelola snapshot volume, konten snapshot, dan kelas snapshot.
+ Menangani operasi untuk snapshot grup volume dan sumber daya terkait.
Kebijakan ini dirancang untuk mendukung manajemen penyimpanan blok komprehensif dalam kluster Amazon EKS yang berjalan dalam Mode Otomatis. Ini menggabungkan izin untuk berbagai operasi termasuk penyediaan, melampirkan, mengubah ukuran, dan snapshotting volume penyimpanan blok.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan penyimpanan blok berfungsi dengan baik.
## Amazon EKSCompute ClusterPolicy
**catatan**
Kebijakan ini ditujukan hanya untuk peran AWS terkait layanan dan tidak dapat digunakan dengan peran yang dikelola pelanggan.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
Kebijakan ini memberikan izin yang diperlukan untuk kemampuan manajemen komputasi Mode Otomatis Amazon EKS. Ini memungkinkan orkestrasi dan penskalaan sumber daya komputasi yang efisien dalam kluster Amazon EKS. Kebijakan ini mencakup izin berikut:
Manajemen Node:
+ Membuat, membaca, memperbarui, menghapus, dan mengelola status NodePools dan NodeClaims.
+ Kelola NodeClasses, termasuk pembuatan, modifikasi, dan penghapusan.
Penjadwalan dan Manajemen Sumber Daya:
+ Baca akses ke pod, node, volume persisten, klaim volume persisten, pengontrol replikasi, dan ruang nama.
+ Baca akses ke kelas penyimpanan, node CSI, dan lampiran volume.
+ Daftar dan tonton penerapan, set daemon, set replika, dan set stateful.
+ Baca anggaran gangguan pod.
Penanganan Acara:
+ Buat, baca, dan kelola acara cluster.
Pencabutan Node dan Penggusuran Pod:
+ Perbarui, tambal, dan hapus node.
+ Buat penggusuran pod dan hapus pod bila perlu.
Manajemen Definisi Sumber Daya Kustom (CRD):
+ Buat yang baru CRDs.
+ Kelola spesifik CRDs yang terkait dengan manajemen node (NodeClasses NodePools, NodeClaims,, dan NodeDiagnostics).
Kebijakan ini dirancang untuk mendukung manajemen komputasi komprehensif dalam kluster Amazon EKS yang berjalan dalam Mode Otomatis. Ini menggabungkan izin untuk berbagai operasi termasuk penyediaan node, penjadwalan, penskalaan, dan optimasi sumber daya.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan manajemen komputasi berfungsi dengan baik.
## Amazon EKSLoad BalancingClusterPolicy
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
Kebijakan ini memberikan izin yang diperlukan untuk kemampuan penyeimbangan beban Mode Otomatis Amazon EKS. Ini memungkinkan manajemen dan konfigurasi sumber daya penyeimbang beban yang efisien dalam kluster Amazon EKS. Kebijakan ini mencakup izin berikut:
Manajemen Acara dan Sumber Daya:
+ Membuat dan menambal acara.
+ Baca akses ke pod, node, endpoint, dan namespace.
+ Perbarui status pod.
Manajemen Layanan dan Ingress:
+ Manajemen penuh layanan dan statusnya.
+ Kontrol komprehensif atas masuknya dan statusnya.
+ Baca akses ke irisan titik akhir dan kelas ingress.
Binding Grup Sasaran:
+ Membuat dan memodifikasi binding grup target dan statusnya.
+ Baca akses ke parameter kelas ingress.
Manajemen Definisi Sumber Daya Kustom (CRD):
+ Buat dan baca semuanya CRDs.
+ Manajemen khusus targetgroupbindings.eks.amazonaws.com dan ingressclassparams.eks.amazonaws.com. CRDs
Konfigurasi Webhook:
+ Membuat dan membaca mutasi dan memvalidasi konfigurasi webhook.
+ Kelola eks-load-balancing-webhook konfigurasi.
Kebijakan ini dirancang untuk mendukung manajemen load balancing yang komprehensif dalam klaster Amazon EKS yang berjalan dalam Mode Otomatis. Ini menggabungkan izin untuk berbagai operasi termasuk eksposur layanan, perutean masuk, dan integrasi dengan layanan penyeimbangan AWS beban.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan penyeimbangan beban berfungsi dengan baik.
## Amazon EKSNetworking ClusterPolicy
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
Amazon EKSNetworking ClusterPolicy
Kebijakan ini memberikan izin yang diperlukan untuk kemampuan jaringan Amazon EKS Auto Mode. Ini memungkinkan manajemen dan konfigurasi sumber daya jaringan yang efisien dalam kluster Amazon EKS. Kebijakan ini mencakup izin berikut:
Manajemen Node dan Pod:
+ Baca akses ke NodeClasses dan status mereka.
+ Baca akses ke NodeClaims dan status mereka.
+ Baca akses ke pod.
Manajemen Node CNI:
+ Izin untuk CNINodes dan statusnya, termasuk membuat, membaca, memperbarui, menghapus, dan menambal.
Manajemen Definisi Sumber Daya Kustom (CRD):
+ Buat dan baca semuanya CRDs.
+ Manajemen khusus (pembaruan, tambalan, hapus) dari CNinodes.eks.amazonaws.com CRD.
Manajemen Acara:
+ Membuat dan menambal acara.
Kebijakan ini dirancang untuk mendukung manajemen jaringan yang komprehensif dalam kluster Amazon EKS yang berjalan dalam Mode Otomatis. Ini menggabungkan izin untuk berbagai operasi termasuk konfigurasi jaringan node, manajemen CNI (Container Network Interface), dan penanganan sumber daya khusus terkait.
Kebijakan ini memungkinkan komponen jaringan untuk berinteraksi dengan sumber daya terkait node, mengelola konfigurasi node khusus CNI, dan menangani sumber daya khusus yang penting untuk operasi jaringan di cluster.
Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM klaster saat Mode Otomatis diaktifkan, memastikan bahwa izin yang diperlukan tersedia agar kemampuan jaringan berfungsi dengan baik.
## EKSHybridKebijakan Amazon
**catatan**
Kebijakan ini ditujukan hanya untuk peran AWS terkait layanan dan tidak dapat digunakan dengan peran yang dikelola pelanggan.
Kebijakan akses ini mencakup izin yang memberikan EKS akses ke node klaster. Ketika dikaitkan dengan entri akses, cakupan aksesnya biasanya adalah klaster, bukan namespace Kubernetes. Kebijakan ini digunakan oleh node hibrida Amazon EKS.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Grup API Kubernetes | Kubernetes NonSumber Daya URLs | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## Amazon EKSCluster InsightsPolicy
**catatan**
Kebijakan ini ditujukan hanya untuk peran AWS terkait layanan dan tidak dapat digunakan dengan peran yang dikelola pelanggan.
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
Kebijakan ini memberikan izin hanya-baca untuk fungsionalitas Amazon EKS Cluster Insights. Kebijakan ini mencakup izin berikut:
Akses Node: - Daftar dan lihat node cluster - Baca informasi status node
DaemonSet Akses: - Baca akses ke konfigurasi kube-proxy
Kebijakan ini dikelola secara otomatis oleh layanan EKS untuk Cluster Insights. Untuk informasi selengkapnya, lihat [Bersiaplah untuk upgrade versi Kubernetes dan pecahkan masalah kesalahan konfigurasi dengan wawasan klaster](cluster-insights.md).
## AWSBackupFullAccessPolicyForBackup
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
Kebijakan ini memberikan izin yang diperlukan untuk AWS Cadangan untuk mengelola dan membuat cadangan Kluster EKS. Kebijakan ini mencakup izin berikut:
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
Kebijakan ini memberikan izin yang diperlukan untuk AWS Cadangan untuk mengelola dan memulihkan cadangan Kluster EKS. Kebijakan ini mencakup izin berikut:
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## Amazon EKSACKPolicy
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
Kebijakan ini memberikan izin yang diperlukan untuk kemampuan AWS Controllers for Kubernetes (ACK) untuk mengelola sumber daya dari Kubernetes. AWS Kebijakan ini mencakup izin berikut:
Manajemen Sumber Daya Kustom ACK:
+ Akses penuh ke semua sumber daya kustom layanan ACK di 50\$1 AWS layanan termasuk S3, RDS, DynamoDB, Lambda, EC2, dan banyak lagi.
+ Buat, baca, perbarui, dan hapus definisi sumber daya khusus ACK.
Akses Namespace:
+ Baca akses ke ruang nama untuk organisasi sumber daya.
Pemilu Pemimpin:
+ Membuat dan membaca sewa koordinasi untuk pemilihan pimpinan.
+ Perbarui dan hapus sewa pengontrol layanan ACK tertentu.
Manajemen Acara:
+ Membuat dan menambal acara untuk operasi ACK.
Kebijakan ini dirancang untuk mendukung pengelolaan AWS sumber daya yang komprehensif melalui APIs Kubernetes. Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM kemampuan yang Anda berikan saat kemampuan ACK dibuat.
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(hanya sewa pengontrol layanan ACK tertentu) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## EKSArgoCDClusterKebijakan Amazon
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
Kebijakan ini memberikan izin tingkat klaster yang diperlukan untuk kemampuan Argo CD untuk menemukan sumber daya dan mengelola objek dengan cakupan klaster. Kebijakan ini mencakup izin berikut:
Manajemen Namespace:
+ Buat, baca, perbarui, dan hapus ruang nama untuk manajemen namespace aplikasi.
Manajemen Definisi Sumber Daya Kustom:
+ Kelola Argo CD-spesifik CRDs (Aplikasi,, AppProjects). ApplicationSets
Penemuan API:
+ Baca akses ke titik akhir API Kubernetes untuk penemuan sumber daya.
Kebijakan ini dirancang untuk mendukung operasi CD Argo tingkat cluster termasuk manajemen namespace dan instalasi CRD. Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM kemampuan yang Anda berikan saat kemampuan Argo CD dibuat.
| Grup API Kubernetes | Kubernetes NonSumber Daya URLs | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions`( CRDs Hanya CD Argo) | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## Amazon EKSArgo CDPolicy
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
Kebijakan ini memberikan izin tingkat ruang nama yang diperlukan untuk kemampuan Argo CD untuk menyebarkan dan mengelola aplikasi. Kebijakan ini mencakup izin berikut:
Manajemen Rahasia:
+ Akses penuh ke rahasia untuk kredensi Git dan rahasia klaster.
ConfigMap Akses:
+ Baca akses ConfigMaps untuk mengirim peringatan jika pelanggan mencoba menggunakan CD Argo yang tidak didukung. ConfigMaps
Manajemen Acara:
+ Baca dan buat acara untuk pelacakan siklus hidup aplikasi.
Manajemen Sumber Daya Argo CD:
+ Akses penuh ke Aplikasi, ApplicationSets, dan AppProjects.
+ Kelola finalizer dan status untuk sumber daya Argo CD.
Kebijakan ini dirancang untuk mendukung operasi CD Argo tingkat namespace termasuk penerapan dan manajemen aplikasi. Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM kemampuan yang Anda berikan saat kemampuan Argo CD dibuat, dicakup ke namespace Argo CD.
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## Amazon EKSKROPolicy
**ARN**–` arn:aws: eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
Kebijakan ini memberikan izin yang diperlukan untuk kemampuan kro (Kube Resource Orchestrator) untuk membuat dan mengelola Kubernetes kustom. APIs Kebijakan ini mencakup izin berikut:
Manajemen Sumber Daya Kro:
+ Akses penuh ke semua sumber daya kro termasuk ResourceGraphDefinitions dan instance sumber daya khusus.
Manajemen Definisi Sumber Daya Kustom:
+ Buat, baca, perbarui, dan hapus CRDs untuk kustom APIs yang ditentukan oleh ResourceGraphDefinitions.
Pemilu Pemimpin:
+ Membuat dan membaca sewa koordinasi untuk pemilihan pimpinan.
+ Perbarui dan hapus sewa pengontrol kro.
Manajemen Acara:
+ Membuat dan menambal acara untuk operasi kro.
Kebijakan ini dirancang untuk mendukung komposisi sumber daya yang komprehensif dan manajemen API kustom melalui kro. Amazon EKS secara otomatis membuat entri akses dengan kebijakan akses ini untuk peran IAM kemampuan yang Anda berikan saat kemampuan kro dibuat.
| Grup API Kubernetes | Sumber daya Kubernetes | Kata kerja Kubernetes (izin) |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(hanya sewa pengontrol kro) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## Akses pembaruan kebijakan
Lihat detail tentang pembaruan untuk mengakses kebijakan, sejak diperkenalkan. Untuk peringatan otomatis tentang perubahan pada halaman ini, berlangganan umpan RSS di. [Riwayat dokumen](doc-history.md)
| Ubah | Deskripsi | Date |
| --- | --- | --- |
| Tambahkan kebijakan untuk Kemampuan EKS | Publikasikan `AmazonEKSACKPolicy``AmazonEKSArgoCDClusterPolicy`,`AmazonEKSArgoCDPolicy`,, dan `AmazonEKSKROPolicy` untuk mengelola Kemampuan EKS | November 22, 2025 |
| Menambahkan `AmazonEKSSecretReaderPolicy` | Menambahkan kebijakan baru untuk akses read-only ke rahasia | November 6, 2025 |
| Tambahkan kebijakan untuk EKS Cluster Insights | Publikasikan `AmazonEKSClusterInsightsPolicy` | Desember 2, 2024 |
| Tambahkan kebijakan untuk Amazon EKS Hybrid | Publikasikan `AmazonEKSHybridPolicy` | Desember 2, 2024 |
| Tambahkan kebijakan untuk Mode Otomatis Amazon EKS | Kebijakan akses ini memberikan izin kepada Peran IAM Cluster dan Peran IAM Node untuk memanggil Kubernetes. APIs AWS menggunakan ini untuk mengotomatiskan tugas-tugas rutin untuk penyimpanan, komputasi, dan sumber daya jaringan. | Desember 2, 2024 |
| Menambahkan `AmazonEKSAdminViewPolicy` | Tambahkan kebijakan baru untuk akses tampilan yang diperluas, termasuk sumber daya seperti Rahasia. | April 23, 2024 |
| Kebijakan akses diperkenalkan. | Amazon EKS memperkenalkan kebijakan akses. | 29 Mei 2023 |
# Ubah mode otentikasi untuk menggunakan entri akses
Untuk mulai menggunakan entri akses, Anda harus mengubah mode otentikasi cluster ke mode `API_AND_CONFIG_MAP` atau`API`. Ini menambahkan API untuk entri akses.
## AWS Konsol
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama cluster tempat Anda ingin membuat entri akses.
1. Pilih tab **Access**.
1. Mode **otentikasi menunjukkan mode** otentikasi cluster saat ini. Jika mode mengatakan EKS API, Anda sudah dapat menambahkan entri akses dan Anda dapat melewati langkah-langkah yang tersisa.
1. Pilih **Kelola akses**.
1. Untuk **mode otentikasi Cluster**, pilih mode dengan EKS API. Perhatikan bahwa Anda tidak dapat mengubah mode otentikasi kembali ke mode yang menghapus API EKS dan entri akses.
1. Pilih **Simpan perubahan**. Amazon EKS mulai memperbarui cluster, status klaster berubah menjadi Memperbarui, dan perubahan dicatat di tab **Riwayat pembaruan**.
1. Tunggu status cluster kembali ke Aktif. Saat cluster Aktif, Anda dapat mengikuti langkah-langkah [Buat entri akses](creating-access-entries.md) untuk menambahkan akses ke cluster untuk prinsipal IAM.
## AWS CLI
1. Instal AWS CLI, seperti yang dijelaskan dalam [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di *Panduan Pengguna Antarmuka Baris AWS Perintah*.
1. Jalankan perintah berikut. Ganti *my-cluster* dengan nama klaster Anda. Jika Anda ingin menonaktifkan `ConfigMap` metode secara permanen, ganti `API_AND_CONFIG_MAP` dengan`API`.
Amazon EKS mulai memperbarui cluster, status klaster berubah menjadi UPDATE, dan perubahan dicatat dalam **aws eks list-updates**.
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. Tunggu status cluster kembali ke Aktif. Saat cluster Aktif, Anda dapat mengikuti langkah-langkah [Buat entri akses](creating-access-entries.md) untuk menambahkan akses ke cluster untuk prinsipal IAM.
## Versi platform yang diperlukan
Untuk menggunakan *entri akses*, klaster harus memiliki versi platform yang sama atau lebih lambat dari versi yang tercantum dalam tabel berikut, atau versi Kubernetes yang lebih lambat dari versi yang tercantum dalam tabel. Jika versi Kubernetes Anda tidak terdaftar, semua versi platform mendukung entri akses.
| Versi Kubernetes | Versi platform |
| --- | --- |
| Tidak Terdaftar | Semua Didukung |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
Untuk informasi selengkapnya, lihat [versi platform](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
# Buat entri akses
Sebelum membuat entri akses, pertimbangkan hal berikut:
+ Mode otentikasi yang diatur dengan benar. Lihat [Ubah mode otentikasi untuk menggunakan entri akses](setting-up-access-entries.md).
+ *Entri akses* mencakup Nama Sumber Daya Amazon (ARN) dari satu, dan hanya satu, prinsipal IAM yang ada. Prinsipal IAM tidak dapat dimasukkan dalam lebih dari satu entri akses. Pertimbangan tambahan untuk ARN yang Anda tentukan:
+ *Praktik terbaik IAM merekomendasikan untuk mengakses klaster Anda menggunakan *peran* IAM yang memiliki kredensi jangka pendek, daripada pengguna IAM yang memiliki kredensi jangka panjang.* Untuk informasi selengkapnya, lihat [Mewajibkan pengguna manusia untuk menggunakan federasi dengan penyedia identitas untuk mengakses AWS menggunakan kredensi sementara](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) di Panduan Pengguna *IAM*.
+ Jika ARN adalah untuk peran IAM, itu *dapat mencakup jalur*. ARNs dalam `aws-auth` `ConfigMap` entri, *tidak dapat* menyertakan jalur. Misalnya, ARN Anda bisa ` arn:aws: iam::<111122223333>:role/` atau. ` arn:aws: iam::<111122223333>:role/`
+ Jika jenis entri akses adalah apa pun selain `STANDARD` (lihat pertimbangan selanjutnya tentang jenis), ARN harus berada di AWS akun yang sama dengan cluster Anda. Jika jenisnya`STANDARD`, ARN bisa berada di akun yang sama, atau berbeda, dari AWS akun tempat cluster Anda berada.
+ Anda tidak dapat mengubah prinsipal IAM setelah entri akses dibuat.
+ Jika Anda pernah menghapus prinsipal IAM dengan ARN ini, entri akses tidak dihapus secara otomatis. Kami menyarankan Anda menghapus entri akses dengan ARN untuk prinsipal IAM yang Anda hapus. Jika Anda tidak menghapus entri akses dan membuat ulang prinsipal IAM, meskipun memiliki ARN yang sama, entri akses tidak akan berfungsi. Ini karena meskipun ARN sama untuk prinsipal IAM yang dibuat ulang, `roleID` atau `userID` (Anda dapat melihat ini dengan perintah `aws sts get-caller-identity` AWS CLI) berbeda untuk prinsipal IAM yang dibuat ulang daripada untuk prinsip IAM asli. Meskipun Anda tidak melihat kepala sekolah IAM `roleID` atau `userID` untuk entri akses, Amazon EKS menyimpannya dengan entri akses.
+ Setiap entri akses memiliki *tipe*. Jenis entri akses tergantung pada jenis sumber daya yang terkait dengannya, dan tidak menentukan izin. Jika Anda tidak menentukan jenis, Amazon EKS secara otomatis menyetel tipe ke `STANDARD`
+ `EC2_LINUX`- Untuk peran IAM yang digunakan dengan Linux atau Bottlerocket node yang dikelola sendiri
+ `EC2_WINDOWS`- Untuk peran IAM yang digunakan dengan node Windows yang dikelola sendiri
+ `FARGATE_LINUX`- Untuk peran IAM yang digunakan dengan AWS Fargate (Fargate)
+ `HYBRID_LINUX`- Untuk peran IAM yang digunakan dengan node hybrid
+ `STANDARD`- Jenis default jika tidak ada yang ditentukan
+ `EC2`- Untuk kelas simpul khusus Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Buat entri akses kelas node](create-node-class.md#auto-node-access-entry).
+ Anda tidak dapat mengubah jenis setelah entri akses dibuat.
+ Tidak perlu membuat entri akses untuk peran IAM yang digunakan untuk grup node terkelola atau profil Fargate. EKS akan membuat entri akses (jika diaktifkan), atau memperbarui peta konfigurasi autentikasi (jika entri akses tidak tersedia)
+ Jika jenis entri aksesnya`STANDARD`, Anda dapat menentukan *nama pengguna* untuk entri akses. Jika Anda tidak menentukan nilai untuk nama pengguna, Amazon EKS menetapkan salah satu nilai berikut untuk Anda, tergantung pada jenis entri akses dan apakah prinsipal IAM yang Anda tentukan adalah peran IAM atau pengguna IAM. Kecuali Anda memiliki alasan khusus untuk menentukan nama pengguna Anda sendiri, sebaiknya jangan tentukan nama pengguna dan biarkan Amazon EKS membuatnya secara otomatis untuk Anda. Jika Anda menentukan nama pengguna Anda sendiri:
+ Itu tidak bisa dimulai dengan`system:`,`eks:`,`aws:`,`amazon:`, atau`iam:`.
+ Jika nama pengguna untuk peran IAM, kami sarankan Anda menambahkan `{{SessionName}}` atau `{{SessionNameRaw}}` ke akhir nama pengguna Anda. Jika Anda menambahkan salah satu `{{SessionName}}` atau `{{SessionNameRaw}}` ke nama pengguna Anda, nama pengguna harus menyertakan titik dua *sebelum* \$1\$1SessionName\$1\$1. Ketika peran ini diasumsikan, nama nama sesi AWS STS yang ditentukan saat mengasumsikan peran secara otomatis diteruskan ke cluster dan akan muncul di CloudTrail log. Misalnya, Anda tidak dapat memiliki nama pengguna`john{{SessionName}}`. Nama pengguna harus `:john{{SessionName}}` atau`jo:hn{{SessionName}}`. Usus besar hanya harus sebelumnya`{{SessionName}}`. Nama pengguna yang dihasilkan oleh Amazon EKS dalam tabel berikut mencakup ARN. Karena ARN termasuk titik dua, ia memenuhi persyaratan ini. Titik dua tidak diperlukan jika Anda tidak menyertakan `{{SessionName}}` nama pengguna Anda. Perhatikan bahwa `{{SessionName}}` dalam karakter khusus “@” diganti dengan “-” di nama sesi. `{{SessionNameRaw}}`menyimpan semua karakter khusus dalam nama sesi.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/creating-access-entries.html)
Anda dapat mengubah nama pengguna setelah entri akses dibuat.
+ Jika jenis entri akses adalah`STANDARD`, dan Anda ingin menggunakan otorisasi Kubernetes RBAC, Anda dapat menambahkan satu atau beberapa nama *grup* ke entri akses. Setelah Anda membuat entri akses, Anda dapat menambahkan dan menghapus nama grup. Agar prinsipal IAM memiliki akses ke objek Kubernetes di klaster Anda, Anda harus membuat dan mengelola objek otorisasi berbasis peran Kubernetes (RBAC). Buat Kubernetes `RoleBinding` atau `ClusterRoleBinding` objek pada klaster Anda yang menentukan nama grup sebagai for. `subject` `kind: Group` Kubernetes mengotorisasi akses utama IAM ke objek klaster apa pun yang telah Anda tentukan dalam Kubernetes `Role` atau `ClusterRole` objek yang juga Anda tentukan dalam pengikatan Anda. `roleRef` Jika Anda menentukan nama grup, sebaiknya Anda terbiasa dengan objek Kubernetes role-based authorization (RBAC). Untuk informasi selengkapnya, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dalam dokumentasi Kubernetes.
**penting**
Amazon EKS tidak mengonfirmasi bahwa objek Kubernetes RBAC apa pun yang ada di klaster Anda menyertakan nama grup apa pun yang Anda tentukan. Misalnya, jika Anda membuat entri akses untuk grup yang saat ini tidak ada, EKS akan membuat grup alih-alih mengembalikan kesalahan.
*Alih-alih, atau sebagai tambahan, Kubernetes mengotorisasi akses utama IAM ke objek Kubernetes di klaster Anda, Anda dapat mengaitkan kebijakan akses Amazon EKS ke entri akses.* Amazon EKS mengotorisasi prinsipal IAM untuk mengakses objek Kubernetes di klaster Anda dengan izin dalam kebijakan akses. Anda dapat membuat cakupan izin kebijakan akses ke ruang nama Kubernetes yang Anda tentukan. Penggunaan kebijakan akses tidak mengharuskan Anda untuk mengelola objek Kubernetes RBAC. Untuk informasi selengkapnya, lihat [Mengaitkan kebijakan akses dengan entri akses](access-policies.md).
+ Jika Anda membuat entri akses dengan tipe `EC2_LINUX` atau`EC2_Windows`, prinsipal IAM yang membuat entri akses harus memiliki `iam:PassRole` izin. Untuk informasi selengkapnya, lihat [Memberikan izin pengguna untuk meneruskan peran ke AWS layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) di Panduan Pengguna *IAM*.
+ Mirip dengan [perilaku IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) standar, pembuatan dan pembaruan entri akses pada akhirnya konsisten, dan mungkin memerlukan beberapa detik untuk menjadi efektif setelah panggilan API awal berhasil dikembalikan. Anda harus merancang aplikasi Anda untuk memperhitungkan potensi penundaan ini. Kami menyarankan agar Anda tidak menyertakan entri akses yang dibuat atau diperbarui di jalur kode ketersediaan tinggi yang penting dari aplikasi Anda. Sebaliknya, buat perubahan dalam inisialisasi terpisah atau rutinitas pengaturan yang lebih jarang Anda lakukan. Selain itu, pastikan untuk memverifikasi bahwa perubahan telah dibuat merata sebelum alur kerja produksi bergantung padanya.
+ Entri akses tidak mendukung [peran terkait layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). Anda tidak dapat membuat entri akses di mana ARN utama adalah peran terkait layanan. Anda dapat mengidentifikasi peran terkait layanan dengan ARN mereka, yang ada dalam format. ` arn:aws: iam::*:role/aws-service-role/*`
Anda dapat membuat entri akses menggunakan Konsol Manajemen AWS atau AWS CLI.
## Konsol Manajemen AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama cluster tempat Anda ingin membuat entri akses.
1. Pilih tab **Access**.
1. Pilih **Buat entri akses**.
1. Untuk **prinsipal IAM**, pilih peran atau pengguna IAM yang ada. *Praktik terbaik IAM merekomendasikan untuk mengakses klaster Anda menggunakan *peran* IAM yang memiliki kredensi jangka pendek, daripada pengguna IAM yang memiliki kredensi jangka panjang.* Untuk informasi selengkapnya, lihat [Mewajibkan pengguna manusia untuk menggunakan federasi dengan penyedia identitas untuk mengakses AWS menggunakan kredensi sementara](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) di Panduan Pengguna *IAM*.
1. Untuk **Type**, jika entri akses adalah untuk peran node yang digunakan untuk EC2 node Amazon yang dikelola sendiri, pilih **EC2 Linux** atau **EC2 Windows**. Jika tidak, terima default (**Standar**).
1. Jika **Jenis** yang Anda pilih adalah **Standar** dan Anda ingin menentukan **Nama Pengguna**, masukkan nama pengguna.
1. **Jika **Tipe** yang Anda pilih adalah **Standar** dan Anda ingin menggunakan otorisasi Kubernetes RBAC untuk prinsipal IAM, tentukan satu atau beberapa nama untuk Grup.** Jika Anda tidak menentukan nama grup apa pun dan ingin menggunakan otorisasi Amazon EKS, Anda dapat mengaitkan kebijakan akses di langkah selanjutnya, atau setelah entri akses dibuat.
1. (Opsional) Untuk **Tag**, tetapkan label ke entri akses. Misalnya, untuk membuatnya lebih mudah untuk menemukan semua sumber daya dengan tag yang sama.
1. Pilih **Berikutnya**.
1. Pada halaman **Add access policy**, jika tipe yang Anda pilih adalah **Standard** dan Anda ingin Amazon EKS mengotorisasi prinsipal IAM untuk memiliki izin ke objek Kubernetes di klaster Anda, selesaikan langkah-langkah berikut. Jika tidak, pilih **Selanjutnya**.
1. Untuk **nama Kebijakan**, pilih kebijakan akses. Anda tidak dapat melihat izin kebijakan akses, tetapi mereka menyertakan izin serupa dengan yang ada di objek yang dihadapi pengguna Kubernetes. `ClusterRole` Untuk informasi selengkapnya, lihat [Peran yang dihadapi pengguna dalam dokumentasi](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) Kubernetes.
1. Pilih salah satu opsi berikut:
+ **Cluster** — Pilih opsi ini jika Anda ingin Amazon EKS mengotorisasi prinsipal IAM untuk memiliki izin dalam kebijakan akses untuk semua objek Kubernetes di klaster Anda.
+ **Namespace Kubernetes** - Pilih opsi ini jika Anda ingin Amazon EKS mengotorisasi prinsipal IAM untuk memiliki izin dalam kebijakan akses untuk semua objek Kubernetes di namespace Kubernetes tertentu di klaster Anda. Untuk **Namespace**, masukkan nama namespace Kubernetes di klaster Anda. Jika Anda ingin menambahkan ruang nama tambahan, pilih **Tambahkan namespace baru dan masukkan nama namespace**.
1. Jika Anda ingin menambahkan kebijakan tambahan, pilih **Tambah kebijakan**. Anda dapat membuat cakupan setiap kebijakan secara berbeda, tetapi Anda dapat menambahkan setiap kebijakan hanya sekali.
1. Pilih **Berikutnya**.
1. Tinjau konfigurasi untuk entri akses Anda. Jika ada yang terlihat salah, pilih **Sebelumnya** untuk kembali melalui langkah-langkah dan memperbaiki kesalahan. Jika konfigurasi sudah benar, pilih **Buat**.
## AWS CLI
1. Instal AWS CLI, seperti yang dijelaskan dalam [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di Panduan Pengguna Antarmuka Baris AWS Perintah.
1. Untuk membuat entri akses Anda dapat menggunakan salah satu contoh berikut untuk membuat entri akses:
+ Buat entri akses untuk grup node Amazon EC2 Linux yang dikelola sendiri. Ganti *my-cluster* dengan nama cluster Anda, *111122223333* dengan ID AWS akun Anda, dan *EKS-my-cluster-self-managed-ng-1* dengan nama [peran IAM node](create-node-role.md) Anda. Jika grup node Anda adalah grup node Windows, maka ganti *EC2\$1LINUX* dengan`EC2_Windows`.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
Anda tidak dapat menggunakan `--kubernetes-groups` opsi ketika Anda menentukan jenis selain`STANDARD`. Anda tidak dapat mengaitkan kebijakan akses ke entri akses ini, karena jenisnya adalah nilai selain`STANDARD`.
+ Buat entri akses yang memungkinkan peran IAM yang tidak digunakan untuk grup node yang EC2 dikelola sendiri Amazon, yang Anda inginkan Kubernetes untuk mengotorisasi akses ke klaster Anda. Ganti *my-cluster* dengan nama klaster Anda, *111122223333* dengan ID AWS akun Anda, dan *my-role* dengan nama peran IAM Anda. Ganti *Viewers* dengan nama grup yang telah Anda tentukan di Kubernetes `RoleBinding` atau `ClusterRoleBinding` objek di klaster Anda.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ Buat entri akses yang memungkinkan pengguna IAM untuk mengautentikasi ke cluster Anda. *Contoh ini diberikan karena hal ini dimungkinkan, meskipun praktik terbaik IAM merekomendasikan untuk mengakses klaster Anda menggunakan *peran* IAM yang memiliki kredensi jangka pendek, daripada pengguna IAM yang memiliki kredensil jangka panjang.* Untuk informasi selengkapnya, lihat [Mewajibkan pengguna manusia untuk menggunakan federasi dengan penyedia identitas untuk mengakses AWS menggunakan kredensi sementara](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) di Panduan Pengguna *IAM*.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:user/my-user --type STANDARD --username my-user
```
Jika Anda ingin pengguna ini memiliki lebih banyak akses ke klaster Anda daripada izin di peran penemuan API Kubernetes, maka Anda perlu mengaitkan kebijakan akses ke entri akses, karena `--kubernetes-groups` opsi tersebut tidak digunakan. Untuk informasi selengkapnya, lihat [Mengaitkan kebijakan akses dengan entri akses](access-policies.md) dan [peran penemuan API](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) dalam dokumentasi Kubernetes.
# Perbarui entri akses
Anda dapat memperbarui entri akses menggunakan Konsol Manajemen AWS atau AWS CLI.
## Konsol Manajemen AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama cluster tempat Anda ingin membuat entri akses.
1. Pilih tab **Access**.
1. Pilih entri akses yang ingin Anda perbarui.
1. Pilih **Edit**.
1. Untuk **Username**, Anda dapat mengubah nilai yang ada.
1. Untuk **Grup**, Anda dapat menghapus nama grup yang ada atau menambahkan nama grup baru. **Jika nama grup berikut ada, jangan hapus mereka: **system:nodes atau system:bootstrappers**.** Menghapus grup ini dapat menyebabkan cluster Anda berfungsi dengan tidak benar. Jika Anda tidak menentukan nama grup apa pun dan ingin menggunakan otorisasi Amazon EKS, kaitkan [kebijakan akses](access-policies.md) di langkah selanjutnya.
1. Untuk **Tag**, Anda dapat menetapkan label ke entri akses. Misalnya, untuk membuatnya lebih mudah untuk menemukan semua sumber daya dengan tag yang sama. Anda juga dapat menghapus tag yang ada.
1. Pilih **Simpan perubahan**.
1. Jika Anda ingin mengaitkan kebijakan akses ke entri, lihat[Mengaitkan kebijakan akses dengan entri akses](access-policies.md).
## AWS CLI
1. Instal AWS CLI, seperti yang dijelaskan dalam [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di Panduan Pengguna Antarmuka Baris AWS Perintah.
1. Untuk memperbarui entri akses Ganti *my-cluster* dengan nama klaster Anda, *111122223333* dengan ID AWS akun Anda, dan *EKS-my-cluster-my-namespace-Viewers* dengan nama peran IAM.
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
Anda tidak dapat menggunakan `--kubernetes-groups` opsi jika jenis entri akses adalah nilai selain`STANDARD`. Anda juga tidak dapat mengaitkan kebijakan akses ke entri akses dengan jenis selain`STANDARD`.
# Hapus entri akses
Jika Anda menemukan bahwa Anda menghapus entri akses karena kesalahan, Anda selalu dapat membuatnya kembali. Jika entri akses yang Anda hapus dikaitkan dengan kebijakan akses apa pun, asosiasi akan dihapus secara otomatis. Anda tidak perlu memisahkan kebijakan akses dari entri akses sebelum menghapus entri akses.
Anda dapat menghapus entri akses menggunakan Konsol Manajemen AWS atau AWS CLI.
## Konsol Manajemen AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama klaster tempat Anda ingin menghapus entri akses.
1. Pilih tab **Access**.
1. Dalam daftar **entri Access**, pilih entri akses yang ingin Anda hapus.
1. Pilih Hapus.
1. Di kotak dialog konfirmasi, pilih **Hapus**.
## AWS CLI
1. Instal AWS CLI, seperti yang dijelaskan dalam [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di Panduan Pengguna Antarmuka Baris AWS Perintah.
1. Untuk menghapus entri akses Ganti *my-cluster* dengan nama klaster Anda, *111122223333* dengan ID AWS akun Anda, dan *my-role* dengan nama peran IAM yang tidak lagi ingin Anda akses ke klaster Anda.
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/my-role
```
# Tetapkan nama pengguna khusus untuk entri akses EKS
Saat membuat entri akses untuk Amazon EKS, Anda dapat menggunakan nama pengguna yang dibuat secara otomatis atau menentukan nama pengguna khusus. Halaman ini menjelaskan kedua opsi dan memandu Anda melalui pengaturan nama pengguna khusus.
## Ikhtisar
Nama pengguna dalam entri akses digunakan untuk mengidentifikasi prinsipal IAM di log Kubernetes dan jalur audit. Secara default, Amazon EKS menghasilkan nama pengguna berdasarkan ARN identitas IAM, tetapi Anda dapat menentukan nama pengguna khusus jika diperlukan.
## Pembuatan nama pengguna default
Jika Anda tidak menentukan nilai untuk nama pengguna, Amazon EKS secara otomatis membuat nama pengguna berdasarkan IAM Identity:
+ **Untuk Pengguna IAM**:
+ EKS menetapkan nama pengguna Kubernetes ke ARN Pengguna IAM
+ Contoh:
```
{arn-aws}iam::<111122223333>:user/
```
+ **Untuk Peran IAM**:
+ EKS menetapkan nama pengguna Kubernetes berdasarkan ARN Peran IAM
+ STS ARN dari peran ketika diasumsikan. Amazon EKS `{{SessionName}}` menambahkan peran tersebut. Jika ARN peran yang Anda tentukan berisi jalur, Amazon EKS menghapusnya di nama pengguna yang dihasilkan.
+ Contoh:
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
Kecuali Anda memiliki alasan khusus untuk menentukan nama pengguna Anda sendiri, kami menyarankan Anda untuk tidak menentukannya dan membiarkan Amazon EKS membuatnya secara otomatis untuk Anda.
## Mengatur nama pengguna khusus
Saat membuat entri akses, Anda dapat menentukan nama pengguna khusus menggunakan `--username` parameter:
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### Persyaratan untuk nama pengguna khusus
Jika Anda menentukan nama pengguna khusus:
+ Nama pengguna tidak dapat dimulai dengan`system:`,`eks:`,`aws:`,`amazon:`, atau`iam:`.
+ Jika nama pengguna untuk peran IAM, kami sarankan Anda menambahkan `{{SessionName}}` atau `{{SessionNameRaw}}` ke akhir nama pengguna Anda.
+ Jika Anda menambahkan salah satu `{{SessionName}}` atau `{{SessionNameRaw}}` ke nama pengguna Anda, nama pengguna harus menyertakan titik dua *sebelum* \$1\$1SessionName\$1\$1.
# Membuat entri akses untuk peran IAM atau pengguna menggunakan kebijakan akses dan CLI AWS
Buat entri akses Amazon EKS yang menggunakan kebijakan akses EKS yang AWS dikelola untuk memberikan izin standar identitas IAM untuk mengakses dan mengelola klaster Kubernetes.
## Gambaran Umum
Entri akses di Amazon EKS menentukan bagaimana identitas IAM (pengguna dan peran) dapat mengakses dan berinteraksi dengan klaster Kubernetes Anda. Dengan membuat entri akses dengan kebijakan akses EKS, Anda dapat:
+ Berikan izin kepada pengguna atau peran IAM tertentu untuk mengakses kluster EKS Anda
+ Kontrol izin menggunakan kebijakan akses AWS EKS terkelola yang menyediakan set izin standar yang telah ditentukan
+ Izin lingkup ke ruang nama tertentu atau seluruh cluster
+ Sederhanakan manajemen akses tanpa memodifikasi `aws-auth` ConfigMap atau membuat sumber daya Kubernetes RBAC
+ Gunakan pendekatan AWS terintegrasi untuk kontrol akses Kubernetes yang mencakup kasus penggunaan umum sambil mempertahankan praktik terbaik keamanan
Pendekatan ini direkomendasikan untuk sebagian besar kasus penggunaan karena memberikan izin standar yang AWS dikelola tanpa memerlukan konfigurasi RBAC Kubernetes manual. Kebijakan akses EKS menghilangkan kebutuhan untuk mengonfigurasi sumber daya Kubernetes RBAC secara manual dan menawarkan set izin yang telah ditentukan sebelumnya yang mencakup kasus penggunaan umum.
## Prasyarat
+ *Mode otentikasi* klaster Anda harus dikonfigurasi untuk mengaktifkan *entri akses*. Untuk informasi selengkapnya, lihat [Ubah mode otentikasi untuk menggunakan entri akses](setting-up-access-entries.md).
+ Instal dan konfigurasikan AWS CLI, seperti yang dijelaskan dalam [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di Panduan Pengguna Antarmuka Baris AWS Perintah.
## Langkah 1: Tentukan entri akses
1. Temukan ARN identitas IAM, seperti pengguna atau peran, yang ingin Anda berikan izin.
+ Setiap identitas IAM hanya dapat memiliki satu entri akses EKS.
1. Tentukan apakah Anda ingin izin kebijakan akses Amazon EKS diterapkan hanya pada namespace Kubernetes tertentu, atau di seluruh klaster.
+ Jika Anda ingin membatasi izin ke namespace tertentu, catat nama namespace.
1. Pilih kebijakan akses EKS yang Anda inginkan untuk identitas IAM. Kebijakan ini memberikan izin dalam klaster. Perhatikan ARN dari kebijakan tersebut.
+ Untuk daftar kebijakan, lihat [kebijakan akses yang tersedia](access-policy-permissions.md).
1. Tentukan apakah nama pengguna yang dibuat secara otomatis sesuai untuk entri akses, atau jika Anda perlu menentukan nama pengguna secara manual.
+ AWS otomatis menghasilkan nilai ini berdasarkan identitas IAM. Anda dapat mengatur nama pengguna khusus. Ini terlihat di log Kubernetes.
+ Untuk informasi selengkapnya, lihat [Tetapkan nama pengguna khusus untuk entri akses EKS](set-custom-username.md).
## Langkah 2: Buat entri akses
Setelah merencanakan entri akses, gunakan AWS CLI untuk membuatnya.
Contoh berikut mencakup sebagian besar kasus penggunaan. [Lihat referensi CLI untuk semua opsi konfigurasi](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
Anda akan melampirkan kebijakan akses pada langkah berikutnya.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## Langkah 3: Kebijakan akses asosiasi
Perintah berbeda berdasarkan apakah Anda ingin kebijakan dibatasi pada namespace Kubernetes tertentu.
Anda memerlukan ARN dari kebijakan akses. Tinjau [kebijakan akses yang tersedia](access-policy-permissions.md).
### Buat kebijakan tanpa cakupan namespace
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### Buat dengan ruang lingkup namespace
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## Langkah selanjutnya
+ [Buat kubeconfig sehingga Anda dapat menggunakan kubectl dengan identitas IAM](create-kubeconfig.md)
# Buat entri akses menggunakan grup Kubernetes dengan CLI AWS
Buat entri akses Amazon EKS yang menggunakan grup Kubernetes untuk otorisasi dan memerlukan konfigurasi RBAC manual.
**catatan**
Untuk sebagian besar kasus penggunaan, sebaiknya gunakan Kebijakan Akses EKS, bukan pendekatan grup Kubernetes yang dijelaskan di halaman ini. Kebijakan Akses EKS menyediakan cara yang lebih sederhana dan lebih AWS terintegrasi untuk mengelola akses tanpa memerlukan konfigurasi RBAC manual. Gunakan pendekatan grup Kubernetes hanya ketika Anda membutuhkan kontrol yang lebih terperinci daripada yang ditawarkan Kebijakan Akses EKS.
## Gambaran Umum
Entri akses menentukan bagaimana identitas IAM (pengguna dan peran) mengakses klaster Kubernetes Anda. Pendekatan grup Kubernetes memberikan izin kepada pengguna IAM atau peran untuk mengakses kluster EKS Anda melalui grup RBAC Kubernetes standar. Metode ini memerlukan pembuatan dan pengelolaan sumber daya Kubernetes RBAC (Peran,, RoleBindings ClusterRoles, dan ClusterRoleBindings) dan direkomendasikan ketika Anda membutuhkan set izin yang sangat disesuaikan, persyaratan otorisasi yang kompleks, atau ingin mempertahankan pola kontrol akses yang konsisten di seluruh lingkungan Kubernetes hybrid.
Topik ini tidak mencakup pembuatan entri akses untuk identitas IAM yang digunakan untuk EC2 instans Amazon untuk bergabung dengan kluster EKS.
## Prasyarat
+ *Mode otentikasi* klaster Anda harus dikonfigurasi untuk mengaktifkan *entri akses*. Untuk informasi selengkapnya, lihat [Ubah mode otentikasi untuk menggunakan entri akses](setting-up-access-entries.md).
+ Instal dan konfigurasikan AWS CLI, seperti yang dijelaskan dalam [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di Panduan Pengguna Antarmuka Baris AWS Perintah.
+ Keakraban dengan Kubernetes RBAC direkomendasikan. Untuk informasi selengkapnya, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dalam dokumentasi Kubernetes.
## Langkah 1: Tentukan entri akses
1. Temukan ARN identitas IAM, seperti pengguna atau peran, yang ingin Anda berikan izin.
+ Setiap identitas IAM hanya dapat memiliki satu entri akses EKS.
1. Tentukan grup Kubernetes mana yang ingin Anda kaitkan dengan identitas IAM ini.
+ Anda perlu membuat atau menggunakan `ClusterRoleBinding` sumber daya Kubernetes`Role`/`ClusterRole`dan`RoleBinding`/yang sudah ada yang mereferensikan kelompok-kelompok ini.
1. Tentukan apakah nama pengguna yang dibuat secara otomatis sesuai untuk entri akses, atau jika Anda perlu menentukan nama pengguna secara manual.
+ AWS otomatis menghasilkan nilai ini berdasarkan identitas IAM. Anda dapat mengatur nama pengguna khusus. Ini terlihat di log Kubernetes.
+ Untuk informasi selengkapnya, lihat [Tetapkan nama pengguna khusus untuk entri akses EKS](set-custom-username.md).
## Langkah 2: Buat entri akses dengan grup Kubernetes
Setelah merencanakan entri akses, gunakan AWS CLI untuk membuatnya dengan grup Kubernetes yang sesuai.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
Ganti:
+ ``dengan nama cluster EKS Anda
+ ``dengan ARN pengguna atau peran IAM
+ ``dengan daftar grup Kubernetes yang dipisahkan koma (misalnya, “system:developers, system:readers”)
[Lihat referensi CLI untuk semua opsi konfigurasi](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
## Langkah 3: Konfigurasikan Kubernetes RBAC
Agar prinsipal IAM memiliki akses ke objek Kubernetes di klaster Anda, Anda harus membuat dan mengelola objek kontrol akses berbasis peran (RBAC) Kubernetes:
1. Buat Kubernetes `Role` atau `ClusterRole` objek yang menentukan izin.
1. Buat Kubernetes `RoleBinding` atau `ClusterRoleBinding` objek pada klaster Anda yang menentukan nama grup sebagai for. `subject` `kind: Group`
Untuk informasi rinci tentang mengonfigurasi grup dan izin di Kubernetes, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) di dokumentasi Kubernetes.
## Langkah selanjutnya
+ [Buat kubeconfig sehingga Anda dapat menggunakan kubectl dengan identitas IAM](create-kubeconfig.md)
# Berikan akses kepada pengguna IAM ke Kubernetes dengan a ConfigMap
**penting**
`aws-auth ConfigMap`Itu sudah usang. Untuk metode yang direkomendasikan untuk mengelola akses ke Kubernetes APIs, lihat. [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md)
Akses ke klaster Anda menggunakan [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) diaktifkan oleh [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), yang berjalan di bidang kontrol Amazon EKS. Authenticator mendapatkan informasi konfigurasinya dari file. `aws-auth` `ConfigMap` Untuk semua `aws-auth` `ConfigMap` pengaturan, lihat [Format Konfigurasi Lengkap](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) aktif GitHub.
## Tambahkan prinsipal IAM ke kluster Amazon EKS Anda
Saat Anda membuat klaster Amazon EKS, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang membuat klaster secara otomatis diberikan `system:masters` izin dalam konfigurasi kontrol akses berbasis peran (RBAC) klaster di bidang kontrol Amazon EKS. Prinsipal ini tidak muncul dalam konfigurasi yang terlihat, jadi pastikan untuk melacak prinsipal mana yang awalnya membuat cluster. Untuk memberikan prinsipal IAM tambahan kemampuan untuk berinteraksi dengan klaster Anda, edit bagian `aws-auth ConfigMap` dalam Kubernetes dan buat Kubernetes `rolebinding` atau `clusterrolebinding` dengan nama yang Anda tentukan di dalamnya. `group` `aws-auth ConfigMap`
**catatan**
Untuk informasi selengkapnya tentang konfigurasi kontrol akses berbasis peran Kubernetes (RBAC), lihat [Menggunakan](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) Otorisasi RBAC dalam dokumentasi Kubernetes.
1. Tentukan kredensyal mana yang `kubectl` digunakan untuk mengakses klaster Anda. Di komputer Anda, Anda dapat melihat kredensyal mana yang `kubectl` digunakan dengan perintah berikut. Ganti *\$1/.kube/config* dengan jalur ke `kubeconfig` file Anda jika Anda tidak menggunakan jalur default.
```
cat ~/.kube/config
```
Contoh output adalah sebagai berikut.
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
Dalam contoh keluaran sebelumnya, kredensyal untuk pengguna bernama *admin* dikonfigurasi untuk klaster bernama. *my-cluster* Jika ini adalah pengguna yang membuat cluster, maka ia sudah memiliki akses ke cluster Anda. Jika bukan pengguna yang membuat cluster, maka Anda perlu menyelesaikan langkah-langkah yang tersisa untuk mengaktifkan akses cluster untuk prinsipal IAM lainnya. [Praktik terbaik IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) menyarankan agar Anda memberikan izin untuk peran, bukan pengguna. Anda dapat melihat prinsipal lain mana yang saat ini memiliki akses ke cluster Anda dengan perintah berikut:
```
kubectl describe -n kube-system configmap/aws-auth
```
Contoh output adalah sebagai berikut.
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
Contoh sebelumnya adalah default `aws-auth``ConfigMap`. Hanya peran instance node yang memiliki akses ke cluster.
1. Pastikan Anda memiliki Kubernetes `roles` dan `rolebindings` or `clusterroles` dan Anda dapat memetakan `clusterrolebindings` prinsipal IAM. Untuk informasi selengkapnya tentang sumber daya ini, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) di dokumentasi Kubernetes.
1. Lihat Kubernetes `roles` atau. `clusterroles` `Roles`dicakup ke a`namespace`, tetapi `clusterroles` dicakup ke cluster.
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. Lihat detail apa pun `role` atau yang `clusterrole` dikembalikan di keluaran sebelumnya dan konfirmasikan bahwa ia memiliki izin (`rules`) yang Anda inginkan untuk dimiliki oleh prinsipal IAM Anda di cluster Anda.
Ganti *role-name* dengan `role` nama yang dikembalikan dalam output dari perintah sebelumnya. Ganti *kube-system* dengan namespace dari file. `role`
```
kubectl describe role role-name -n kube-system
```
Ganti *cluster-role-name* dengan `clusterrole` nama yang dikembalikan dalam output dari perintah sebelumnya.
```
kubectl describe clusterrole cluster-role-name
```
1. Lihat Kubernetes `rolebindings` atau. `clusterrolebindings` `Rolebindings`dicakup ke a`namespace`, tetapi `clusterrolebindings` dicakup ke cluster.
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. Lihat detail apa pun `rolebinding` atau `clusterrolebinding` dan konfirmasikan bahwa ia memiliki `role` atau `clusterrole` dari langkah sebelumnya yang terdaftar sebagai `roleRef` dan nama grup yang terdaftar untuk`subjects`.
Ganti *role-binding-name* dengan `rolebinding` nama yang dikembalikan dalam output dari perintah sebelumnya. Ganti *kube-system* dengan `namespace` dari`rolebinding`.
```
kubectl describe rolebinding role-binding-name -n kube-system
```
Contoh output adalah sebagai berikut.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
Ganti *cluster-role-binding-name* dengan `clusterrolebinding` nama yang dikembalikan dalam output dari perintah sebelumnya.
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
Contoh output adalah sebagai berikut.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. Edit `aws-auth``ConfigMap`. Anda dapat menggunakan alat seperti `eksctl` untuk memperbarui `ConfigMap` atau Anda dapat memperbaruinya secara manual dengan mengeditnya.
**penting**
Kami merekomendasikan menggunakan`eksctl`, atau alat lain, untuk mengedit`ConfigMap`. Untuk informasi tentang alat lain yang dapat Anda gunakan, lihat [Menggunakan alat untuk membuat perubahan pada aws- authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap) dalam panduan praktik terbaik Amazon EKS. Format yang tidak benar `aws-auth` `ConfigMap` dapat menyebabkan Anda kehilangan akses ke cluster Anda.
+ Lihat langkah-langkah untuk [mengedit configmap dengan](#configmap-eksctl) eksctl.
+ Lihat langkah-langkah untuk [mengedit configmap](#configmap-manual) secara manual.
### Edit Configmap dengan Eksctl
1. Anda memerlukan versi `0.215.0` atau yang lebih baru dari alat baris `eksctl` perintah yang diinstal pada perangkat Anda atau AWS CloudShell. Untuk menginstal atau memperbarui`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
1. Lihat pemetaan saat ini di. `ConfigMap` Ganti *my-cluster* dengan nama klaster Anda. Ganti *region-code* dengan AWS Wilayah tempat cluster Anda berada.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Contoh output adalah sebagai berikut.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. Tambahkan pemetaan untuk peran. Ganti *my-role* dengan nama peran Anda. Ganti *eks-console-dashboard-full-access-group* dengan nama grup yang ditentukan dalam Kubernetes `RoleBinding` atau objek Anda. `ClusterRoleBinding` Ganti *111122223333* dengan ID akun Anda. Anda dapat mengganti *admin* dengan nama apa pun yang Anda pilih.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**penting**
Peran ARN tidak dapat menyertakan jalur seperti. `role/my-team/developers/my-role` Format ARN harus. ` arn:aws: iam::111122223333:role/my-role ` Dalam contoh ini, `my-team/developers/` perlu dihapus.
Contoh output adalah sebagai berikut.
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. Tambahkan pemetaan untuk pengguna. [Praktik terbaik IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) menyarankan agar Anda memberikan izin untuk peran, bukan pengguna. Ganti *my-user* dengan nama pengguna Anda. Ganti *eks-console-dashboard-restricted-access-group* dengan nama grup yang ditentukan dalam Kubernetes `RoleBinding` atau objek Anda. `ClusterRoleBinding` Ganti *111122223333* dengan ID akun Anda. Anda dapat mengganti *my-user* dengan nama apa pun yang Anda pilih.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
Contoh output adalah sebagai berikut.
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws: iam::111122223333:user/my-user" to auth ConfigMap
```
1. Lihat pemetaan di lagi. `ConfigMap`
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Contoh output adalah sebagai berikut.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws: iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Edit Configmap secara manual
1. Buka `ConfigMap` untuk mengedit.
```
kubectl edit -n kube-system configmap/aws-auth
```
**catatan**
Jika Anda menerima kesalahan yang menyatakan "`Error from server (NotFound): configmaps "aws-auth" not found`“, maka gunakan prosedur di [Terapkan aws-auth ConfigMap ke cluster Anda untuk](#aws-auth-configmap) menerapkan stok. `ConfigMap`
1. Tambahkan prinsip IAM Anda ke. `ConfigMap` Grup IAM bukanlah prinsipal IAM, sehingga tidak dapat ditambahkan ke. `ConfigMap`
+ **Untuk menambahkan peran IAM (misalnya, untuk [pengguna federasi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)):** Tambahkan detail peran ke `mapRoles` bagian`ConfigMap`, di bawah. `data` Tambahkan bagian ini jika belum ada di dalam file. Setiap masuk mendukung parameter berikut:
+ **rolearn**: ARN IAM role untuk menambahkan. Nilai ini tidak dapat menyertakan jalur. Misalnya, Anda tidak dapat menentukan ARN seperti. ` arn:aws: iam::111122223333:role/my-team/developers/role-name ` ARN harus sebagai gantinya. ` arn:aws: iam::111122223333:role/role-name `
+ **nama pengguna**: Nama pengguna dalam Kubernetes untuk memetakan ke dalam IAM role.
+ **grup**: Grup atau daftar grup Kubernetes untuk memetakan peran. Grup dapat berupa grup default, atau grup yang ditentukan dalam `clusterrolebinding` atau`rolebinding`. Untuk informasi selengkapnya, lihat [Peran default dan binding peran](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) dalam dokumentasi Kubernetes.
+ **Untuk menambahkan pengguna IAM:** [Praktik terbaik IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) menyarankan Anda memberikan izin ke peran, bukan pengguna. Tambahkan detail pengguna ke `mapUsers` bagian`ConfigMap`, di bawah`data`. Tambahkan bagian ini jika belum ada di dalam file. Setiap entri mendukung parameter berikut:
+ **userarn**: ARN pengguna IAM untuk ditambahkan.
+ **nama pengguna**: nama pengguna dalam Kubernetes untuk memetakan ke pengguna IAM.
+ **grup**: Grup, atau daftar grup Kubernetes untuk memetakan pengguna. Grup dapat berupa grup default, atau grup yang ditentukan dalam `clusterrolebinding` atau`rolebinding`. Untuk informasi selengkapnya, lihat [Peran default dan binding peran](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) dalam dokumentasi Kubernetes.
1. Misalnya, blok YAMAL berikut berisi:
+ `mapRoles`Bagian yang memetakan instance node IAM ke grup Kubernetes sehingga node dapat mendaftarkan diri mereka sendiri dengan klaster dan peran `my-console-viewer-role` IAM yang dipetakan ke grup Kubernetes yang dapat melihat semua sumber daya Kubernetes untuk semua cluster. Untuk daftar izin grup IAM dan Kubernetes yang diperlukan untuk peran IAM, lihat. `my-console-viewer-role` [Izin yang diperlukan](view-kubernetes-resources.md#view-kubernetes-resources-permissions)
+ `mapUsers`Bagian yang memetakan pengguna `admin` IAM dari AWS akun default ke grup `system:masters` Kubernetes dan `my-user` pengguna dari AWS akun lain yang dipetakan ke grup Kubernetes yang dapat melihat sumber daya Kubernetes untuk namespace tertentu. Untuk daftar izin grup IAM dan Kubernetes yang diperlukan untuk pengguna IAM, lihat. `my-user` [Izin yang diperlukan](view-kubernetes-resources.md#view-kubernetes-resources-permissions)
Tambahkan atau hapus baris seperlunya dan ganti semua nilai contoh dengan nilai Anda sendiri.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws: iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws: iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws: iam::444455556666:user/my-user
username: my-user
```
1. Simpan file dan keluar dari editor teks Anda.
## Terapkan `aws-auth` `ConfigMap` ke cluster Anda
Secara otomatis `aws-auth` `ConfigMap` dibuat dan diterapkan ke cluster Anda ketika Anda membuat grup node terkelola atau ketika Anda membuat grup node menggunakan`eksctl`. Ini awalnya dibuat untuk memungkinkan node bergabung dengan cluster Anda, tetapi Anda juga menggunakan ini `ConfigMap` untuk menambahkan akses kontrol akses berbasis peran (RBAC) ke prinsip-prinsip IAM. Jika Anda telah meluncurkan node yang dikelola sendiri dan belum menerapkannya `aws-auth` `ConfigMap` ke cluster Anda, Anda dapat melakukannya dengan prosedur berikut.
1. Periksa untuk melihat apakah Anda sudah menerapkan `aws-auth``ConfigMap`.
```
kubectl describe configmap -n kube-system aws-auth
```
Jika Anda menerima kesalahan yang menyatakan "`Error from server (NotFound): configmaps "aws-auth" not found`“, maka lanjutkan dengan langkah-langkah berikut untuk menerapkan stok`ConfigMap`.
1. Unduh, edit, dan terapkan peta konfigurasi AWS autentikator.
1. Unduh peta konfigurasi.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Dalam `aws-auth-cm.yaml` file, atur `rolearn` ke Amazon Resource Name (ARN) dari peran IAM yang terkait dengan node Anda. Anda dapat melakukan ini dengan editor teks, atau dengan mengganti *my-node-instance-role* dan menjalankan perintah berikut:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
Jangan mengubah baris lain dalam file ini.
**penting**
Peran ARN tidak dapat menyertakan jalur seperti. `role/my-team/developers/my-role` Format ARN harus. ` arn:aws: iam::111122223333:role/my-role ` Dalam contoh ini, `my-team/developers/` perlu dihapus.
Anda dapat memeriksa output AWS CloudFormation tumpukan untuk grup node Anda dan mencari nilai berikut:
+ **InstanceRoleARN** — Untuk grup node yang dibuat dengan `eksctl`
+ **NodeInstanceRole**— Untuk grup simpul yang dibuat dengan AWS CloudFormation templat penjual Amazon EKS di Konsol Manajemen AWS
1. Terapkan konfigurasi. Perintah ini mungkin memerlukan waktu beberapa menit untuk diselesaikan.
```
kubectl apply -f aws-auth-cm.yaml
```
**catatan**
Jika Anda menerima kesalahan otorisasi atau jenis sumber daya, lihat [Tidak sah atau akses ditolak (`kubectl`)](troubleshooting.md#unauthorized) di topik pemecahan masalah.
1. Perhatikan status simpul Anda dan tunggu sampai simpul mencapai Status `Ready`.
```
kubectl get nodes --watch
```
Masukkan `Ctrl`\$1`C` untuk kembali ke prompt shell.
# Beri pengguna akses ke Kubernetes dengan penyedia OIDC eksternal
Amazon EKS mendukung penggunaan penyedia identitas OpenID Connect (OIDC) sebagai metode untuk mengautentikasi pengguna ke klaster Anda. Penyedia identitas OIDC dapat digunakan dengan, atau sebagai alternatif untuk AWS Identity and Access Management (IAM). Untuk informasi selengkapnya tentang penggunaan IAM, lihat [Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md). Setelah mengonfigurasi autentikasi ke klaster Anda, Anda dapat membuat `roles` dan `clusterroles` Kubernetes untuk memberikan izin ke dalam peran, dan kemudian mengikat peran ke dalam identitas menggunakan `rolebindings` dan `clusterrolebindings` Kubernetes. Untuk informasi selengkapnya, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dalam dokumentasi Kubernetes.
+ Anda dapat mengaitkan satu penyedia identitas OIDC ke klaster Anda.
+ Kubernetes tidak menyediakan penyedia identitas OIDC. Anda dapat menggunakan penyedia identitas OIDC publik yang sudah ada, atau Anda dapat menjalankan penyedia identitas milik Anda sendiri. Untuk daftar penyedia tersertifikasi, lihat [OpenID Certification](https://openid.net/certification/) di situs OpenID.
+ URL penerbit penyedia identitas OIDC harus dapat diakses publik, sehingga Amazon EKS dapat menemukan kunci penandatanganan. Amazon EKS tidak mendukung penyedia identitas OIDC dengan sertifikat yang ditandatangani sendiri.
+ Anda tidak dapat menonaktifkan autentikasi IAM ke klaster Anda, karena masih diperlukan untuk menggabungkan node ke cluster.
+ Cluster Amazon EKS masih harus dibuat oleh [prinsipal AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), bukan pengguna penyedia identitas OIDC. Ini karena pembuat cluster berinteraksi dengan Amazon EKS APIs, bukan APIs Kubernetes.
+ Pengguna yang diautentikasi penyedia identitas OIDC tercantum dalam log audit klaster jika CloudWatch log dihidupkan untuk bidang kontrol. Untuk informasi selengkapnya, lihat [Mengaktifkan atau menonaktifkan log bidang kontrol](control-plane-logs.md#enabling-control-plane-log-export).
+ Anda tidak dapat masuk ke akun Konsol Manajemen AWS dengan akun dari penyedia OIDC. Anda hanya [Lihat sumber daya Kubernetes di Konsol Manajemen AWS](view-kubernetes-resources.md) dapat masuk ke akun Identity and Access Management Konsol Manajemen AWS dengan akun AWS Identity and Access Management.
## Kaitkan penyedia identitas OIDC
Sebelum Anda dapat mengaitkan penyedia identitas OIDC dengan klaster Anda, Anda memerlukan informasi berikut dari penyedia Anda:
**URL Penerbit**
URL penyedia identitas OIDC yang memungkinkan server API menemukan kunci penandatanganan publik untuk memverifikasi token. URL harus dimulai dengan `https://` dan harus sesuai dengan `iss` klaim dalam token ID OIDC penyedia. Sesuai dengan standar OIDC, komponen jalur diperbolehkan tetapi parameter kueri tidak. Biasanya URL hanya terdiri dari nama host, seperti `https://server.example.org` atau `https://example.com`. URL ini harus mengarah ke level di bawah `.well-known/openid-configuration` dan harus dapat diakses oleh publik melalui internet.
**ID Klien (juga dikenal sebagai *audiens*)**
ID untuk aplikasi klien yang membuat permintaan otentikasi ke penyedia identitas OIDC.
Anda dapat mengaitkan penyedia identitas menggunakan `eksctl` atau Konsol Manajemen AWS.
### Kaitkan penyedia identitas menggunakan eksctl
1. Buat file bernama `associate-identity-provider.yaml` dengan isi berikut ini. Ganti Contoh nilai dengan nilai Anda sendiri. Nilai-nilai dalam bagian `identityProviders` diperoleh dari penyedia identitas OIDC Anda. Nilai hanya diperlukan untuk `name`, `type`, `issuerUrl`, dan pengaturan `clientId` di bawah `identityProviders`.
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**penting**
Jangan tentukan`system:`, atau bagian mana pun dari string itu, untuk `groupsPrefix` atau`usernamePrefix`.
1. Buat penyedia.
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. Untuk digunakan `kubectl` untuk bekerja dengan cluster dan penyedia identitas OIDC Anda, lihat [Menggunakan kubectl di dokumentasi Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl).
### Kaitkan penyedia identitas menggunakan AWS Konsol
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih klaster Anda, lalu pilih tab **Access**.
1. Di bagian **Penyedia Identitas OIDC, pilih\$1 Penyedia Identitas** Rekan\$1.
1. Pada halaman **Penyedia Identitas Associate OIDC**, masukkan atau pilih opsi berikut, dan kemudian pilih **Associate**.
+ Untuk **Nama**, masukkan nama unik untuk penyedia.
+ Untuk **Penerbit URL**, masukkan URL untuk penyedia Anda. URL ini harus dapat diakses melalui internet.
+ Untuk **ID Klien**, masukkan ID klien penyedia identitas OIDC (juga dikenal sebagai **audiens**).
+ Untuk **Klaim nama pengguna**, masukkan klaim untuk digunakan sebagai nama pengguna.
+ Untuk **klaim Grup**, masukkan klaim yang akan digunakan sebagai grup pengguna.
+ (Opsional) Pilih **Opsi lanjutan**, masukkan atau pilih informasi berikut.
+ **Prefiks nama pengguna** – Masukkan prefiks untuk ditambahkan ke klaim nama pengguna. Prefiks diawali dengan nama pengguna klaim untuk mencegah bentrokan dengan nama yang sudah ada. Jika Anda tidak memberikan nilai, dan nama pengguna adalah nilai selain `email`, prefiks default ke dalam nilai untuk **Penerbit URL**. Anda dapat menggunakan ` -`nilai untuk menonaktifkan semua prefiks. Jangan tentukan `system:` atau bagian mana pun dari string itu.
+ **Prefiks grup** – Masukkan prefiks untuk ditambahkan ke klaim grup. Prefiks ditambahkan ke klaim grup untuk mencegah bentrokan dengan nama yang sudah ada (seperti` system: groups`). Misalnya, `oidc:` nilai membuat nama grup seperti `oidc:engineering` dan `oidc:infra`. Jangan tentukan `system:` atau bagian mana pun dari string itu..
+ **Klaim yang diperlukan** – Pilih **Tambahkan klaim** dan masukkan satu atau beberapa pasangan nilai kunci yang menjelaskan klaim yang diperlukan dalam token ID klien. Pasangan tersebut menjelaskan klaim yang diperlukan dalam Token ID. Jika diatur, setiap klaim diverifikasi untuk ada dalam token ID dengan nilai yang cocok.
1. Untuk digunakan `kubectl` untuk bekerja dengan cluster dan penyedia identitas OIDC Anda, lihat [Menggunakan kubectl di dokumentasi Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl).
## Contoh kebijakan IAM
Jika Anda ingin mencegah penyedia identitas OIDC dikaitkan dengan klaster, buat dan kaitkan kebijakan IAM berikut ke dalam akun IAM Amazon EKS administrator Anda. Untuk informasi selengkapnya, lihat [Membuat kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dan [Menambahkan izin identitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) di *Panduan Pengguna dan [Tindakan](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html) IAM* di Referensi Otorisasi Layanan.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
Contoh kebijakan berikut memungkinkan asosiasi penyedia identitas OIDC jika `clientID` adalah `kubernetes` dan `issuerUrl` adalah `https://cognito-idp.us-west-2amazonaws.com/*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# Putuskan penyedia identitas OIDC dari klaster Anda
Jika Anda memisahkan penyedia identitas OIDC dari klaster Anda, pengguna yang disertakan dalam penyedia tidak dapat lagi mengakses klaster. Namun, Anda masih dapat mengakses cluster dengan [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal).
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pada bagian **Penyedia Identitas OIDC**, pilih **Pisahkan**, masukkan nama penyedia identitas, dan kemudian pilih `Disassociate`.
# Lihat sumber daya Kubernetes di Konsol Manajemen AWS
Anda dapat melihat sumber daya Kubernetes yang diterapkan ke klaster Anda dengan file. Konsol Manajemen AWS[Anda tidak dapat melihat sumber daya Kubernetes dengan CLI AWS atau eksctl.](https://eksctl.io/) [Untuk melihat sumber daya Kubernetes menggunakan alat baris perintah, gunakan kubectl.](install-kubectl.md)
**catatan**
Untuk melihat tab **Resources** dan bagian **Nodes** pada tab **Compute** di Konsol Manajemen AWS, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang Anda gunakan harus memiliki izin IAM dan Kubernetes tertentu. Untuk informasi selengkapnya, lihat [Izin yang diperlukan](#view-kubernetes-resources-permissions).
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dalam daftar **Clusters**, pilih cluster yang berisi resource Kubernetes yang ingin Anda lihat.
1. Pilih tab **Sumber Daya**.
1. Pilih grup **tipe sumber daya** yang ingin Anda lihat sumber daya, seperti **Beban kerja**. Anda melihat daftar jenis sumber daya di grup itu.
1. Pilih jenis sumber daya, seperti **Deployment**, di grup Beban **kerja**. Anda melihat deskripsi tipe sumber daya, tautan ke dokumentasi Kubernetes untuk informasi lebih lanjut tentang tipe sumber daya, dan daftar sumber daya dari jenis tersebut yang digunakan di klaster Anda. Jika daftar kosong, maka tidak ada sumber daya dari jenis itu yang diterapkan ke cluster Anda.
1. Pilih sumber daya untuk melihat informasi lebih lanjut tentangnya. Coba contoh berikut:
+ **Pilih grup **Beban kerja**, pilih jenis sumber daya **Deployment**, lalu pilih sumber daya coredns.** Ketika Anda memilih sumber daya, Anda berada dalam **tampilan Terstruktur**, secara default. Untuk beberapa jenis sumber daya, Anda melihat bagian **Pod** dalam **tampilan Terstruktur**. Bagian ini mencantumkan Pod yang dikelola oleh beban kerja. Anda dapat memilih Pod yang terdaftar untuk melihat informasi tentang Pod. Tidak semua jenis sumber daya menampilkan informasi dalam **Tampilan Terstruktur**. Jika Anda memilih **tampilan Raw** di sudut kanan atas halaman untuk sumber daya, Anda akan melihat respons JSON lengkap dari API Kubernetes untuk sumber daya.
+ Pilih grup **Cluster** dan kemudian pilih jenis sumber daya **Node**. Anda melihat daftar semua node di cluster Anda. Node dapat berupa [jenis simpul Amazon EKS](eks-compute.md). Ini adalah daftar yang sama yang Anda lihat di bagian **Nodes** ketika Anda memilih tab **Compute** untuk cluster Anda. Pilih sumber daya node dari daftar. Dalam **tampilan Terstruktur**, Anda juga melihat bagian **Pod**. Bagian ini menunjukkan kepada Anda semua Pod yang berjalan pada node.
## Izin yang diperlukan
Untuk melihat tab **Resources** dan bagian **Nodes** pada tab **Compute** di Konsol Manajemen AWS, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang Anda gunakan harus memiliki izin IAM dan Kubernetes minimum tertentu. Anda harus memiliki izin IAM dan Kubernetes RBAC yang dikonfigurasi dengan benar. Selesaikan langkah-langkah berikut untuk menetapkan izin yang diperlukan untuk kepala sekolah IAM Anda.
1. Pastikan bahwa`eks:AccessKubernetesApi`, dan izin IAM lain yang diperlukan untuk melihat sumber daya Kubernetes, ditetapkan ke prinsipal IAM yang Anda gunakan. Untuk informasi selengkapnya tentang cara mengedit izin untuk prinsipal IAM, lihat [Mengontrol akses untuk prinsipal di Panduan Pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals). Untuk informasi selengkapnya tentang cara mengedit izin untuk peran, lihat [Memodifikasi kebijakan izin peran (konsol)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy) di Panduan Pengguna IAM.
Contoh kebijakan berikut mencakup izin yang diperlukan bagi prinsipal untuk melihat sumber daya Kubernetes untuk semua klaster di akun Anda. Ganti *111122223333* dengan ID AWS akun Anda.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
Untuk melihat node dalam [cluster yang terhubung](eks-connector.md), [peran IAM konektor Amazon EKS](connector-iam-role.md) harus dapat meniru prinsipal di cluster. Hal ini memungkinkan [Amazon EKS Connector](eks-connector.md) untuk memetakan prinsipal ke pengguna Kubernetes.
1. Konfigurasikan izin Kubernetes RBAC menggunakan entri akses EKS.
**Apa itu Entri Akses EKS?**
Entri akses EKS adalah cara yang efisien untuk memberikan akses kepada prinsipal IAM (pengguna dan peran) ke klaster Kubernetes Anda. Alih-alih mengelola sumber daya Kubernetes RBAC secara manual dan `aws-auth` ConfigMap, entri akses secara otomatis menangani pemetaan antara izin IAM dan Kubernetes menggunakan kebijakan terkelola yang disediakan oleh. AWS Untuk informasi rinci tentang entri akses, lihat[Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md). Untuk informasi tentang kebijakan akses yang tersedia dan izinnya, lihat Izin [kebijakan akses](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html).
Anda dapat melampirkan izin Kubernetes untuk mengakses entri dengan dua cara:
+ **Gunakan kebijakan akses: Kebijakan akses** adalah templat izin Kubernetes yang telah ditentukan sebelumnya yang dikelola oleh. AWS Ini menyediakan set izin standar untuk kasus penggunaan umum.
+ **Mereferensikan grup Kubernetes:** Jika Anda mengaitkan identitas IAM dengan grup Kubernetes, Anda dapat membuat sumber daya Kubernetes yang memberikan izin grup. Untuk informasi selengkapnya, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dalam dokumentasi Kubernetes.
1. Buat entri akses untuk prinsipal IAM Anda menggunakan AWS CLI. Ganti *my-cluster* dengan nama klaster Anda. Ganti *111122223333* dengan ID akun Anda.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
Contoh output adalah sebagai berikut.
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws: eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. Kaitkan kebijakan dengan entri akses. Untuk melihat sumber daya Kubernetes, gunakan: `AmazonEKSViewPolicy`
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
Contoh output adalah sebagai berikut.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
Untuk akses khusus ruang nama, Anda dapat membuat cakupan kebijakan ke ruang nama tertentu:
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. Verifikasi entri akses berhasil dibuat:
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
1. Buat daftar kebijakan terkait untuk mengonfirmasi asosiasi kebijakan:
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
Contoh output adalah sebagai berikut.
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## CloudTrail visibilitas
Saat melihat sumber daya Kubernetes, Anda akan melihat nama operasi berikut di log Anda: CloudTrail
+ `AccessKubernetesApi`- Saat membaca atau melihat sumber daya
CloudTrail Acara ini menyediakan jejak audit akses baca ke sumber daya Kubernetes Anda.
**catatan**
Nama operasi ini muncul di CloudTrail log untuk tujuan audit saja. Ini bukan tindakan IAM dan tidak dapat digunakan dalam pernyataan kebijakan IAM. Untuk mengontrol akses baca ke sumber daya Kubernetes melalui kebijakan IAM, gunakan `eks:AccessKubernetesApi` izin seperti yang ditunjukkan di bagian. [Izin yang diperlukan](#view-kubernetes-resources-permissions)
# AWS Layanan hibah akses tulis ke Kubernetes APIs
## Izin yang diperlukan
Untuk mengaktifkan AWS layanan untuk melakukan operasi penulisan pada resource Kubernetes di klaster Amazon EKS Anda, Anda harus memberikan izin kepada IAM `eks:AccessKubernetesApi` dan `eks:MutateViaKubernetesApi` IAM.
Misalnya, Amazon SageMaker HyperPod menggunakan izin ini untuk mengaktifkan penerapan model dari SageMaker AI Studio. Untuk informasi selengkapnya, lihat [Menyiapkan izin JavaScript SDK opsional](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js) di Panduan Pengembang Amazon SageMaker AI.
**penting**
Operasi tulis seperti membuat, memperbarui, dan menghapus memerlukan kedua izin—jika salah satu izin hilang, operasi tulis akan gagal.
## CloudTrail visibilitas
Saat melakukan operasi tulis pada sumber daya Kubernetes, Anda akan melihat nama operasi tertentu di log Anda: CloudTrail
+ `createKubernetesObject`- Saat membuat sumber daya baru
+ `updateKubernetesObject`- Saat memodifikasi sumber daya yang ada
+ `deleteKubernetesObject`- Saat menghapus sumber daya
CloudTrail Peristiwa ini menyediakan jejak audit terperinci dari semua modifikasi yang dilakukan pada sumber daya Kubernetes Anda.
**catatan**
Nama operasi ini muncul di CloudTrail log hanya untuk tujuan audit. Mereka bukan tindakan IAM dan tidak dapat digunakan dalam pernyataan kebijakan IAM. Untuk mengontrol akses tulis ke sumber daya Kubernetes melalui kebijakan IAM, gunakan `eks:MutateViaKubernetesApi` izin seperti yang ditunjukkan di bagian. [Izin yang diperlukan](#mutate-kubernetes-resources-permissions)
# Connect kubectl ke kluster EKS dengan membuat file kubeconfig
**Tip**
[Daftar](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) untuk lokakarya Amazon EKS mendatang.
Dalam topik ini, Anda membuat `kubeconfig` file untuk klaster Anda (atau memperbarui yang sudah ada).
Alat `kubectl` baris perintah menggunakan informasi konfigurasi dalam `kubeconfig` file untuk berkomunikasi dengan server API cluster. Untuk informasi selengkapnya, lihat [Mengatur Akses Cluster Menggunakan File kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) dalam dokumentasi Kubernetes.
Amazon EKS menggunakan `aws eks get-token` perintah `kubectl` untuk otentikasi cluster. Secara default, AWS CLI menggunakan kredenal yang sama yang dikembalikan dengan perintah berikut:
```
aws sts get-caller-identity
```
+ Sebuah klaster Amazon EKS yang sudah ada. Untuk menyebarkan satu, lihat[Memulai dengan Amazon EKS](getting-started.md).
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
+ Pengguna IAM atau peran dengan izin untuk menggunakan tindakan `eks:DescribeCluster` API untuk klaster yang Anda tentukan. Untuk informasi selengkapnya, lihat [Contoh kebijakan berbasis identitas Amazon EKS](security-iam-id-based-policy-examples.md). Jika Anda menggunakan identitas dari penyedia OpenID Connect Anda sendiri untuk mengakses klaster Anda, lihat [Menggunakan kubectl di dokumentasi Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) untuk membuat atau memperbarui file Anda. `kube config`
## Buat `kubeconfig` file secara otomatis
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
+ Izin untuk menggunakan tindakan `eks:DescribeCluster` API untuk klaster yang Anda tentukan. Untuk informasi selengkapnya, lihat [Contoh kebijakan berbasis identitas Amazon EKS](security-iam-id-based-policy-examples.md).
1. Buat atau perbarui file `kubeconfig` untuk klaster Anda. Ganti *region-code* dengan AWS Region tempat cluster Anda berada dan ganti *my-cluster* dengan nama cluster Anda.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Secara default, file konfigurasi yang dihasilkan dibuat di `kubeconfig` jalur default (`.kube`) di direktori home Anda atau digabungkan dengan `config` file yang ada di lokasi tersebut. Anda dapat menentukan jalur lain dengan opsi `--kubeconfig`.
Anda dapat menentukan ARN IAM role dengan pilihan `--role-arn` untuk digunakan dalam autentikasi ketika Anda mengeluarkan perintah `kubectl`. Jika tidak, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) dalam rantai kredensi AWS CLI atau SDK default Anda akan digunakan. Anda dapat melihat identitas AWS CLI atau SDK default Anda dengan menjalankan perintah. `aws sts get-caller-identity`
*Untuk semua opsi yang tersedia, jalankan `aws eks update-kubeconfig help` perintah atau lihat [update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html) di CLI Command Reference. AWS *
1. Uji konfigurasi Anda.
```
kubectl get svc
```
Contoh output adalah sebagai berikut.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
Jika Anda menerima kesalahan otorisasi atau jenis sumber daya, lihat [Tidak sah atau akses ditolak (`kubectl`)](troubleshooting.md#unauthorized) di topik pemecahan masalah.
# Berikan akses beban kerja Kubernetes untuk AWS menggunakan Akun Layanan Kubernetes
[Mengelola Akun Layanan](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[IAM role untuk akun layanan](iam-roles-for-service-accounts.md)[Pelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS](pod-identities.md)
## Token akun layanan
[BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)Fitur ini diaktifkan secara default dalam versi Kubernetes. Fitur ini meningkatkan keamanan token akun layanan dengan memungkinkan beban kerja yang berjalan di Kubernetes untuk meminta token web JSON yang bersifat audience, time, dan key bound. Token akun layanan memiliki masa kedaluwarsa satu jam. Di versi Kubernetes sebelumnya, token tidak memiliki kedaluwarsa. Ini berarti bahwa klien yang mengandalkan token ini harus menyegarkan token dalam waktu satu jam. [Klien Kubernetes](https://kubernetes.io/docs/reference/using-api/client-libraries/) berikut SDKs menyegarkan token secara otomatis dalam jangka waktu yang diperlukan:
+ Versi Go `0.15.7` dan yang lebih baru
+ Versi `12.0.0` Python dan yang lebih baru
+ Versi Java `9.0.0` dan yang lebih baru
+ JavaScript versi `0.10.3` dan yang lebih baru
+ Cabang Ruby `master`
+ Versi Haskell `0.3.0.0`
+ Versi C\$1 `7.0.5` dan yang lebih baru
Jika beban kerja Anda menggunakan versi klien sebelumnya, maka Anda harus memperbaruinya. Untuk mengaktifkan kelancaran migrasi klien ke token akun layanan terikat waktu yang lebih baru, Kubernetes menambahkan periode kedaluwarsa yang diperpanjang ke token akun layanan selama satu jam default. Untuk cluster Amazon EKS, periode kedaluwarsa yang diperpanjang adalah 90 hari. Server API Kubernetes klaster Amazon EKS Anda menolak permintaan dengan token yang berusia lebih dari 90 hari. Kami menyarankan Anda memeriksa aplikasi Anda dan dependensinya untuk memastikan bahwa klien Kubernetes sama atau lebih lambat dari versi yang SDKs tercantum sebelumnya.
Saat server API menerima permintaan dengan token yang berumur lebih dari satu jam, server API akan menganotasi peristiwa log audit API. `annotations.authentication.k8s.io/stale-token` Nilai anotasi terlihat seperti contoh berikut:
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
Jika klaster Anda mengaktifkan [pencatatan bidang kontrol](control-plane-logs.md), maka anotasi ada di log audit. Anda dapat menggunakan kueri [Wawasan CloudWatch Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) berikut untuk mengidentifikasi semua Pod di klaster Amazon EKS Anda yang menggunakan token basi:
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
`subject`Ini mengacu pada akun layanan yang digunakan Pod. `elapsedtime`Ini menunjukkan waktu yang telah berlalu (dalam detik) setelah membaca token terbaru. Permintaan ke server API ditolak ketika `elapsedtime` melebihi 90 hari (7.776.000 detik). Anda harus secara proaktif memperbarui SDK klien Kubernetes aplikasi Anda untuk menggunakan salah satu versi yang terdaftar sebelumnya yang secara otomatis menyegarkan token. Jika token akun layanan yang digunakan mendekati 90 hari dan Anda tidak memiliki cukup waktu untuk memperbarui versi SDK klien Anda sebelum token kedaluwarsa, maka Anda dapat menghentikan Pod yang ada dan membuat yang baru. Ini menghasilkan refetching token akun layanan, memberi Anda tambahan 90 hari untuk memperbarui versi klien Anda. SDKs
Jika Pod adalah bagian dari penerapan, cara yang disarankan untuk menghentikan Pod sambil menjaga ketersediaan tinggi adalah dengan melakukan peluncuran dengan perintah berikut. Ganti *my-deployment* dengan nama penerapan Anda.
```
kubectl rollout restart deployment/my-deployment
```
## Pengaya klaster
Add-on klaster berikut telah diperbarui untuk menggunakan klien Kubernetes SDKs yang secara otomatis mengisi ulang token akun layanan. Sebaiknya pastikan bahwa versi yang terdaftar, atau versi yang lebih baru, diinstal pada cluster Anda.
+ Plugin Amazon VPC CNI untuk Kubernetes dan plugin pembantu metrik versi dan yang lebih baru. `1.8.0` Untuk memeriksa versi Anda saat ini atau memperbaruinya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md) dan [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md).
+ Versi CoreDNS dan `1.8.4` yang lebih baru. Untuk memeriksa versi Anda saat ini atau memperbaruinya, lihat[Kelola CoreDNS untuk DNS di kluster Amazon EKS](managing-coredns.md).
+ AWS Load Balancer Controller versi `2.0.0` dan yang lebih baru. Untuk memeriksa versi Anda saat ini atau memperbaruinya, lihat[Rute lalu lintas internet dengan AWS Load Balancer Controller](aws-load-balancer-controller.md).
+ `kube-proxy`Versi saat ini. Untuk memeriksa versi Anda saat ini atau memperbaruinya, lihat[Kelola `kube-proxy` di kluster Amazon EKS](managing-kube-proxy.md).
+ AWS untuk versi Fluent Bit `2.25.0` atau yang lebih baru. Untuk memperbarui versi Anda saat ini, lihat [Rilis](https://github.com/aws/aws-for-fluent-bit/releases) di GitHub.
+ [Fluentd image versi [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) atau yang lebih baru dan plugin filter Fluentd untuk metadata Kubernetes versi 2.11.1 atau yang lebih baru.](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1)
## Memberikan izin AWS Identity and Access Management untuk beban kerja di klaster Amazon Elastic Kubernetes Service
*Amazon EKS menyediakan dua cara untuk memberikan izin AWS Identity and Access Management ke beban kerja yang berjalan di klaster Amazon EKS: *peran IAM untuk akun layanan*, dan EKS Pod Identities.*
**Peran IAM untuk akun layanan**
*Peran IAM untuk akun layanan (IRSA)* mengonfigurasi aplikasi Kubernetes yang berjalan AWS dengan izin IAM berbutir halus untuk mengakses berbagai sumber daya lain seperti bucket AWS Amazon S3, tabel Amazon DynamoDB, dan banyak lagi. Anda dapat menjalankan beberapa aplikasi bersama-sama di cluster Amazon EKS yang sama, dan memastikan setiap aplikasi hanya memiliki set izin minimum yang diperlukan. IRSA dibangun untuk mendukung berbagai opsi penerapan Kubernetes yang didukung oleh AWS seperti Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS, dan cluster Kubernetes yang dikelola sendiri di instans Amazon. EC2 Dengan demikian, IRSA dibangun menggunakan AWS layanan dasar seperti IAM, dan tidak mengambil ketergantungan langsung pada layanan Amazon EKS dan EKS API. Untuk informasi selengkapnya, lihat [IAM role untuk akun layanan](iam-roles-for-service-accounts.md).
**Identitas EKS Pod**
EKS Pod Identity menawarkan kepada administrator klaster alur kerja yang disederhanakan untuk mengautentikasi aplikasi untuk mengakses berbagai AWS sumber daya lain seperti bucket Amazon S3, tabel Amazon DynamoDB, dan banyak lagi. EKS Pod Identity hanya untuk EKS, dan sebagai hasilnya, ini menyederhanakan bagaimana administrator klaster dapat mengkonfigurasi aplikasi Kubernetes untuk mendapatkan izin IAM. Izin ini sekarang dapat dengan mudah dikonfigurasi dengan lebih sedikit langkah langsung melalui Konsol Manajemen AWS, EKS API, dan AWS CLI, dan tidak ada tindakan apa pun untuk diambil di dalam cluster di objek Kubernetes mana pun. Administrator klaster tidak perlu beralih antara layanan EKS dan IAM, atau menggunakan operasi IAM istimewa untuk mengonfigurasi izin yang diperlukan oleh aplikasi Anda. Peran IAM sekarang dapat digunakan di beberapa cluster tanpa perlu memperbarui kebijakan kepercayaan peran saat membuat cluster baru. Kredensyal IAM yang disediakan oleh EKS Pod Identity mencakup tag sesi peran, dengan atribut seperti nama cluster, namespace, nama akun layanan. Tag sesi peran memungkinkan administrator untuk membuat peran tunggal yang dapat bekerja di seluruh akun layanan dengan mengizinkan akses ke AWS sumber daya berdasarkan tag yang cocok. Untuk informasi selengkapnya, lihat [Pelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS](pod-identities.md).
### Membandingkan Identitas Pod EKS dan IRSA
Pada tingkat tinggi, baik EKS Pod Identity dan IRSA memungkinkan Anda untuk memberikan izin IAM untuk aplikasi yang berjalan pada klaster Kubernetes. Tetapi mereka pada dasarnya berbeda dalam cara Anda mengonfigurasinya, batas yang didukung, dan fitur yang diaktifkan. Di bawah ini, kami membandingkan beberapa aspek kunci dari kedua solusi.
**catatan**
AWS merekomendasikan penggunaan EKS Pod Identities untuk memberikan akses ke AWS sumber daya ke pod Anda bila memungkinkan. Untuk informasi selengkapnya, lihat [Pelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS](pod-identities.md).
| Atribut | Identitas Pod EKS | IRSA |
| --- | --- | --- |
| Perluasan peran | Anda harus mengatur setiap peran sekali untuk membangun kepercayaan dengan prinsipal layanan Amazon EKS yang baru diperkenalkan. `pods.eks.amazonaws.com` Setelah langkah satu kali ini, Anda tidak perlu memperbarui kebijakan kepercayaan peran setiap kali digunakan di klaster baru. | Anda harus memperbarui kebijakan kepercayaan peran IAM dengan titik akhir penyedia OIDC cluster EKS baru setiap kali Anda ingin menggunakan peran tersebut di cluster baru. |
| Skalabilitas cluster | EKS Pod Identity tidak mengharuskan pengguna untuk menyiapkan penyedia IAM OIDC, jadi batasan ini tidak berlaku. | Setiap cluster EKS memiliki URL penerbit OpenID Connect (OIDC) yang terkait dengannya. Untuk menggunakan IRSA, penyedia OpenID Connect yang unik perlu dibuat untuk setiap cluster EKS di IAM. IAM memiliki batas global default 100 penyedia OIDC untuk setiap akun. AWS Jika Anda berencana untuk memiliki lebih dari 100 kluster EKS untuk setiap AWS akun dengan IRSA, maka Anda akan mencapai batas penyedia IAM OIDC. |
| Skalabilitas peran | EKS Pod Identity tidak mengharuskan pengguna untuk menentukan hubungan kepercayaan antara peran IAM dan akun layanan dalam kebijakan kepercayaan, sehingga batasan ini tidak berlaku. | Dalam IRSA, Anda mendefinisikan hubungan kepercayaan antara peran IAM dan akun layanan dalam kebijakan kepercayaan peran. Secara default, panjang ukuran kebijakan kepercayaan adalah`2048`. Ini berarti bahwa Anda biasanya dapat mendefinisikan 4 hubungan kepercayaan dalam satu kebijakan kepercayaan. Meskipun Anda bisa mendapatkan batas panjang kebijakan kepercayaan yang meningkat, Anda biasanya terbatas pada maksimal 8 hubungan kepercayaan dalam satu kebijakan kepercayaan. |
| Penggunaan Kuota API STS | EKS Pod Identity menyederhanakan pengiriman AWS kredensyal ke pod Anda, dan tidak mengharuskan kode Anda melakukan panggilan dengan AWS Security Token Service (STS) secara langsung. Layanan EKS menangani asumsi peran, dan memberikan kredensyal ke aplikasi yang ditulis menggunakan AWS SDK di pod Anda tanpa pod Anda berkomunikasi dengan AWS STS atau menggunakan Kuota API STS. | Di IRSA, aplikasi yang ditulis menggunakan AWS SDK di pod Anda menggunakan token untuk memanggil `AssumeRoleWithWebIdentity` API pada AWS Security Token Service (STS). Bergantung pada logika kode Anda pada AWS SDK, kode Anda dapat membuat panggilan yang tidak diperlukan ke STS dan menerima kesalahan pelambatan. AWS |
| Peran dapat digunakan kembali | AWS Kredensyal sementara STS yang disediakan oleh EKS Pod Identity mencakup tag sesi peran, seperti nama cluster, namespace, nama akun layanan. Tag sesi peran memungkinkan administrator untuk membuat peran IAM tunggal yang dapat digunakan dengan beberapa akun layanan, dengan izin efektif yang berbeda, dengan mengizinkan akses ke AWS sumber daya berdasarkan tag yang dilampirkan padanya. Ini juga disebut Attribute-based Access Control (ABAC). Untuk informasi selengkapnya, lihat [Berikan akses Pod ke AWS sumber daya berdasarkan tag](pod-id-abac.md). | AWS Tag sesi STS tidak didukung. Anda dapat menggunakan kembali peran antar klaster, tetapi setiap pod menerima semua izin peran tersebut. |
| Lingkungan didukung | EKS Pod Identity hanya tersedia di Amazon EKS. | IRSA dapat digunakan seperti Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS, dan cluster Kubernetes yang dikelola sendiri di instans Amazon. EC2 |
| Versi EKS didukung | Semua versi cluster EKS yang didukung. Untuk versi platform tertentu, lihat[EKS Pod Identity versi cluster](pod-identities.md#pod-id-cluster-versions). | Semua versi cluster EKS yang didukung. |
# IAM role untuk akun layanan
**Tip**
[Daftar](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) untuk lokakarya Amazon EKS mendatang.
Aplikasi dalam kontainer Pod dapat menggunakan AWS SDK atau AWS CLI untuk membuat permintaan API AWS ke layanan AWS menggunakan izin Identity and Access Management (IAM). Aplikasi harus menandatangani permintaan AWS API mereka dengan AWS kredensialnya. **Peran IAM untuk akun layanan (IRSA)** menyediakan kemampuan untuk mengelola kredensil untuk aplikasi Anda, mirip dengan cara profil EC2 instans Amazon memberikan kredensil ke instans Amazon. EC2 Alih-alih membuat dan mendistribusikan AWS kredensialmu ke container atau menggunakan peran EC2 instans Amazon, kamu mengaitkan peran IAM dengan akun layanan Kubernetes dan mengonfigurasi Pod kamu untuk menggunakan akun layanan. Anda tidak dapat menggunakan peran IAM untuk akun layanan dengan [kluster lokal untuk Amazon EKS di AWS Outposts](eks-outposts-local-cluster-overview.md).
Peran IAM untuk akun layanan memberikan manfaat berikut:
+ **Keistimewaan paling** kecil — Anda dapat memberikan cakupan izin IAM ke akun layanan, dan hanya Pod yang menggunakan akun layanan tersebut yang memiliki akses ke izin tersebut. Fitur ini juga mengurangi kebutuhan akan solusi dari pihak ketiga seperti `kiam` atau `kube2iam`.
+ **Isolasi kredenal** — Ketika akses ke [Amazon EC2 Instance Metadata Service (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) dibatasi, kontainer Pod hanya dapat mengambil kredensil untuk peran IAM yang terkait dengan akun layanan yang digunakan container. Container tidak pernah memiliki akses ke kredensi yang digunakan oleh kontainer lain di Pod lain. Jika IMDS tidak dibatasi, kontainer Pod juga memiliki akses ke [peran IAM node Amazon EKS](create-node-role.md) dan kontainer mungkin dapat memperoleh akses ke kredensial-kredensi peran IAM dari Pod lain pada node yang sama. Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).
**catatan**
Pod yang dikonfigurasi `hostNetwork: true` akan selalu memiliki akses IMDS, tetapi CLI AWS SDKs dan akan menggunakan kredenal IRSA saat diaktifkan.
+ **Auditabilitas** — Akses dan pencatatan peristiwa tersedia AWS CloudTrail untuk membantu memastikan audit retrospektif.
**penting**
Kontainer bukan batas keamanan, dan penggunaan peran IAM untuk akun layanan tidak mengubah ini. Pod yang ditetapkan ke node yang sama akan berbagi kernel dan kemungkinan sumber daya lainnya tergantung pada konfigurasi Pod Anda. Sementara Pod yang berjalan pada node terpisah akan diisolasi pada lapisan komputasi, ada aplikasi node yang memiliki izin tambahan di API Kubernetes di luar cakupan instance individual. Beberapa contohnya adalah `kubelet``kube-proxy`, driver penyimpanan CSI, atau aplikasi Kubernetes Anda sendiri.
Aktifkan peran IAM untuk akun layanan dengan menyelesaikan prosedur berikut:
1. [Buat penyedia IAM OIDC untuk klaster Anda — Anda hanya menyelesaikan prosedur ini satu kali untuk setiap cluster](enable-iam-roles-for-service-accounts.md).
**catatan**
Jika Anda mengaktifkan titik akhir EKS VPC, titik akhir layanan EKS OIDC tidak dapat diakses dari dalam VPC itu. Akibatnya, operasi Anda seperti membuat penyedia OIDC dengan `eksctl` VPC tidak akan berfungsi dan akan menghasilkan batas waktu saat mencoba meminta. `https://oidc.eks.region.amazonaws.com` Contoh pesan kesalahan berikut:
```
server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
```
Untuk menyelesaikan langkah ini, Anda dapat menjalankan perintah di luar VPC, misalnya di dalam AWS CloudShell atau di komputer yang terhubung ke internet. Atau, Anda dapat membuat resolver bersyarat split-horizon di VPC, seperti Route 53 Resolver untuk menggunakan resolver yang berbeda untuk URL Penerbit OIDC dan tidak menggunakan DNS VPC untuk itu. [Untuk contoh penerusan bersyarat di CoreDNS, lihat permintaan fitur Amazon EKS di.](https://github.com/aws/containers-roadmap/issues/2038) GitHub
1. [Tetapkan peran IAM ke akun layanan Kubernetes](associate-service-account-role.md) — Selesaikan prosedur ini untuk setiap set izin unik yang Anda inginkan untuk dimiliki aplikasi.
1. [Konfigurasikan Pod untuk menggunakan akun layanan Kubernetes](pod-configuration.md) — Selesaikan prosedur ini untuk setiap Pod yang membutuhkan akses ke layanan. AWS
1. [Gunakan IRSA dengan AWS SDK](iam-roles-for-service-accounts-minimum-sdk.md) — Konfirmasikan bahwa beban kerja menggunakan AWS SDK versi yang didukung dan beban kerja menggunakan rantai kredenal default.
## Informasi latar belakang IAM, Kubernetes, dan OpenID Connect (OIDC)
Pada tahun 2014, AWS Identity and Access Management menambahkan dukungan untuk identitas federasi menggunakan OpenID Connect (OIDC). Fitur ini memungkinkan Anda untuk mengautentikasi panggilan AWS API dengan penyedia identitas yang didukung dan menerima token web OIDC JSON (JWT) yang valid. Anda dapat meneruskan token ini ke operasi AWS STS `AssumeRoleWithWebIdentity` API dan menerima kredenal peran sementara IAM. Anda dapat menggunakan kredensil ini untuk berinteraksi dengan AWS layanan apa pun, termasuk Amazon S3 dan DynamoDB.
Setiap token JWT ditandatangani oleh tanda tangan key pair. Kunci disajikan pada penyedia OIDC yang dikelola oleh Amazon EKS dan kunci pribadi berputar setiap 7 hari. Amazon EKS menyimpan kunci publik sampai kedaluwarsa. Jika Anda menghubungkan klien OIDC eksternal, ketahuilah bahwa Anda perlu menyegarkan kunci penandatanganan sebelum kunci publik kedaluwarsa. Pelajari cara [Mengambil kunci penandatanganan untuk memvalidasi token OIDC](irsa-fetch-keys.md).
Kubernetes telah lama menggunakan akun layanan sebagai sistem identitas internalnya sendiri. Pod-pod dapat mengautentikasi dengan server API Kubernetes menggunakan token yang dipasang secara otomatis (yang merupakan non-OIDC JWT) yang hanya dapat divalidasi oleh server API Kubernetes. Token akun layanan lama ini tidak kedaluwarsa, dan memutar kunci penandatanganan adalah proses yang sulit. Dalam versi Kubernetes`1.12`, dukungan ditambahkan untuk fitur baru. `ProjectedServiceAccountToken` Fitur ini adalah token web OIDC JSON yang juga berisi identitas akun layanan dan mendukung audiens yang dapat dikonfigurasi.
Amazon EKS menghosting titik akhir penemuan OIDC publik untuk setiap cluster yang berisi kunci penandatanganan untuk token web `ProjectedServiceAccountToken` JSON sehingga sistem eksternal, seperti IAM, dapat memvalidasi dan menerima token OIDC yang dikeluarkan oleh Kubernetes.
# Buat penyedia IAM OIDC untuk klaster Anda
Cluster Anda memiliki URL penerbit [OpenID Connect](https://openid.net/connect/) (OIDC) yang terkait dengannya. Untuk menggunakan peran AWS Identity and Access Management (IAM) and Access Management (IAM) untuk akun layanan, penyedia IAM OIDC harus ada untuk URL penerbit OIDC klaster Anda.
## Prasyarat
+ Sebuah klaster Amazon EKS yang sudah ada. Untuk menyebarkan satu, lihat[Memulai dengan Amazon EKS](getting-started.md).
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ `kubectl``config`File yang sudah ada yang berisi konfigurasi cluster Anda. Untuk membuat `kubectl` `config` file, lihat[Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md).
Anda dapat membuat penyedia IAM OIDC untuk cluster Anda menggunakan `eksctl` atau. Konsol Manajemen AWS
## Buat penyedia OIDC (eksctl)
1. Versi `0.215.0` atau yang lebih baru dari alat baris `eksctl` perintah yang diinstal pada perangkat Anda atau AWS CloudShell. Untuk menginstal atau memperbarui`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
1. Tentukan ID penerbit OIDC untuk klaster Anda.
Ambil ID penerbit OIDC cluster Anda dan simpan dalam variabel. Ganti `` dengan nilai milik Anda sendiri.
```
cluster_name=
oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
echo $oidc_id
```
1. Tentukan apakah penyedia IAM OIDC dengan ID penerbit klaster Anda sudah ada di akun Anda.
```
aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
```
Jika output dikembalikan, maka Anda sudah memiliki penyedia IAM OIDC untuk cluster Anda dan Anda dapat melewati langkah berikutnya. Jika tidak ada output yang dikembalikan, maka Anda harus membuat penyedia IAM OIDC untuk cluster Anda.
1. Buat penyedia identitas IAM OIDC untuk klaster Anda dengan perintah berikut.
```
eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
```
**catatan**
Jika Anda mengaktifkan titik akhir EKS VPC, titik akhir layanan EKS OIDC tidak dapat diakses dari dalam VPC itu. Akibatnya, operasi Anda seperti membuat penyedia OIDC dengan `eksctl` VPC tidak akan berfungsi dan akan menghasilkan batas waktu. Contoh pesan kesalahan berikut:
```
** server cant find oidc.eks..amazonaws.com: NXDOMAIN
```
Untuk menyelesaikan langkah ini, Anda dapat menjalankan perintah di luar VPC, misalnya di dalam AWS CloudShell atau di komputer yang terhubung ke internet. Atau, Anda dapat membuat resolver bersyarat split-horizon di VPC, seperti Route 53 Resolver untuk menggunakan resolver yang berbeda untuk URL Penerbit OIDC dan tidak menggunakan DNS VPC untuk itu. [Untuk contoh penerusan bersyarat di CoreDNS, lihat permintaan fitur Amazon EKS di.](https://github.com/aws/containers-roadmap/issues/2038) GitHub
## Buat penyedia OIDC (Konsol)AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel kiri, pilih **Cluster**, lalu pilih nama cluster Anda di halaman **Clusters**.
1. Di bagian **Detail** pada tab **Ikhtisar**, perhatikan nilai URL **penyedia OpenID Connect**.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi kiri, pilih **Penyedia Identitas** di bawah **Manajemen akses**. Jika **Penyedia** tercantum dalam daftar yang cocok dengan URL untuk klaster Anda, maka Anda sudah memiliki penyedia untuk klaster Anda. Jika penyedia tidak terdaftar yang cocok dengan URL untuk klaster Anda, maka Anda harus membuatnya.
1. Untuk membuat penyedia, pilih **Tambah penyedia**.
1. Untuk **jenis Provider**, pilih **OpenID Connect**.
1. Untuk **URL Penyedia**, masukkan URL penyedia OIDC untuk klaster Anda.
1. Untuk **Audiens**, masukkan`sts.amazonaws.com`.
1. (Opsional) Tambahkan tag apa pun, misalnya tag untuk mengidentifikasi cluster mana untuk penyedia ini.
1. Pilih **Tambah penyedia**.
Langkah selanjutnya: [Tetapkan peran IAM ke akun layanan Kubernetes](associate-service-account-role.md)
# Tetapkan peran IAM ke akun layanan Kubernetes
Topik ini membahas cara mengonfigurasi akun layanan Kubernetes untuk mengambil peran AWS Identity and Access Management (IAM). Pod apa pun yang dikonfigurasi untuk menggunakan akun layanan kemudian dapat mengakses AWS layanan apa pun yang perannya memiliki izin untuk diakses.
## Prasyarat
+ Sebuah klaster yang sudah ada. Jika Anda tidak memilikinya, Anda dapat membuatnya dengan mengikuti salah satu panduan di[Memulai dengan Amazon EKS](getting-started.md).
+ Penyedia IAM OpenID Connect (OIDC) yang sudah ada untuk klaster Anda. Untuk mengetahui apakah Anda sudah memilikinya atau cara membuatnya, lihat[Buat penyedia IAM OIDC untuk klaster Anda](enable-iam-roles-for-service-accounts.md).
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ `kubectl``config`File yang sudah ada yang berisi konfigurasi cluster Anda. Untuk membuat `kubectl` `config` file, lihat[Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md).
## Langkah 1: Buat Kebijakan IAM
Jika Anda ingin mengaitkan kebijakan IAM yang ada dengan peran IAM Anda, lewati ke langkah berikutnya.
1. Buat kebijakan IAM. Anda dapat membuat kebijakan sendiri, atau menyalin kebijakan AWS terkelola yang telah memberikan beberapa izin yang Anda perlukan dan menyesuaikannya dengan persyaratan spesifik Anda. Untuk informasi selengkapnya, lihat [Membuat kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dalam *Panduan Pengguna IAM*.
1. Buat file yang menyertakan izin untuk AWS layanan yang ingin diakses oleh Pod. Untuk daftar semua tindakan untuk semua AWS layanan, lihat [Referensi Otorisasi Layanan](https://docs.aws.amazon.com/service-authorization/latest/reference/).
Anda dapat menjalankan perintah berikut untuk membuat contoh file kebijakan yang memungkinkan akses hanya-baca ke bucket Amazon S3. Anda dapat secara opsional menyimpan informasi konfigurasi atau skrip bootstrap di bucket ini, dan container di Pod Anda dapat membaca file dari bucket dan memuatnya ke dalam aplikasi Anda. Jika Anda ingin membuat kebijakan contoh ini, salin konten berikut ke perangkat Anda. Ganti *my-pod-secrets-bucket* dengan nama bucket Anda dan jalankan perintah.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. Buat kebijakan IAM.
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
## Langkah 2: Buat dan kaitkan Peran IAM
Buat peran IAM dan kaitkan dengan akun layanan Kubernetes. Anda dapat menggunakan salah satu `eksctl` atau AWS CLI.
### Buat dan asosiasikan peran (eksctl)
`eksctl`Perintah ini membuat akun layanan Kubernetes di namespace yang ditentukan, membuat peran IAM (jika tidak ada) dengan nama yang ditentukan, melampirkan ARN kebijakan IAM yang ada ke peran, dan membuat anotasi akun layanan dengan peran IAM ARN. Pastikan untuk mengganti nilai placeholder sampel dalam perintah ini dengan nilai spesifik Anda. Untuk menginstal atau memperbarui`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
--attach-policy-arn arn:aws: iam::111122223333:policy/my-policy --approve
```
**penting**
Jika akun peran atau layanan sudah ada, perintah sebelumnya mungkin gagal. `eksctl`memiliki opsi berbeda yang dapat Anda berikan dalam situasi tersebut. Untuk informasi lebih lanjut jalankan`eksctl create iamserviceaccount --help`.
### Buat dan asosiasikan peran (AWS CLI)
Jika Anda memiliki akun layanan Kubernetes yang ingin Anda ambil peran IAM, Anda dapat melewati langkah ini.
1. Buat akun layanan Kubernetes. Salin konten berikut ke perangkat Anda. Ganti *my-service-account* dengan nama yang Anda inginkan dan *default* dengan namespace yang berbeda, jika perlu. Jika Anda berubah*default*, namespace harus sudah ada.
```
cat >my-service-account.yaml <
1. Konfirmasikan bahwa kebijakan kepercayaan peran IAM telah dikonfigurasi dengan benar.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
Contoh output adalah sebagai berikut.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Konfirmasikan bahwa kebijakan yang Anda lampirkan pada peran Anda di langkah sebelumnya dilampirkan pada peran tersebut.
```
aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
```
Contoh output adalah sebagai berikut.
```
arn:aws: iam::111122223333:policy/my-policy
```
1. Tetapkan variabel untuk menyimpan Nama Sumber Daya Amazon (ARN) kebijakan yang ingin Anda gunakan. Ganti *my-policy* dengan nama kebijakan yang ingin Anda konfirmasi izin.
```
export policy_arn=arn:aws: iam::111122223333:policy/my-policy
```
1. Lihat versi default kebijakan.
```
aws iam get-policy --policy-arn $policy_arn
```
Contoh output adalah sebagai berikut.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws: iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Lihat konten kebijakan untuk memastikan bahwa kebijakan tersebut menyertakan semua izin yang dibutuhkan Pod Anda. Jika perlu, ganti *1* dalam perintah berikut dengan versi yang dikembalikan pada output sebelumnya.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
Contoh output adalah sebagai berikut.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Jika Anda membuat kebijakan contoh di langkah sebelumnya, maka output Anda sama. Jika Anda membuat kebijakan yang berbeda, maka *example* kontennya berbeda.
1. Konfirmasikan bahwa akun layanan Kubernetes dianotasi dengan peran tersebut.
```
kubectl describe serviceaccount my-service-account -n default
```
Contoh output adalah sebagai berikut.
```
Name: my-service-account
Namespace: default
Annotations: eks.amazonaws.com/role-arn: arn:aws: iam::111122223333:role/my-role
Image pull secrets:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## Langkah selanjutnya
+ [Konfigurasikan Pod untuk menggunakan akun layanan Kubernetes](pod-configuration.md)
# Konfigurasikan Pod untuk menggunakan akun layanan Kubernetes
Jika sebuah Pod perlu mengakses AWS layanan, maka Anda harus mengonfigurasinya untuk menggunakan akun layanan Kubernetes. Akun layanan harus dikaitkan dengan peran AWS Identity and Access Management (IAM) and Access Management (IAM) yang memiliki izin untuk mengakses layanan. AWS
+ Sebuah klaster yang sudah ada. Jika Anda tidak memilikinya, Anda dapat membuatnya menggunakan salah satu panduan di[Memulai dengan Amazon EKS](getting-started.md).
+ Penyedia IAM OpenID Connect (OIDC) yang sudah ada untuk klaster Anda. Untuk mengetahui apakah Anda sudah memilikinya atau cara membuatnya, lihat[Buat penyedia IAM OIDC untuk klaster Anda](enable-iam-roles-for-service-accounts.md).
+ Akun layanan Kubernetes yang sudah ada yang terkait dengan peran IAM. Akun layanan harus dianotasi dengan Nama Sumber Daya Amazon (ARN) dari peran IAM. Peran tersebut harus memiliki kebijakan IAM terkait yang berisi izin yang Anda inginkan untuk Pod Anda untuk menggunakan AWS layanan. Untuk informasi selengkapnya tentang cara membuat akun dan peran layanan, dan mengonfigurasinya, lihat[Tetapkan peran IAM ke akun layanan Kubernetes](associate-service-account-role.md).
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ `kubectl``config`File yang ada yang berisi konfigurasi cluster Anda. Untuk membuat `kubectl` `config` file, lihat[Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md).
1. Gunakan perintah berikut untuk membuat manifes deployment yang dapat digunakan untuk meng-deploy Pod untuk mengonfirmasi konfigurasi. Ganti nilai contoh dengan nilai Anda sendiri.
```
cat >my-deployment.yaml <
Jika Anda menggunakan akun layanan Kubernetes dengan [peran IAM untuk akun layanan](iam-roles-for-service-accounts.md), maka Anda dapat mengonfigurasi jenis titik akhir Layanan Token AWS Keamanan yang digunakan oleh akun layanan.
AWS merekomendasikan menggunakan titik akhir AWS STS regional alih-alih titik akhir global. Ini mengurangi latensi, menyediakan redundansi bawaan, dan meningkatkan validitas token sesi. AWS Security Token Service harus aktif di AWS Region dimana Pod berjalan. Selain itu, aplikasi Anda harus memiliki redundansi bawaan untuk AWS Wilayah yang berbeda jika terjadi kegagalan layanan di AWS Wilayah. Untuk informasi selengkapnya, lihat [Mengelola AWS STS di AWS Wilayah](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) di Panduan Pengguna IAM.
+ Sebuah klaster yang sudah ada. Jika Anda tidak memilikinya, Anda dapat membuatnya menggunakan salah satu panduan di[Memulai dengan Amazon EKS](getting-started.md).
+ Penyedia IAM OIDC yang sudah ada untuk klaster Anda. Untuk informasi selengkapnya, lihat [Buat penyedia IAM OIDC untuk klaster Anda](enable-iam-roles-for-service-accounts.md).
+ Akun layanan Kubernetes yang sudah ada yang dikonfigurasi untuk digunakan dengan fitur [Amazon EKS IAM untuk](iam-roles-for-service-accounts.md) akun layanan.
[Contoh berikut semuanya menggunakan akun layanan Kubernetes aws-node yang digunakan oleh plugin Amazon VPC CNI.](cni-iam-role.md) Anda dapat menggantinya *example values* dengan akun layanan, Pod, ruang nama, dan sumber daya lainnya.
1. Pilih Pod yang menggunakan akun layanan yang ingin Anda ubah endpoint. Tentukan AWS Region mana Pod berjalan. Ganti *aws-node-6mfgv* dengan nama Pod Anda dan *kube-system* dengan namespace Pod Anda.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
```
Contoh output adalah sebagai berikut.
```
ip-192-168-79-166.us-west-2/192.168.79.166
```
Pada output sebelumnya, Pod berjalan pada sebuah node di Region us-west-2 AWS .
1. Tentukan tipe endpoint yang digunakan oleh akun layanan Pod.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
Contoh output adalah sebagai berikut.
```
AWS_STS_REGIONAL_ENDPOINTS: regional
```
Jika titik akhir saat ini bersifat global, `global` maka dikembalikan dalam output. Jika tidak ada output yang dikembalikan, maka tipe endpoint default sedang digunakan dan belum diganti.
1. Jika versi cluster atau platform Anda sama atau lebih lambat dari yang tercantum dalam tabel, maka Anda dapat mengubah jenis titik akhir yang digunakan oleh akun layanan Anda dari tipe default ke tipe yang berbeda dengan salah satu perintah berikut. Ganti *aws-node* dengan nama akun layanan Anda dan *kube-system* dengan namespace untuk akun layanan Anda.
+ Jika tipe titik akhir default atau saat ini bersifat global dan Anda ingin mengubahnya menjadi regional:
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
```
Jika Anda menggunakan [peran IAM untuk akun layanan guna](iam-roles-for-service-accounts.md) menghasilkan S3 yang telah ditandatangani sebelumnya URLs dalam aplikasi yang berjalan di container Pods, format URL untuk titik akhir regional mirip dengan contoh berikut:
```
https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
+ Jika tipe titik akhir default atau saat ini bersifat regional dan Anda ingin mengubahnya menjadi global:
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
```
Jika aplikasi Anda secara eksplisit membuat permintaan ke titik akhir global AWS STS dan Anda tidak mengganti perilaku default menggunakan titik akhir regional di kluster Amazon EKS, permintaan akan gagal dengan kesalahan. Untuk informasi selengkapnya, lihat [Kontainer pod menerima kesalahan berikut: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint).
Jika Anda menggunakan [peran IAM untuk akun layanan guna](iam-roles-for-service-accounts.md) menghasilkan S3 yang telah ditandatangani sebelumnya URLs dalam aplikasi yang berjalan di container Pods, format URL untuk titik akhir global mirip dengan contoh berikut:
```
https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
Jika Anda memiliki otomatisasi yang mengharapkan URL yang telah ditandatangani sebelumnya dalam format tertentu atau jika aplikasi atau dependensi hilir yang menggunakan pra-tanda tangan URLs memiliki harapan untuk AWS Wilayah yang ditargetkan, maka buat perubahan yang diperlukan untuk menggunakan titik akhir STS yang sesuai. AWS
1. Hapus dan buat ulang semua Pod yang ada yang terkait dengan akun layanan untuk menerapkan variabel lingkungan kredensyal. Web hook yang bermutasi tidak menerapkannya pada Pod yang sudah berjalan. Anda dapat mengganti*Pods*,*kube-system*, dan *-l k8s-app=aws-node* dengan informasi untuk Pod yang Anda tetapkan anotasi.
```
kubectl delete Pods -n kube-system -l k8s-app=aws-node
```
1. Konfirmasikan bahwa semua Pod dimulai ulang.
```
kubectl get Pods -n kube-system -l k8s-app=aws-node
```
1. Lihat variabel lingkungan untuk salah satu Pod. Verifikasi bahwa `AWS_STS_REGIONAL_ENDPOINTS` nilainya adalah apa yang Anda atur pada langkah sebelumnya.
```
kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
Contoh output adalah sebagai berikut.
```
AWS_STS_REGIONAL_ENDPOINTS=regional
```
# Otentikasi ke akun lain dengan IRSA
Anda dapat mengonfigurasi izin IAM lintas akun baik dengan membuat penyedia identitas dari klaster akun lain atau dengan menggunakan operasi berantai. `AssumeRole` Dalam contoh berikut, *Akun A* memiliki klaster Amazon EKS yang mendukung peran IAM untuk akun layanan. Pod yang berjalan di klaster tersebut harus mengasumsikan izin IAM dari *Akun* B.
+ **Opsi 1** lebih sederhana tetapi membutuhkan Akun B untuk membuat dan mengelola penyedia identitas OIDC untuk klaster Akun A.
+ **Opsi 2** membuat manajemen OIDC di Akun A tetapi membutuhkan rantai peran melalui dua panggilan. `AssumeRole`
## Opsi 1: Buat penyedia identitas dari cluster akun lain
Dalam contoh ini, Akun A menyediakan Akun B dengan URL penerbit OpenID Connect (OIDC) dari klaster mereka. Akun B mengikuti petunjuk dalam [Membuat penyedia IAM OIDC untuk klaster Anda](enable-iam-roles-for-service-accounts.md) dan [Tetapkan peran IAM ke akun layanan Kubernetes](associate-service-account-role.md) menggunakan URL penerbit OIDC dari klaster Akun A. Kemudian, administrator klaster memberi anotasi pada akun layanan di klaster Akun A untuk menggunakan peran dari Akun B ()*444455556666*.
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
```
## Opsi 2: Gunakan operasi berantai `AssumeRole`
Dalam pendekatan ini, setiap akun membuat peran IAM. Peran Akun B mempercayai Akun A, dan peran Akun A menggunakan federasi OIDC untuk mendapatkan kredensi dari klaster. Pod kemudian menghubungkan kedua peran tersebut bersama-sama menggunakan profil AWS CLI.
### Langkah 1: Buat peran target di Akun B
Akun B (*444455556666*) membuat peran IAM dengan izin yang dibutuhkan Pod di klaster Akun A. Akun B melampirkan kebijakan izin yang diinginkan ke peran ini, lalu menambahkan kebijakan kepercayaan berikut.
**Kebijakan kepercayaan untuk peran Akun B** — Kebijakan ini memungkinkan peran IRSA spesifik Akun A untuk mengambil peran ini.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**penting**
Untuk hak istimewa terkecil, ganti `Principal` ARN dengan peran spesifik ARN dari Akun A alih-alih menggunakan root akun (). `arn:aws:iam::111122223333:root` Menggunakan root akun memungkinkan *setiap* prinsipal IAM di Akun A untuk mengambil peran ini.
### Langkah 2: Buat peran IRSA di Akun A
Akun A (*111122223333*) membuat peran dengan kebijakan kepercayaan yang mendapatkan kredensional dari penyedia identitas yang dibuat dengan alamat penerbit OIDC klaster.
**Kebijakan kepercayaan untuk peran Akun A (federasi OIDC)** — Kebijakan ini memungkinkan penyedia OIDC klaster EKS untuk mengeluarkan kredensi untuk peran ini.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**penting**
Untuk sedikit hak istimewa, tambahkan `StringEquals` kondisi untuk `sub` klaim untuk membatasi peran ini ke akun layanan Kubernetes tertentu. Tanpa `sub` syarat, akun layanan apa pun di cluster dapat mengambil peran ini. `sub`Nilai menggunakan format`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Misalnya, untuk membatasi ke akun layanan bernama `my-service-account` di `default` namespace:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### Langkah 3: Lampirkan AssumeRole izin ke peran Akun A
Akun A melampirkan kebijakan izin ke peran yang dibuat di Langkah 2. Kebijakan ini memungkinkan peran untuk mengambil peran Akun B.
**Kebijakan izin untuk peran Akun A** — Kebijakan ini memberikan `sts:AssumeRole` peran target Akun B.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### Langkah 4: Konfigurasikan Pod ke peran rantai
Kode aplikasi untuk Pod untuk mengambil peran Akun B menggunakan dua profil: `account_b_role` dan`account_a_role`. Profil `account_b_role` menggunakan profil `account_a_role` sebagai sumbernya. Untuk AWS CLI, `~/.aws/config` file ini mirip dengan yang berikut ini.
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws: iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws: iam::111122223333:role/account-a-role
```
Untuk menentukan profil berantai untuk lainnya AWS SDKs, lihat dokumentasi SDK yang Anda gunakan. Untuk informasi selengkapnya, lihat [Alat untuk Dibangun AWS](https://aws.amazon.com/developer/tools/).
# Gunakan IRSA dengan SDK AWS
**Menggunakan kredensialnya**
Untuk menggunakan kredensi dari peran IAM untuk akun layanan (IRSA), kode Anda dapat menggunakan SDK apa pun untuk membuat klien untuk AWS layanan dengan AWS SDK, dan secara default SDK mencari di rantai lokasi untuk kredensi Identity and Access Management AWS yang akan digunakan. Peran IAM untuk kredenal akun layanan akan digunakan jika Anda tidak menentukan penyedia kredensi saat membuat klien atau menginisialisasi SDK.
Ini berfungsi karena peran IAM untuk akun layanan telah ditambahkan sebagai langkah dalam rantai kredensi default. Jika beban kerja Anda saat ini menggunakan kredenal yang sebelumnya dalam rantai kredensional, kredensial tersebut akan terus digunakan bahkan jika Anda mengonfigurasi peran IAM untuk akun layanan untuk beban kerja yang sama.
SDK secara otomatis menukar token OIDC akun layanan untuk kredensi sementara dari AWS Security Token Service dengan menggunakan tindakan tersebut. `AssumeRoleWithWebIdentity` Amazon EKS dan tindakan SDK ini terus memutar kredensi sementara dengan memperbaruinya sebelum kedaluwarsa.
Saat menggunakan [peran IAM untuk akun layanan](iam-roles-for-service-accounts.md), container di Pod Anda harus menggunakan versi AWS SDK yang mendukung asumsi peran IAM melalui file token identitas web OpenID Connect. Pastikan Anda menggunakan versi berikut, atau yang lebih baru, untuk AWS SDK Anda:
+ Java (Versi 2) - [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11)
+ Jawa — [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782)
+ AWS [SDK for Go v1 - 1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13)
+ AWS SDK for Go v2 - Semua versi mendukung
+ [Python (Boto3) - 1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220)
+ [Python (botocore) - 1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200)
+ AWS [CLI — 1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232)
+ [Node — [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) dan 3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0)
+ [Ruby — 3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01)
+ [C\$1\$1 — 1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174)
+ .NET — [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) — Anda juga harus menyertakan. `AWSSDK.SecurityToken`
+ PHP — [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7)
Banyak add-on Kubernetes yang populer, seperti [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), [lalu lintas internet Route dengan Load AWS Balancer Controller,](aws-load-balancer-controller.md) dan plugin [Amazon VPC](cni-iam-role.md) CNI untuk Kubernetes mendukung peran IAM untuk akun layanan.
Untuk memastikan bahwa Anda menggunakan SDK yang didukung, ikuti petunjuk penginstalan untuk SDK pilihan Anda di [Tools to Build on AWS](https://aws.amazon.com/tools/) saat Anda membuat container.
## Pertimbangan
### Java
Saat menggunakan Java, Anda *harus* menyertakan `sts` modul pada classpath. Untuk informasi selengkapnya, lihat [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html)di dokumen Java SDK.
# Ambil kunci penandatanganan untuk memvalidasi token OIDC
Kubernetes mengeluarkan a `ProjectedServiceAccountToken` ke setiap Akun Layanan Kubernetes. Token ini adalah token OIDC, yang selanjutnya merupakan jenis token web JSON (JWT). Amazon EKS menghosting endpoint OIDC publik untuk setiap cluster yang berisi kunci penandatanganan untuk token sehingga sistem eksternal dapat memvalidasinya.
Untuk memvalidasi`ProjectedServiceAccountToken`, Anda perlu mengambil kunci penandatanganan publik OIDC, juga disebut JSON Web Key Set (JWKS). Gunakan kunci ini dalam aplikasi Anda untuk memvalidasi token. Misalnya, Anda dapat menggunakan pustaka [PyjWT Python](https://pyjwt.readthedocs.io/en/latest/) untuk memvalidasi token menggunakan kunci ini. Untuk informasi lebih lanjut tentang`ProjectedServiceAccountToken`, lihat[Informasi latar belakang IAM, Kubernetes, dan OpenID Connect (OIDC)](iam-roles-for-service-accounts.md#irsa-oidc-background).
## Prasyarat
+ Penyedia OpenID Connect (OIDC) AWS Identity and Access Management (IAM) yang sudah ada untuk klaster Anda. Untuk menentukan apakah Anda sudah memiliki satu, atau harus membuat satu, lihat [Buat penyedia IAM OIDC untuk klaster Anda](enable-iam-roles-for-service-accounts.md).
+ ** AWS CLI** — Alat baris perintah untuk bekerja dengan AWS layanan, termasuk Amazon EKS. Untuk informasi selengkapnya, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di Panduan Pengguna Antarmuka Baris AWS Perintah. Setelah menginstal AWS CLI, kami sarankan Anda juga mengkonfigurasinya. Untuk informasi selengkapnya, lihat [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di Panduan Pengguna Antarmuka Baris AWS Perintah.
## Prosedur
1. Ambil URL OIDC untuk klaster Amazon EKS Anda menggunakan CLI. AWS
```
$ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
"https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
```
1. Ambil kunci penandatanganan publik menggunakan curl, atau alat serupa. Hasilnya adalah [JSON Web Key Set (JWKS](https://www.rfc-editor.org/rfc/rfc7517#section-5)).
**penting**
Amazon EKS membatasi panggilan ke titik akhir OIDC. Anda harus men-cache kunci penandatanganan publik. Hormati `cache-control` header yang termasuk dalam respons.
**penting**
Amazon EKS memutar kunci penandatanganan OIDC setiap tujuh hari.
```
$ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
{"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
```
# Pelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS
Aplikasi dalam kontainer Pod dapat menggunakan AWS SDK atau AWS CLI untuk membuat permintaan API AWS ke layanan AWS menggunakan izin Identity and Access Management (IAM). Aplikasi harus menandatangani permintaan AWS API mereka dengan AWS kredensialnya.
*EKS Pod Identities* menyediakan kemampuan untuk mengelola kredensional untuk aplikasi Anda, mirip dengan cara profil EC2 instans Amazon memberikan kredensi ke instans Amazon. EC2 Alih-alih membuat dan mendistribusikan AWS kredensialmu ke container atau menggunakan peran EC2 instans Amazon, kamu mengaitkan peran IAM dengan akun layanan Kubernetes dan mengonfigurasi Pod kamu untuk menggunakan akun layanan.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)
Setiap asosiasi EKS Pod Identity memetakan peran ke akun layanan di namespace di cluster yang ditentukan. Jika Anda memiliki aplikasi yang sama di beberapa cluster, Anda dapat membuat asosiasi identik di setiap cluster tanpa mengubah kebijakan kepercayaan peran.
Jika sebuah pod menggunakan akun layanan yang memiliki asosiasi, Amazon EKS menetapkan variabel lingkungan dalam kontainer pod. Variabel lingkungan mengonfigurasi AWS SDKs, termasuk AWS CLI, untuk menggunakan kredenal Identitas Pod EKS.
## Manfaat Identitas EKS Pod
EKS Pod Identities memberikan manfaat sebagai berikut:
+ **Keistimewaan paling** kecil — Anda dapat memberikan cakupan izin IAM ke akun layanan, dan hanya Pod yang menggunakan akun layanan tersebut yang memiliki akses ke izin tersebut. Fitur ini juga mengurangi kebutuhan akan solusi dari pihak ketiga seperti `kiam` atau `kube2iam`.
+ **Isolasi kredenal** — Ketika akses ke [Amazon EC2 Instance Metadata Service (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) dibatasi, container Pod hanya dapat mengambil kredensial untuk peran IAM yang terkait dengan akun layanan yang digunakan container. Container tidak pernah memiliki akses ke kredensi yang digunakan oleh kontainer lain di Pod lain. Jika IMDS tidak dibatasi, kontainer Pod juga memiliki akses ke [peran IAM node Amazon EKS](create-node-role.md) dan kontainer mungkin dapat memperoleh akses ke kredensial-kredensi peran IAM dari Pod lain pada node yang sama. Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).
**catatan**
Pod yang dikonfigurasi `hostNetwork: true` akan selalu memiliki akses IMDS, tetapi CLI AWS SDKs dan akan menggunakan kredenal Identitas Pod saat diaktifkan.
+ **Auditabilitas** — Akses dan pencatatan peristiwa tersedia AWS CloudTrail untuk membantu memfasilitasi audit retrospektif.
**penting**
Container bukanlah batas keamanan, dan penggunaan Pod Identity tidak mengubah ini. Pod yang ditetapkan ke node yang sama akan berbagi kernel dan kemungkinan sumber daya lainnya tergantung pada konfigurasi Pod Anda. Sementara Pod yang berjalan pada node terpisah akan diisolasi pada lapisan komputasi, ada aplikasi node yang memiliki izin tambahan di API Kubernetes di luar cakupan instance individual. Beberapa contohnya adalah `kubelet``kube-proxy`, driver penyimpanan CSI, atau aplikasi Kubernetes Anda sendiri.
EKS Pod Identity adalah metode yang lebih sederhana daripada[IAM role untuk akun layanan](iam-roles-for-service-accounts.md), karena metode ini tidak menggunakan penyedia identitas OIDC. EKS Pod Identity memiliki penyempurnaan sebagai berikut:
+ **Operasi independen** — Di banyak organisasi, membuat penyedia identitas OIDC adalah tanggung jawab tim yang berbeda daripada mengelola klaster Kubernetes. EKS Pod Identity memiliki pemisahan tugas yang bersih, di mana semua konfigurasi asosiasi Identitas Pod EKS dilakukan di Amazon EKS dan semua konfigurasi izin IAM dilakukan di IAM.
+ **Reusability** — EKS Pod Identity menggunakan satu prinsipal IAM, bukan prinsipal terpisah untuk setiap klaster yang digunakan peran IAM untuk akun layanan. Administrator IAM Anda menambahkan prinsipal berikut ke kebijakan kepercayaan dari peran apa pun agar dapat digunakan oleh EKS Pod Identities.
```
"Principal": {
"Service": "pods.eks.amazonaws.com"
}
```
+ **Skalabilitas** — Setiap set kredensial sementara diasumsikan oleh layanan EKS Auth di EKS Pod Identity, bukan setiap AWS SDK yang Anda jalankan di setiap pod. Kemudian, Amazon EKS Pod Identity Agent yang berjalan di setiap node mengeluarkan kredensialnya ke. SDKs Dengan demikian beban dikurangi menjadi satu kali untuk setiap node dan tidak diduplikasi di setiap pod. Untuk detail lebih lanjut tentang prosesnya, lihat[Pahami cara kerja EKS Pod Identity](pod-id-how-it-works.md).
Untuk informasi lebih lanjut untuk membandingkan dua alternatif, lihat[Berikan akses beban kerja Kubernetes untuk AWS menggunakan Akun Layanan Kubernetes](service-accounts.md).
## Ikhtisar pengaturan EKS Pod Identities
Aktifkan Identitas Pod EKS dengan menyelesaikan prosedur berikut:
1. [Siapkan Agen Identitas Amazon EKS Pod](pod-id-agent-setup.md)— Anda hanya menyelesaikan prosedur ini sekali untuk setiap cluster. Anda tidak perlu menyelesaikan langkah ini jika Mode Otomatis EKS diaktifkan di cluster Anda.
1. [Menetapkan peran IAM ke akun layanan Kubernetes](pod-id-association.md)— Selesaikan prosedur ini untuk setiap set izin unik yang Anda inginkan untuk dimiliki aplikasi.
1. [Konfigurasikan Pod untuk mengakses AWS layanan dengan akun layanan](pod-id-configure-pods.md)— Selesaikan prosedur ini untuk setiap Pod yang membutuhkan akses ke AWS layanan.
1. [Menggunakan identitas pod dengan AWS SDK](pod-id-minimum-sdk.md)— Konfirmasikan bahwa beban kerja menggunakan AWS SDK versi yang didukung dan bahwa beban kerja menggunakan rantai kredenal default.
## Batas
+ Hingga 5.000 asosiasi Identitas Pod EKS per cluster untuk memetakan peran IAM ke akun layanan Kubernetes didukung.
## Pertimbangan
+ **Asosiasi Peran IAM**: Setiap akun layanan Kubernetes dalam klaster dapat dikaitkan dengan satu peran IAM dari akun yang sama AWS dengan klaster. Untuk mengubah peran, edit asosiasi EKS Pod Identity. Untuk akses lintas akun, delegasikan akses ke peran menggunakan peran IAM. Untuk mempelajari lebih lanjut, lihat [Mendelegasikan akses di seluruh AWS akun menggunakan peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) di Panduan Pengguna *IAM*.
+ **Agen Identitas Pod EKS**: Agen Identitas Pod wajib menggunakan EKS Pod Identity. Agen berjalan sebagai Kubernetes `DaemonSet` pada node cluster, memberikan kredensi hanya untuk pod pada node yang sama. Ini menggunakan node`hostNetwork`, menempati port `80` dan `2703` pada alamat link-lokal (`169.254.170.23`untuk IPv4, `[fd00:ec2::23]` untuk). IPv6 Jika IPv6 dinonaktifkan di klaster Anda, nonaktifkan IPv6 untuk Agen Identitas Pod. Untuk mempelajari lebih lanjut, lihat [Menonaktifkan IPv6 di Agen Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html).
+ **Konsistensi Akhir**: Asosiasi Identitas Pod EKS pada akhirnya konsisten, dengan potensi penundaan beberapa detik setelah panggilan API. Hindari membuat atau memperbarui asosiasi di jalur kode ketersediaan tinggi yang kritis. Sebagai gantinya, lakukan tindakan ini dalam rutinitas inisialisasi atau pengaturan yang terpisah dan lebih jarang. Untuk mempelajari selengkapnya, lihat [Grup Keamanan Per Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) di *Panduan Praktik Terbaik EKS*.
+ **Pertimbangan Grup Proxy dan Keamanan**: Untuk pod yang menggunakan proxy, tambahkan `169.254.170.23` (IPv4) dan `[fd00:ec2::23]` (IPv6) ke variabel `no_proxy/NO_PROXY` lingkungan untuk mencegah permintaan gagal ke Agen Identitas Pod EKS. Jika menggunakan Grup Keamanan untuk Pod dengan AWS VPC CNI, atur `ENABLE_POD_ENI` flag ke 'true' dan flag ke 'standard'. `POD_SECURITY_GROUP_ENFORCING_MODE` Untuk mempelajari lebih lanjut, lihat [Menetapkan grup keamanan ke Pod individual](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html).
### EKS Pod Identity versi cluster
Untuk menggunakan EKS Pod Identity, cluster harus memiliki versi platform yang sama atau lebih lambat dari versi yang tercantum dalam tabel berikut, atau versi Kubernetes yang lebih lambat dari versi yang tercantum dalam tabel. Untuk menemukan versi yang disarankan dari Amazon EKS Pod Identity Agent untuk versi Kubernetes, lihat. [Verifikasi kompatibilitas versi add-on Amazon EKS dengan klaster](addon-compat.md)
| Versi Kubernetes | Versi platform |
| --- | --- |
| Versi Kubernetes tidak terdaftar | Semua versi platform mendukung |
| `1.28` | `eks.4` |
### Pembatasan Identitas Pod EKS
Identitas Pod EKS tersedia pada hal-hal berikut:
+ Amazon EKS versi cluster tercantum dalam topik sebelumnya[EKS Pod Identity versi cluster](#pod-id-cluster-versions).
+ Node pekerja di cluster yang merupakan EC2 instance Linux Amazon.
EKS Pod Identities tidak tersedia di berikut ini:
+ AWS Outposts.
+ Amazon EKS Anywhere.
+ Cluster Kubernetes yang Anda buat dan jalankan di Amazon. EC2 Komponen EKS Pod Identity hanya tersedia di Amazon EKS.
Anda tidak dapat menggunakan EKS Pod Identities dengan:
+ Pod yang berjalan di mana saja kecuali EC2 instance Linux Amazon. Pod Linux dan Windows yang berjalan di AWS Fargate (Fargate) tidak didukung. Pod yang berjalan di EC2 instans Windows Amazon tidak didukung.
# Pahami cara kerja EKS Pod Identity
Asosiasi Amazon EKS Pod Identity menyediakan kemampuan untuk mengelola kredensional untuk aplikasi Anda, mirip dengan cara profil EC2 instans Amazon memberikan kredensil ke instans Amazon. EC2
Amazon EKS Pod Identity memberikan kredensi ke beban kerja Anda dengan API *Auth EKS* tambahan dan pod agen yang berjalan di setiap node.
Di add-on Anda, seperti *add-on Amazon EKS* dan pengontrol yang dikelola sendiri, operator, dan add-on lainnya, penulis perlu memperbarui perangkat lunak mereka untuk menggunakan yang terbaru. AWS SDKs Untuk daftar kompatibilitas antara EKS Pod Identity dan add-on yang diproduksi oleh Amazon EKS, lihat bagian [Pembatasan Identitas Pod EKS](pod-identities.md#pod-id-restrictions) sebelumnya.
## Menggunakan Identitas Pod EKS dalam kode Anda
Dalam kode Anda, Anda dapat menggunakan AWS SDKs untuk mengakses AWS layanan. Anda menulis kode untuk membuat klien untuk AWS layanan dengan SDK, dan secara default SDK mencari di rantai lokasi untuk menggunakan kredenal AWS Identity and Access Management. Setelah kredensi yang valid ditemukan, pencarian dihentikan. Untuk informasi selengkapnya tentang lokasi default yang digunakan, lihat [rantai penyedia kredenal](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) di Panduan Referensi Alat AWS SDKs dan Alat.
EKS Pod Identities telah ditambahkan ke *penyedia kredensi Container* yang dicari dalam satu langkah dalam rantai kredensi default. Jika beban kerja Anda saat ini menggunakan kredensial yang sebelumnya ada dalam rantai kredensil, kredensial-kredensialnya akan terus digunakan meskipun Anda mengonfigurasi asosiasi Identitas Pod EKS untuk beban kerja yang sama. Dengan cara ini Anda dapat dengan aman bermigrasi dari jenis kredensil lain dengan membuat asosiasi terlebih dahulu, sebelum menghapus kredensil lama.
Penyedia kredensial kontainer menyediakan kredensi sementara dari agen yang berjalan di setiap node. Di Amazon EKS, agennya adalah Agen Identitas Pod Amazon EKS dan di Amazon Elastic Container Service agennya adalah`amazon-ecs-agent`. Variabel lingkungan SDKs penggunaan untuk menemukan agen untuk terhubung ke.
Sebaliknya, *peran IAM untuk akun layanan* menyediakan token *identitas web* yang harus ditukar oleh AWS SDK dengan AWS Security Token Service. `AssumeRoleWithWebIdentity`
## Bagaimana Agen Identitas EKS Pod bekerja dengan Pod
1. Saat Amazon EKS memulai pod baru yang menggunakan akun layanan dengan asosiasi Identitas Pod EKS, klaster akan menambahkan konten berikut ke manifes Pod:
```
env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
value: "http://169.254.170.23/v1/credentials"
volumeMounts:
- mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
name: eks-pod-identity-token
volumes:
- name: eks-pod-identity-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: pods.eks.amazonaws.com
expirationSeconds: 86400 # 24 hours
path: eks-pod-identity-token
```
1. Kubernetes memilih node mana yang akan menjalankan pod. Kemudian, Amazon EKS Pod Identity Agent pada node menggunakan [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)action untuk mengambil kredensial sementara dari EKS Auth API.
1. Agen Identitas Pod EKS membuat kredensil ini tersedia untuk AWS SDKs yang Anda jalankan di dalam kontainer Anda.
1. Anda menggunakan SDK dalam aplikasi Anda tanpa menentukan penyedia kredensi untuk menggunakan rantai kredensi default. Atau, Anda menentukan penyedia kredensi kontainer. Untuk informasi selengkapnya tentang lokasi default yang digunakan, lihat [rantai penyedia kredenal](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) di Panduan Referensi Alat AWS SDKs dan Alat.
1. SDK menggunakan variabel lingkungan untuk terhubung ke Agen Identitas Pod EKS dan mengambil kredensialnya.
**catatan**
Jika beban kerja Anda saat ini menggunakan kredensial yang sebelumnya ada dalam rantai kredensil, kredensial-kredensialnya akan terus digunakan meskipun Anda mengonfigurasi asosiasi Identitas Pod EKS untuk beban kerja yang sama.
# Siapkan Agen Identitas Amazon EKS Pod
Asosiasi Amazon EKS Pod Identity menyediakan kemampuan untuk mengelola kredensional untuk aplikasi Anda, mirip dengan cara profil EC2 instans Amazon memberikan kredensi ke instans Amazon. EC2
Amazon EKS Pod Identity memberikan kredensi ke beban kerja Anda dengan API *Auth EKS* tambahan dan pod agen yang berjalan di setiap node.
**Tip**
Anda tidak perlu menginstal Agen Identitas Pod EKS pada Kluster Mode Otomatis EKS. Kemampuan ini dibangun ke dalam Mode Otomatis EKS.
## Pertimbangan-pertimbangan
+ Secara default, Agen Identitas Pod EKS sudah diinstal sebelumnya pada kluster Mode Otomatis EKS. Untuk mempelajari selengkapnya, lihat [Mengotomatiskan infrastruktur klaster dengan Mode Otomatis EKS](automode.md).
+ Secara default, Agen Identitas Pod EKS mendengarkan `IPv4` dan `IPv6` alamat pod untuk meminta kredensialnya. Agen menggunakan alamat IP loopback (localhost) `169.254.170.23` untuk `IPv4` dan alamat IP localhost untuk. `[fd00:ec2::23]` `IPv6`
+ Jika Anda menonaktifkan `IPv6` alamat, atau mencegah alamat `IPv6` IP localhost, agen tidak dapat memulai. Untuk memulai agen pada node yang tidak dapat digunakan`IPv6`, ikuti langkah-langkah [Nonaktifkan `IPv6` di Agen Identitas Pod EKS](pod-id-agent-config-ipv6.md) untuk menonaktifkan `IPv6` konfigurasi.
## Membuat Agen Identitas Amazon EKS Pod
### Prasyarat agen
+ Sebuah klaster Amazon EKS yang sudah ada. Untuk menyebarkan satu, lihat[Memulai dengan Amazon EKS](getting-started.md). Versi cluster dan versi platform harus sama atau lebih lambat dari versi yang tercantum dalam [versi cluster EKS Pod Identity](pod-identities.md#pod-id-cluster-versions).
+ Peran node memiliki izin bagi agen untuk melakukan `AssumeRoleForPodIdentity` tindakan di EKS Auth API. Anda dapat menggunakan [kebijakan AWS terkelola: Amazon EKSWorker NodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) atau menambahkan kebijakan khusus yang serupa dengan berikut ini:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}
```
Tindakan ini dapat dibatasi oleh tag untuk membatasi peran mana yang dapat diasumsikan oleh pod yang menggunakan agen.
+ Node dapat menjangkau dan mengunduh gambar dari Amazon ECR. Gambar kontainer untuk add-on ada di pendaftar yang tercantum di Lihat [pendaftar gambar kontainer Amazon untuk add-on Amazon EKS.](add-ons-images.md)
Perhatikan bahwa Anda dapat mengubah lokasi gambar dan `imagePullSecrets` menyediakan add-on EKS di **pengaturan konfigurasi Opsional** di Konsol Manajemen AWS, dan `--configuration-values` di AWS CLI.
+ Node dapat mencapai Amazon EKS Auth API. Untuk cluster pribadi, `eks-auth` titik akhir di AWS PrivateLink diperlukan.
### Agen penyiapan dengan AWS konsol
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih **Clusters**, lalu pilih nama cluster yang ingin Anda konfigurasikan untuk add-on EKS Pod Identity Agent.
1. Pilih tab **Add-ons**.
1. Pilih **Get more add-ons**
1. Pilih kotak di kanan atas kotak add-on untuk EKS Pod Identity Agent dan kemudian pilih **Berikutnya**.
1. Pada halaman **Konfigurasi pengaturan add-on yang dipilih**, pilih versi apa pun di daftar **dropdown Versi**.
1. (Opsional) Perluas **pengaturan konfigurasi opsional** untuk memasukkan konfigurasi tambahan. Misalnya, Anda dapat memberikan lokasi gambar kontainer alternatif dan`ImagePullSecrets`. Skema JSON dengan kunci yang diterima ditampilkan dalam skema konfigurasi **Add-on**.
Masukkan tombol konfigurasi dan nilai dalam **nilai Konfigurasi**.
1. Pilih **Berikutnya**.
1. Konfirmasikan bahwa pod EKS Pod Identity Agent berjalan di klaster Anda.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Contoh output adalah sebagai berikut.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Anda sekarang dapat menggunakan asosiasi EKS Pod Identity di klaster Anda. Untuk informasi selengkapnya, lihat [Menetapkan peran IAM ke akun layanan Kubernetes](pod-id-association.md).
### Agen penyiapan dengan AWS CLI
1. Jalankan perintah AWS CLI berikut. Ganti `my-cluster` dengan nama klaster Anda.
```
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
```
**catatan**
Agen Identitas Pod EKS tidak menggunakan *peran `service-account-role-arn` untuk IAM untuk akun layanan*. Anda harus memberikan izin kepada Agen Identitas Pod EKS dalam peran node.
1. Konfirmasikan bahwa pod EKS Pod Identity Agent berjalan di klaster Anda.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Contoh output adalah sebagai berikut.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Anda sekarang dapat menggunakan asosiasi EKS Pod Identity di klaster Anda. Lihat informasi yang lebih lengkap di [Menetapkan peran IAM ke akun layanan Kubernetes](pod-id-association.md).
# Menetapkan peran IAM ke akun layanan Kubernetes
Topik ini membahas cara mengkonfigurasi akun layanan Kubernetes untuk mengambil peran AWS Identity and Access Management (IAM) dengan EKS Pod Identity. Pod apa pun yang dikonfigurasi untuk menggunakan akun layanan kemudian dapat mengakses AWS layanan apa pun yang perannya memiliki izin untuk diakses.
Untuk membuat asosiasi EKS Pod Identity, hanya ada satu langkah; Anda membuat asosiasi di EKS melalui Konsol Manajemen AWS, AWS CLI, AWS SDKs, AWS CloudFormation dan alat-alat lainnya. Tidak ada data atau metadata tentang asosiasi di dalam cluster di objek Kubernetes mana pun dan Anda tidak menambahkan anotasi apa pun ke akun layanan.
**Prasyarat**
+ Sebuah klaster yang sudah ada. Jika Anda tidak memilikinya, Anda dapat membuatnya dengan mengikuti salah satu panduan di[Memulai dengan Amazon EKS](getting-started.md).
+ Prinsip IAM yang menciptakan asosiasi harus memiliki`iam:PassRole`.
+ Versi terbaru dari AWS CLI diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Anda dapat memeriksa versi saat ini dengan `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di Panduan Pengguna Antarmuka Baris AWS Perintah. Versi AWS CLI yang diinstal di AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di AWS CloudShell Panduan Pengguna.
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ `kubectl``config`File yang sudah ada yang berisi konfigurasi cluster Anda. Untuk membuat `kubectl` `config` file, lihat[Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md).
## Membuat asosiasi Pod Identity (AWS Console)
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi sebelah kiri, pilih **Clusters**, lalu pilih nama cluster yang ingin Anda konfigurasikan untuk add-on EKS Pod Identity Agent.
1. Pilih tab **Access**.
1. Dalam **asosiasi Pod Identity**, pilih **Create**.
1. Untuk peran **IAM, pilih peran** IAM dengan izin yang Anda inginkan untuk memiliki beban kerja.
**catatan**
Daftar ini hanya berisi peran yang memiliki kebijakan kepercayaan berikut yang memungkinkan EKS Pod Identity untuk menggunakannya.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
`sts:AssumeRole`— EKS Pod Identity digunakan `AssumeRole` untuk mengambil peran IAM sebelum meneruskan kredensi sementara ke pod Anda.
`sts:TagSession`— EKS Pod Identity menggunakan `TagSession` untuk menyertakan *tag sesi* dalam permintaan ke AWS STS.
Anda dapat menggunakan tag ini di *kunci kondisi* dalam kebijakan kepercayaan untuk membatasi akun layanan, ruang nama, dan klaster mana yang dapat menggunakan peran ini.
*Untuk daftar kunci kondisi Amazon EKS, lihat [Ketentuan yang ditentukan oleh Amazon Elastic Kubernetes Service di Referensi Otorisasi Layanan.](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)* Untuk mempelajari tindakan dan sumber daya yang dapat digunakan untuk menggunakan kunci kondisi, lihat [Tindakan yang ditentukan oleh Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
1. Untuk namespace **Kubernetes, pilih namespace** Kubernetes yang berisi akun layanan dan beban kerja. Secara opsional, Anda dapat menentukan namespace dengan nama yang tidak ada di cluster.
1. Untuk akun layanan **Kubernetes, pilih akun layanan** Kubernetes yang akan digunakan. Manifes untuk beban kerja Kubernetes Anda harus menentukan akun layanan ini. Secara opsional, Anda dapat menentukan akun layanan berdasarkan nama yang tidak ada di cluster.
1. (Opsional) Pilih **Nonaktifkan tag sesi** untuk menonaktifkan tag sesi default yang ditambahkan Pod Identity secara otomatis ketika mengambil peran.
1. (Opsional) Alihkan **kebijakan sesi Konfigurasi untuk mengonfigurasi kebijakan** IAM agar menerapkan batasan tambahan pada asosiasi Identitas Pod ini di luar izin yang ditentukan dalam kebijakan IAM yang dilampirkan pada peran IAM.
**catatan**
Kebijakan sesi hanya dapat diterapkan jika setelan **Nonaktifkan tag sesi** dicentang.
1. (Opsional) Untuk **Tag**, pilih **Tambahkan tag** untuk menambahkan metadata dalam pasangan kunci dan nilai. Tag ini diterapkan pada asosiasi dan dapat digunakan dalam kebijakan IAM.
Anda dapat mengulangi langkah ini untuk menambahkan beberapa tag.
1. Pilih **Buat**.
## Membuat asosiasi Pod Identity (AWS CLI)
1. Jika Anda ingin mengaitkan kebijakan IAM yang ada dengan peran IAM Anda, lewati ke langkah berikutnya.
Buat kebijakan IAM. Anda dapat membuat kebijakan sendiri, atau menyalin kebijakan AWS terkelola yang telah memberikan beberapa izin yang Anda perlukan dan menyesuaikannya dengan persyaratan spesifik Anda. Untuk informasi selengkapnya, lihat [Membuat kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dalam *Panduan Pengguna IAM*.
1. Buat file yang menyertakan izin untuk AWS layanan yang ingin diakses oleh Pod. Untuk daftar semua tindakan untuk semua AWS layanan, lihat [Referensi Otorisasi Layanan](https://docs.aws.amazon.com/service-authorization/latest/reference/).
Anda dapat menjalankan perintah berikut untuk membuat contoh file kebijakan yang memungkinkan akses hanya-baca ke bucket Amazon S3. Anda dapat secara opsional menyimpan informasi konfigurasi atau skrip bootstrap di bucket ini, dan kontainer di Pod Anda dapat membaca file dari bucket dan memuatnya ke dalam aplikasi Anda. Jika Anda ingin membuat kebijakan contoh ini, salin konten berikut ke perangkat Anda. Ganti *my-pod-secrets-bucket* dengan nama bucket Anda dan jalankan perintah.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. Buat kebijakan IAM.
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
1. Buat peran IAM dan kaitkan dengan akun layanan Kubernetes.
1. Jika Anda memiliki akun layanan Kubernetes yang ingin Anda ambil peran IAM, Anda dapat melewati langkah ini.
Buat akun layanan Kubernetes. Salin konten berikut ke perangkat Anda. Ganti *my-service-account* dengan nama yang Anda inginkan dan *default* dengan namespace yang berbeda, jika perlu. Jika Anda berubah*default*, namespace harus sudah ada.
```
cat >my-service-account.yaml <
1. Konfirmasikan bahwa kebijakan kepercayaan peran IAM telah dikonfigurasi dengan benar.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
Contoh output adalah sebagai berikut.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow EKS Auth service to assume this role for Pod Identities",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Konfirmasikan bahwa kebijakan yang Anda lampirkan pada peran Anda di langkah sebelumnya dilampirkan pada peran tersebut.
```
aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
```
Contoh output adalah sebagai berikut.
```
arn:aws: iam::111122223333:policy/my-policy
```
1. Tetapkan variabel untuk menyimpan Nama Sumber Daya Amazon (ARN) kebijakan yang ingin Anda gunakan. Ganti *my-policy* dengan nama kebijakan yang ingin Anda konfirmasi izin.
```
export policy_arn=arn:aws: iam::111122223333:policy/my-policy
```
1. Lihat versi default kebijakan.
```
aws iam get-policy --policy-arn $policy_arn
```
Contoh output adalah sebagai berikut.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws: iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Lihat konten kebijakan untuk memastikan bahwa kebijakan tersebut menyertakan semua izin yang dibutuhkan Pod Anda. Jika perlu, ganti *1* dalam perintah berikut dengan versi yang dikembalikan pada output sebelumnya.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
Contoh output adalah sebagai berikut.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Jika Anda membuat kebijakan contoh di langkah sebelumnya, maka output Anda sama. Jika Anda membuat kebijakan yang berbeda, maka *example* kontennya berbeda.
## Langkah Berikutnya
[Konfigurasikan Pod untuk mengakses AWS layanan dengan akun layanan](pod-id-configure-pods.md)
# Akses AWS Sumber Daya menggunakan Peran IAM Target Identitas EKS Pod
Saat menjalankan aplikasi di Amazon Elastic Kubernetes Service (Amazon EKS), Anda mungkin perlu mengakses sumber daya yang ada di AWS akun yang berbeda. AWS Panduan ini menunjukkan kepada Anda cara mengatur akses lintas akun menggunakan EKS Pod Identity, yang memungkinkan pod Kubernetes Anda mengakses AWS sumber daya lain menggunakan peran target.
## Prasyarat
Sebelum Anda mulai, pastikan Anda telah menyelesaikan langkah-langkah berikut:
+ [Siapkan Agen Identitas Amazon EKS Pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)
+ [Buat peran Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)
## Cara Kerjanya
Pod Identity memungkinkan aplikasi di klaster EKS Anda untuk mengakses AWS sumber daya di seluruh akun melalui proses yang disebut role chaining.
Saat membuat asosiasi Pod Identity, Anda dapat memberikan dua peran IAM: peran [Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) di akun yang sama dengan cluster EKS Anda dan Peran IAM Target dari akun yang berisi AWS sumber daya yang ingin Anda akses, (seperti bucket S3 atau Database RDS). [Peran EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) harus ada di akun kluster EKS Anda karena PassRole persyaratan [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html), sedangkan Target IAM Role dapat berada di akun apa pun AWS . PassRole memungkinkan AWS entitas untuk mendelegasikan asumsi peran ke layanan lain. EKS Pod Identity digunakan PassRole untuk menghubungkan peran ke akun layanan Kubernetes, yang mengharuskan peran dan identitas yang melewatinya berada di AWS akun yang sama dengan cluster EKS. Ketika pod aplikasi Anda perlu mengakses AWS sumber daya, ia meminta kredensil dari Pod Identity. Pod Identity kemudian secara otomatis melakukan dua asumsi peran secara berurutan: pertama dengan asumsi peran [EKS Pod Identity, kemudian menggunakan kredensial-kredensialnya untuk mengasumsikan Target IAM Role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html). Proses ini memberi pod Anda kredensi sementara yang memiliki izin yang ditentukan dalam peran target, memungkinkan akses aman ke sumber daya di akun lain. AWS
## Pertimbangan caching
Karena mekanisme caching, pembaruan peran IAM dalam asosiasi Identitas Pod yang ada mungkin tidak langsung berlaku di pod yang berjalan di klaster EKS Anda. Agen Identitas Pod menyimpan kredensial-kredensial IAM berdasarkan konfigurasi asosiasi pada saat kredensialnya diambil. Jika asosiasi hanya menyertakan [peran Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) dan tidak ada Peran IAM Target, kredenal yang di-cache akan bertahan selama 6 jam. Jika asosiasi tersebut mencakup [peran EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN dan Target IAM Role, kredenal cache akan berlangsung selama 59 menit. Memodifikasi asosiasi yang ada, seperti memperbarui [peran EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN atau menambahkan Peran IAM Target, tidak mengatur ulang cache yang ada. Akibatnya, agen tidak akan mengenali pembaruan sampai kredenial yang di-cache disegarkan. Untuk menerapkan perubahan lebih cepat, Anda dapat membuat ulang pod yang ada; jika tidak, Anda harus menunggu cache kedaluwarsa.
## Langkah 1: Buat dan kaitkan Peran IAM Target
Pada langkah ini, Anda akan membangun rantai kepercayaan yang aman dengan membuat dan mengonfigurasi Peran IAM Target. Untuk demonstrasi, kami akan membuat Peran IAM Target baru untuk membangun rantai kepercayaan antara dua AWS akun: peran [Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (misalnya,`eks-pod-identity-primary-role`) di AWS akun kluster EKS mendapatkan izin untuk mengambil Peran IAM Target (misalnya`eks-pod-identity-aws-resources`) di akun target Anda, memungkinkan akses ke sumber daya seperti bucket AWS Amazon S3.
### Buat Peran IAM Target
1. Buka [Amazon IAM console (Konsol Amazon IAM)](https://console.aws.amazon.com/iam/home).
1. Di bilah navigasi atas, verifikasi bahwa Anda masuk ke akun yang berisi AWS sumber daya (seperti bucket S3 atau tabel DynamoDB) untuk Peran IAM Target Anda.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Pilih tombol **Buat peran**, lalu ** AWS akun** di bawah “Jenis entitas tepercaya.”
1. Pilih ** AWS Akun lain**, masukkan nomor AWS akun Anda (akun tempat [peran Identitas EKS Pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) Anda ada), lalu pilih **Berikutnya**.
1. **Tambahkan kebijakan izin yang ingin Anda kaitkan ke peran (misalnya, AmazonS3FullAccess), lalu pilih Berikutnya.**
1. Masukkan nama peran, seperti`MyCustomIAMTargetRole`, lalu pilih **Buat peran**.
### Perbarui kebijakan kepercayaan Peran IAM Target
1. Setelah membuat peran, Anda akan dikembalikan ke daftar **Peran**. Temukan dan pilih peran baru yang Anda buat di langkah sebelumnya (mis.,`MyCustomIAMTargetRole`).
1. Pilih tab **Trust relationship**.
1. Klik **Edit kebijakan kepercayaan** di sisi kanan.
1. Di editor kebijakan, ganti JSON default dengan kebijakan kepercayaan Anda. Ganti nilai placeholder untuk nama peran dan `111122223333` ARN peran IAM dengan ID AWS akun yang menghosting kluster EKS Anda. Anda juga dapat menggunakan PrincipalTags kebijakan kepercayaan peran secara opsional untuk mengotorisasi hanya akun layanan tertentu dari klaster dan namespace tertentu untuk mengambil peran target Anda. Contoh:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
"aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
"aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
}
]
}
```
Kebijakan kebijakan di atas memungkinkan peran `eks-pod-identeity-primary-role` dari AWS akun 111122223333 dengan Tag Sesi [Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) yang relevan mengambil peran ini.
Jika Anda [Menonaktifkan Tag Sesi](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) dalam Identitas Pod EKS Anda, EKS Pod Identity juga menyetel informasi tentang cluster, namespace, dan akun layanan pod saat mengasumsikan peran target. `sts:ExternalId`
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:TagSession"
}
]
}
```
Kebijakan di atas membantu memastikan bahwa hanya klaster, namespace, dan akun layanan yang diharapkan yang dapat mengambil peran target.
### Memperbarui kebijakan izin untuk peran EKS Pod Identity
Pada langkah ini, Anda akan memperbarui kebijakan izin [peran Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) yang terkait dengan klaster Amazon EKS Anda dengan menambahkan ARN Peran IAM Target sebagai sumber daya.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih **Clusters**, lalu pilih nama kluster EKS Anda.
1. Pilih tab **Access**.
1. Di bawah **asosiasi Pod Identity**, pilih [peran Identitas Pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) Anda.
1. Pilih **Izin**, **Tambahkan izin**, lalu **Buat kebijakan sebaris**.
1. Pilih **JSON** di sisi kanan.
1. Di editor kebijakan, ganti JSON default dengan kebijakan izin Anda. Ganti nilai placeholder untuk nama peran dan `222233334444` ARN peran IAM dengan Peran IAM Target Anda. Contoh:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
}
]
}
```
## Langkah 2: Kaitkan Peran IAM Target ke akun layanan Kubernetes
Pada langkah ini, Anda akan membuat asosiasi antara peran IAM Target dan akun layanan Kubernetes di kluster EKS Anda.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih **Clusters**, lalu pilih nama cluster yang ingin Anda tambahkan asosiasi.
1. Pilih tab **Access**.
1. Dalam **asosiasi Pod Identity**, pilih **Create**.
1. Pilih [peran Identitas Pod EKS dalam peran](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) **IAM** untuk diasumsikan oleh beban kerja Anda.
1. Pilih peran IAM Target dalam peran **IAM Target yang akan diasumsikan oleh peran** [EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).
1. Di bidang **namespace Kubernetes**, masukkan nama namespace tempat Anda ingin membuat asosiasi (misalnya,). `my-app-namespace` Ini menentukan di mana akun layanan berada.
1. Di kolom **akun layanan Kubernetes, masukkan nama akun** layanan (misalnya,`my-service-account`) yang akan menggunakan kredensial IAM. Ini menautkan peran IAM ke akun layanan.
1. (Opsional) Pilih **Nonaktifkan tag sesi** untuk menonaktifkan tag sesi default yang ditambahkan Pod Identity secara otomatis ketika mengambil peran.
1. **(Opsional) Alihkan **kebijakan sesi Konfigurasi untuk mengonfigurasi kebijakan** IAM agar menerapkan batasan tambahan pada asosiasi Identitas Pod ini di luar izin yang ditentukan dalam kebijakan IAM yang dilampirkan pada peran IAM Target.**
**catatan**
1. Kebijakan sesi hanya dapat diterapkan jika setelan **Nonaktifkan tag sesi** dicentang. 2. Jika Anda menetapkan kebijakan sesi, maka pembatasan kebijakan berlaku untuk izin peran IAM **Target dan bukan peran IAM** yang terkait dengan asosiasi **Identitas** Pod ini.
1. Pilih **Buat** untuk membuat asosiasi.
# Konfigurasikan Pod untuk mengakses AWS layanan dengan akun layanan
Jika sebuah Pod perlu mengakses AWS layanan, maka Anda harus mengonfigurasinya untuk menggunakan akun layanan Kubernetes. Akun layanan harus dikaitkan dengan peran AWS Identity and Access Management (IAM) and Access Management (IAM) yang memiliki izin untuk mengakses layanan. AWS
+ Sebuah klaster yang sudah ada. Jika Anda tidak memilikinya, Anda dapat membuatnya menggunakan salah satu panduan di[Memulai dengan Amazon EKS](getting-started.md).
+ Akun layanan Kubernetes yang sudah ada dan asosiasi Identitas Pod EKS yang mengaitkan akun layanan dengan peran IAM. Peran tersebut harus memiliki kebijakan IAM terkait yang berisi izin yang Anda inginkan untuk Pod Anda untuk menggunakan AWS layanan. Untuk informasi selengkapnya tentang cara membuat akun dan peran layanan, dan mengonfigurasinya, lihat[Menetapkan peran IAM ke akun layanan Kubernetes](pod-id-association.md).
+ Versi terbaru dari AWS CLI diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Anda dapat memeriksa versi saat ini dengan `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di Panduan Pengguna Antarmuka Baris AWS Perintah. Versi AWS CLI yang diinstal di AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di AWS CloudShell Panduan Pengguna.
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ `kubectl``config`File yang sudah ada yang berisi konfigurasi cluster Anda. Untuk membuat `kubectl` `config` file, lihat[Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md).
1. Gunakan perintah berikut untuk membuat manifes deployment yang dapat digunakan untuk meng-deploy Pod untuk mengonfirmasi konfigurasi. Ganti nilai contoh dengan nilai Anda sendiri.
```
cat >my-deployment.yaml <
Kontrol akses berbasis atribut (ABAC) memberikan hak kepada pengguna melalui kebijakan yang menggabungkan atribut bersama-sama. EKS Pod Identity melampirkan tag ke kredensial sementara untuk setiap Pod dengan atribut seperti nama cluster, namespace, dan nama akun layanan. Tag sesi peran ini memungkinkan administrator untuk membuat peran tunggal yang dapat bekerja di seluruh akun layanan dengan mengizinkan akses ke AWS sumber daya berdasarkan tag yang cocok. Dengan menambahkan dukungan untuk tag sesi peran, Anda dapat menerapkan batasan keamanan yang lebih ketat antara kluster, dan beban kerja dalam klaster, sambil menggunakan kembali peran IAM dan kebijakan IAM yang sama.
## Contoh kebijakan dengan tag
Di bawah ini adalah contoh kebijakan IAM yang memberikan `s3:GetObject` izin ketika objek yang sesuai ditandai dengan nama cluster EKS.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
}
}
}
]
}
```
## Mengaktifkan atau menonaktifkan tag sesi
Identitas Pod EKS menambahkan set tanda sesi yang telah ditentukan sebelumnya ketika mengambil peran. Tag sesi ini memungkinkan administrator untuk membuat peran tunggal yang dapat bekerja di seluruh sumber daya dengan mengizinkan akses ke AWS sumber daya berdasarkan tag yang cocok.
### Aktifkan tag sesi
Tag sesi diaktifkan secara otomatis dengan identitas Pod EKS — tidak ada tindakan yang diperlukan di pihak Anda. Secara default, EKS Pod Identity melampirkan satu set tag yang telah ditentukan ke sesi Anda. Untuk mereferensikan tag ini dalam kebijakan, gunakan sintaks yang `${aws:PrincipalTag/` diikuti oleh kunci tag. Misalnya, `${aws:PrincipalTag/kubernetes-namespace}`.
+ `eks-cluster-arn`
+ `eks-cluster-name`
+ `kubernetes-namespace`
+ `kubernetes-service-account`
+ `kubernetes-pod-name`
+ `kubernetes-pod-uid`
### Menonaktifkan tanda sesi
AWS mengompres kebijakan sesi inline, kebijakan terkelola ARNs, dan tag sesi ke dalam format biner yang dikemas yang memiliki batas terpisah. Jika Anda menerima `PackedPolicyTooLarge` kesalahan yang menunjukkan format biner yang dikemas telah melebihi batas ukuran, Anda dapat mencoba mengurangi ukuran dengan menonaktifkan tag sesi yang ditambahkan oleh EKS Pod Identity. Untuk menonaktifkan tag sesi ini, ikuti langkah-langkah berikut:
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih **Cluster**, lalu pilih nama cluster yang ingin Anda ubah.
1. Pilih tab **Access**.
1. Di **asosiasi Identitas Pod**, pilih ID asosiasi yang ingin Anda ubah di **ID Asosiasi**, lalu pilih **Edit**.
1. Di bawah **Tag sesi**, pilih **Nonaktifkan tag sesi**.
1. Pilih **Simpan perubahan**.
## Tag lintas-akun
Semua tag sesi yang ditambahkan oleh EKS Pod Identity bersifat *transitif*; kunci dan nilai tag diteruskan ke `AssumeRole` tindakan apa pun yang digunakan beban kerja Anda untuk beralih peran ke akun lain. Anda dapat menggunakan tag ini dalam kebijakan di akun lain untuk membatasi akses dalam skenario lintas akun. Untuk informasi selengkapnya, lihat [Merantai peran dengan tag sesi di Panduan Pengguna](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining) *IAM*.
## Tag kustom
EKS Pod Identity tidak dapat menambahkan tag kustom tambahan ke `AssumeRole` tindakan yang dilakukannya. Namun, tag yang Anda terapkan ke peran IAM selalu tersedia melalui format yang sama: `${aws:PrincipalTag/` diikuti oleh kunci, misalnya`${aws:PrincipalTag/MyCustomTag}`.
**catatan**
Tag yang ditambahkan ke sesi melalui `sts:AssumeRole` permintaan diutamakan dalam kasus konflik. Misalnya, katakan bahwa:
Amazon EKS menambahkan kunci `eks-cluster-name` dan nilai `my-cluster` ke sesi ketika EKS mengasumsikan peran pelanggan dan
Anda menambahkan `eks-cluster-name` tag ke peran IAM dengan nilai`my-own-cluster`.
Dalam hal ini, yang pertama diutamakan dan nilai untuk `eks-cluster-name` tag akan menjadi. `my-cluster`
# Menggunakan identitas pod dengan AWS SDK
## Menggunakan kredensial Identitas Pod EKS
Untuk menggunakan kredensi dari asosiasi Identitas Pod EKS, kode Anda dapat menggunakan AWS SDK apa pun untuk membuat klien untuk AWS layanan dengan SDK, dan secara default SDK akan mencari di rantai lokasi untuk menggunakan kredensi AWS Identity and Access Management. Kredensial Identitas Pod EKS akan digunakan jika Anda tidak menentukan penyedia kredensi saat Anda membuat klien atau menginisialisasi SDK.
Ini berfungsi karena EKS Pod Identities telah ditambahkan ke *penyedia kredensi Container* yang dicari dalam satu langkah dalam rantai kredensi default. Jika beban kerja Anda saat ini menggunakan kredensial yang sebelumnya ada dalam rantai kredensial, kredensial-kredensialnya akan terus digunakan meskipun Anda mengonfigurasi asosiasi Identitas Pod EKS untuk beban kerja yang sama.
Untuk informasi selengkapnya tentang cara kerja Identitas Pod EKS, lihat[Pahami cara kerja EKS Pod Identity](pod-id-how-it-works.md).
Saat menggunakan [Pelajari cara EKS Pod Identity memberikan akses Pod ke AWS layanan](pod-identities.md), container dalam Pod Anda harus menggunakan versi AWS SDK yang mendukung asumsi peran IAM dari Agen Identitas Pod EKS. Pastikan Anda menggunakan versi berikut, atau yang lebih baru, untuk AWS SDK Anda:
+ Java (Versi 2) - [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30)
+ Jawa — [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746)
+ [Pergi v1 - v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11)
+ Go v2 - [rilis-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14)
+ [Python (Boto3) — 1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41)
+ [Python (botocore) — 1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41)
+ AWS [CLI — 1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0)
AWS [CLI — 2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0)
+ JavaScript v2 — [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0)
+ JavaScript [v3 — v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0)
+ [Kotlin — v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1)
+ [Ruby — 3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22)
+ Karat — [rilis-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13)
+ [C\$1\$1 — 1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263)
+ .NET — [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0)
+ PowerShell — [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502)
+ PHP — [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1)
Untuk memastikan bahwa Anda menggunakan SDK yang didukung, ikuti petunjuk penginstalan untuk SDK pilihan Anda di [Tools to Build on AWS](https://aws.amazon.com/tools/) saat Anda membuat container.
Untuk daftar add-on yang mendukung EKS Pod Identity, lihat[Referensi Dukungan Pod Identity](retreive-iam-info.md#pod-id-add-on-versions).
# Nonaktifkan `IPv6` di Agen Identitas Pod EKS
## Konsol Manajemen AWS
1. Untuk menonaktifkan `IPv6` di EKS Pod Identity Agent, tambahkan konfigurasi berikut ke **pengaturan konfigurasi Opsional** dari EKS Add-on.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih **Clusters**, lalu pilih nama cluster yang ingin Anda konfigurasikan add-on.
1. Pilih tab **Add-ons**.
1. Pilih kotak di kanan atas kotak add-on Agen Identitas Pod EKS dan kemudian pilih **Edit**.
1. Pada halaman **Configure EKS Pod Identity Agent**:
1. Pilih **Versi** yang ingin Anda gunakan. Kami menyarankan Anda menyimpan versi yang sama dengan langkah sebelumnya, dan memperbarui versi dan konfigurasi dalam tindakan terpisah.
1. Perluas **pengaturan konfigurasi opsional**.
1. **Masukkan kunci JSON `"agent":` dan nilai objek JSON bersarang dengan kunci `"additionalArgs":` dalam nilai Konfigurasi.** Teks yang dihasilkan harus berupa objek JSON yang valid. Jika kunci dan nilai ini adalah satu-satunya data dalam kotak teks, kelilingi kunci dan nilai dengan kurawal kurawal. `{ }` Contoh berikut menunjukkan kebijakan jaringan diaktifkan:
```
{
"agent": {
"additionalArgs": {
"-b": "169.254.170.23"
}
}
}
```
Konfigurasi ini menetapkan `IPv4` alamat menjadi satu-satunya alamat yang digunakan oleh agen.
1. Untuk menerapkan konfigurasi baru dengan mengganti pod EKS Pod Identity Agent, pilih **Simpan perubahan**.
Amazon EKS menerapkan perubahan pada Add-on EKS dengan menggunakan *peluncuran* Kubernetes `DaemonSet` for EKS Pod Identity Agent. Anda dapat melacak status peluncuran dalam **riwayat Pembaruan** add-on di dan dengan Konsol Manajemen AWS . `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`
`kubectl rollout`memiliki perintah berikut:
```
$ kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
**Jika peluncuran terlalu lama, Amazon EKS akan membatalkan peluncuran, dan pesan dengan jenis Pembaruan **Addon dan status **Gagal** akan ditambahkan ke riwayat Pembaruan add-on**.** Untuk menyelidiki masalah apa pun, mulailah dari riwayat peluncuran, dan jalankan `kubectl logs` pada pod EKS Pod Identity Agent untuk melihat log dari EKS Pod Identity Agent.
1. Jika entri baru dalam **riwayat Pembaruan** memiliki status **Sukses**, maka peluncuran telah selesai dan add-on menggunakan konfigurasi baru di semua pod Agen Identitas Pod EKS.
## AWS CLI
1. Untuk menonaktifkan `IPv6` di EKS Pod Identity Agent, tambahkan konfigurasi berikut ke **nilai konfigurasi** Eks Add-on.
Jalankan perintah AWS CLI berikut. Ganti `my-cluster` dengan nama cluster Anda dan peran IAM ARN dengan peran yang Anda gunakan.
```
aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
--resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
```
Konfigurasi ini menetapkan `IPv4` alamat menjadi satu-satunya alamat yang digunakan oleh agen.
Amazon EKS menerapkan perubahan pada Add-on EKS dengan menggunakan *peluncuran* Kubernetes DaemonSet for EKS Pod Identity Agent. Anda dapat melacak status peluncuran dalam **riwayat Pembaruan** add-on di dan dengan Konsol Manajemen AWS . `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`
`kubectl rollout`memiliki perintah berikut:
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
**Jika peluncuran terlalu lama, Amazon EKS akan membatalkan peluncuran, dan pesan dengan jenis Pembaruan **Addon dan status **Gagal** akan ditambahkan ke riwayat Pembaruan add-on**.** Untuk menyelidiki masalah apa pun, mulailah dari riwayat peluncuran, dan jalankan `kubectl logs` pada pod EKS Pod Identity Agent untuk melihat log dari EKS Pod Identity Agent.
# Buat peran IAM dengan kebijakan kepercayaan yang diperlukan oleh EKS Pod Identity
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
** `sts:AssumeRole` **
EKS Pod Identity menggunakan `AssumeRole` untuk mengambil peran IAM sebelum meneruskan kredensialnya sementara ke pod Anda.
** `sts:TagSession` **
EKS Pod Identity menggunakan `TagSession` untuk menyertakan *tag sesi* dalam permintaan ke AWS STS.
**Pengaturan Kondisi**
Anda dapat menggunakan tag ini di *kunci kondisi* dalam kebijakan kepercayaan untuk membatasi akun layanan, ruang nama, dan klaster mana yang dapat menggunakan peran ini. Untuk daftar tag permintaan yang ditambahkan Pod Identity, lihat[Mengaktifkan atau menonaktifkan tag sesi](pod-id-abac.md#pod-id-abac-tags).
Misalnya, Anda dapat membatasi pod mana yang dapat mengambil peran sebagai Peran IAM Identitas Pod ke yang spesifik `ServiceAccount` dan `Namespace` dengan Kebijakan Kepercayaan berikut dengan menambahkan: `Condition`
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-namespace": [
"Namespace"
],
"aws:RequestTag/kubernetes-service-account": [
"ServiceAccount"
]
}
}
}
]
}
```
*Untuk daftar kunci kondisi Amazon EKS, lihat [Ketentuan yang ditentukan oleh Amazon Elastic Kubernetes Service di Referensi Otorisasi Layanan.](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)* Untuk mempelajari tindakan dan sumber daya yang dapat digunakan untuk menggunakan kunci kondisi, lihat [Tindakan yang ditentukan oleh Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).