**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.
# Keamanan di Amazon EKS
Keamanan cloud di AWS adalah prioritas tertinggi. Sebagai AWS pelanggan, Anda mendapat manfaat dari pusat data dan arsitektur jaringan yang dibangun untuk memenuhi persyaratan organisasi yang paling sensitif terhadap keamanan.
Keamanan adalah tanggung jawab bersama antara Anda AWS dan Anda. [Model tanggung jawab bersama](https://aws.amazon.com/compliance/shared-responsibility-model/) menggambarkan hal ini sebagai keamanan *dari* cloud dan keamanan *di* cloud:
+ **Keamanan cloud** — AWS bertanggung jawab untuk melindungi infrastruktur yang menjalankan AWS layanan di AWS Cloud. Untuk Amazon EKS, AWS bertanggung jawab atas bidang kontrol Kubernetes, yang mencakup node dan database bidang kontrol. `etcd` Auditor pihak ketiga secara teratur menguji dan memverifikasi keefektifan keamanan kami sebagai bagian dari [program kepatuhan AWS](https://aws.amazon.com/compliance/programs/). Untuk mempelajari tentang program kepatuhan yang berlaku untuk Amazon EKS, lihat [Layanan AWS yang Dicakup oleh Program Kepatuhan](https://aws.amazon.com/compliance/services-in-scope/).
+ **Kemanan di dalam cloud** – Tanggung jawab Anda meliputi area berikut.
+ Konfigurasi keamanan bidang data, mencakup konfigurasi grup keamanan yang memungkinkan lalu lintas berpindah dari bidang kendali Amazon EKS ke VPC pelanggan
+ Konfigurasi simpul dan kontainer itu sendiri
+ Sistem operasi node (termasuk pembaruan dan patch keamanan)
+ Perangkat lunak aplikasi terkait lainnya:
+ Menyiapkan dan mengelola kendali jaringan, misalnya aturan firewall
+ Mengelola identitas tingkat platform dan manajemen akses, baik dengan ataupun selain IAM
+ Sensitivitas data Anda, persyaratan perusahaan Anda, serta hukum dan peraturan yang berlaku
Amazon EKS disertifikasi oleh beberapa program kepatuhan untuk aplikasi yang diatur dan sensitif. [https://aws.amazon.com/compliance/hitrust/](https://aws.amazon.com/compliance/hitrust/) Untuk informasi selengkapnya, lihat [Pelajari cara kerja kontrol akses di Amazon EKS](cluster-auth.md).
Dokumentasi ini membantu Anda memahami cara menerapkan model tanggung jawab bersama saat menggunakan Amazon EKS. Topik berikut menunjukkan cara mengonfigurasi Amazon EKS untuk memenuhi tujuan keamanan dan kepatuhan Anda. Anda juga mempelajari cara menggunakan AWS layanan lain yang membantu Anda memantau dan mengamankan sumber daya Amazon EKS Anda.
**catatan**
Kontainer Linux terdiri dari grup kontrol (cgroups) dan ruang nama yang membantu membatasi apa yang dapat diakses oleh wadah, tetapi semua kontainer berbagi kernel Linux yang sama dengan instance Amazon host. EC2 Menjalankan kontainer sebagai pengguna asal (UID 0) atau memberikan akses kontainer ke sumber daya host atau namespaces, seperti jaringan host atau namespace host PID, sangat tidak disarankan karena hal itu dapat mengurangi efektivitas isolasi yang disediakan oleh kontainer.
**Topics**
+ [Amankan kluster Amazon EKS dengan praktik terbaik](security-best-practices.md)
+ [Analisis kerentanan di Amazon EKS](configuration-vulnerability-analysis.md)
+ [Validasi kepatuhan untuk kluster Amazon EKS](compliance.md)
+ [Pertimbangan keamanan untuk Amazon Elastic Kubernetes Service](security-eks.md)
+ [Pertimbangan keamanan untuk Kubernetes](security-k8s.md)
+ [Pertimbangan keamanan untuk Amazon EKS Auto Mode](auto-security.md)
+ [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)
+ [Identity and access management untuk Amazon EKS](security-iam.md)
# Amankan kluster Amazon EKS dengan praktik terbaik
Praktik terbaik keamanan Amazon EKS ada dalam [Praktik Terbaik untuk Keamanan](https://docs.aws.amazon.com/eks/latest/best-practices/security.html) di *Panduan Praktik Terbaik Amazon EKS*.
# Analisis kerentanan di Amazon EKS
Keamanan adalah pertimbangan penting untuk mengonfigurasi dan memelihara klaster serta aplikasi Kubernetes. Berikut ini mencantumkan sumber daya bagi Anda untuk menganalisis konfigurasi keamanan klaster EKS Anda, sumber daya bagi Anda untuk memeriksa kerentanan, dan integrasi dengan AWS layanan yang dapat melakukan analisis itu untuk Anda.
## Patokan Pusat Keamanan Internet (CIS) untuk Amazon EKS
[Pusat Keamanan Internet (CIS) Kubernetes Benchmark memberikan](https://www.cisecurity.org/benchmark/kubernetes/) panduan untuk konfigurasi keamanan Amazon EKS. Tolok ukur:
+ Berlaku untuk EC2 node Amazon (baik yang dikelola maupun yang dikelola sendiri) di mana Anda bertanggung jawab atas konfigurasi keamanan komponen Kubernetes.
+ Menyediakan cara standar yang disetujui komunitas untuk memastikan bahwa Anda telah mengonfigurasi klaster dan simpul Kubernetes dengan aman saat menggunakan Amazon EKS.
+ Terdiri dari empat bagian; konfigurasi pencatatan bidang kendali, konfigurasi keamanan simpul, kebijakan, dan layanan terkelola.
+ Mendukung semua versi Kubernetes yang saat ini tersedia di Amazon EKS dan dapat dijalankan menggunakan [kube-bench](https://github.com/aquasecurity/kube-bench), yaitu alat sumber terbuka standar untuk memeriksa konfigurasi menggunakan tolok ukur CIS pada klaster Kubernetes.
Untuk mempelajari selengkapnya, lihat [Memperkenalkan Tolok Ukur CIS Amazon EKS](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark).
Untuk `aws-sample` pipeline otomatis untuk memperbarui grup node Anda dengan AMI benchmark CIS, lihat AMI Hardening Pipeline yang [dioptimalkan EKS](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates).
## Amazon EKS versi platform
*Versi platform* Amazon EKS mewakili kemampuan bidang kontrol cluster, termasuk flag server API Kubernetes yang diaktifkan dan versi patch Kubernetes saat ini. Klaster baru di-deploy dengan versi platform terbaru. Untuk detailnya, lihat versi [platform EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
Anda dapat [memperbarui klaster Amazon EKS](update-cluster.md) ke versi Kubernetes yang lebih baru. Ketika versi Kubernetes baru tersedia di Amazon EKS, kami sarankan supaya Anda secara proaktif memperbarui klaster Anda untuk menggunakan versi terbaru yang tersedia. Untuk informasi selengkapnya tentang versi Kubernetes di EKS, lihat versi yang didukung [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
## Daftar kerentanan sistem operasi
### AL2023 daftar kerentanan
Lacak peristiwa keamanan atau privasi untuk Amazon Linux 2023 di [Pusat Keamanan Amazon Linux](https://alas.aws.amazon.com/alas2023.html) atau berlangganan umpan [RSS](https://alas.aws.amazon.com/AL2023/alas.rss) terkait. Kejadian keamanan dan privasi mencakup gambaran umum masalah yang terpengaruh, paket, dan petunjuk untuk memperbarui instans Anda guna memperbaiki masalah.
### Daftar kerentanan Amazon Linux 2
Lacak kejadian keamanan atau privasi untuk Amazon Linux 2 di [Pusat Keamanan Amazon Linux](https://alas.aws.amazon.com/alas2.html) atau berlangganan ke [umpan RSS](https://alas.aws.amazon.com/AL2/alas.rss) terkait. Kejadian keamanan dan privasi mencakup gambaran umum masalah yang terpengaruh, paket, dan petunjuk untuk memperbarui instans Anda guna memperbaiki masalah.
## Deteksi node dengan Amazon Inspector
Anda dapat menggunakan [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) untuk memeriksa aksesibilitas jaringan node yang tidak diinginkan dan kerentanan pada instans Amazon tersebut. EC2
## Deteksi cluster dan node dengan Amazon GuardDuty
Layanan deteksi GuardDuty ancaman Amazon yang membantu melindungi akun, kontainer, beban kerja, dan data di AWS lingkungan Anda. Di antara fitur-fitur lainnya, GuardDuty menawarkan dua fitur berikut yang mendeteksi potensi ancaman terhadap kluster EKS Anda: *Perlindungan EKS* dan Pemantauan *Runtime*.
Lihat informasi yang lebih lengkap di [Mendeteksi ancaman dengan Amazon GuardDuty](integration-guardduty.md).
# Validasi kepatuhan untuk kluster Amazon EKS
Untuk mengetahui apakah suatu AWS layanan berada dalam lingkup program kepatuhan tertentu, lihat [AWS layanan dalam Lingkup oleh Program Kepatuhan](https://aws.amazon.com/compliance/services-in-scope/) dan pilih program kepatuhan yang Anda minati. Untuk informasi umum, lihat [Program Kepatuhan AWS](https://aws.amazon.com/compliance/programs/).
Anda dapat mengunduh laporan audit pihak ketiga menggunakan AWS Artifact. Untuk informasi selengkapnya, lihat [Mengunduh Laporan di AWS Artifak](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Tanggung jawab kepatuhan Anda saat menggunakan AWS layanan ditentukan oleh sensitivitas data Anda, tujuan kepatuhan perusahaan Anda, dan hukum dan peraturan yang berlaku. AWS menyediakan sumber daya berikut untuk membantu kepatuhan:
+ [Kepatuhan dan Tata Kelola Keamanan](https://aws.amazon.com/solutions/security/security-compliance-governance/) – Panduan implementasi solusi ini membahas pertimbangan arsitektur serta memberikan langkah-langkah untuk menerapkan fitur keamanan dan kepatuhan.
+ [Referensi Layanan yang Memenuhi Syarat HIPAA](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) — Daftar layanan yang memenuhi syarat HIPAA. Tidak semua AWS layanan memenuhi syarat HIPAA.
+ [AWS Sumber Daya Kepatuhan](https://aws.amazon.com/compliance/resources/) — Kumpulan buku kerja dan panduan ini mungkin berlaku untuk industri dan lokasi Anda.
+ [AWS Panduan Kepatuhan Pelanggan](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) - Memahami model tanggung jawab bersama melalui lensa kepatuhan. Panduan ini merangkum praktik terbaik untuk mengamankan AWS layanan dan memetakan panduan untuk kontrol keamanan di berbagai kerangka kerja (termasuk Institut Standar dan Teknologi Nasional (NIST), Dewan Standar Keamanan Industri Kartu Pembayaran (PCI), dan Organisasi Internasional untuk Standardisasi (ISO)).
+ [Mengevaluasi Sumber Daya dengan Aturan](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) dalam Panduan *Pengembang AWS Config* — Layanan AWS Config menilai seberapa baik konfigurasi sumber daya Anda mematuhi praktik internal, pedoman industri, dan peraturan.
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) — AWS Layanan ini memberikan pandangan komprehensif tentang keadaan keamanan Anda di dalamnya AWS. Security Hub menggunakan kontrol keamanan untuk mengevaluasi AWS sumber daya Anda dan untuk memeriksa kepatuhan Anda terhadap standar industri keamanan dan praktik terbaik. Untuk daftar layanan dan kontrol yang didukung, lihat [Referensi kontrol Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) — AWS Layanan ini mendeteksi potensi ancaman terhadap AWS akun, beban kerja, kontainer, dan data Anda dengan memantau lingkungan Anda untuk aktivitas mencurigakan dan berbahaya. GuardDuty dapat membantu Anda mengatasi berbagai persyaratan kepatuhan, seperti PCI DSS, dengan memenuhi persyaratan deteksi intrusi yang diamanatkan oleh kerangka kerja kepatuhan tertentu.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) — AWS Layanan ini membantu Anda terus mengaudit AWS penggunaan Anda untuk menyederhanakan cara Anda mengelola risiko dan kepatuhan terhadap peraturan dan standar industri.
# Pertimbangan keamanan untuk Amazon Elastic Kubernetes Service
Berikut ini adalah pertimbangan untuk keamanan cloud, karena mempengaruhi Amazon EKS.
**Topics**
+ [Keamanan infrastruktur di Amazon EKS](infrastructure-security.md)
+ [Memahami ketahanan di kluster Amazon EKS](disaster-recovery-resiliency.md)
+ [Pencegahan wakil kebingungan lintas layanan di Amazon EKS](cross-service-confused-deputy-prevention.md)
# Keamanan infrastruktur di Amazon EKS
Sebagai layanan terkelola, Amazon Elastic Kubernetes Service dilindungi oleh keamanan jaringan global. AWS Untuk informasi tentang layanan AWS keamanan dan cara AWS melindungi infrastruktur, lihat [Keamanan AWS Cloud](https://aws.amazon.com/security/). Untuk mendesain AWS lingkungan Anda menggunakan praktik terbaik untuk keamanan infrastruktur, lihat [Perlindungan Infrastruktur dalam Kerangka Kerja](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) yang * AWS Diarsiteksikan dengan Baik Pilar Keamanan*.
Anda menggunakan panggilan API yang AWS dipublikasikan untuk mengakses Amazon EKS melalui jaringan. Klien harus mendukung hal-hal berikut:
+ Keamanan Lapisan Pengangkutan (TLS). Kami mensyaratkan TLS 1.2 dan menganjurkan TLS 1.3.
+ Sandi cocok dengan sistem kerahasiaan maju sempurna (perfect forward secrecy, PFS) seperti DHE (Ephemeral Diffie-Hellman) atau ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Sebagian besar sistem modern seperti Java 7 dan versi lebih baru mendukung mode-mode ini.
Selain itu, permintaan harus ditandatangani menggunakan ID kunci akses dan kunci akses rahasia yang terkait dengan prinsipal IAM. Atau Anda dapat menggunakan [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) untuk menghasilkan kredenal keamanan sementara untuk menandatangani permintaan.
Ketika Anda membuat klaster Amazon EKS, Anda menentukan subnet VPC untuk digunakan oleh klaster Anda. Amazon EKS membutuhkan subnet, setidaknya di dua Availability Zone. Kami merekomendasikan VPC dengan subnet publik dan privat sehingga Kubernetes dapat membuat penyeimbang beban publik di subnet publik yang memuat lalu lintas keseimbangan ke Pod yang berjalan pada node yang berada di subnet pribadi.
Untuk informasi selengkapnya tentang pertimbangan VPC, lihat [Lihat persyaratan jaringan Amazon EKS untuk VPC dan subnet](network-reqs.md).
Jika Anda membuat grup VPC dan node dengan AWS CloudFormation templat yang disediakan dalam panduan [Memulai dengan Amazon EKS](getting-started.md), maka grup keamanan bidang kontrol dan node Anda dikonfigurasi dengan pengaturan yang kami rekomendasikan.
Untuk informasi selengkapnya tentang pertimbangan grup keamanan, lihat [Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md).
Ketika Anda membuat klaster baru, Amazon EKS membuat titik akhir untuk server API Kubernetes terkelola yang Anda gunakan untuk berkomunikasi dengan klaster Anda (alat pengelolaan Kubernetes seperti `kubectl`). Secara default, endpoint server API ini bersifat publik ke internet, dan akses ke server API diamankan menggunakan kombinasi AWS Identity and Access Management (IAM) and Access Management (IAM) dan native [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) Role Based Access Control (RBAC).
Anda dapat mengaktifkan akses privat ke server API Kubernetes sehingga semua komunikasi antara simpul Anda dan server API tetap berada di dalam VPC Anda. Anda dapat membatasi alamat IP yang dapat mengakses server API Anda dari internet, atau menonaktifkan sepenuhnya akses internet ke server API.
Untuk informasi selengkapnya tentang cara memodifikasi akses titik akhir klaster, lihat [Memodifikasi akses titik akhir klaster](cluster-endpoint.md#modify-endpoint-access).
[Anda dapat menerapkan *kebijakan jaringan* Kubernetes dengan Amazon VPC CNI atau alat pihak ketiga seperti Project Calico.](https://docs.tigera.io/calico/latest/about/) Untuk informasi selengkapnya tentang menggunakan Amazon VPC CNI untuk kebijakan jaringan, lihat. [Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes](cni-network-policy.md) Project Calico merupakan proyek sumber terbuka pihak ketiga. Untuk informasi selengkapnya, lihat [Project Calico documentation](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/).
# Akses Amazon EKS menggunakan AWS PrivateLink
Anda dapat menggunakannya AWS PrivateLink untuk membuat koneksi pribadi antara VPC Anda dan Amazon Elastic Kubernetes Service. Anda dapat mengakses Amazon EKS seolah-olah berada di VPC Anda, tanpa menggunakan gateway internet, perangkat NAT, koneksi VPN, atau koneksi Direct AWS Connect. Instans di VPC Anda tidak memerlukan alamat IP publik untuk mengakses Amazon EKS.
Anda membuat koneksi pribadi ini dengan membuat titik akhir antarmuka yang didukung oleh AWS PrivateLink. Kami membuat antarmuka jaringan endpoint di setiap subnet yang Anda aktifkan untuk titik akhir antarmuka. Ini adalah antarmuka jaringan yang dikelola pemohon yang berfungsi sebagai titik masuk untuk lalu lintas yang ditujukan untuk Amazon EKS.
Untuk informasi selengkapnya, lihat [Akses AWS layanan melalui AWS PrivateLink AWS](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) *PrivateLink Panduan*.
## Sebelum Anda mulai
Sebelum memulai, pastikan Anda telah melakukan tugas-tugas berikut:
+ *Tinjau [Akses AWS layanan menggunakan titik akhir VPC antarmuka](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) di Panduan AWS PrivateLink *
## Pertimbangan
+ **Support and Limitations**: Endpoint antarmuka Amazon EKS memungkinkan akses aman ke semua tindakan Amazon EKS API dari VPC Anda tetapi dilengkapi dengan batasan khusus: mereka tidak mendukung akses ke APIs Kubernetes, karena ini memiliki titik akhir pribadi yang terpisah, Anda tidak dapat mengonfigurasi Amazon EKS agar hanya dapat diakses melalui titik akhir antarmuka.
+ **Harga**: Menggunakan titik akhir antarmuka untuk Amazon EKS menimbulkan AWS PrivateLink biaya standar: biaya per jam untuk setiap titik akhir yang disediakan di setiap Zona Ketersediaan, biaya pemrosesan data untuk lalu lintas melalui titik akhir. Untuk mempelajari lebih lanjut, lihat [AWS PrivateLink harga](https://aws.amazon.com/privatelink/pricing/).
+ **Keamanan dan Kontrol Akses**: Sebaiknya tingkatkan keamanan dan kontrol akses dengan konfigurasi tambahan ini—gunakan kebijakan titik akhir VPC untuk mengontrol akses ke Amazon EKS melalui titik akhir antarmuka, mengaitkan grup keamanan dengan antarmuka jaringan titik akhir untuk mengelola lalu lintas, menggunakan log aliran VPC untuk menangkap dan memantau lalu lintas IP ke dan dari titik akhir antarmuka, dengan log yang dapat dipublikasikan ke Amazon atau Amazon S3. CloudWatch Untuk mempelajari lebih lanjut, lihat [Mengontrol akses ke titik akhir VPC menggunakan kebijakan titik akhir dan Mencatat lalu lintas IP menggunakan](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) [Log Aliran VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
+ **Opsi Konektivitas**: Titik akhir antarmuka menawarkan opsi konektivitas fleksibel menggunakan **akses lokal** (sambungkan pusat data lokal Anda ke VPC dengan titik akhir antarmuka menggunakan Direct AWS Connect atau AWS Site-to-Site VPN) atau melalui konektivitas **antar-VPC (gunakan Transit AWS Gateway atau peering VPC** untuk VPCs menghubungkan orang lain ke VPC dengan titik akhir antarmuka, menjaga lalu lintas dalam jaringan). AWS
+ **Dukungan Versi IP**: Titik akhir yang dibuat sebelum Agustus 2024 mendukung hanya IPv4 menggunakan eks.region.amazonaws.com. Titik akhir baru yang dibuat setelah Agustus 2024 mendukung dual-stack IPv4 dan IPv6 (misalnya, eks.region.amazonaws.com, eks.region.api.aws).
+ **Ketersediaan Regional**: AWS PrivateLink untuk EKS API tidak tersedia di wilayah Asia Pasifik (Malaysia) (ap-tenggara 5), Asia Pasifik (Thailand) (ap-tenggara - 7), Meksiko (Tengah) (mx-sentral-1), dan Asia Pasifik (Taipei) (ap-timur-2). AWS PrivateLink dukungan untuk eks-auth (EKS Pod Identity) tersedia di wilayah Asia Pasifik (Malaysia) (ap-tenggara 5).
## Buat titik akhir antarmuka untuk Amazon EKS
Anda dapat membuat titik akhir antarmuka untuk Amazon EKS menggunakan konsol Amazon VPC atau Antarmuka Baris AWS Perintah (AWS CLI). *Untuk informasi selengkapnya, lihat [Membuat titik akhir VPC di Panduan](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws). AWS PrivateLink *
Buat titik akhir antarmuka untuk Amazon EKS menggunakan nama layanan berikut:
### EKS API
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (untuk titik akhir yang sesuai dengan FIPS)
### EKS Auth API (Identitas EKS Pod)
+ com.amazonaws.region-code.eks-auth
## Fitur DNS pribadi untuk titik akhir antarmuka Amazon EKS
Fitur DNS pribadi, diaktifkan secara default untuk titik akhir antarmuka Amazon EKS dan AWS layanan lainnya, memfasilitasi permintaan API yang aman dan pribadi menggunakan nama DNS Regional default. Fitur ini memastikan bahwa panggilan API dirutekan melalui titik akhir antarmuka melalui AWS jaringan pribadi, meningkatkan keamanan dan kinerja.
Fitur DNS pribadi aktif secara otomatis saat Anda membuat titik akhir antarmuka untuk Amazon EKS atau layanan lainnya. AWS Untuk mengaktifkan, Anda perlu mengkonfigurasi VPC Anda dengan benar dengan mengatur atribut tertentu:
+ **enableDnsHostnames**: Memungkinkan instance dalam VPC memiliki nama host DNS.
+ **enableDnsSupport**: Mengaktifkan resolusi DNS di seluruh VPC.
Untuk step-by-step petunjuk untuk memeriksa atau mengubah pengaturan ini, lihat [Melihat dan memperbarui atribut DNS untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
### Nama DNS dan jenis alamat IP
Dengan mengaktifkan fitur DNS pribadi, Anda dapat menggunakan nama DNS tertentu untuk terhubung ke Amazon EKS, dan opsi ini berkembang seiring waktu:
+ **eks.region.amazonaws.com**: Nama DNS tradisional, hanya diselesaikan ke alamat sebelum Agustus 2024. IPv4 Untuk titik akhir yang ada yang diperbarui ke dual-stack, nama ini diselesaikan ke keduanya dan alamat. IPv4 IPv6
+ **eks.region.api.aws**: Tersedia untuk titik akhir baru yang dibuat setelah Agustus 2024, nama DNS tumpukan ganda ini diselesaikan ke keduanya dan alamat. IPv4 IPv6
Setelah Agustus 2024, titik akhir antarmuka baru hadir dengan dua nama DNS, dan Anda dapat memilih jenis alamat IP dual-stack. Untuk titik akhir yang ada, memperbarui ke dual-stack memodifikasi **eks.region.amazonaws.com** untuk mendukung keduanya dan. IPv4 IPv6
### Menggunakan fitur DNS Pribadi
Setelah dikonfigurasi, fitur DNS pribadi dapat diintegrasikan ke dalam alur kerja Anda, menawarkan kemampuan berikut:
+ **Permintaan API**: Gunakan nama DNS Regional default, baik `eks.region.amazonaws.com` atau`eks.region.api.aws`, berdasarkan penyiapan titik akhir Anda untuk membuat permintaan API ke Amazon EKS.
+ **Kompatibilitas Aplikasi**: Aplikasi Anda yang ada yang memanggil EKS tidak APIs memerlukan perubahan untuk memanfaatkan fitur ini.
+ ** AWS CLI dengan Dual-Stack***: Untuk menggunakan titik akhir dual-stack dengan AWS CLI, lihat konfigurasi titik akhir [Dual-stack dan FIPS di](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) Panduan Referensi Alat dan. AWS SDKs *
+ **Perutean Otomatis**: Setiap panggilan ke titik akhir layanan default Amazon EKS secara otomatis diarahkan melalui titik akhir antarmuka, memastikan konektivitas pribadi dan aman.
# Memahami ketahanan di kluster Amazon EKS
Infrastruktur AWS global dibangun di sekitar AWS Wilayah dan Zona Ketersediaan. AWS Wilayah menyediakan beberapa Availability Zone yang terpisah secara fisik dan terisolasi, yang terhubung dengan latensi rendah, throughput tinggi, dan jaringan yang sangat redundan. Dengan Zona Ketersediaan, Anda dapat merancang dan mengoperasikan aplikasi dan basis data yang secara otomatis melakukan failover di antara Zona Ketersediaan tanpa gangguan. Zona Ketersediaan memiliki ketersediaan dan toleransi kesalahan yang lebih baik, dan dapat diskalakan dibandingkan infrastruktur biasa yang terdiri dari satu atau beberapa pusat data.
Amazon EKS menjalankan dan menskalakan pesawat kontrol Kubernetes di beberapa AWS Availability Zone untuk memastikan ketersediaan yang tinggi. Amazon EKS secara otomatis menskalakan instans pesawat kontrol berdasarkan beban, mendeteksi, dan mengganti instans bidang kontrol yang tidak sehat, dan secara otomatis menambal bidang kontrol. Setelah Anda memulai pembaruan versi, Amazon EKS memperbarui bidang kontrol untuk Anda, menjaga ketersediaan tinggi bidang kontrol selama pembaruan.
Bidang kontrol ini terdiri dari setidaknya dua instance server API dan tiga `etcd` instance yang berjalan di tiga Availability Zone dalam suatu AWS Region. Amazon EKS:
+ Secara aktif memantau beban pada instans bidang kendali dan secara otomatis menskalakannya guna memastikan kinerja yang tinggi.
+ Secara otomatis mendeteksi dan mengganti instans bidang kontrol yang tidak sehat, memulai ulang di seluruh Availability Zone dalam Wilayah sesuai kebutuhan. AWS
+ Memanfaatkan arsitektur AWS Daerah untuk menjaga ketersediaan tinggi. Karena itu, Amazon EKS mampu menawarkan [SLA untuk ketersediaan titik akhir server API](https://aws.amazon.com/eks/sla).
Untuk informasi selengkapnya tentang AWS Wilayah dan Availability Zone, lihat [infrastruktur AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
# Pencegahan wakil kebingungan lintas layanan di Amazon EKS
Masalah deputi yang membingungkan adalah masalah keamanan di mana entitas yang tidak memiliki izin untuk melakukan tindakan dapat memaksa entitas yang lebih istimewa untuk melakukan tindakan. Pada tahun AWS, peniruan lintas layanan dapat mengakibatkan masalah wakil yang membingungkan. Peniruan identitas lintas layanan dapat terjadi ketika satu layanan (*layanan yang dipanggil*) memanggil layanan lain (*layanan yang dipanggil*). Layanan panggilan dapat dimanipulasi untuk menggunakan izinnya untuk bertindak atas sumber daya pelanggan lain dengan cara yang seharusnya tidak memiliki izin untuk mengakses. Untuk mencegah hal ini, AWS sediakan alat yang membantu Anda melindungi data Anda untuk semua layanan dengan prinsip layanan yang telah diberikan akses ke sumber daya di akun Anda.
Sebaiknya gunakan kunci konteks kondisi [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)global dalam kebijakan sumber daya untuk membatasi izin yang diberikan Amazon Elastic Kubernetes Service (Amazon EKS) ke layanan lain ke sumber daya. [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)
`aws:SourceArn`
Gunakan `aws:SourceArn` untuk mengaitkan hanya satu sumber daya dengan akses lintas layanan.
`aws:SourceAccount`
Gunakan `aws:SourceAccount` untuk membiarkan sumber daya apa pun di akun itu dikaitkan dengan penggunaan lintas layanan.
Cara paling efektif untuk melindungi dari masalah "confused deputy" adalah dengan menggunakan kunci konteks kondisi global `aws:SourceArn` dengan ARN lengkap sumber daya. Jika Anda tidak mengetahui ARN lengkap sumber daya atau jika Anda menentukan beberapa sumber daya, gunakan kunci kondisi konteks `aws:SourceArn` global dengan karakter wildcard (\$1) untuk bagian ARN yang tidak diketahui. Misalnya, ` arn:aws::*:<123456789012>:*`.
Jika `aws:SourceArn` nilainya tidak berisi ID akun, seperti ARN bucket Amazon S3, Anda harus menggunakan keduanya `aws:SourceAccount` dan `aws:SourceArn` untuk membatasi izin.
## Peran klaster Amazon EKS lintas layanan membingungkan pencegahan wakil
Peran IAM cluster Amazon EKS diperlukan untuk setiap cluster. Cluster Kubernetes yang dikelola oleh Amazon EKS menggunakan peran ini untuk mengelola node dan [Cloud Provider lama](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) menggunakan peran ini untuk membuat penyeimbang beban dengan Elastic Load Balancing untuk layanan. Tindakan klaster ini hanya dapat memengaruhi akun yang sama, jadi sebaiknya Anda membatasi setiap peran klaster ke klaster dan akun tersebut. Ini adalah aplikasi khusus dari AWS rekomendasi untuk mengikuti *prinsip hak istimewa paling sedikit* di akun Anda.
**Sumber format ARN**
Nilai `aws:SourceArn` harus ARN dari cluster EKS dalam format. ` arn:aws: eks:region:account:cluster/cluster-name ` Misalnya, ` arn:aws: eks:us-west-2:123456789012:cluster/my-cluster`.
**Format kebijakan kepercayaan untuk peran klaster EKS**
Contoh berikut menunjukkan bagaimana Anda dapat menggunakan `aws:SourceArn` dan kunci konteks kondisi `aws:SourceAccount` global di Amazon EKS untuk mencegah masalah wakil yang membingungkan.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
# Pertimbangan keamanan untuk Kubernetes
Berikut ini adalah pertimbangan untuk keamanan di cloud, karena mereka mempengaruhi Kubernetes di cluster Amazon EKS. Untuk tinjauan mendalam tentang kontrol dan praktik keamanan di Kubernetes, lihat [Cloud Native Security dan Kubernetes di dokumentasi Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/).
**Topics**
+ [Amankan beban kerja dengan sertifikat Kubernetes](cert-signing.md)
+ [Memahami peran dan pengguna RBAC yang dibuat Amazon EKS](default-roles-users.md)
+ [Enkripsi rahasia Kubernetes dengan KMS di cluster yang ada](enable-kms.md)
+ [Gunakan AWS rahasia Secrets Manager dengan Amazon EKS Pods](manage-secrets.md)
+ [Enkripsi amplop default untuk semua Data API Kubernetes](envelope-encryption.md)
# Amankan beban kerja dengan sertifikat Kubernetes
[Kubernetes Certificates API mengotomatiskan penyediaan kredenal X.509.](https://www.itu.int/rec/T-REC-X.509) API ini memiliki antarmuka baris perintah untuk klien API Kubernetes untuk meminta dan memperoleh sertifikat [X.509 dari Certificate](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) Authority (CA). Anda dapat menggunakan sumber daya `CertificateSigningRequest` (CSR) untuk meminta penandatangan yang dilambangkan menandatangani sertifikat. Permintaan Anda disetujui atau ditolak sebelum ditandatangani. Kubernetes mendukung penandatangan bawaan dan penandatangan khusus dengan perilaku yang terdefinisi dengan baik. Dengan cara ini, klien dapat memprediksi apa yang terjadi pada mereka CSRs. Untuk mempelajari selengkapnya tentang penandatanganan sertifikat, lihat [permintaan penandatanganan](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/).
Salah satu penandatangan bawaan adalah`kubernetes.io/legacy-unknown`. `v1beta1`API sumber daya CSR menghormati penandatangan yang tidak dikenal lama ini. Namun, `v1` API CSR yang stabil tidak memungkinkan `signerName` untuk disetel ke`kubernetes.io/legacy-unknown`.
Jika ingin menggunakan Amazon EKS CA untuk membuat sertifikat di klaster, Anda harus menggunakan penandatangan khusus. Untuk menggunakan versi CSR `v1` API dan menghasilkan sertifikat baru, Anda harus memigrasikan manifes dan klien API yang ada. Sertifikat yang ada yang dibuat dengan `v1beta1` API yang ada valid dan berfungsi hingga sertifikat kedaluwarsa. Ini termasuk yang berikut:
+ Distribusi kepercayaan: Tidak ada. Tidak ada kepercayaan atau distribusi standar untuk penandatangan ini di klaster Kubernetes.
+ Subjek yang diizinkan: Apa saja
+ Ekstensi x509 yang diizinkan: Menghormati subjectAltName dan ekstensi penggunaan kunci dan membuang ekstensi lainnya
+ Penggunaan kunci yang diizinkan: Tidak boleh menyertakan penggunaan di luar ["encipherment kunci”, “tanda tangan digital”, “autentikasi server"]
**catatan**
Penandatanganan sertifikat klien tidak didukung.
+ Kedaluwarsa/masa pakai sertifikat: 1 tahun (default dan maksimum)
+ CA bit diizinkan/tidak diizinkan: Tidak diizinkan
## Contoh pembuatan CSR dengan SignerName
Langkah-langkah ini menunjukkan cara menghasilkan sertifikat penyajian untuk `myserver.default.svc` menggunakan `signerName: beta.eks.amazonaws.com/app-serving` nama DNS. Gunakan ini sebagai panduan untuk lingkungan Anda sendiri.
1. Jalankan `openssl genrsa -out myserver.key 2048` perintah untuk menghasilkan kunci pribadi RSA.
```
openssl genrsa -out myserver.key 2048
```
1. Jalankan perintah berikut untuk menghasilkan permintaan sertifikat.
```
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
```
1. Hasilkan `base64` nilai untuk permintaan CSR dan simpan dalam variabel untuk digunakan di langkah selanjutnya.
```
base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")
```
1. Jalankan perintah berikut untuk membuat file bernama`mycsr.yaml`. Dalam contoh berikut, `beta.eks.amazonaws.com/app-serving` adalah`signerName`.
```
cat >mycsr.yaml < myserver.crt
```
# Memahami peran dan pengguna RBAC yang dibuat Amazon EKS
Saat Anda membuat klaster Kubernetes, beberapa identitas Kubernetes default dibuat di klaster tersebut agar Kubernetes berfungsi dengan baik. Amazon EKS membuat identitas Kubernetes untuk setiap komponen defaultnya. Identitas menyediakan kontrol otorisasi berbasis peran Kubernetes (RBAC) untuk komponen cluster. Untuk informasi selengkapnya, lihat [Menggunakan Otorisasi RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dalam dokumentasi Kubernetes.
Saat Anda menginstal [add-on](eks-add-ons.md) opsional ke klaster Anda, identitas Kubernetes tambahan mungkin ditambahkan ke klaster Anda. Untuk informasi selengkapnya tentang identitas yang tidak dibahas oleh topik ini, lihat dokumentasi untuk add-on.
Anda dapat melihat daftar identitas Kubernetes yang dibuat Amazon EKS di klaster Anda menggunakan alat baris perintah Konsol Manajemen AWS atau`kubectl`. Semua identitas pengguna muncul di log `kube` audit yang tersedia untuk Anda melalui Amazon CloudWatch.
## Konsol Manajemen AWS
### Prasyarat
[Prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang Anda gunakan harus memiliki izin yang dijelaskan dalam Izin yang [diperlukan](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
### Untuk melihat identitas yang dibuat Amazon EKS menggunakan Konsol Manajemen AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dalam daftar **Clusters**, pilih cluster yang berisi identitas yang ingin Anda lihat.
1. Pilih tab **Sumber Daya**.
1. Di bawah **Jenis sumber daya**, pilih **Otorisasi**.
1. Pilih, **ClusterRoles**, **ClusterRoleBindings**, **Peran**, atau **RoleBindings**. Semua sumber daya yang diawali dengan **eks** dibuat oleh Amazon EKS. Sumber daya identitas tambahan yang dibuat Amazon EKS adalah:
+ **ClusterRole**Dan **ClusterRoleBinding**bernama **aws-node**. Sumber daya **aws-node** mendukung [plugin Amazon VPC CNI untuk Kubernetes,](managing-vpc-cni.md) yang diinstal Amazon EKS di semua cluster.
+ Yang **ClusterRole**bernama **vpc-resource-controller-role**dan **ClusterRoleBinding**bernama **vpc-resource-controller-rolebinding**. Sumber daya ini mendukung [pengontrol sumber daya VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s) Amazon, yang dipasang Amazon EKS di semua cluster.
Selain sumber daya yang Anda lihat di konsol, identitas pengguna khusus berikut ada di klaster Anda, meskipun tidak terlihat dalam konfigurasi cluster:
+ **`eks:cluster-bootstrap`**- Digunakan untuk `kubectl` operasi selama bootstrap cluster.
+ **`eks:support-engineer`**— Digunakan untuk operasi manajemen cluster.
1. Pilih sumber daya tertentu untuk melihat detailnya. Secara default, Anda ditampilkan informasi dalam **tampilan Terstruktur**. Di sudut kanan atas halaman detail, Anda dapat memilih **Tampilan mentah** untuk melihat semua informasi sumber daya.
## Kubectl
### Prasyarat
Entitas yang Anda gunakan (AWS Identity and Access Management (IAM) and Access Management (IAM) atau OpenID Connect (OIDC)) untuk mencantumkan resource Kubernetes di klaster harus diautentikasi oleh IAM atau penyedia identitas OIDC Anda. Entitas harus diberikan izin untuk menggunakan Kubernetes `get` dan `list` kata kerja untuk`Role`,, `ClusterRole``RoleBinding`, dan `ClusterRoleBinding` sumber daya di klaster Anda yang Anda inginkan untuk dikerjakan oleh entitas tersebut. Untuk informasi selengkapnya tentang pemberian entitas IAM akses ke klaster Anda, lihat. [Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md) Untuk informasi selengkapnya tentang pemberian entitas yang diautentikasi oleh penyedia OIDC Anda sendiri akses ke klaster Anda, lihat. [Beri pengguna akses ke Kubernetes dengan penyedia OIDC eksternal](authenticate-oidc-identity-provider.md)
### Untuk melihat identitas Amazon EKS yang dibuat menggunakan `kubectl`
Jalankan perintah untuk jenis sumber daya yang ingin Anda lihat. Semua sumber daya yang dikembalikan yang diawali dengan **eks** dibuat oleh Amazon EKS. Selain sumber daya yang dikembalikan dalam output dari perintah, identitas pengguna khusus berikut ada di cluster Anda, meskipun tidak terlihat dalam konfigurasi cluster:
+ **`eks:cluster-bootstrap`**- Digunakan untuk `kubectl` operasi selama bootstrap cluster.
+ **`eks:support-engineer`**— Digunakan untuk operasi manajemen cluster.
**ClusterRoles**— `ClusterRoles` dicakup ke klaster Anda, jadi izin apa pun yang diberikan untuk peran berlaku untuk sumber daya di namespace Kubernetes apa pun di klaster.
Perintah berikut mengembalikan semua Kubernetes Amazon EKS yang dibuat `ClusterRoles` di klaster Anda.
```
kubectl get clusterroles | grep eks
```
Selain `ClusterRoles` dikembalikan dalam output yang diawali dengan, berikut ini `ClusterRoles` ada.
+ **`aws-node`**— Ini `ClusterRole` mendukung [plugin Amazon VPC CNI untuk Kubernetes](managing-vpc-cni.md), yang dipasang Amazon EKS di semua cluster.
+ **`vpc-resource-controller-role`**— Ini `ClusterRole` mendukung [pengontrol sumber daya Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), yang dipasang Amazon EKS di semua cluster.
Untuk melihat spesifikasi untuk a`ClusterRole`, ganti *eks:k8s-metrics* dalam perintah berikut dengan `ClusterRole` dikembalikan dalam output dari perintah sebelumnya. Contoh berikut mengembalikan spesifikasi untuk *eks:k8s-metrics*`ClusterRole`.
```
kubectl describe clusterrole eks:k8s-metrics
```
Contoh output adalah sebagai berikut.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
[/metrics] [] [get]
endpoints [] [] [list]
nodes [] [] [list]
pods [] [] [list]
deployments.apps [] [] [list]
```
**ClusterRoleBindings**— `ClusterRoleBindings` dicakup ke cluster Anda.
Perintah berikut mengembalikan semua Kubernetes Amazon EKS yang dibuat `ClusterRoleBindings` di klaster Anda.
```
kubectl get clusterrolebindings | grep eks
```
Selain `ClusterRoleBindings` dikembalikan dalam output, berikut ini `ClusterRoleBindings` ada.
+ **`aws-node`**— Ini `ClusterRoleBinding` mendukung [plugin Amazon VPC CNI untuk Kubernetes](managing-vpc-cni.md), yang dipasang Amazon EKS di semua cluster.
+ **`vpc-resource-controller-rolebinding`**— Ini `ClusterRoleBinding` mendukung [pengontrol sumber daya Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), yang dipasang Amazon EKS di semua cluster.
Untuk melihat spesifikasi untuk a`ClusterRoleBinding`, ganti *eks:k8s-metrics* dalam perintah berikut dengan `ClusterRoleBinding` dikembalikan dalam output dari perintah sebelumnya. Contoh berikut mengembalikan spesifikasi untuk *eks:k8s-metrics*`ClusterRoleBinding`.
```
kubectl describe clusterrolebinding eks:k8s-metrics
```
Contoh output adalah sebagai berikut.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
**Peran** — `Roles` dicakup ke namespace Kubernetes. Semua Amazon EKS `Roles` yang dibuat dicakup ke namespace. `kube-system`
Perintah berikut mengembalikan semua Kubernetes Amazon EKS yang dibuat `Roles` di klaster Anda.
```
kubectl get roles -n kube-system | grep eks
```
Untuk melihat spesifikasi untuk a`Role`, ganti *eks:k8s-metrics* dalam perintah berikut dengan nama yang `Role` dikembalikan dalam output dari perintah sebelumnya. Contoh berikut mengembalikan spesifikasi untuk *eks:k8s-metrics*`Role`.
```
kubectl describe role eks:k8s-metrics -n kube-system
```
Contoh output adalah sebagai berikut.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [aws-node] [get]
deployments.apps [] [vpc-resource-controller] [get]
```
**RoleBindings**— `RoleBindings` dicakup ke namespace Kubernetes. Semua Amazon EKS `RoleBindings` yang dibuat dicakup ke namespace. `kube-system`
Perintah berikut mengembalikan semua Kubernetes Amazon EKS yang dibuat `RoleBindings` di klaster Anda.
```
kubectl get rolebindings -n kube-system | grep eks
```
Untuk melihat spesifikasi untuk a`RoleBinding`, ganti *eks:k8s-metrics* dalam perintah berikut dengan `RoleBinding` dikembalikan dalam output dari perintah sebelumnya. Contoh berikut mengembalikan spesifikasi untuk *eks:k8s-metrics*`RoleBinding`.
```
kubectl describe rolebinding eks:k8s-metrics -n kube-system
```
Contoh output adalah sebagai berikut.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: Role
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
# Enkripsi rahasia Kubernetes dengan KMS di cluster yang ada
**penting**
Prosedur ini hanya berlaku untuk klaster EKS yang menjalankan Kubernetes versi 1.27 atau lebih rendah. Jika Anda menjalankan Kubernetes versi 1.28 atau lebih tinggi, rahasia Kubernetes Anda dilindungi dengan enkripsi amplop secara default. Untuk informasi selengkapnya, lihat [Enkripsi amplop default untuk semua Data API Kubernetes](envelope-encryption.md).
Jika Anda mengaktifkan [enkripsi rahasia](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), rahasia Kubernetes dienkripsi menggunakan kunci AWS KMS yang Anda pilih. Kunci KMS harus memenuhi ketentuan berikut:
+ Simetris
+ Dapat mengenkripsi dan mendekripsi data
+ Dibuat di AWS Wilayah yang sama dengan cluster
+ Jika kunci KMS dibuat di akun yang berbeda, [kepala sekolah IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) harus memiliki akses ke kunci KMS.
Untuk informasi selengkapnya, lihat [Mengizinkan kepala IAM di akun lain menggunakan kunci KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) di Panduan Pengembang Layanan Manajemen *[AWS Kunci](https://docs.aws.amazon.com/kms/latest/developerguide/)*.
**Awas**
Anda tidak dapat menonaktifkan enkripsi rahasia setelah mengaktifkannya. Tindakan ini tidak dapat diubah.
eksctl
Prosedur ini hanya berlaku untuk klaster EKS yang menjalankan Kubernetes versi 1.27 atau lebih rendah. Untuk informasi selengkapnya, lihat [Enkripsi amplop default untuk semua Data API Kubernetes](envelope-encryption.md).
Anda dapat mengaktifkan enkripsi dengan dua cara:
+ Tambahkan enkripsi ke klaster Anda dengan satu perintah.
Untuk mengenkripsi ulang rahasia Anda secara otomatis, jalankan perintah berikut.
```
eksctl utils enable-secrets-encryption \
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key
```
Untuk memilih keluar dari mengenkripsi ulang rahasia Anda secara otomatis, jalankan perintah berikut.
```
eksctl utils enable-secrets-encryption
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key \
--encrypt-existing-secrets=false
```
+ Tambahkan enkripsi ke cluster Anda dengan `kms-cluster.yaml` file.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
secretsEncryption:
keyARN: arn:aws: kms:region-code:account:key/key
```
Agar rahasia Anda mengenkripsi ulang secara otomatis, jalankan perintah berikut.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml
```
Untuk memilih keluar dari enkripsi ulang rahasia Anda secara otomatis, jalankan perintah berikut.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
```
Konsol Manajemen AWS
1. Prosedur ini hanya berlaku untuk klaster EKS yang menjalankan Kubernetes versi 1.27 atau lebih rendah. Untuk informasi selengkapnya, lihat [Enkripsi amplop default untuk semua Data API Kubernetes](envelope-encryption.md).
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih cluster yang ingin Anda tambahkan enkripsi KMS.
1. Pilih tab **Ikhtisar** (ini dipilih secara default).
1. Gulir ke bawah ke bagian **enkripsi Rahasia** dan pilih **Aktifkan**.
1. Pilih kunci dari daftar dropdown dan pilih tombol **Enable**. Jika tidak ada kunci yang tercantum, Anda harus membuatnya dulu. Untuk informasi selengkapnya, lihat [Membuat kunci](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
1. Pilih tombol **Konfirmasi** untuk menggunakan tombol yang dipilih.
AWS CLI
1. Prosedur ini hanya berlaku untuk klaster EKS yang menjalankan Kubernetes versi 1.27 atau lebih rendah. Untuk informasi selengkapnya, lihat [Enkripsi amplop default untuk semua Data API Kubernetes](envelope-encryption.md).
1. Kaitkan konfigurasi [enkripsi rahasia](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) dengan cluster Anda menggunakan perintah AWS CLI berikut. Ganti Contoh nilai dengan nilai Anda sendiri.
```
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws: kms:region-code:account:key/key"}}]'
```
Contoh output adalah sebagai berikut.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "InProgress",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734,
"errors": []
}
}
```
1. Anda dapat memantau status pembaruan enkripsi Anda dengan perintah berikut. Gunakan spesifik `cluster name` dan `update ID` yang dikembalikan pada output sebelumnya. Ketika `Successful` status ditampilkan, pembaruan selesai.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id 3141b835-8103-423a-8e68-12c2521ffa4d
```
Contoh output adalah sebagai berikut.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "Successful",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734>,
"errors": []
}
}
```
1. Untuk memverifikasi bahwa enkripsi diaktifkan di klaster Anda, jalankan perintah `describe-cluster`. Responsnya berisi `EncryptionConfig` string.
```
aws eks describe-cluster --region region-code --name my-cluster
```
Setelah mengaktifkan enkripsi di klaster, Anda harus mengenkripsi semua rahasia yang ada dengan kunci baru:
**catatan**
Jika Anda menggunakan`eksctl`, menjalankan perintah berikut hanya diperlukan jika Anda memilih untuk tidak mengenkripsi ulang rahasia Anda secara otomatis.
```
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"
```
**Awas**
Jika Anda mengaktifkan [enkripsi rahasia](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) untuk cluster yang ada dan kunci KMS yang Anda gunakan pernah dihapus, maka tidak ada cara untuk memulihkan cluster. Jika Anda menghapus kunci KMS, Anda secara permanen menempatkan cluster dalam keadaan terdegradasi. Untuk informasi selengkapnya, lihat [Menghapus kunci AWS KMS.](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html)
**catatan**
Secara default, `create-key` perintah membuat [kunci KMS enkripsi simetris](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html) dengan kebijakan kunci yang memberikan akses admin root akun pada tindakan dan sumber daya AWS KMS. Jika Anda ingin mengurangi izin, pastikan bahwa `kms:CreateGrant` tindakan `kms:DescribeKey` dan diizinkan pada kebijakan untuk prinsipal yang memanggil `create-cluster` API.
Untuk cluster yang menggunakan Enkripsi Amplop KMS, `kms:CreateGrant` izin diperlukan. Kondisi `kms:GrantIsForAWSResource` ini tidak didukung untuk CreateCluster tindakan, dan tidak boleh digunakan dalam kebijakan KMS untuk mengontrol `kms:CreateGrant` izin bagi pengguna yang melakukan. CreateCluster
# Gunakan AWS rahasia Secrets Manager dengan Amazon EKS Pods
Untuk menampilkan rahasia dari Secrets Manager dan parameter dari Parameter Store sebagai file yang dipasang di Amazon EKS Pods, Anda dapat menggunakan AWS Secrets and Configuration Provider (ASCP) untuk [Kubernetes Secrets](https://secrets-store-csi-driver.sigs.k8s.io/) Store CSI Driver.
Dengan ASCP, Anda dapat menyimpan dan mengelola rahasia Anda di Secrets Manager dan kemudian mengambilnya melalui beban kerja Anda yang berjalan di Amazon EKS. Anda dapat menggunakan peran dan kebijakan IAM untuk membatasi akses ke rahasia Anda ke Pod Kubernetes tertentu dalam sebuah klaster. ASCP mengambil identitas Pod dan menukar identitas untuk peran IAM. ASCP mengasumsikan peran IAM dari Pod, dan kemudian dapat mengambil rahasia dari Secrets Manager yang diberi wewenang untuk peran tersebut.
Jika Anda menggunakan rotasi otomatis Secrets Manager untuk rahasia Anda, Anda juga dapat menggunakan fitur reconciler rotasi Driver Secrets Store CSI untuk memastikan Anda mengambil rahasia terbaru dari Secrets Manager.
**catatan**
AWS Grup simpul Fargate (Fargate) tidak didukung.
Untuk informasi selengkapnya, lihat [Menggunakan rahasia Secrets Manager di Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) di Panduan Pengguna AWS Secrets Manager.
# Enkripsi amplop default untuk semua Data API Kubernetes
Amazon Elastic Kubernetes Service (Amazon EKS) menyediakan enkripsi amplop default untuk semua data API Kubernetes di cluster EKS yang menjalankan Kubernetes versi 1.28 atau lebih tinggi.
Enkripsi amplop melindungi data yang Anda simpan dengan server API Kubernetes. Misalnya, enkripsi amplop berlaku untuk konfigurasi klaster Kubernetes Anda, seperti. `ConfigMaps` Enkripsi amplop tidak berlaku untuk data pada node atau volume EBS. EKS sebelumnya mendukung enkripsi rahasia Kubernetes, dan sekarang enkripsi amplop ini meluas ke semua data API Kubernetes.
Ini memberikan pengalaman default terkelola yang mengimplementasikan defense-in-depth aplikasi Kubernetes Anda dan tidak memerlukan tindakan apa pun dari pihak Anda.
Amazon EKS menggunakan AWS [Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) dengan [penyedia Kubernetes KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) untuk lapisan keamanan tambahan ini dengan [kunci milik Amazon Web Services, dan opsi bagi Anda untuk membawa kunci](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) [terkelola pelanggan (CMK) Anda sendiri dari KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk). AWS
## Memahami enkripsi amplop
Enkripsi amplop adalah proses mengenkripsi data teks biasa dengan kunci enkripsi data (DEK) sebelum dikirim ke datastore (etcd), dan kemudian mengenkripsi DEK dengan kunci KMS root yang disimpan dalam sistem KMS jarak jauh yang dikelola secara terpusat (KMS).AWS Ini adalah defense-in-depth strategi karena melindungi data dengan kunci enkripsi (DEK), dan kemudian menambahkan lapisan keamanan lain dengan melindungi DEK itu dengan kunci enkripsi terpisah yang disimpan dengan aman yang disebut kunci enkripsi kunci (KEK).
## Bagaimana Amazon EKS mengaktifkan enkripsi amplop default dengan KMS v2 dan KMS AWS
[Amazon EKS menggunakan [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2) untuk mengimplementasikan enkripsi amplop default untuk semua data API di bidang kontrol Kubernetes yang dikelola sebelum disimpan dalam database etcd.](https://etcd.io/docs/v3.5/faq/) Saat startup, server API cluster menghasilkan kunci enkripsi data (DEK) dari seed rahasia yang dikombinasikan dengan data yang dihasilkan secara acak. Juga saat startup, server API membuat panggilan ke plugin KMS untuk mengenkripsi benih DEK menggunakan kunci enkripsi kunci jarak jauh (KEK) dari AWS KMS. Ini adalah panggilan satu kali yang dijalankan saat startup server API dan pada rotasi KEK. Server API kemudian menyimpan benih DEK terenkripsi. Setelah ini, server API menggunakan benih DEK yang di-cache untuk menghasilkan penggunaan tunggal lainnya DEKs berdasarkan Fungsi Derivasi Kunci (KDF). Masing-masing yang dihasilkan DEKs ini kemudian digunakan hanya sekali untuk mengenkripsi satu sumber daya Kubernetes sebelum disimpan dalam etcd. Dengan penggunaan seed DEK yang di-cache terenkripsi di KMS v2, proses mengenkripsi sumber daya Kubernetes di server API menjadi lebih berkinerja dan hemat biaya.
**Secara default, KEK ini dimiliki oleh AWS, tetapi Anda dapat secara opsional membawa milik Anda sendiri dari AWS KMS.**
Diagram di bawah ini menggambarkan pembuatan dan enkripsi DEK pada saat startup server API.
![\[Diagram menggambarkan pembuatan dan enkripsi DEK saat startup server API\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/security-generate-dek.png)
Diagram tingkat tinggi di bawah ini menggambarkan enkripsi sumber daya Kubernetes sebelum disimpan dalam etcd.
![\[Diagram tingkat tinggi menggambarkan enkripsi sumber daya Kubernetes sebelum disimpan dalam etcd.\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/security-encrypt-request.png)
## Pertanyaan umum
### Bagaimana enkripsi amplop default meningkatkan postur keamanan cluster EKS saya?
Fitur ini mengurangi luas permukaan dan periode waktu di mana metadata dan konten pelanggan tidak dienkripsi. Dengan enkripsi amplop default, metadata dan konten pelanggan hanya pernah dalam keadaan tidak terenkripsi sementara di memori kube-apiserver sebelum disimpan dalam etcd. [Memori kube-apiserver diamankan melalui sistem Nitro.](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html) Amazon EKS hanya menggunakan [instans EC2 berbasis Nitro](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html) untuk control plane Kubernetes yang dikelola. Instans ini memiliki desain kontrol keamanan yang mencegah sistem atau orang mengakses memori mereka.
### Versi Kubernetes mana yang perlu saya jalankan untuk memiliki fitur ini?
Agar enkripsi amplop default diaktifkan, klaster Amazon EKS Anda harus menjalankan Kubernetes versi 1.28 atau yang lebih baru.
### Apakah data saya masih aman jika saya menjalankan versi cluster Kubernetes yang tidak mendukung fitur ini?
Ya. Pada AWS, [keamanan adalah prioritas utama kami](https://aws.amazon.com/security/). Kami mendasarkan semua transformasi dan inovasi digital kami pada praktik operasional keamanan tertinggi, dan tetap berkomitmen untuk meningkatkan standar itu.
Semua data yang disimpan dalam etcd dienkripsi pada tingkat disk untuk setiap cluster EKS, terlepas dari versi Kubernetes yang sedang dijalankan. EKS menggunakan kunci root yang menghasilkan kunci enkripsi volume yang dikelola oleh layanan EKS. Selain itu, setiap kluster Amazon EKS dijalankan dalam VPC terisolasi menggunakan mesin virtual khusus cluster. Karena arsitektur ini, dan praktik kami seputar keamanan operasional, Amazon EKS telah [mencapai beberapa peringkat dan standar kepatuhan](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html) termasuk kelayakan SOC 1,2,3, PCI-DSS, ISO, dan HIPAA. Peringkat dan standar kepatuhan ini dipertahankan untuk semua kluster EKS dengan atau tanpa enkripsi amplop default.
### Bagaimana cara kerja enkripsi amplop di Amazon EKS?
Saat startup, server API cluster menghasilkan kunci enkripsi data (DEK) dari seed rahasia yang dikombinasikan dengan data yang dihasilkan secara acak. Juga saat startup, server API membuat panggilan ke plugin KMS untuk mengenkripsi DEK menggunakan kunci enkripsi kunci jarak jauh (KEK) dari AWS KMS. Ini adalah panggilan satu kali yang dijalankan saat startup server API dan pada rotasi KEK. Server API kemudian menyimpan benih DEK terenkripsi. Setelah ini, server API menggunakan benih DEK yang di-cache untuk menghasilkan penggunaan tunggal lainnya DEKs berdasarkan Fungsi Derivasi Kunci (KDF). Masing-masing yang dihasilkan DEKs ini kemudian digunakan hanya sekali untuk mengenkripsi satu sumber daya Kubernetes sebelum disimpan dalam etcd.
Penting untuk dicatat bahwa ada panggilan tambahan yang dilakukan dari server API untuk memverifikasi kesehatan dan fungsionalitas normal integrasi AWS KMS. Pemeriksaan kesehatan tambahan ini terlihat di Anda AWS CloudTrail.
### Apakah saya harus melakukan sesuatu atau mengubah izin apa pun agar fitur ini berfungsi di cluster EKS saya?
Tidak, Anda tidak perlu mengambil tindakan apa pun. Enkripsi amplop di Amazon EKS sekarang merupakan konfigurasi default yang diaktifkan di semua cluster yang menjalankan Kubernetes versi 1.28 atau lebih tinggi. Integrasi AWS KMS dibuat oleh server API Kubernetes yang dikelola oleh. AWS Ini berarti Anda tidak perlu mengonfigurasi izin apa pun untuk mulai menggunakan enkripsi KMS untuk cluster Anda.
### Bagaimana saya bisa tahu jika enkripsi amplop default diaktifkan di cluster saya?
Jika Anda bermigrasi untuk menggunakan CMK Anda sendiri, maka Anda akan melihat ARN dari kunci KMS yang terkait dengan cluster Anda. Selain itu, Anda dapat melihat log AWS CloudTrail peristiwa yang terkait dengan penggunaan CMK cluster Anda.
Jika cluster Anda menggunakan kunci yang AWS dimiliki, maka ini akan dirinci di konsol EKS (tidak termasuk ARN kunci).
### Bisakah AWS mengakses kunci yang AWS dimiliki yang digunakan untuk enkripsi amplop default di Amazon EKS?
Tidak. AWS memiliki kontrol keamanan yang ketat di Amazon EKS yang mencegah siapa pun mengakses kunci enkripsi teks biasa yang digunakan untuk mengamankan data dalam database etcd. Langkah-langkah keamanan ini juga diterapkan pada kunci KMS yang AWS dimiliki.
### Apakah enkripsi amplop default diaktifkan di cluster EKS saya yang ada?
Jika Anda menjalankan klaster Amazon EKS dengan Kubernetes versi 1.28 atau lebih tinggi, enkripsi amplop semua data API Kubernetes diaktifkan. Untuk cluster yang ada, Amazon EKS menggunakan `eks:kms-storage-migrator` RBAC ClusterRole untuk memigrasikan data yang sebelumnya tidak dienkripsi dalam etcd ke status enkripsi baru ini.
### Apa artinya ini jika saya sudah mengaktifkan enkripsi amplop untuk Rahasia di cluster EKS saya?
Jika Anda memiliki Customer Managed Key (CMK) di KMS yang digunakan untuk menyelubungi enkripsi Kubernetes Secrets Anda, kunci yang sama akan digunakan sebagai KEK untuk enkripsi amplop dari semua tipe data Kubernetes API di klaster Anda.
### Apakah ada biaya tambahan untuk menjalankan cluster EKS dengan enkripsi amplop default?
Tidak ada biaya tambahan yang terkait dengan control plane Kubernetes yang dikelola jika Anda menggunakan [kunci milik Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) untuk enkripsi amplop default. Secara default, setiap kluster EKS yang menjalankan Kubernetes versi 1.28 atau yang lebih baru menggunakan kunci milik [Amazon Web Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). Namun, jika Anda menggunakan kunci AWS KMS Anda sendiri, [harga KMS normal akan berlaku](https://aws.amazon.com/kms/pricing/).
### Berapa biaya untuk menggunakan kunci AWS KMS saya sendiri untuk mengenkripsi data API Kubernetes di cluster saya?
Anda membayar \$11 per bulan untuk menyimpan kunci khusus apa pun yang Anda buat atau impor ke KMS. Biaya KMS untuk permintaan enkripsi dan dekripsi. Ada tingkat gratis 20.000 permintaan per bulan per akun dan Anda membayar \$10,03 per 10.000 permintaan di atas tingkat gratis per bulan. Ini berlaku di semua penggunaan KMS untuk akun, sehingga biaya penggunaan kunci AWS KMS Anda sendiri di klaster Anda akan dipengaruhi oleh penggunaan kunci ini pada cluster atau AWS sumber daya lain dalam akun Anda.
### Apakah biaya KMS saya akan lebih tinggi sekarang karena kunci terkelola pelanggan (CMK) saya digunakan untuk membungkus enkripsi semua data API Kubernetes dan bukan hanya Rahasia?
Tidak. Implementasi kami dengan KMS v2 secara signifikan mengurangi jumlah panggilan yang dilakukan ke AWS KMS. Ini pada gilirannya akan mengurangi biaya yang terkait dengan CMK Anda terlepas dari data Kubernetes tambahan yang dienkripsi atau didekripsi di kluster EKS Anda.
Seperti yang dijelaskan di atas, seed DEK yang dihasilkan yang digunakan untuk enkripsi sumber daya Kubernetes disimpan secara lokal di cache server API Kubernetes setelah dienkripsi dengan KEK jarak jauh. Jika benih DEK terenkripsi tidak ada dalam cache server API, server API akan memanggil AWS KMS untuk mengenkripsi benih DEK. Server API kemudian menyimpan benih DEK terenkripsi untuk penggunaan masa depan di cluster tanpa memanggil KMS. Demikian pula, untuk permintaan dekripsi, server API akan memanggil AWS KMS untuk permintaan dekripsi pertama, setelah itu benih DEK yang didekripsi akan di-cache dan digunakan untuk operasi dekripsi masa depan.
Untuk informasi selengkapnya, lihat [KEP-3299: KMS v2 Improvements in the Kubernetes Enhancements](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements) on. GitHub
### Bisakah saya menggunakan kunci CMK yang sama untuk beberapa kluster Amazon EKS?
Ya. Untuk menggunakan kunci lagi, Anda dapat menautkannya ke cluster di wilayah yang sama dengan mengaitkan ARN dengan cluster selama pembuatan. Namun, jika Anda menggunakan CMK yang sama untuk beberapa kluster EKS, Anda harus menerapkan langkah-langkah yang diperlukan untuk mencegah penonaktifan CMK secara sewenang-wenang. Jika tidak, CMK yang dinonaktifkan yang terkait dengan beberapa kluster EKS akan memiliki cakupan dampak yang lebih luas pada cluster tergantung pada kunci itu.
### Apa yang terjadi pada cluster EKS saya jika CMK saya menjadi tidak tersedia setelah enkripsi amplop default diaktifkan?
Jika Anda menonaktifkan kunci KMS, itu tidak dapat digunakan dalam operasi [kriptografi](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations) apa pun. Tanpa akses ke CMK yang ada, server API tidak akan dapat mengenkripsi dan mempertahankan objek Kubernetes yang baru dibuat, serta mendekripsi objek Kubernetes yang sebelumnya dienkripsi yang disimpan dalam etcd. Jika CMK dinonaktifkan, klaster akan segera ditempatkan dalam unhealthy/degraded keadaan di mana kami tidak akan dapat memenuhi [Komitmen Layanan](https://aws.amazon.com/eks/sla/) kami sampai Anda mengaktifkan kembali CMK terkait.
Ketika CMK dinonaktifkan, Anda akan menerima pemberitahuan tentang kesehatan klaster EKS Anda yang menurun dan kebutuhan untuk mengaktifkan kembali CMK Anda dalam waktu 30 hari setelah menonaktifkannya untuk memastikan pemulihan sumber daya pesawat kontrol Kubernetes Anda berhasil.
### Bagaimana saya bisa melindungi kluster EKS saya dari dampak disabled/deleted CMK?
Untuk melindungi klaster EKS Anda dari kejadian seperti itu, administrator kunci Anda harus mengelola akses ke operasi kunci KMS menggunakan kebijakan IAM dengan prinsip hak istimewa paling sedikit untuk mengurangi risiko penonaktifan sewenang-wenang atau penghapusan kunci yang terkait dengan kluster EKS. Selain itu, Anda dapat mengatur [CloudWatch alarm](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html) untuk diberi tahu tentang status CMK Anda.
### Apakah cluster EKS saya akan dipulihkan jika saya mengaktifkan kembali CMK?
Untuk memastikan pemulihan klaster EKS Anda berhasil, kami sangat menyarankan untuk mengaktifkan kembali CMK Anda dalam 30 hari pertama setelah CMK dinonaktifkan. Namun, pemulihan klaster EKS Anda yang berhasil juga akan bergantung pada apakah klaster tersebut mengalami perubahan yang melanggar API karena peningkatan Kubernetes otomatis yang mungkin terjadi saat klaster dalam keadaan. unhealthy/degraded
### Mengapa cluster EKS saya ditempatkan dalam unhealthy/degraded keadaan setelah menonaktifkan CMK?
Server API bidang kontrol EKS menggunakan kunci DEK yang dienkripsi dan di-cache di memori server API untuk mengenkripsi semua objek selama create/update operasi sebelum disimpan dalam etcd. Ketika objek yang ada diambil dari etcd, server API menggunakan kunci DEK cache yang sama dan mendekripsi objek sumber daya Kubernetes. Jika Anda menonaktifkan CMK, server API tidak akan melihat dampak langsung karena kunci DEK yang di-cache di memori server API. Namun, ketika instance server API dimulai ulang, itu tidak akan memiliki DEK yang di-cache dan perlu memanggil AWS KMS untuk mengenkripsi dan mendekripsi operasi. Tanpa CMK, proses ini akan gagal dengan kode kesalahan KMS\$1KEY\$1DISABLED, mencegah server API berhasil melakukan booting.
### Apa yang terjadi pada cluster EKS saya jika saya menghapus CMK saya?
Menghapus kunci CMK yang terkait dengan kluster EKS Anda akan menurunkan kesehatannya setelah pemulihan. Tanpa CMK klaster Anda, server API tidak akan lagi dapat mengenkripsi dan mempertahankan objek Kubernetes baru, serta mendekripsi objek Kubernetes yang sebelumnya dienkripsi yang disimpan dalam database etcd. Anda hanya harus melanjutkan dengan menghapus kunci CMK untuk cluster EKS Anda ketika Anda yakin bahwa Anda tidak perlu menggunakan cluster EKS lagi.
Harap dicatat bahwa jika CMK tidak ditemukan (KMS\$1KEY\$1NOT\$1FOUND) atau hibah untuk CMK yang terkait dengan cluster Anda dicabut (KMS\$1GRANT\$1REVOKED), klaster Anda tidak akan dapat dipulihkan. Untuk informasi selengkapnya tentang kesehatan klaster dan kode kesalahan, lihat [Kesehatan klaster FAQs dan kode kesalahan dengan jalur resolusi](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status).
### Apakah saya masih akan dikenakan biaya untuk klaster degraded/unhealthy EKS karena saya menonaktifkan atau menghapus CMK saya?
Ya. Meskipun bidang kontrol EKS tidak akan dapat digunakan jika CMK dinonaktifkan, masih AWS akan menjalankan sumber daya infrastruktur khusus yang dialokasikan ke kluster EKS sampai dihapus oleh pelanggan. Selain itu, [Komitmen Layanan](https://aws.amazon.com/eks/sla/) kami tidak akan berlaku dalam keadaan seperti itu karena akan menjadi tindakan sukarela atau tidak bertindak oleh pelanggan yang mencegah kesehatan normal dan pengoperasian klaster EKS Anda.
### Bisakah cluster EKS saya ditingkatkan secara otomatis saat dalam unhealthy/degraded keadaan karena CMK yang dinonaktifkan?
Ya. Namun, jika cluster Anda memiliki CMK yang dinonaktifkan, Anda akan memiliki periode 30 hari untuk mengaktifkannya kembali. Dalam periode 30 hari ini, klaster Kubernetes Anda tidak akan ditingkatkan secara otomatis. Namun, jika periode ini berlalu dan Anda belum mengaktifkan kembali CMK, klaster akan secara otomatis ditingkatkan ke versi berikutnya (n\$11) yang berada dalam dukungan standar, mengikuti siklus hidup versi Kubernetes di EKS.
Kami sangat menyarankan untuk mengaktifkan kembali CMK yang dinonaktifkan dengan cepat ketika Anda mengetahui klaster yang terkena dampak. Penting untuk dicatat, bahwa meskipun EKS akan secara otomatis memutakhirkan klaster yang terkena dampak ini, tidak ada jaminan bahwa mereka akan berhasil pulih, terutama jika cluster mengalami beberapa peningkatan otomatis karena ini mungkin termasuk perubahan pada Kubernetes API dan perilaku tak terduga dalam proses bootstrap server API.
### Bisakah saya menggunakan alias kunci KMS?
Ya. Amazon EKS [mendukung penggunaan alias kunci KMS](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). Alias adalah nama yang ramah untuk kunci [Amazon Web Service KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys). Misalnya, alias memungkinkan Anda merujuk ke kunci KMS sebagai kunci saya, **bukan**. **`1234abcd-12ab-34cd-56ef-1234567890ab`**
### Apakah saya masih dapat mencadangkan dan memulihkan sumber daya klaster saya menggunakan solusi cadangan Kubernetes saya sendiri?
Ya. Anda dapat menggunakan solusi cadangan Kubernetes (seperti [Velero](https://velero.io/)) untuk pemulihan bencana klaster Kubernetes, migrasi data, dan perlindungan data. Jika Anda menjalankan solusi cadangan Kubernetes yang mengakses sumber daya cluster melalui server API, data apa pun yang diambil aplikasi akan didekripsi sebelum mencapai klien. Ini akan memungkinkan Anda untuk memulihkan sumber daya cluster di cluster Kubernetes lain.
# Pertimbangan keamanan untuk Amazon EKS Auto Mode
Topik ini menjelaskan arsitektur keamanan, kontrol, dan praktik terbaik untuk Mode Otomatis Amazon EKS. Ketika organisasi menerapkan aplikasi kontainer dalam skala besar, mempertahankan postur keamanan yang kuat menjadi semakin kompleks. Mode Otomatis EKS mengimplementasikan kontrol keamanan otomatis dan terintegrasi dengan layanan AWS keamanan untuk membantu Anda melindungi infrastruktur klaster, beban kerja, dan data Anda. Melalui fitur keamanan bawaan seperti manajemen siklus hidup node yang diberlakukan dan penerapan patch otomatis, Mode Otomatis EKS membantu Anda mempertahankan praktik terbaik keamanan sekaligus mengurangi overhead operasional.
Sebelum melanjutkan dengan topik ini, pastikan Anda terbiasa dengan konsep Mode Otomatis EKS dasar dan telah meninjau prasyarat untuk mengaktifkan Mode Otomatis EKS di cluster Anda. Untuk informasi umum tentang keamanan Amazon EKS, lihat[Keamanan di Amazon EKS](security.md).
Amazon EKS Auto Mode dibangun di atas fondasi keamanan Amazon EKS yang ada sambil memperkenalkan kontrol keamanan otomatis tambahan untuk instans EC2 terkelola.
## Keamanan dan otentikasi API
Amazon EKS Auto Mode menggunakan mekanisme keamanan AWS platform untuk mengamankan dan mengautentikasi panggilan ke Amazon EKS API.
+ Akses ke API Kubernetes diamankan melalui entri akses EKS, yang terintegrasi dengan identitas IAM. AWS
+ Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md).
+ Pelanggan dapat menerapkan kontrol akses berbutir halus ke titik akhir API Kubernetes melalui konfigurasi entri akses EKS.
## Keamanan jaringan
Amazon EKS Auto Mode mendukung beberapa lapisan keamanan jaringan:
+ **Integrasi VPC**
+ Beroperasi dalam Amazon Virtual Private Cloud (VPC)
+ Mendukung konfigurasi VPC kustom dan tata letak subnet
+ Mengaktifkan jaringan pribadi antara komponen cluster
+ Untuk informasi selengkapnya, lihat [Mengelola tanggung jawab keamanan untuk Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)
+ **Kebijakan Jaringan**
+ Dukungan asli untuk Kebijakan Jaringan Kubernetes
+ Kemampuan untuk menentukan aturan lalu lintas jaringan granular
+ Untuk informasi selengkapnya, silakan lihat [Batasi lalu lintas Pod dengan kebijakan jaringan Kubernetes](cni-network-policy.md)
## EC2 keamanan instance terkelola
Amazon EKS Auto Mode mengoperasikan instans EC2 terkelola dengan kontrol keamanan berikut:
### EC2 keamanan
+ EC2 instans terkelola mempertahankan fitur keamanan Amazon EC2.
+ Untuk informasi selengkapnya tentang instans EC2 terkelola, lihat [Keamanan di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html).
### Manajemen siklus hidup instans
EC2 instans terkelola yang dioperasikan oleh Mode Otomatis EKS memiliki masa pakai maksimum 21 hari. Mode Otomatis Amazon EKS secara otomatis menghentikan instans yang melebihi masa pakai ini. Batas siklus hidup ini membantu mencegah penyimpangan konfigurasi dan mempertahankan postur keamanan.
### Perlindungan data
+ Amazon EC2 Instance Storage dienkripsi, ini adalah penyimpanan yang langsung dilampirkan ke instance. Untuk informasi selengkapnya, lihat [Perlindungan data di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html).
+ Mode Otomatis EKS mengelola volume yang dilampirkan ke EC2 instance pada waktu pembuatan, termasuk volume root dan data. Mode Otomatis EKS tidak sepenuhnya mengelola volume EBS yang dibuat menggunakan fitur penyimpanan persisten Kubernetes.
### Manajemen tambalan
+ Mode Otomatis Amazon EKS secara otomatis menerapkan tambalan ke instans terkelola.
+ Patch meliputi:
+ Pembaruan sistem operasi
+ Patch keamanan
+ Komponen Mode Otomatis Amazon EKS
**catatan**
Pelanggan bertanggung jawab untuk mengamankan dan memperbarui beban kerja yang berjalan pada instans ini.
### Kontrol akses
+ Akses instans langsung dibatasi:
+ Akses SSH tidak tersedia.
+ AWS Akses Systems Manager Session Manager (SSM) tidak tersedia.
+ Operasi manajemen dilakukan melalui Amazon EKS API dan Kubernetes API.
## Manajemen sumber daya otomatis
Amazon EKS Auto Mode tidak sepenuhnya mengelola Volume Amazon Elastic Block Store (Amazon EBS) yang dibuat menggunakan fitur penyimpanan persisten Kubernetes. Mode Otomatis EKS juga tidak mengelola Elastic Load Balancers (ELB). Amazon EKS Auto Mode mengotomatiskan tugas rutin untuk sumber daya ini.
### Keamanan penyimpanan
+ AWS merekomendasikan agar Anda mengaktifkan enkripsi untuk Volume EBS yang disediakan oleh fitur penyimpanan persisten Kubernetes. Untuk informasi selengkapnya, lihat [Buat kelas penyimpanan](create-storage-class.md).
+ Enkripsi saat istirahat menggunakan AWS KMS
+ Anda dapat mengonfigurasi AWS akun Anda untuk menerapkan enkripsi volume EBS baru dan salinan snapshot yang Anda buat. Untuk informasi selengkapnya, lihat [Mengaktifkan enkripsi Amazon EBS secara default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) di Panduan Pengguna Amazon EBS.
+ Untuk informasi selengkapnya, lihat [Keamanan di Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html).
### Keamanan penyeimbang beban
+ Konfigurasi otomatis Elastic Load Balancers
+ Manajemen sertifikat SSL/TLS melalui integrasi Certificate Manager AWS
+ Otomatisasi grup keamanan untuk kontrol akses penyeimbang beban
+ Untuk informasi selengkapnya, lihat [Keamanan di Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html).
## Praktik terbaik keamanan
Bagian berikut menjelaskan praktik terbaik keamanan untuk Amazon EKS Auto Mode.
+ Tinjau kebijakan AWS IAM dan entri akses EKS secara teratur.
+ Menerapkan pola akses hak istimewa terkecil untuk beban kerja.
+ Pantau aktivitas cluster melalui AWS CloudTrail dan Amazon CloudWatch. Untuk informasi selengkapnya, silakan lihat [Log panggilan API sebagai AWS CloudTrail peristiwa](logging-using-cloudtrail.md) dan [Pantau data cluster dengan Amazon CloudWatch](cloudwatch.md).
+ Gunakan AWS Security Hub untuk penilaian postur keamanan.
+ Terapkan standar keamanan pod yang sesuai untuk beban kerja Anda.
# Pertimbangan keamanan untuk Kemampuan EKS
Topik ini mencakup pertimbangan keamanan penting untuk Kemampuan EKS, termasuk konfigurasi peran IAM, izin Kubernetes, dan pola arsitektur untuk penerapan multi-cluster dan manajemen sumber daya lintas akun. AWS
Kemampuan EKS menggunakan kombinasi peran IAM, entri akses EKS, dan Kubernetes RBAC untuk menyediakan akses aman ke layanan, sumber daya Kubernetes in-cluster, dan integrasi dengan, Secrets Manager, dan AWS layanan lainnya. AWS CodeConnections AWS AWS
## Kemampuan peran IAM
Saat Anda membuat kemampuan, Anda memberikan peran kemampuan IAM yang digunakan EKS untuk melakukan tindakan atas nama Anda. Peran ini harus:
+ Berada di AWS akun yang sama dengan cluster dan sumber daya kemampuan
+ Memiliki kebijakan kepercayaan yang memungkinkan kepala `capabilities.eks.amazonaws.com` layanan untuk mengambil peran
+ Memiliki izin IAM yang sesuai untuk jenis kemampuan dan kasus penggunaan, tergantung pada kebutuhan Anda. Untuk informasi rinci tentang izin IAM yang diperlukan, lihat,[Connect ke repositori Git dengan AWS CodeConnections](integration-codeconnections.md), dan [Kelola rahasia aplikasi dengan AWS Secrets Manager](integration-secrets-manager.md) [Konfigurasikan izin ACK](ack-permissions.md)
Merupakan praktik terbaik untuk mempertimbangkan ruang lingkup hak istimewa yang diperlukan untuk kasus penggunaan spesifik Anda dan hanya memberikan izin yang diperlukan untuk memenuhi kebutuhan Anda. Misalnya, saat menggunakan Kemampuan EKS untuk Kube Resource Orchestrator, izin IAM mungkin tidak diperlukan, sementara ketika menggunakan Kemampuan EKS untuk AWS Pengontrol untuk Kubernetes, Anda dapat memberikan akses penuh ke satu atau beberapa layanan. AWS
**penting**
Meskipun beberapa kasus penggunaan mungkin menjamin penggunaan hak administratif yang luas, ikuti prinsip hak istimewa paling sedikit dengan hanya memberikan izin IAM minimum yang diperlukan untuk kasus penggunaan spesifik Anda, membatasi akses ke sumber daya tertentu menggunakan ARNs dan kunci kondisi daripada menggunakan izin wildcard.
Untuk informasi rinci tentang membuat dan mengonfigurasi peran IAM kemampuan, lihat. [Peran IAM kemampuan Amazon EKS](capability-role.md)
## Entri akses EKS
Saat Anda membuat kemampuan dengan peran IAM, Amazon EKS secara otomatis membuat entri akses untuk peran tersebut di klaster Anda. Entri akses ini memberikan izin dasar kemampuan Kubernetes untuk berfungsi.
**catatan**
Entri akses dibuat untuk cluster tempat kemampuan dibuat. Untuk penyebaran CD Argo ke cluster jarak jauh, Anda harus membuat entri akses pada cluster tersebut dengan izin yang sesuai untuk kemampuan Argo CD untuk menyebarkan dan mengelola aplikasi.
Entri akses meliputi:
+ IAM berperan ARN sebagai kepala sekolah
+ Kebijakan entri akses khusus kemampuan yang memberikan izin Kubernetes dasar
+ Cakupan yang sesuai (luster-wide atau namespace-scoped) berdasarkan jenis kemampuan
**catatan**
Untuk Argo CD, izin dengan cakupan ruang nama diberikan ke namespace yang ditentukan dalam konfigurasi kemampuan (default ke). `argocd`
**Kebijakan entri akses default berdasarkan kemampuan**
Setiap jenis kemampuan memberikan peran kemampuan izin yang diperlukan, menetapkan kebijakan entri akses default yang berbeda sebagai berikut:
**kro**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`(Cluster cakupan)
Memberikan izin untuk menonton ResourceGraphDefinitions dan mengelola serta membuat instance sumber daya kustom yang ditentukan oleh. RGDs
**ACK**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`(Cluster cakupan)
Memberikan izin untuk membuat, membaca, memperbarui, dan menghapus sumber daya khusus ACK di semua ruang nama.
**Argo CD**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`(Cluster cakupan)
Memberikan izin tingkat cluster untuk Argo CD untuk menemukan sumber daya dan mengelola objek dengan cakupan cluster.
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`(cakupan ruang nama)
Memberikan izin tingkat ruang nama untuk Argo CD untuk menyebarkan dan mengelola aplikasi. Dicakup ke namespace yang ditentukan dalam konfigurasi kemampuan (default ke). `argocd`
Lihat [Tinjau izin kebijakan akses](access-policy-permissions.md) untuk informasi lebih rinci.
## Izin Kubernetes tambahan
Beberapa kemampuan mungkin memerlukan izin Kubernetes tambahan di luar kebijakan entri akses default. Anda dapat memberikan izin ini menggunakan:
+ **Kebijakan entri akses**: Kaitkan kebijakan terkelola tambahan ke entri akses
+ **Kubernetes RBAC**: Membuat `Role` atau mengikat untuk pengguna `ClusterRole` Kubernetes kemampuan
**Izin pembaca rahasia ACK**
Beberapa pengontrol ACK perlu membaca rahasia Kubernetes untuk mengambil data sensitif seperti kata sandi database. Pengontrol ACK berikut memerlukan akses baca rahasia:
+ `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager`
Untuk memberikan izin baca rahasia:
1. Kaitkan kebijakan entri `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` akses ke entri akses kemampuan
1. Cakupan kebijakan ke ruang nama tertentu di mana sumber daya ACK akan mereferensikan rahasia, atau memberikan akses ke seluruh klaster
**penting**
Izin baca rahasia dicakup ke ruang nama yang Anda tentukan saat mengaitkan kebijakan entri akses. Ini memungkinkan Anda untuk membatasi rahasia mana yang dapat diakses oleh kemampuan.
**izin sumber daya arbitrer kro**
kro memerlukan izin untuk membuat dan mengelola sumber daya yang ditentukan dalam Anda. ResourceGraphDefinitions Secara default, kro hanya dapat menonton dan mengelola RGDs sendiri.
Untuk memberikan izin kro untuk membuat sumber daya:
**Opsi 1: Kebijakan entri akses**
Mengaitkan kebijakan entri akses yang telah ditentukan sebelumnya seperti `AmazonEKSAdminPolicy` atau `AmazonEKSEditPolicy` dengan entri akses kemampuan.
**Opsi 2: Kubernetes RBAC**
Buat sebuah `ClusterRoleBinding` yang memberi pengguna kemampuan Kubernetes izin yang diperlukan:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**catatan**
Nama pengguna Kubernetes untuk kro mengikuti pola: `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO`
Nama sesi `/KRO` (huruf besar) secara otomatis diatur oleh kemampuan EKS kro.
## Izin IAM diperlukan oleh kemampuan
**kro (Orkestra Sumber Daya Kube)**
Tidak diperlukan izin IAM. Anda dapat membuat peran kapabilitas tanpa kebijakan terlampir. kro hanya membutuhkan izin Kubernetes RBAC.
**ACK (AWS Pengontrol untuk Kubernetes)**
Memerlukan izin untuk mengelola AWS sumber daya yang akan dibuat dan dikelola ACK. Anda harus mencakup izin untuk layanan, tindakan, dan sumber daya tertentu berdasarkan kebutuhan Anda. Untuk informasi terperinci tentang mengonfigurasi izin ACK, termasuk praktik terbaik produksi dengan Penyeleksi Peran IAM, lihat. [Konfigurasikan izin ACK](ack-permissions.md)
**Argo CD**
Tidak ada izin IAM yang diperlukan secara default. Izin opsional mungkin diperlukan untuk:
+ AWS Secrets Manager: Jika menyimpan kredensi repositori Git di Secrets Manager
+ AWS CodeConnections: Jika menggunakan CodeConnections untuk otentikasi repositori Git
+ Amazon ECR: Jika menggunakan bagan Helm yang disimpan dalam format OCI di Amazon ECR
## Praktik terbaik keamanan
### Hak istimewa IAM paling sedikit
Berikan sumber daya kemampuan Anda hanya izin yang diperlukan untuk kasus penggunaan Anda. Ini tidak berarti Anda tidak dapat memberikan izin administratif yang luas untuk kemampuan Anda jika diperlukan. Dalam kasus seperti itu, Anda harus mengatur akses ke sumber daya tersebut dengan tepat.
**Peran kemampuan**:
+ **ACK**: Jika memungkinkan, batasi izin IAM untuk AWS layanan dan sumber daya tertentu yang dibutuhkan tim Anda, berdasarkan kasus penggunaan dan persyaratan
+ **Argo CD: Batasi** akses ke repositori Git tertentu dan ruang nama Kubernetes
+ **kro**: Memerlukan peran kemampuan untuk kebijakan kepercayaan, tetapi tidak diperlukan izin IAM (hanya menggunakan cluster RBAC)
**Contoh**: Alih-alih`"Resource": "*"`, tentukan pola untuk sumber daya atau kelompok sumber daya tertentu.
```
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```
Gunakan kunci kondisi IAM untuk membatasi akses lebih lanjut:
```
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
```
Untuk informasi konfigurasi IAM tambahan, lihat bagian pertimbangan untuk setiap kemampuan.
### Isolasi namespace untuk rahasia Argo CD
Kemampuan CD Argo yang dikelola memiliki akses ke semua rahasia Kubernetes dalam namespace yang dikonfigurasi (default:). `argocd` Untuk mempertahankan postur keamanan yang optimal, ikuti praktik isolasi namespace ini:
+ Simpan hanya rahasia yang relevan dengan Argo CD di dalam namespace Argo CD
+ Hindari menyimpan rahasia aplikasi yang tidak terkait di namespace yang sama dengan Argo CD
+ Gunakan ruang nama terpisah untuk rahasia aplikasi yang tidak diperlukan untuk operasi Argo CD
Isolasi ini memastikan bahwa akses rahasia Argo CD terbatas hanya pada kredenal yang dibutuhkan untuk otentikasi repositori Git dan operasi khusus Argo CD lainnya.
### Kubernetes RBAC
Kontrol pengguna dan akun layanan mana yang dapat membuat dan mengelola sumber daya kemampuan. Ini adalah praktik terbaik untuk menyebarkan sumber daya kemampuan di ruang nama khusus dengan kebijakan RBAC yang sesuai.
Contoh: Peran RBAC untuk bekerja dengan ACK, memungkinkan pengelolaan sumber daya S3 Bucket di namespace: `app-team`
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
```
### Pencatatan audit
**CloudTrail**: Semua operasi API Kemampuan EKS (buat, perbarui, hapus) dicatat AWS CloudTrail.
Aktifkan CloudTrail logging untuk melacak:
+ Siapa yang menciptakan atau memodifikasi kemampuan
+ Ketika konfigurasi kemampuan berubah
+ Peran kemampuan apa yang digunakan
### Akses jaringan dan titik akhir VPC
#### Akses API CD Argo pribadi
Anda dapat membatasi akses ke server Argo CD API dengan mengaitkan satu atau beberapa titik akhir VPC dengan titik akhir Argo CD yang dihosting. Ini memungkinkan konektivitas pribadi dari dalam VPC Anda tanpa melintasi internet publik. Titik akhir VPC menyediakan akses ke UI web Argo CD dan Argo CD API (termasuk akses CLI).
**catatan**
Titik akhir VPC terhubung ke titik akhir API Argo CD yang dihosting (menggunakan kemampuan eks. *region*.amazonaws.com) tidak mendukung kebijakan titik akhir VPC.
#### Menyebarkan ke cluster pribadi
Kemampuan Argo CD dapat menyebarkan aplikasi ke cluster EKS yang sepenuhnya pribadi, memberikan manfaat operasional yang signifikan dengan menghilangkan kebutuhan akan peering VPC atau konfigurasi jaringan yang kompleks. Namun, ketika merancang arsitektur ini, pertimbangkan bahwa Argo CD akan menarik konfigurasi dari repositori Git (yang mungkin bersifat publik) dan menerapkannya ke cluster pribadi Anda.
Pastikan Anda:
+ Gunakan repositori Git pribadi untuk beban kerja yang sensitif
+ Menerapkan kontrol akses repositori Git yang tepat dan otentikasi
+ Tinjau dan setujui perubahan melalui permintaan tarik sebelum menggabungkan
+ Pertimbangkan untuk menggunakan jendela sinkronisasi Argo CD untuk mengontrol kapan penerapan dapat terjadi
+ Pantau log audit Argo CD untuk perubahan konfigurasi yang tidak sah
### Kepatuhan
Kemampuan EKS dikelola sepenuhnya dan memiliki sertifikasi kepatuhan Amazon EKS.
Untuk informasi kepatuhan saat ini, lihat [AWS Layanan dalam Lingkup menurut Program Kepatuhan](https://aws.amazon.com/compliance/services-in-scope/).
## Langkah selanjutnya
+ [Konfigurasikan izin ACK](ack-permissions.md)- Konfigurasikan izin IAM untuk ACK
+ [Konfigurasikan izin kro](kro-permissions.md)- Konfigurasikan Kubernetes RBAC untuk kro
+ [Konfigurasikan izin Argo CD](argocd-permissions.md)- Konfigurasikan integrasi Pusat Identitas untuk Argo CD
+ [Memecahkan Masalah Kemampuan EKS](capabilities-troubleshooting.md)- Memecahkan masalah keamanan dan izin
# Identity and access management untuk Amazon EKS
AWS Identity and Access Management (IAM) adalah AWS layanan yang membantu administrator mengontrol akses ke sumber daya dengan aman. AWS Administrator IAM mengendalikan siapa yang dapat *diautentikasi* (masuk) dan *diotorisasi* (memiliki izin) untuk menggunakan sumber daya Amazon EKS. IAM adalah AWS layanan yang dapat Anda gunakan tanpa biaya tambahan.
## Audiens
Cara Anda menggunakan AWS Identity and Access Management (IAM) berbeda, tergantung pada pekerjaan yang Anda lakukan di Amazon EKS.
**Pengguna layanan** – Jika Anda menggunakan layanan Amazon EKS untuk melakukan tugas, maka administrator Anda akan memberikan kredensial dan izin yang dibutuhkan. Saat Anda menggunakan lebih banyak fitur di Amazon EKS untuk melakukan pekerjaan, Anda mungkin memerlukan izin tambahan. Memahami bagaimana akses dikelola dapat membantu Anda untuk meminta izin yang tepat dari administrator Anda. Jika Anda tidak dapat mengakses fitur di Amazon EKS, lihat [Menyelesaikan masalah IAM](security-iam-troubleshoot.md).
**Administrator layanan** - Jika Anda bertanggung jawab atas sumber daya Amazon EKS di perusahaan Anda, Anda mungkin memiliki akses penuh ke Amazon EKS. Tugas Anda adalah menentukan fitur dan sumber daya Amazon EKS mana yang harus diakses pengguna layanan Anda. Kemudian, Anda harus mengirimkan permintaan kepada administrator IAM untuk mengubah izin pengguna layanan Anda. Tinjau informasi di halaman ini untuk memahami konsep dasar IAM. Untuk mempelajari selengkapnya tentang bagaimana perusahaan Anda dapat menggunakan IAM dengan Amazon EKS, lihat [Bagaimana cara Amazon EKS bekerja sama dengan IAM](security-iam-service-with-iam.md).
**Administrator IAM** - Jika Anda seorang administrator IAM, Anda mungkin ingin mempelajari detail tentang cara menulis kebijakan untuk mengelola akses ke Amazon EKS. Untuk melihat contoh kebijakan berbasis identitas Amazon EKS yang dapat Anda gunakan di IAM, lihat [Contoh kebijakan berbasis identitas Amazon EKS](security-iam-id-based-policy-examples.md).
## Mengautentikasi dengan identitas
Otentikasi adalah cara Anda masuk AWS menggunakan kredensi identitas Anda. Anda harus *diautentikasi* (masuk ke AWS) sebagai pengguna root AWS akun, sebagai pengguna IAM, atau dengan mengambil peran IAM.
Anda dapat masuk AWS sebagai identitas federasi dengan menggunakan kredensil yang disediakan melalui sumber identitas. AWS Pengguna IAM Identity Center (IAM Identity Center), autentikasi masuk tunggal perusahaan Anda, dan kredensi Google atau Facebook Anda adalah contoh identitas federasi. Saat Anda masuk sebagai identitas terfederasi, administrator Anda sebelumnya menyiapkan federasi identitas menggunakan peran IAM. Ketika Anda mengakses AWS dengan menggunakan federasi, Anda secara tidak langsung mengambil peran.
Bergantung pada jenis pengguna Anda, Anda dapat masuk ke Konsol Manajemen AWS atau portal AWS akses. Untuk informasi selengkapnya tentang masuk AWS, lihat [Cara masuk ke AWS akun Anda](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) di *Panduan Pengguna AWS Masuk*.
Jika Anda mengakses AWS secara terprogram, AWS sediakan kit pengembangan perangkat lunak (SDK) dan antarmuka baris perintah (CLI) untuk menandatangani permintaan Anda secara kriptografis dengan menggunakan kredensil Anda. Jika Anda tidak menggunakan AWS alat, Anda harus menandatangani permintaan sendiri. Untuk informasi selengkapnya tentang penggunaan metode yang disarankan untuk menandatangani permintaan sendiri, lihat [Menandatangani permintaan AWS API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) di *Panduan Pengguna IAM*.
Apa pun metode autentikasi yang digunakan, Anda mungkin diminta untuk menyediakan informasi keamanan tambahan. Misalnya, AWS merekomendasikan agar Anda menggunakan otentikasi multi-faktor (MFA) untuk meningkatkan keamanan akun Anda. *Untuk mempelajari lebih lanjut, lihat [Autentikasi multi-faktor](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) di *Panduan Pengguna Pusat AWS Identitas IAM* dan [Menggunakan otentikasi multi-faktor (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) di Panduan Pengguna IAM. AWS*
### AWS pengguna root akun
Saat Anda membuat AWS akun, Anda mulai dengan satu identitas masuk yang memiliki akses lengkap ke semua AWS layanan dan sumber daya di akun. Identitas ini disebut *pengguna root AWS * akun dan diakses dengan masuk dengan alamat email dan kata sandi yang Anda gunakan untuk membuat akun. Kami sangat menyarankan agar Anda tidak menggunakan pengguna root untuk tugas sehari-hari Anda. Lindungi kredensial pengguna root Anda dan gunakan kredensial tersebut untuk melakukan tugas yang hanya dapat dilakukan pengguna root. Untuk daftar lengkap tugas yang mengharuskan Anda masuk sebagai pengguna root, lihat [Tugas yang memerlukan kredensial pengguna root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dalam *Panduan Pengguna IAM*.
### Pengguna dan grup IAM
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) adalah identitas dalam AWS akun Anda yang memiliki izin khusus untuk satu orang atau aplikasi. Jika memungkinkan, kami merekomendasikan untuk mengandalkan kredensial sementara, bukan membuat pengguna IAM yang memiliki kredensial jangka panjang seperti kata sandi dan kunci akses. Namun, jika Anda memiliki kasus penggunaan tertentu yang memerlukan kredensial jangka panjang dengan pengguna IAM, kami merekomendasikan Anda merotasi kunci akses. Untuk informasi selengkapnya, lihat [Merotasi kunci akses secara teratur untuk kasus penggunaan yang memerlukan kredensial jangka panjang](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) dalam *Panduan Pengguna IAM*.
[Grup IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) adalah identitas yang menentukan sekumpulan pengguna IAM. Anda tidak dapat masuk sebagai grup. Anda dapat menggunakan grup untuk menentukan izin bagi beberapa pengguna sekaligus. Grup mempermudah manajemen izin untuk sejumlah besar pengguna sekaligus. Misalnya, Anda dapat meminta kelompok untuk menyebutkan *IAMAdmins* dan memberikan izin kepada grup tersebut untuk mengelola sumber daya IAM.
Pengguna berbeda dari peran. Pengguna secara unik terkait dengan satu orang atau aplikasi, tetapi peran dimaksudkan untuk dapat digunakan oleh siapa pun yang membutuhkannya. Pengguna memiliki kredensial jangka panjang permanen, tetapi peran memberikan kredensial sementara. Untuk mempelajari selengkapnya, lihat [Kapan harus membuat pengguna IAM (bukan peran)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) dalam *Panduan Pengguna IAM*.
### Peran IAM
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) adalah identitas dalam AWS akun Anda yang memiliki izin khusus. Peran ini mirip dengan pengguna IAM, tetapi tidak terkait dengan orang tertentu. Anda dapat mengambil peran IAM untuk sementara Konsol Manajemen AWS dengan [beralih peran](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Anda dapat mengambil peran dengan memanggil operasi AWS CLI atau AWS API atau dengan menggunakan URL khusus. Untuk informasi selengkapnya tentang cara menggunakan peran, lihat [Menggunakan peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) dalam *Panduan Pengguna IAM*.
Peran IAM dengan kredensial sementara berguna dalam situasi berikut:
+ **Akses pengguna terfederasi** – Untuk menetapkan izin ke identitas terfederasi, Anda membuat peran dan menentukan izin untuk peran tersebut. Ketika identitas terfederasi mengautentikasi, identitas tersebut terhubung dengan peran dan diberi izin yang ditentukan oleh peran. Untuk informasi tentang peran untuk federasi, lihat [Membuat peran untuk Penyedia Identitas pihak ketiga](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) dalam *Panduan Pengguna IAM*. Jika menggunakan Pusat Identitas IAM, Anda harus mengonfigurasi set izin. Untuk mengontrol apa yang dapat diakses identitas Anda setelah identitas tersebut diautentikasi, Pusat Identitas IAM akan mengorelasikan set izin ke peran dalam IAM. Untuk informasi tentang set izin, lihat [Set izin](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) di *Panduan Pengguna Pusat AWS Identitas IAM*.
+ **Izin pengguna IAM sementara** – Pengguna atau peran IAM dapat mengambil peran IAM guna mendapatkan berbagai izin secara sementara untuk tugas tertentu.
+ **Akses lintas akun** – Anda dapat menggunakan peran IAM untuk mengizinkan seseorang (principal tepercaya) di akun lain untuk mengakses sumber daya di akun Anda. Peran adalah cara utama untuk memberikan akses lintas akun. Namun, dengan beberapa AWS layanan, Anda dapat melampirkan kebijakan langsung ke sumber daya (alih-alih menggunakan peran sebagai proxy). Untuk mempelajari perbedaan antara peran dan kebijakan berbasis sumber daya untuk akses lintas akun, lihat [Akses sumber daya lintas akun di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dalam *Panduan Pengguna IAM*.
+ **Akses lintas layanan** — Beberapa AWS layanan menggunakan fitur di AWS layanan lain. Misalnya, saat Anda melakukan panggilan dalam suatu layanan, biasanya layanan tersebut menjalankan aplikasi di Amazon EC2 atau menyimpan objek di Amazon S3. Layanan mungkin melakukan ini menggunakan izin kepala panggilan, menggunakan peran layanan, atau menggunakan peran terkait layanan.
+ **Sesi akses teruskan (FAS)** — Saat Anda menggunakan pengguna atau peran IAM untuk melakukan tindakan AWS, Anda dianggap sebagai prinsipal. Ketika Anda menggunakan beberapa layanan, Anda mungkin melakukan sebuah tindakan yang kemudian menginisiasi tindakan lain di layanan yang berbeda. FAS menggunakan izin dari prinsipal yang memanggil AWS layanan, dikombinasikan dengan layanan yang meminta untuk membuat permintaan ke AWS layanan hilir. Permintaan FAS hanya dibuat ketika layanan menerima permintaan yang memerlukan interaksi dengan AWS layanan atau sumber daya lain untuk diselesaikan. Dalam hal ini, Anda harus memiliki izin untuk melakukan kedua tindakan tersebut. Untuk detail kebijakan ketika mengajukan permintaan FAS, lihat [Sesi akses terusan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Peran layanan** – Peran layanan adalah [peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) yang dijalankan oleh layanan untuk melakukan tindakan atas nama Anda. Administrator IAM dapat membuat, mengubah, dan menghapus peran layanan dari dalam IAM. Untuk informasi selengkapnya, lihat [Membuat peran untuk mendelegasikan izin ke AWS layanan di Panduan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) Pengguna *IAM*.
+ **Peran terkait layanan — Peran** terkait layanan adalah jenis peran layanan yang ditautkan ke layanan. AWS Layanan tersebut dapat menjalankan peran untuk melakukan tindakan atas nama Anda. Peran terkait layanan muncul di AWS akun Anda dan dimiliki oleh layanan. Administrator IAM dapat melihat, tetapi tidak dapat mengedit izin untuk peran terkait layanan.
+ **Aplikasi yang berjalan di Amazon EC2** — Anda dapat menggunakan peran IAM untuk mengelola kredensi sementara untuk aplikasi yang berjalan pada EC2 instance dan membuat permintaan AWS CLI atau API. AWS Ini lebih baik untuk menyimpan kunci akses dalam EC2 instance. Untuk menetapkan AWS peran ke EC2 instance dan membuatnya tersedia untuk semua aplikasinya, Anda membuat profil instance yang dilampirkan ke instance. Profil instance berisi peran dan memungkinkan program yang berjalan pada EC2 instance untuk mendapatkan kredensi sementara. Untuk informasi selengkapnya, lihat [Menggunakan peran IAM untuk memberikan izin ke aplikasi yang berjalan di EC2 instans Amazon di Panduan Pengguna](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) *IAM*.
Untuk mempelajari apakah kita harus menggunakan peran IAM atau pengguna IAM, lihat [Kapan harus membuat peran IAM (bukan pengguna)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) dalam *Panduan Pengguna IAM*.
## Mengelola akses menggunakan kebijakan
Anda mengontrol akses AWS dengan membuat kebijakan dan melampirkannya ke AWS identitas atau sumber daya. Kebijakan adalah objek AWS yang, ketika dikaitkan dengan identitas atau sumber daya, menentukan izinnya. AWS mengevaluasi kebijakan ini ketika prinsipal (pengguna, pengguna root, atau sesi peran) membuat permintaan. Izin dalam kebijakan menentukan apakah permintaan diizinkan atau ditolak. Sebagian besar kebijakan disimpan AWS sebagai dokumen JSON. Untuk informasi selengkapnya tentang struktur dan isi dokumen kebijakan JSON, lihat [Gambaran umum kebijakan JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dalam *Panduan Pengguna IAM*.
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, **principal** dapat melakukan **tindakan** pada suatu **sumber daya**, dan dalam suatu **syarat**.
Secara default, pengguna dan peran tidak memiliki izin. Untuk memberikan izin kepada pengguna untuk melakukan tindakan di sumber daya yang mereka perlukan, administrator IAM dapat membuat kebijakan IAM. Administrator kemudian dapat menambahkan kebijakan IAM ke peran, dan pengguna dapat mengambil peran.
Kebijakan IAM mendefinisikan izin untuk suatu tindakan terlepas dari metode yang Anda gunakan untuk melakukan operasinya. Misalnya, anggaplah Anda memiliki kebijakan yang mengizinkan tindakan `iam:GetRole`. Pengguna dengan kebijakan itu bisa mendapatkan informasi peran dari Konsol Manajemen AWS, AWS CLI, atau API. AWS
### Kebijakan berbasis identitas
Kebijakan berbasis identitas adalah dokumen kebijakan izin JSON yang dapat Anda lampirkan ke sebuah identitas, seperti pengguna IAM, grup pengguna IAM, atau peran IAM. Kebijakan ini mengontrol jenis tindakan yang dapat dilakukan oleh pengguna dan peran, di sumber daya mana, dan berdasarkan kondisi seperti apa. Untuk mempelajari cara membuat kebijakan berbasis identitas, lihat [Membuat kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dalam *Panduan Pengguna IAM*.
Kebijakan berbasis identitas dapat dikategorikan lebih lanjut sebagai *kebijakan inline* atau *kebijakan yang dikelola*. Kebijakan inline disematkan langsung ke satu pengguna, grup, atau peran. Kebijakan terkelola adalah kebijakan mandiri yang dapat Anda lampirkan ke beberapa pengguna, grup, dan peran di AWS akun Anda. Kebijakan AWS terkelola mencakup kebijakan terkelola dan kebijakan yang dikelola pelanggan. Untuk mempelajari cara memilih antara kebijakan yang dikelola atau kebijakan inline, lihat [Memilih antara kebijakan yang dikelola dan kebijakan inline](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) dalam *Panduan Pengguna IAM*.
### Kebijakan berbasis sumber daya
Kebijakan berbasis sumber daya adalah dokumen kebijakan JSON yang Anda lampirkan ke sumber daya. Contoh kebijakan berbasis sumber daya adalah *kebijakan kepercayaan peran* IAM dan *kebijakan bucket* Amazon S3. Dalam layanan yang mendukung kebijakan berbasis sumber daya, administrator layanan dapat menggunakannya untuk mengontrol akses ke sumber daya tertentu. Untuk sumber daya tempat kebijakan dilampirkan, kebijakan menentukan tindakan apa yang dapat dilakukan oleh principal tertentu pada sumber daya tersebut dan dalam kondisi apa. Anda harus [menentukan principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dalam kebijakan berbasis sumber daya. Prinsipal dapat mencakup akun, pengguna, peran, pengguna federasi, atau layanan. AWS
Kebijakan berbasis sumber daya merupakan kebijakan inline yang terletak di layanan tersebut. Anda tidak dapat menggunakan kebijakan AWS terkelola dari IAM dalam kebijakan berbasis sumber daya.
### Daftar kontrol akses (ACLs)
Access control lists (ACLs) mengontrol prinsipal mana (anggota akun, pengguna, atau peran) yang memiliki izin untuk mengakses sumber daya. ACLs mirip dengan kebijakan berbasis sumber daya, meskipun mereka tidak menggunakan format dokumen kebijakan JSON.
Amazon S3, AWS WAF, dan Amazon VPC adalah contoh layanan yang mendukung. ACLs Untuk mempelajari selengkapnya ACLs, lihat [Ringkasan daftar kontrol akses (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) di *Panduan Pengembang Layanan Penyimpanan Sederhana Amazon*.
### Jenis-jenis kebijakan lain
AWS mendukung jenis kebijakan tambahan yang kurang umum. Jenis-jenis kebijakan ini dapat mengatur izin maksimum yang diberikan kepada Anda oleh jenis kebijakan yang lebih umum.
+ **Batasan izin** – Batasan izin adalah fitur lanjutan tempat Anda mengatur izin maksimum yang dapat diberikan oleh kebijakan berbasis identitas ke entitas IAM (pengguna IAM atau peran IAM). Anda dapat menetapkan batasan izin untuk suatu entitas. Izin yang dihasilkan adalah persimpangan kebijakan berbasis identitas entitas dan batas izinnya. Kebijakan berbasis sumber daya yang menentukan pengguna atau peran dalam bidang `Principal` tidak dibatasi oleh batasan izin. Penolakan eksplisit dalam salah satu kebijakan ini akan menggantikan pemberian izin. Untuk informasi selengkapnya tentang batasan izin, lihat [Batasan izin untuk entitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dalam *Panduan Pengguna IAM*.
+ **Kebijakan kontrol layanan (SCPs)** — SCPs adalah kebijakan JSON yang menentukan izin maksimum untuk organisasi atau unit organisasi (OU) di Organizations AWS . AWS Organizations adalah layanan untuk mengelompokkan dan mengelola beberapa AWS akun yang dimiliki bisnis Anda secara terpusat. Jika Anda mengaktifkan semua fitur dalam suatu organisasi, maka Anda dapat menerapkan kebijakan kontrol layanan (SCPs) ke salah satu atau semua akun Anda. SCP membatasi izin untuk entitas di akun anggota, termasuk setiap pengguna root AWS akun. Untuk informasi selengkapnya tentang Organizations dan SCPs, lihat [Kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) di *Panduan Pengguna AWS Organizations*.
+ **Kebijakan sesi** – Kebijakan sesi adalah kebijakan lanjutan yang Anda berikan sebagai parameter ketika Anda membuat sesi sementara secara programatis untuk peran atau pengguna terfederasi. Izin sesi yang dihasilkan adalah persimpangan kebijakan berbasis identitas pengguna atau peran dan kebijakan sesi. Izin juga bisa datang dari kebijakan berbasis sumber daya. Penolakan eksplisit dalam salah satu kebijakan ini akan menggantikan pemberian izin. Untuk informasi selengkapnya, lihat [Kebijakan sesi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dalam *Panduan Pengguna IAM*.
### Berbagai jenis kebijakan
Ketika beberapa jenis kebijakan berlaku pada suatu permintaan, izin yang dihasilkan lebih rumit untuk dipahami. Untuk mempelajari cara AWS menentukan apakah akan mengizinkan permintaan saat beberapa jenis kebijakan terlibat, lihat [Logika evaluasi kebijakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) di *Panduan Pengguna IAM*.
# Bagaimana cara Amazon EKS bekerja sama dengan IAM
Sebelum Anda menggunakan IAM untuk mengelola akses ke Amazon EKS, Anda harus memahami fitur-fitur IAM apa yang tersedia untuk digunakan dengan Amazon EKS. Untuk mendapatkan tampilan tingkat tinggi tentang cara Amazon EKS dan AWS layanan lainnya bekerja dengan IAM, lihat [AWS layanan yang bekerja dengan IAM di Panduan Pengguna *IAM*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
**Topics**
+ [Kebijakan berbasis identitas Amazon EKS](#security-iam-service-with-iam-id-based-policies)
+ [kebijakan berbasis sumber daya Amazon EKS](#security-iam-service-with-iam-resource-based-policies)
+ [Otorisasi berdasarkan tanda Amazon EKS](#security-iam-service-with-iam-tags)
+ [IAM role Amazon EKS](#security-iam-service-with-iam-roles)
## Kebijakan berbasis identitas Amazon EKS
Dengan kebijakan berbasis identitas IAM, Anda dapat menentukan apakah tindakan dan sumber daya diizinkan atau ditolak, serta persyaratan terkait diizinkan atau ditolak-nya tindakan tersebut. Amazon EKS mendukung tindakan, sumber daya, dan kunci syarat tertentu. Untuk mempelajari semua elemen yang Anda gunakan dalam kebijakan JSON, lihat [Referensi elemen kebijakan IAM JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dalam *Panduan Pengguna IAM*.
### Tindakan
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, di mana **utama** dapat melakukan **tindakan** pada **sumber daya**, dan dalam **kondisi apa**.
Elemen `Action` dari kebijakan JSON menjelaskan tindakan yang dapat Anda gunakan untuk mengizinkan atau menolak akses dalam sebuah kebijakan. Tindakan kebijakan biasanya memiliki nama yang sama dengan operasi AWS API terkait. Ada beberapa pengecualian, seperti *tindakan khusus izin yang* tidak memiliki operasi API yang cocok. Ada juga beberapa operasi yang memerlukan beberapa tindakan dalam suatu kebijakan. Tindakan tambahan ini disebut *tindakan dependen*.
Sertakan tindakan dalam kebijakan untuk memberikan izin pelaksanaan operasi yang terkait.
Tindakan kebijakan di Amazon EKS menggunakan prefiks berikut sebelum tindakan: `eks:`. Misalnya, untuk memberikan izin kepada seseorang agar mendapatkan informasi deskriptif tentang klaster Amazon EKS, Anda menyertakan tindakan `DescribeCluster` dalam kebijakan mereka. Pernyataan kebijakan harus memuat elemen `Action` atau `NotAction`.
Untuk menetapkan beberapa tindakan dalam satu pernyataan, pisahkan dengan koma seperti berikut:
```
"Action": ["eks:action1", "eks:action2"]
```
Anda dapat menentukan beberapa tindakan menggunakan wildcard (\$1). Sebagai contoh, untuk menentukan semua tindakan yang dimulai dengan kata `Describe`, sertakan tindakan berikut:
```
"Action": "eks:Describe*"
```
*Untuk melihat daftar tindakan Amazon EKS, 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)*
### Sumber daya
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, di mana **utama** dapat melakukan **tindakan** pada **sumber daya**, dan dalam **kondisi apa**.
Elemen kebijakan JSON `Resource` menentukan objek yang menjadi target penerapan tindakan. Pernyataan harus menyertakan elemen `Resource` atau `NotResource`. Praktik terbaiknya, tentukan sumber daya menggunakan [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Anda dapat melakukan ini untuk tindakan yang mendukung jenis sumber daya tertentu, yang dikenal sebagai *izin tingkat sumber daya*.
Untuk tindakan yang tidak mendukung izin tingkat sumber daya, seperti operasi daftar, gunakan wildcard (\$1) untuk menunjukkan bahwa pernyataan tersebut berlaku untuk semua sumber daya.
```
"Resource": "*"
```
Sumber daya cluster Amazon EKS memiliki ARN berikut.
```
arn:aws: eks:region-code:account-id:cluster/cluster-name
```
Untuk informasi selengkapnya tentang format ARNs, lihat [Amazon resource names (ARNs) dan ruang nama AWS layanan](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Misalnya, untuk menentukan cluster dengan nama *my-cluster* dalam pernyataan Anda, gunakan ARN berikut:
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/my-cluster"
```
Untuk menentukan semua cluster milik akun dan AWS Wilayah tertentu, gunakan wildcard (\$1):
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/*"
```
Beberapa tindakan Amazon EKS, seperti untuk membuat sumber daya, tidak dapat dilakukan pada sumber daya tertentu. Dalam kasus tersebut, Anda harus menggunakan wildcard (\$1).
```
"Resource": "*"
```
*Untuk melihat daftar jenis sumber daya Amazon EKS dan jenisnya ARNs, lihat Sumber [daya yang ditentukan oleh Amazon Elastic Kubernetes Service dalam Referensi Otorisasi](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies) Layanan.* Untuk mempelajari tindakan mana yang dapat Anda tentukan ARN dari setiap resource, 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).
### Kunci syarat
Amazon EKS menentukan set kunci syaratnya sendiri dan juga mendukung penggunaan beberapa kunci syarat global. Untuk melihat semua kunci kondisi AWS global, lihat [Kunci Konteks Kondisi AWS Global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) di *Panduan Pengguna IAM*.
Anda dapat mengatur kunci syarat ketika mengaitkan penyedia OpenID Connect ke klaster Anda. Untuk informasi selengkapnya, lihat [Contoh kebijakan IAM](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy).
Semua tindakan Amazon EC2 mendukung kunci syarat `aws:RequestedRegion` dan `ec2:Region`. Untuk informasi selengkapnya, lihat [Contoh: Membatasi Akses ke AWS Wilayah Tertentu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
*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).
### Contoh
Untuk melihat contoh kebijakan berbasis identitas Amazon EKS, lihat [Contoh kebijakan berbasis identitas Amazon EKS](security-iam-id-based-policy-examples.md).
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`
Untuk informasi lebih lanjut tentang bekerja dengan ConfigMap, lihat[Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md).
## kebijakan berbasis sumber daya Amazon EKS
Amazon EKS tidak mendukung kebijakan berbasis sumber daya.
## Otorisasi berdasarkan tanda Amazon EKS
Anda dapat melampirkan tanda ke sumber daya Amazon EKS atau meneruskan tanda dalam sebuah permintaan ke Amazon EKS. Untuk mengendalikan akses berdasarkan tanda, Anda dapat memberikan informasi tentang tanda di [elemen syarat](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) kebijakan menggunakan kunci kondisi `aws:ResourceTag/key-name `, `aws:RequestTag/key-name `, atau `aws:TagKeys`. Untuk informasi selengkapnya tentang penandaan sumber daya Amazon EKS, lihat [Mengatur sumber daya Amazon EKS dengan tag](eks-using-tags.md). Untuk informasi selengkapnya tentang tindakan yang dapat Anda gunakan dengan tag dalam kunci kondisi, lihat [Tindakan yang ditentukan oleh Amazon EKS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) di [Referensi Otorisasi Layanan](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html).
## IAM role Amazon EKS
[Peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) adalah entitas dalam AWS akun Anda yang memiliki izin tertentu.
### Menggunakan kredensial sementara dengan Amazon EKS
Anda dapat menggunakan kredensial sementara untuk masuk dengan gabungan, menjalankan IAM role, atau menjalankan peran lintas akun. Anda memperoleh kredensi keamanan sementara dengan memanggil operasi AWS STS API seperti [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)atau. [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)
Amazon EKS mendukung penggunaan kredensial sementara.
### Peran terkait layanan
[Peran terkait AWS layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) memungkinkan layanan mengakses sumber daya di layanan lain untuk menyelesaikan tindakan atas nama Anda. Peran tertaut layanan muncul di akun IAM Anda dan dimiliki oleh layanan tersebut. Administrator dapat melihat tetapi tidak dapat mengedit izin untuk peran terkait layanan.
Amazon EKS mendukung peran tertaut-layanan. Untuk informasi selengkapnya tentang cara membuat atau mengelola peran tertaut layanan Amazon EKS, lihat [Menggunakan peran tertaut layanan untuk Amazon EKS](using-service-linked-roles.md).
### Peran layanan
Fitur ini memungkinkan layanan untuk menerima [peran layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role) atas nama Anda. Peran ini mengizinkan layanan untuk mengakses sumber daya di layanan lain untuk menyelesaikan tindakan atas nama Anda. Peran layanan muncul di akun IAM Anda dan dimiliki oleh akun tersebut. Ini berarti administrator IAM dapat mengubah izin untuk peran ini. Namun, hal itu dapat merusak fungsionalitas layanan.
Amazon EKS mendukung peran layanan. Untuk informasi selengkapnya, lihat [IAM role klaster Amazon EKS](cluster-iam-role.md) dan [IAM role simpul Amazon EKS](create-node-role.md).
### Memilih IAM role di Amazon EKS
Saat Anda membuat sumber daya kluster di Amazon EKS, Anda harus memilih peran untuk memungkinkan Amazon EKS mengakses beberapa AWS sumber daya lain atas nama Anda. Jika sebelumnya Anda telah membuat peran layanan, maka Amazon EKS akan memberi Anda daftar peran untuk dipilih. Penting untuk memilih peran yang memiliki kebijakan terkelola Amazon EKS yang melekat padanya. Lihat informasi yang lebih lengkap di [Periksa apakah peran klaster sudah ada](cluster-iam-role.md#check-service-role) dan [Periksa apakah peran simpul sudah ada](create-node-role.md#check-worker-node-role).
# Contoh kebijakan berbasis identitas Amazon EKS
Secara default, pengguna dan peran IAM tidak memiliki izin untuk membuat atau memodifikasi sumber daya Amazon EKS. Mereka juga tidak dapat melakukan tugas menggunakan Konsol Manajemen AWS, AWS CLI, atau AWS API. Administrator IAM harus membuat kebijakan IAM yang memberikan izin kepada pengguna dan peran untuk melakukan operasi API tertentu pada sumber daya yang diperlukan. Administrator kemudian harus melampirkan kebijakan tersebut ke pengguna IAM atau grup yang memerlukan izin tersebut.
Untuk mempelajari cara membuat kebijakan berbasis identitas IAM menggunakan contoh dokumen kebijakan JSON ini, lihat [Membuat kebijakan di tab JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dalam *Panduan Pengguna IAM*.
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`
Untuk informasi lebih lanjut tentang bekerja dengan ConfigMap, lihat[Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md).
**Topics**
+ [Praktik terbaik kebijakan](#security-iam-service-with-iam-policy-best-practices)
+ [Menggunakan konsol Amazon EKS](#security-iam-id-based-policy-examples-console)
+ [Izinkan pengguna IAM untuk melihat izin mereka sendiri](#security-iam-id-based-policy-examples-view-own-permissions)
+ [Buat klaster Kubernetes di Cloud AWS](#policy-create-cluster)
+ [Buat klaster Kubernetes lokal di Outpost](#policy-create-local-cluster)
+ [Perbarui klaster Kubernetes](#policy-example1)
+ [Buat daftar atau deskripsikan semua klaster](#policy-example2)
## Praktik terbaik kebijakan
Kebijakan berbasis identitas menentukan apakah seseorang dapat membuat, mengakses, atau menghapus sumber daya Amazon EKS di akun Anda. Tindakan ini dapat menimbulkan biaya untuk AWS akun Anda. Ketika Anda membuat atau mengedit kebijakan berbasis identitas, ikuti panduan dan rekomendasi ini:
+ **Mulailah dengan kebijakan AWS terkelola dan beralih ke izin hak istimewa paling sedikit — Untuk mulai memberikan izin** kepada pengguna dan beban kerja Anda, gunakan *kebijakan AWS terkelola* yang memberikan izin untuk banyak kasus penggunaan umum. Mereka tersedia di AWS akun Anda. Kami menyarankan Anda mengurangi izin lebih lanjut dengan menentukan kebijakan yang dikelola AWS pelanggan yang khusus untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat [Kebijakan yang dikelola AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) atau [Kebijakan yang dikelola AWS untuk fungsi tugas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dalam *Panduan Pengguna IAM*.
+ **Menerapkan izin dengan hak akses paling rendah** – Ketika Anda menetapkan izin dengan kebijakan IAM, hanya berikan izin yang diperlukan untuk melakukan tugas. Anda melakukannya dengan mendefinisikan tindakan yang dapat diambil pada sumber daya tertentu dalam kondisi tertentu, yang juga dikenal sebagai *izin dengan hak akses paling rendah*. Untuk informasi selengkapnya tentang cara menggunakan IAM untuk mengajukan izin, lihat [Kebijakan dan izin dalam IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dalam *Panduan Pengguna IAM*.
+ **Gunakan kondisi dalam kebijakan IAM untuk membatasi akses lebih lanjut** – Anda dapat menambahkan suatu kondisi ke kebijakan Anda untuk membatasi akses ke tindakan dan sumber daya. Sebagai contoh, Anda dapat menulis kondisi kebijakan untuk menentukan bahwa semua permintaan harus dikirim menggunakan SSL. Anda juga dapat menggunakan ketentuan untuk memberikan akses ke tindakan layanan jika digunakan melalui AWS layanan tertentu, seperti AWS CloudFormation. Untuk informasi selengkapnya, lihat [Elemen kebijakan JSON IAM: Kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dalam *Panduan Pengguna IAM*.
+ **Gunakan IAM Access Analyzer untuk memvalidasi kebijakan IAM Anda untuk memastikan izin yang aman dan fungsional** – IAM Access Analyzer memvalidasi kebijakan baru dan yang sudah ada sehingga kebijakan tersebut mematuhi bahasa kebijakan IAM (JSON) dan praktik terbaik IAM. IAM Access Analyzer menyediakan lebih dari 100 pemeriksaan kebijakan dan rekomendasi yang dapat ditindaklanjuti untuk membantu Anda membuat kebijakan yang aman dan fungsional. Untuk informasi selengkapnya, lihat [Validasi kebijakan IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dalam *Panduan Pengguna IAM*.
+ **Memerlukan otentikasi multi-faktor (MFA)** - Jika Anda memiliki skenario yang mengharuskan pengguna IAM atau pengguna root di akun Anda AWS , aktifkan MFA untuk keamanan tambahan. Untuk meminta MFA ketika operasi API dipanggil, tambahkan kondisi MFA pada kebijakan Anda. Untuk informasi selengkapnya, lihat [Mengonfigurasi akses API yang dilindungi MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dalam *Panduan Pengguna IAM*.
Untuk informasi selengkapnya tentang praktik terbaik dalam IAM, lihat [Praktik terbaik keamanan dalam IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dalam *Panduan Pengguna IAM*.
## Menggunakan konsol Amazon EKS
Untuk mengakses konsol Amazon EKS, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), harus memiliki set izin minimum. Izin ini memungkinkan kepala sekolah untuk membuat daftar dan melihat detail tentang sumber daya Amazon EKS di AWS akun Anda. Jika Anda membuat kebijakan berbasis identitas yang lebih ketat daripada izin minimum yang diperlukan, konsol tidak akan berfungsi sebagaimana dimaksud untuk prinsipal dengan kebijakan yang dilampirkan padanya.
Untuk memastikan bahwa prinsipal IAM Anda masih dapat menggunakan konsol Amazon EKS, buat kebijakan dengan nama unik Anda sendiri, seperti. `AmazonEKSAdminPolicy` Lampirkan kebijakan ke kepala sekolah. Untuk informasi lebih lanjut, lihat [Menambahkan dan menghapus izin identitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dalam *Panduan Pengguna IAM*.
**penting**
Contoh kebijakan berikut memungkinkan prinsipal untuk melihat informasi pada tab **Konfigurasi** di konsol. Untuk melihat informasi pada tab **Ikhtisar** dan **Sumber Daya** di Konsol Manajemen AWS, prinsipal juga membutuhkan izin Kubernetes. Untuk informasi selengkapnya, lihat [Izin yang diperlukan](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
Anda tidak perlu mengizinkan izin konsol minimum untuk prinsipal yang melakukan panggilan hanya ke CLI AWS atau API. AWS Sebagai gantinya, izinkan akses hanya ke tindakan yang cocok dengan operasi API yang Anda coba lakukan.
## Izinkan pengguna IAM untuk melihat izin mereka sendiri
Contoh ini menunjukkan cara membuat kebijakan yang mengizinkan pengguna IAM melihat kebijakan inline dan terkelola yang dilampirkan ke identitas pengguna mereka. Kebijakan ini mencakup izin untuk menyelesaikan tindakan ini di konsol atau menggunakan CLI AWS atau API secara terprogram. AWS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Buat klaster Kubernetes di Cloud AWS
Kebijakan contoh ini mencakup izin minimum yang diperlukan untuk membuat klaster Amazon EKS yang diberi nama *my-cluster* di *us-west-2* AWS Wilayah. Anda dapat mengganti AWS Region dengan AWS Region tempat Anda ingin membuat klaster. Jika Anda melihat peringatan yang mengatakan **Tindakan dalam kebijakan Anda tidak mendukung izin tingkat sumber daya dan mengharuskan Anda untuk memilih** Konsol Manajemen AWS, tindakan tersebut dapat `All resources` diabaikan dengan aman. Jika akun Anda sudah memiliki *AWSServiceRoleForAmazonEKS* peran, Anda dapat menghapus `iam:CreateServiceLinkedRole` tindakan dari kebijakan. Jika Anda pernah membuat kluster Amazon EKS di akun Anda, maka peran ini sudah ada, kecuali Anda menghapusnya.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Buat klaster Kubernetes lokal di Outpost
Kebijakan contoh ini mencakup izin minimum yang diperlukan untuk membuat klaster lokal Amazon EKS yang diberi nama *my-cluster* di Pos Luar di *us-west-2* AWS Wilayah. Anda dapat mengganti AWS Region dengan AWS Region tempat Anda ingin membuat klaster. Jika Anda melihat peringatan yang mengatakan **Tindakan dalam kebijakan Anda tidak mendukung izin tingkat sumber daya dan mengharuskan Anda untuk memilih** Konsol Manajemen AWS, tindakan tersebut dapat `All resources` diabaikan dengan aman. Jika akun Anda sudah memiliki `AWSServiceRoleForAmazonEKSLocalOutpost` peran, Anda dapat menghapus `iam:CreateServiceLinkedRole` tindakan dari kebijakan. Jika Anda pernah membuat kluster lokal Amazon EKS di Outpost di akun Anda, maka peran ini sudah ada, kecuali Anda menghapusnya.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Perbarui klaster Kubernetes
Kebijakan contoh ini mencakup izin minimum yang diperlukan untuk memperbarui klaster bernama *my-cluster* di Wilayah us-west-2 AWS .
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## Buat daftar atau deskripsikan semua klaster
Kebijakan contoh ini mencakup izin minimum yang diperlukan untuk mencantumkan dan menjelaskan semua klaster di akun Anda. [Prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) harus dapat membuat daftar dan mendeskripsikan cluster untuk menggunakan perintah CLI `update-kubeconfig` AWS .
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Menggunakan peran tertaut layanan untuk Amazon EKS
[Amazon Elastic Kubernetes Service AWS menggunakan peran terkait layanan Identity and Access Management (IAM) and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan mencakup semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
**Topics**
+ [Menggunakan peran untuk klaster Amazon EKS](using-service-linked-roles-eks.md)
+ [Menggunakan peran untuk grup simpul Amazon EKS](using-service-linked-roles-eks-nodegroups.md)
+ [Menggunakan peran untuk profil Amazon EKS Fargate](using-service-linked-roles-eks-fargate.md)
+ [Menggunakan peran untuk menghubungkan klaster Kubernetes ke Amazon EKS](using-service-linked-roles-eks-connector.md)
+ [Menggunakan peran untuk kluster lokal Amazon EKS di Outpost](using-service-linked-roles-eks-outpost.md)
+ [Menggunakan peran untuk Dasbor Amazon EKS](using-service-linked-roles-eks-dashboard.md)
# Menggunakan peran untuk klaster Amazon EKS
[Amazon Elastic Kubernetes Service AWS menggunakan peran terkait layanan Identity and Access Management (IAM) and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan mencakup semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
Peran terkait layanan membuat pengaturan Amazon EKS lebih mudah karena Anda tidak perlu menambahkan izin yang diperlukan secara manual. Amazon EKS menentukan izin atas peran tertaut layanan, dan jika tidak ada ketentuan lain, hanya Amazon EKS yang dapat menjalankan perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, dan kebijakan izin tersebut tidak dapat dilampirkan ke entitas IAM lainnya.
Anda dapat menghapus peran tertaut layanan hanya setelah menghapus sumber daya terkait terlebih dahulu. Ini melindungi sumber daya Amazon EKS Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, silakan lihat [layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dan carilah layanan yang memiliki opsi **Ya** di kolom **Peran terkait layanan**. Pilih **Ya** bersama tautan untuk melihat dokumentasi peran tertaut layanan untuk layanan tersebut.
## Izin peran tertaut layanan untuk Amazon EKS
Amazon EKS menggunakan peran terkait layanan bernama. `AWSServiceRoleForAmazonEKS` Peran ini memungkinkan Amazon EKS untuk mengelola cluster di akun Anda. Kebijakan terlampir memungkinkan peran untuk mengelola sumber daya berikut: antarmuka jaringan, grup keamanan, log, dan VPCs file.
**catatan**
Peran tertaut layanan `AWSServiceRoleForAmazonEKS` berbeda dari peran yang diperlukan untuk pembuatan klaster. Untuk informasi selengkapnya, lihat [IAM role klaster Amazon EKS](cluster-iam-role.md).
Peran tertaut layanan `AWSServiceRoleForAmazonEKS` mempercayai layanan berikut untuk mengambil peran tersebut:
+ `eks.amazonaws.com`
Kebijakan izin peran mengizinkan Amazon EKS untuk menyelesaikan tindakan berikut pada sumber daya yang ditentukan:
+ [Amazon EKSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Anda harus mengonfigurasi izin untuk mengizinkan entitas IAM (seperti pengguna, grup, atau peran) untuk membuat, mengedit, atau menghapus peran terkait layanan. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dalam *Panduan Pengguna IAM*.
## Membuat peran tertaut layanan untuk Amazon EKS
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda membuat klaster di Konsol Manajemen AWS, AWS CLI, atau AWS API, Amazon EKS membuat peran terkait layanan untuk Anda.
Jika Anda menghapus peran tertaut layanan ini, dan ingin membuatnya lagi, Anda dapat mengulangi proses yang sama untuk membuat peran tersebut di akun Anda. Ketika Anda membuat klaster, Amazon EKS membuatkan peran tertaut layanan lagi untuk Anda.
## Mengedit Peran tertaut layanan untuk Amazon EKS
Amazon EKS tidak mengizinkan Anda untuk mengedit peran tertaut layanan `AWSServiceRoleForAmazonEKS`. Setelah membuat peran tertaut layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin mereferensikan peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
## Menghapus peran tertaut layanan untuk Amazon EKS
Jika Anda tidak perlu lagi menggunakan fitur atau layanan yang memerlukan peran terkait layanan, kami merekomendasikan Anda menghapus peran tersebut. Dengan begitu, Anda tidak memiliki entitas yang tidak digunakan dan tidak dipantau atau dipelihara secara aktif. Namun, Anda harus membersihkan peran tertaut layanan terlebih dahulu sebelum dapat menghapusnya secara manual.
### Membersihkan peran tertaut-layanan
Sebelum dapat menggunakan IAM untuk menghapus peran tertaut-layanan, Anda harus terlebih dahulu menghapus semua sumber daya yang digunakan oleh peran tersebut.
**catatan**
Jika layanan Amazon EKS menggunakan peran saat Anda mencoba untuk menghapus sumber daya, maka penghapusan tersebut kemungkinan gagal. Jika hal itu terjadi, tunggu beberapa menit dan coba mengoperasikannya lagi.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi sebelah kiri, pilih **Klaster**.
1. Jika klaster Anda memiliki grup simpul atau profil Fargate, Anda harus menghapusnya sebelum dapat menghapus klaster. Untuk informasi lebih lanjut, lihat [Menghapus grup node terkelola dari klaster](delete-managed-node-group.md) dan [Hapus profil Fargate](delete-fargate-profile.md).
1. Pada halaman **Klaster**, pilih klaster yang ingin Anda hapus dan pilih **Hapus**.
1. Ketik nama klaster di jendela konfirmasi penghapusan, dan kemudian pilih **Hapus**.
1. Ulangi prosedur ini untuk klaster lain di akun Anda. Tunggu sampai semua operasi penghapusan selesai.
### Hapus peran tertaut layanan secara manual
Gunakan konsol IAM, AWS CLI, atau AWS API untuk menghapus peran terkait layanan`AWSServiceRoleForAmazonEKS`. Untuk informasi selengkapnya, lihat [Menghapus peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dalam *Panduan Pengguna IAM*.
## Wilayah yang didukung untuk peran tertaut-layanan Amazon EKS
Amazon EKS mendukung penggunaan peran tertaut-layanan di semua wilayah tempat layanan tersedia. Untuk informasi selengkapnya, lihat [titik akhir dan kuota Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Menggunakan peran untuk grup simpul Amazon EKS
[Amazon EKS menggunakan peran AWS terkait layanan Identity and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan mencakup semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
Peran terkait layanan membuat pengaturan Amazon EKS lebih mudah karena Anda tidak perlu menambahkan izin yang diperlukan secara manual. Amazon EKS menentukan izin atas peran tertaut layanan, dan jika tidak ada ketentuan lain, hanya Amazon EKS yang dapat menjalankan perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, dan kebijakan izin tersebut tidak dapat dilampirkan ke entitas IAM lainnya.
Anda dapat menghapus peran tertaut layanan hanya setelah menghapus sumber daya terkait terlebih dahulu. Ini melindungi sumber daya Amazon EKS Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, silakan lihat [layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dan carilah layanan yang memiliki opsi **Ya** di kolom **Peran terkait layanan**. Pilih **Ya** bersama tautan untuk melihat dokumentasi peran tertaut layanan untuk layanan tersebut.
## Izin peran tertaut layanan untuk Amazon EKS
Amazon EKS menggunakan peran terkait layanan bernama. `AWSServiceRoleForAmazonEKSNodegroup` Peran ini memungkinkan Amazon EKS untuk mengelola grup node di akun Anda. `AWSServiceRoleForAmazonEKSNodegroup`Kebijakan terlampir memungkinkan peran mengelola sumber daya berikut: Grup Auto Scaling, grup keamanan, templat peluncuran, dan profil instans IAM. Untuk informasi selengkapnya, lihat [AWS kebijakan terkelola: AWSService RoleForAmazon EKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup).
Peran tertaut layanan `AWSServiceRoleForAmazonEKSNodegroup` mempercayai layanan berikut untuk mengambil peran tersebut:
+ `eks-nodegroup.amazonaws.com`
Kebijakan izin peran mengizinkan Amazon EKS untuk menyelesaikan tindakan berikut pada sumber daya yang ditentukan:
+ [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
Anda harus mengonfigurasi izin untuk mengizinkan entitas IAM (seperti pengguna, grup, atau peran) untuk membuat, mengedit, atau menghapus peran tertaut layanan. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dalam *Panduan Pengguna IAM*.
## Membuat peran tertaut layanan untuk Amazon EKS
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda CreateNodegroup berada di Konsol Manajemen AWS, AWS CLI, atau AWS API, Amazon EKS membuat peran terkait layanan untuk Anda.
**penting**
Peran tertaut layanan ini dapat muncul di akun Anda jika Anda menyelesaikan tindakan di layanan lain yang menggunakan fitur yang disupport oleh peran ini. Jika Anda menggunakan layanan Amazon EKS sebelum 1 Januari 2017, ketika mulai mendukung peran terkait layanan, maka Amazon EKS membuat AWSService RoleForAmazon EKSNodegroup peran di akun Anda. Untuk mempelajari lebih lanjut, lihat [Peran baru muncul di akun IAM saya](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Membuat peran terkait layanan di Amazon EKS (API)AWS
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda membuat grup node terkelola di Konsol Manajemen AWS, AWS CLI, atau AWS API, Amazon EKS membuat peran terkait layanan untuk Anda.
Jika Anda menghapus peran tertaut layanan ini, dan ingin membuatnya lagi, Anda dapat mengulangi proses yang sama untuk membuat kembali peran tersebut di akun Anda. Ketika Anda membuat grup simpul terkelola lainnya, Amazon EKS membuatkan peran tertaut layanan lagi untuk Anda.
## Mengedit peran tertaut-layanan untuk Amazon EKS
Amazon EKS tidak mengizinkan Anda untuk mengedit peran tertaut layanan `AWSServiceRoleForAmazonEKSNodegroup`. Setelah membuat peran tertaut layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin mereferensikan peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
## Menghapus peran tertaut layanan untuk Amazon EKS
Jika Anda tidak perlu lagi menggunakan fitur atau layanan yang memerlukan peran terkait layanan, kami merekomendasikan Anda menghapus peran tersebut. Dengan begitu, Anda tidak memiliki entitas yang tidak digunakan dan tidak dipantau atau dipelihara secara aktif. Namun, Anda harus membersihkan peran tertaut layanan terlebih dahulu sebelum dapat menghapusnya secara manual.
### Membersihkan peran tertaut-layanan
Sebelum dapat menggunakan IAM untuk menghapus peran tertaut-layanan, Anda harus terlebih dahulu menghapus semua sumber daya yang digunakan oleh peran tersebut.
**catatan**
Jika layanan Amazon EKS menggunakan peran saat Anda mencoba untuk menghapus sumber daya, maka penghapusan tersebut kemungkinan gagal. Jika hal itu terjadi, tunggu beberapa menit dan coba mengoperasikannya lagi.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pada panel navigasi sebelah kiri, pilih **Klaster**.
1. Pilih tab **Compute**.
1. Di bagian **Node groups**, pilih grup node yang akan dihapus.
1. Ketik nama grup simpul di jendela konfirmasi penghapusan, dan kemudian pilih **Hapus**.
1. Ulangi prosedur ini untuk grup simpul lainnya dalam klaster. Tunggu sampai semua operasi penghapusan selesai.
### Hapus peran tertaut layanan secara manual
Gunakan konsol IAM, AWS CLI, atau AWS API untuk menghapus peran terkait layanan`AWSServiceRoleForAmazonEKSNodegroup`. Untuk informasi selengkapnya, lihat [Menghapus peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dalam *Panduan Pengguna IAM*.
## Wilayah yang didukung untuk peran tertaut-layanan Amazon EKS
Amazon EKS mendukung penggunaan peran tertaut-layanan di semua wilayah tempat layanan tersedia. Untuk informasi selengkapnya, lihat [titik akhir dan kuota Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Menggunakan peran untuk profil Amazon EKS Fargate
[Amazon EKS menggunakan peran AWS terkait layanan Identity and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan mencakup semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
Peran terkait layanan membuat pengaturan Amazon EKS lebih mudah karena Anda tidak perlu menambahkan izin yang diperlukan secara manual. Amazon EKS menentukan izin atas peran tertaut layanan, dan jika tidak ada ketentuan lain, hanya Amazon EKS yang dapat menjalankan perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, dan kebijakan izin tersebut tidak dapat dilampirkan ke entitas IAM lainnya.
Anda dapat menghapus peran tertaut layanan hanya setelah menghapus sumber daya terkait terlebih dahulu. Ini melindungi sumber daya Amazon EKS Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, silakan lihat [layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dan carilah layanan yang memiliki opsi **Ya** di kolom **Peran terkait layanan**. Pilih **Ya** bersama tautan untuk melihat dokumentasi peran tertaut layanan untuk layanan tersebut.
## Izin peran tertaut layanan untuk Amazon EKS
Amazon EKS menggunakan peran terkait layanan bernama. `AWSServiceRoleForAmazonEKSForFargate` Peran ini memungkinkan Amazon EKS Fargate untuk mengonfigurasi jaringan VPC yang diperlukan untuk Pod Fargate. Kebijakan terlampir memungkinkan peran untuk membuat dan menghapus antarmuka jaringan elastis dan menggambarkan Antarmuka dan sumber daya jaringan elastis.
Peran tertaut layanan `AWSServiceRoleForAmazonEKSForFargate` mempercayai layanan berikut untuk mengambil peran tersebut:
+ `eks-fargate.amazonaws.com`
Kebijakan izin peran mengizinkan Amazon EKS untuk menyelesaikan tindakan berikut pada sumber daya yang ditentukan:
+ [Amazon EKSFor FargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
Anda harus mengonfigurasi izin untuk mengizinkan entitas IAM (seperti pengguna, grup, atau peran) untuk membuat, mengedit, atau menghapus peran terkait layanan. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dalam *Panduan Pengguna IAM*.
## Membuat peran tertaut layanan untuk Amazon EKS
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda membuat profil Fargate di Konsol Manajemen AWS, AWS CLI, atau API AWS , Amazon EKS membuat peran terkait layanan untuk Anda.
**penting**
Peran tertaut layanan ini dapat muncul di akun Anda jika Anda menyelesaikan tindakan di layanan lain yang menggunakan fitur yang disupport oleh peran ini. Jika Anda menggunakan layanan Amazon EKS sebelum 13 Desember 2019, ketika mulai mendukung peran terkait layanan, maka Amazon EKS membuat peran AWSService RoleForAmazon EKSFor Fargate di akun Anda. Untuk mempelajari lebih lanjut, lihat [Peran baru muncul di akun IAM saya](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Membuat peran terkait layanan di Amazon EKS (API)AWS
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda membuat profil Fargate di Konsol Manajemen AWS, AWS CLI, atau API AWS , Amazon EKS membuat peran terkait layanan untuk Anda.
Jika Anda menghapus peran tertaut layanan ini, dan ingin membuatnya lagi, Anda dapat mengulangi proses yang sama untuk membuat kembali peran tersebut di akun Anda. Ketika Anda membuat grup simpul terkelola lainnya, Amazon EKS membuatkan peran tertaut layanan lagi untuk Anda.
## Mengedit peran tertaut-layanan untuk Amazon EKS
Amazon EKS tidak mengizinkan Anda untuk mengedit peran tertaut layanan `AWSServiceRoleForAmazonEKSForFargate`. Setelah membuat peran tertaut layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin mereferensikan peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
## Menghapus peran tertaut layanan untuk Amazon EKS
Jika Anda tidak perlu lagi menggunakan fitur atau layanan yang memerlukan peran terkait layanan, kami merekomendasikan Anda menghapus peran tersebut. Dengan begitu, Anda tidak memiliki entitas yang tidak digunakan dan tidak dipantau atau dipelihara secara aktif. Namun, Anda harus membersihkan peran tertaut layanan terlebih dahulu sebelum dapat menghapusnya secara manual.
### Membersihkan peran tertaut-layanan
Sebelum dapat menggunakan IAM untuk menghapus peran tertaut-layanan, Anda harus terlebih dahulu menghapus semua sumber daya yang digunakan oleh peran tersebut.
**catatan**
Jika layanan Amazon EKS menggunakan peran saat Anda mencoba untuk menghapus sumber daya, maka penghapusan tersebut kemungkinan gagal. Jika hal itu terjadi, tunggu beberapa menit dan coba mengoperasikannya lagi.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pada panel navigasi sebelah kiri, pilih **Klaster**.
1. Pada halaman **Klaster**, pilih klaster Anda.
1. Pilih tab **Compute**.
1. **Jika ada profil Fargate di bagian **profil Fargate**, pilih masing-masing satu per satu, lalu pilih Hapus.**
1. Ketik nama profil di jendela konfirmasi penghapusan, dan kemudian pilih **Hapus**.
1. Ulangi prosedur ini untuk profil Fargate lainnya di dalam klaster dan untuk klaster lainnya di akun Anda.
### Untuk menghapus peran tertaut-layanan secara manual
Gunakan konsol IAM, AWS CLI, atau API untuk menghapus AWS peran terkait layanan AWSService RoleForAmazon EKSFor Fargate. Untuk informasi selengkapnya, lihat [Menghapus peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dalam *Panduan Pengguna IAM*.
## Wilayah yang didukung untuk peran tertaut-layanan Amazon EKS
Amazon EKS mendukung penggunaan peran tertaut-layanan di semua wilayah tempat layanan tersedia. Untuk informasi selengkapnya, lihat [titik akhir dan kuota Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Menggunakan peran untuk menghubungkan klaster Kubernetes ke Amazon EKS
[Amazon EKS menggunakan peran AWS terkait layanan Identity and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan mencakup semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
Peran terkait layanan membuat pengaturan Amazon EKS lebih mudah karena Anda tidak perlu menambahkan izin yang diperlukan secara manual. Amazon EKS menentukan izin atas peran tertaut layanan, dan jika tidak ada ketentuan lain, hanya Amazon EKS yang dapat menjalankan perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, dan kebijakan izin tersebut tidak dapat dilampirkan ke entitas IAM lainnya.
Anda dapat menghapus peran tertaut layanan hanya setelah menghapus sumber daya terkait terlebih dahulu. Ini melindungi sumber daya Amazon EKS Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, silakan lihat [layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dan carilah layanan yang memiliki opsi **Ya** di kolom **Peran terkait layanan**. Pilih **Ya** bersama tautan untuk melihat dokumentasi peran tertaut layanan untuk layanan tersebut.
## Izin peran tertaut layanan untuk Amazon EKS
Amazon EKS menggunakan peran terkait layanan bernama. `AWSServiceRoleForAmazonEKSConnector` Peran ini memungkinkan Amazon EKS untuk menghubungkan cluster Kubernetes. Kebijakan terlampir memungkinkan peran untuk mengelola sumber daya yang diperlukan untuk terhubung ke klaster Kubernetes Anda yang terdaftar.
Peran tertaut layanan `AWSServiceRoleForAmazonEKSConnector` mempercayai layanan berikut untuk mengambil peran tersebut:
+ `eks-connector.amazonaws.com`
Kebijakan izin peran mengizinkan Amazon EKS untuk menyelesaikan tindakan berikut pada sumber daya yang ditentukan:
+ [Amazon EKSConnector ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
Anda harus mengonfigurasi izin untuk mengizinkan entitas IAM (seperti pengguna, grup, atau peran) untuk membuat, mengedit, atau menghapus peran terkait layanan. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dalam *Panduan Pengguna IAM*.
Peran ini menggunakan izin SSM (Systems Manager) untuk membuat koneksi aman dan mengelola klaster Kubernetes yang terhubung.
## Membuat peran tertaut layanan untuk Amazon EKS
Anda tidak perlu membuat peran terkait layanan secara manual untuk menghubungkan kluster. Saat Anda menghubungkan cluster di Konsol Manajemen AWS, AWS CLI, atau AWS API`eksctl`, Amazon EKS membuat peran terkait layanan untuk Anda.
Jika Anda menghapus peran terkait layanan ini, dan ingin membuatnya lagi, Anda dapat mengulangi proses yang sama untuk membuat kembali peran tersebut di akun Anda. Saat Anda menghubungkan kluster, Amazon EKS membuat peran terkait layanan untuk Anda lagi.
## Mengedit Peran tertaut layanan untuk Amazon EKS
Amazon EKS tidak mengizinkan Anda untuk mengedit peran tertaut layanan `AWSServiceRoleForAmazonEKSConnector`. Setelah membuat peran tertaut layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin mereferensikan peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
## Menghapus peran tertaut layanan untuk Amazon EKS
Jika Anda tidak perlu lagi menggunakan fitur atau layanan yang memerlukan peran terkait layanan, sebaiknya hapus peran tersebut. Dengan begitu, Anda tidak memiliki entitas yang tidak digunakan dan tidak dipantau atau dipelihara secara aktif. Namun, Anda harus membersihkan peran tertaut layanan terlebih dahulu sebelum dapat menghapusnya secara manual.
### Membersihkan peran tertaut-layanan
Sebelum dapat menggunakan IAM untuk menghapus peran tertaut-layanan, Anda harus terlebih dahulu menghapus semua sumber daya yang digunakan oleh peran tersebut.
**catatan**
Jika layanan Amazon EKS menggunakan peran saat Anda mencoba untuk menghapus sumber daya, maka penghapusan tersebut kemungkinan gagal. Jika hal itu terjadi, tunggu beberapa menit dan coba mengoperasikannya lagi.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pada panel navigasi sebelah kiri, pilih **Klaster**.
1. Pada halaman **Klaster**, pilih klaster Anda.
1. **Pilih tab **Deregister** dan kemudian pilih tab Ok.**
### Menghapus peran tertaut layanan secara manual
Gunakan konsol IAM, AWS CLI, atau AWS API untuk menghapus peran terkait layanan AWSService RoleForAmazonEKSConnector . Untuk informasi selengkapnya, lihat [Menghapus peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dalam *Panduan Pengguna IAM*.
# Menggunakan peran untuk kluster lokal Amazon EKS di Outpost
[Amazon Elastic Kubernetes Service AWS menggunakan peran terkait layanan Identity and Access Management (IAM) and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan mencakup semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
Peran terkait layanan membuat pengaturan Amazon EKS lebih mudah karena Anda tidak perlu menambahkan izin yang diperlukan secara manual. Amazon EKS menentukan izin atas peran tertaut layanan, dan jika tidak ada ketentuan lain, hanya Amazon EKS yang dapat menjalankan perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, dan kebijakan izin tersebut tidak dapat dilampirkan ke entitas IAM lainnya.
Anda dapat menghapus peran tertaut layanan hanya setelah menghapus sumber daya terkait terlebih dahulu. Ini melindungi sumber daya Amazon EKS Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, silakan lihat [layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dan carilah layanan yang memiliki opsi **Ya** di kolom **Peran terkait layanan**. Pilih **Ya** bersama tautan untuk melihat dokumentasi peran tertaut layanan untuk layanan tersebut.
## Izin peran tertaut layanan untuk Amazon EKS
Amazon EKS menggunakan peran terkait layanan bernama. `AWSServiceRoleForAmazonEKSLocalOutpost` Peran ini memungkinkan Amazon EKS untuk mengelola cluster lokal di akun Anda. Kebijakan terlampir memungkinkan peran mengelola sumber daya berikut: antarmuka jaringan, grup keamanan, log, dan EC2 instans Amazon.
**catatan**
Peran tertaut layanan `AWSServiceRoleForAmazonEKSLocalOutpost` berbeda dari peran yang diperlukan untuk pembuatan klaster. Untuk informasi selengkapnya, lihat [IAM role klaster Amazon EKS](cluster-iam-role.md).
Peran tertaut layanan `AWSServiceRoleForAmazonEKSLocalOutpost` mempercayai layanan berikut untuk mengambil peran tersebut:
+ `outposts.eks-local.amazonaws.com`
Kebijakan izin peran mengizinkan Amazon EKS untuk menyelesaikan tindakan berikut pada sumber daya yang ditentukan:
+ [Amazon EKSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Anda harus mengonfigurasi izin untuk mengizinkan entitas IAM (seperti pengguna, grup, atau peran) untuk membuat, mengedit, atau menghapus peran terkait layanan. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dalam *Panduan Pengguna IAM*.
## Membuat peran tertaut layanan untuk Amazon EKS
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda membuat klaster di Konsol Manajemen AWS, AWS CLI, atau AWS API, Amazon EKS membuat peran terkait layanan untuk Anda.
Jika Anda menghapus peran tertaut layanan ini, dan ingin membuatnya lagi, Anda dapat mengulangi proses yang sama untuk membuat peran tersebut di akun Anda. Ketika Anda membuat klaster, Amazon EKS membuatkan peran tertaut layanan lagi untuk Anda.
## Mengedit Peran tertaut layanan untuk Amazon EKS
Amazon EKS tidak mengizinkan Anda untuk mengedit peran tertaut layanan `AWSServiceRoleForAmazonEKSLocalOutpost`. Setelah membuat peran terkait layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin mereferensikan peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
## Menghapus peran tertaut layanan untuk Amazon EKS
Jika Anda tidak perlu lagi menggunakan fitur atau layanan yang memerlukan peran terkait layanan, kami merekomendasikan Anda menghapus peran tersebut. Dengan begitu, Anda tidak memiliki entitas yang tidak digunakan dan tidak dipantau atau dipelihara secara aktif. Namun, Anda harus membersihkan peran tertaut layanan terlebih dahulu sebelum dapat menghapusnya secara manual.
### Membersihkan peran tertaut-layanan
Sebelum dapat menggunakan IAM untuk menghapus peran tertaut-layanan, Anda harus terlebih dahulu menghapus semua sumber daya yang digunakan oleh peran tersebut.
**catatan**
Jika layanan Amazon EKS menggunakan peran saat Anda mencoba untuk menghapus sumber daya, maka penghapusan tersebut kemungkinan gagal. Jika hal itu terjadi, tunggu beberapa menit dan coba mengoperasikannya lagi.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih Amazon EKS **Clusters**.
1. Jika klaster Anda memiliki grup simpul atau profil Fargate, Anda harus menghapusnya sebelum dapat menghapus klaster. Untuk informasi lebih lanjut, lihat [Menghapus grup node terkelola dari klaster](delete-managed-node-group.md) dan [Hapus profil Fargate](delete-fargate-profile.md).
1. Pada halaman **Klaster**, pilih klaster yang ingin Anda hapus dan pilih **Hapus**.
1. Ketik nama klaster di jendela konfirmasi penghapusan, dan kemudian pilih **Hapus**.
1. Ulangi prosedur ini untuk klaster lain di akun Anda. Tunggu sampai semua operasi penghapusan selesai.
### Hapus peran tertaut layanan secara manual
Gunakan konsol IAM, AWS CLI, atau AWS API untuk menghapus peran terkait layanan`AWSServiceRoleForAmazonEKSLocalOutpost`. Untuk informasi selengkapnya, lihat [Menghapus peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dalam *Panduan Pengguna IAM*.
## Wilayah yang didukung untuk peran tertaut-layanan Amazon EKS
Amazon EKS mendukung penggunaan peran tertaut-layanan di semua wilayah tempat layanan tersedia. Untuk informasi selengkapnya, lihat [titik akhir dan kuota Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Menggunakan peran untuk Dasbor Amazon EKS
Dasbor Amazon EKS menggunakan peran terkait layanan ini untuk mengumpulkan informasi tentang sumber daya klaster dari beberapa wilayah dan akun. Dasbor terintegrasi dengan AWS Organizations untuk membaca informasi tentang beberapa akun di organisasi Anda dengan aman.
Untuk mempelajari lebih lanjut tentang Dasbor Amazon EKS, lihat[Melihat data agregat tentang sumber daya klaster dengan Dasbor EKS](cluster-dashboard.md).
## Latar Belakang
[Amazon EKS menggunakan peran AWS terkait layanan Identity and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan mencakup semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
Peran terkait layanan membuat pengaturan Amazon EKS lebih mudah karena Anda tidak perlu menambahkan izin yang diperlukan secara manual. Amazon EKS menentukan izin atas peran tertaut layanan, dan jika tidak ada ketentuan lain, hanya Amazon EKS yang dapat menjalankan perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, dan kebijakan izin tersebut tidak dapat dilampirkan ke entitas IAM lainnya.
Anda dapat menghapus peran tertaut layanan hanya setelah menghapus sumber daya terkait terlebih dahulu. Ini melindungi sumber daya Amazon EKS Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, silakan lihat [layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dan carilah layanan yang memiliki opsi **Ya** di kolom **Peran terkait layanan**. Pilih **Ya** bersama tautan untuk melihat dokumentasi peran tertaut layanan untuk layanan tersebut.
## Izin peran tertaut layanan untuk Amazon EKS
Amazon EKS menggunakan peran terkait layanan bernama. `AWSServiceRoleForAmazonEKSDashboard` Peran ini memungkinkan Amazon EKS untuk menghasilkan dan menampilkan Dasbor EKS, termasuk informasi gabungan tentang sumber daya cluster. `AmazonEKSDashboardServiceRolePolicy`Kebijakan terlampir memungkinkan peran mengelola sumber daya berikut: Grup Auto Scaling, grup keamanan, templat peluncuran, dan profil instans IAM. Untuk informasi selengkapnya, lihat [AWS kebijakan terkelola: Amazon EKSDashboard ServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy).
Peran tertaut layanan `AWSServiceRoleForAmazonEKSDashboard` memercayai layanan berikut untuk mengambil peran tersebut:
+ `dashboard.eks.amazonaws.com`
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSDashboard ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
Anda harus mengonfigurasi izin untuk mengizinkan entitas IAM (seperti pengguna, grup, atau peran) untuk membuat, mengedit, atau menghapus peran terkait layanan. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dalam *Panduan Pengguna IAM*.
## Membuat peran tertaut layanan untuk Amazon EKS
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda mengaktifkan dasbor di AWS konsol, Amazon EKS membuat peran terkait layanan untuk Anda.
Untuk informasi selengkapnya tentang mengaktifkan Dasbor EKS, lihat[Konfigurasikan integrasi Dasbor EKS dengan AWS Organizations](cluster-dashboard-orgs.md).
**penting**
Peran tertaut layanan ini dapat muncul di akun Anda jika Anda menyelesaikan tindakan di layanan lain yang menggunakan fitur yang disupport oleh peran ini.
## Mengedit Peran tertaut layanan untuk Amazon EKS
Amazon EKS tidak mengizinkan Anda untuk mengedit peran tertaut layanan `AWSServiceRoleForAmazonEKSDashboard`. Setelah membuat peran tertaut layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin mereferensikan peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
## Menghapus peran tertaut layanan untuk Amazon EKS
Jika Anda tidak perlu lagi menggunakan fitur atau layanan yang memerlukan peran terkait layanan, sebaiknya hapus peran tersebut. Dengan begitu, Anda tidak memiliki entitas yang tidak digunakan dan tidak dipantau atau dipelihara secara aktif. Namun, Anda harus membersihkan peran tertaut layanan terlebih dahulu sebelum dapat menghapusnya secara manual.
### Membersihkan peran tertaut-layanan
Sebelum dapat menggunakan IAM untuk menghapus peran tertaut-layanan, Anda harus terlebih dahulu menghapus semua sumber daya yang digunakan oleh peran tersebut.
**catatan**
Jika layanan Amazon EKS menggunakan peran saat Anda mencoba untuk menghapus sumber daya, maka penghapusan tersebut kemungkinan gagal. Jika hal itu terjadi, tunggu beberapa menit dan coba mengoperasikannya lagi.
Untuk informasi selengkapnya tentang menonaktifkan Dasbor EKS, lihat. [Konfigurasikan integrasi Dasbor EKS dengan AWS Organizations](cluster-dashboard-orgs.md)
### Menghapus peran tertaut layanan secara manual
Gunakan konsol IAM, AWS CLI, atau AWS API untuk menghapus peran terkait layanan`AWSServiceRoleForAmazonEKSDashboard`. Untuk informasi selengkapnya, lihat [Menghapus peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dalam *Panduan Pengguna IAM*.
## Wilayah yang didukung untuk peran tertaut-layanan Amazon EKS
Amazon EKS mendukung penggunaan peran tertaut-layanan di semua wilayah tempat layanan tersedia. Untuk informasi selengkapnya, lihat [titik akhir dan kuota Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Peran IAM eksekusi Pod Amazon EKS
Peran eksekusi Amazon EKS Pod diperlukan untuk menjalankan Pod pada infrastruktur AWS Fargate.
Saat klaster Anda membuat Pod pada infrastruktur AWS Fargate, komponen yang berjalan pada infrastruktur Fargate harus melakukan panggilan atas nama Anda. AWS APIs Ini agar mereka dapat melakukan tindakan seperti menarik gambar kontainer dari Amazon ECR atau merutekan log ke AWS layanan lain. Peran eksekusi Amazon EKS Pod memberikan izin IAM untuk melakukan ini.
Saat membuat profil Fargate, Anda harus menentukan peran eksekusi Pod untuk komponen Amazon EKS yang berjalan di infrastruktur Fargate menggunakan profil tersebut. Peran ini ditambahkan ke Kubernetes [Role based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) klaster untuk otorisasi. Hal ini memungkinkan `kubelet` yang berjalan di infrastruktur Fargate untuk mendaftar dengan cluster Amazon EKS Anda sehingga dapat muncul di cluster Anda sebagai node.
**catatan**
Profil Fargate harus memiliki peran IAM yang berbeda dari grup node Amazon EC2 .
**penting**
Container yang berjalan di Fargate Pod tidak dapat mengasumsikan izin IAM yang terkait dengan peran eksekusi Pod. Untuk memberikan izin pada container di Fargate Pod Anda untuk mengakses AWS layanan lain, Anda harus menggunakan [peran IAM](iam-roles-for-service-accounts.md) untuk akun layanan.
[Sebelum Anda membuat profil Fargate, Anda harus membuat peran IAM dengan Amazon. EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html)
## Memeriksa peran eksekusi Pod yang sudah dikonfigurasi dengan benar
Anda dapat menggunakan prosedur berikut untuk memeriksa dan melihat apakah akun Anda sudah memiliki peran eksekusi Amazon EKS Pod yang dikonfigurasi dengan benar. Untuk menghindari masalah keamanan wakil yang membingungkan, penting bahwa peran membatasi akses berdasarkan`SourceArn`. Anda dapat memodifikasi peran eksekusi sesuai kebutuhan untuk menyertakan dukungan untuk profil Fargate di cluster lain.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Pada halaman **Peran**, cari daftar peran untuk **Amazon EKSFargate PodExecutionRole**. Jika peran tidak ada, lihat [Membuat peran eksekusi Amazon EKS Pod](#create-pod-execution-role) untuk membuat peran. Jika peran itu memang ada, pilih perannya.
1. Di EKSFargate PodExecutionRole halaman **Amazon**, lakukan hal berikut:
1. Pilih **Izin**.
1. Pastikan kebijakan terkelola **EKSFargatePodExecutionRolePolicyAmazon** Amazon dilampirkan pada peran tersebut.
1. Pilih **Hubungan kepercayaan**.
1. Pilih **Edit kebijakan kepercayaan**.
1. Pada halaman **Edit kebijakan kepercayaan**, verifikasi bahwa hubungan kepercayaan berisi kebijakan berikut dan memiliki baris untuk profil Fargate di klaster Anda. Jika demikian, pilih **Batalkan**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Jika kebijakan cocok tetapi tidak memiliki baris yang menentukan profil Fargate di klaster, Anda dapat menambahkan baris berikut di bagian `ArnLike` atas objek. Ganti *region-code* dengan AWS Region tempat klaster Anda berada, *111122223333* dengan ID akun Anda, dan *my-cluster* dengan nama klaster Anda.
```
"aws:SourceArn": "arn:aws: eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
Jika kebijakan tidak cocok, salin kebijakan lengkap sebelumnya ke dalam formulir dan pilih **Perbarui kebijakan**. Ganti *region-code* dengan AWS Wilayah tempat klaster Anda berada. Jika Anda ingin menggunakan peran yang sama di semua AWS Wilayah di akun Anda, ganti *region-code* dengan`*`. Ganti *111122223333* dengan ID akun Anda dan *my-cluster* dengan nama cluster Anda. Jika Anda ingin menggunakan peran yang sama untuk semua cluster di akun Anda, ganti *my-cluster* dengan`*`.
## Membuat peran eksekusi Amazon EKS Pod
Jika Anda belum memiliki peran eksekusi Amazon EKS Pod untuk klaster Anda, Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI untuk membuatnya.
Konsol Manajemen AWS
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Pada halaman **Peran**, pilih **Buat peran**.
1. Pada halaman **Pilih entitas tepercaya**, lakukan hal berikut:
1. Di bagian **Jenis entitas tepercaya**, pilih ** AWS layanan**.
1. **Dari daftar dropdown **Use case for other AWS services**, pilih EKS.**
1. Pilih **EKS - Fargate** Pod.
1. Pilih **Berikutnya**.
1. Pada halaman **Tambahkan izin**, pilih **Berikutnya**.
1. Pada halaman **Nama, tinjau, dan buat**, lakukan hal berikut:
1. Untuk **nama Peran**, masukkan nama unik untuk peran Anda, seperti`AmazonEKSFargatePodExecutionRole`.
1. Di bawah **Tambahkan tag (Opsional)**, tambahkan metadata ke peran dengan melampirkan tag sebagai pasangan nilai kunci. Untuk informasi selengkapnya tentang penggunaan tanda di IAM, lihat [Menandai sumber daya IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) di *Panduan Pengguna IAM*.
1. Pilih **Buat peran**.
1. Pada halaman **Peran**, cari daftar peran untuk **Amazon EKSFargate PodExecutionRole**. Pilih perannya.
1. Di EKSFargate PodExecutionRole halaman **Amazon**, lakukan hal berikut:
1. Pilih **Hubungan kepercayaan**.
1. Pilih **Edit kebijakan kepercayaan**.
1. Pada halaman **Edit kebijakan kepercayaan**, lakukan hal berikut:
1. Salin dan tempel konten berikut ke dalam formulir **Edit kebijakan kepercayaan**. Ganti *region-code* dengan AWS Wilayah tempat klaster Anda berada. Jika Anda ingin menggunakan peran yang sama di semua AWS Wilayah di akun Anda, ganti *region-code* dengan`*`. Ganti *111122223333* dengan ID akun Anda dan *my-cluster* dengan nama cluster Anda. Jika Anda ingin menggunakan peran yang sama untuk semua cluster di akun Anda, ganti *my-cluster* dengan`*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Pilih **Perbarui kebijakan**.
AWS CLI
1. Salin dan tempel konten berikut ke file bernama`pod-execution-role-trust-policy.json`. Ganti *region-code* dengan AWS Wilayah tempat klaster Anda berada. Jika Anda ingin menggunakan peran yang sama di semua AWS Wilayah di akun Anda, ganti *region-code* dengan`*`. Ganti *111122223333* dengan ID akun Anda dan *my-cluster* dengan nama cluster Anda. Jika Anda ingin menggunakan peran yang sama untuk semua cluster di akun Anda, ganti *my-cluster* dengan`*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Buat peran IAM eksekusi Pod.
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. Lampirkan kebijakan terkelola IAM Amazon EKS yang diperlukan untuk peran tersebut.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Peran IAM konektor Amazon EKS
Anda dapat menghubungkan klaster Kubernetes untuk melihatnya di kluster Anda. Konsol Manajemen AWS Untuk terhubung ke klaster Kubernetes, buat peran IAM.
## Periksa peran konektor EKS yang ada
Anda dapat menggunakan prosedur berikut untuk memeriksa dan melihat apakah akun Anda sudah memiliki peran konektor Amazon EKS.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Cari daftar peran untuk `AmazonEKSConnectorAgentRole`. Jika peran yang menyertakan `AmazonEKSConnectorAgentRole` tidak ada, maka lihat [Membuat peran agen konektor Amazon EKS](#create-connector-role) untuk membuat peran tersebut. Jika peran yang mencakup `AmazonEKSConnectorAgentRole` ada, kemudian pilih peran untuk melihat kebijakan terlampir.
1. Pilih **Izin**.
1. Pastikan kebijakan EKSConnector AgentPolicy terkelola **Amazon** melekat pada peran tersebut. Jika kebijakan dilampirkan, peran konektor Amazon EKS Anda dikonfigurasi dengan benar.
1. Pilih **Trust relationship**, lalu pilih **Edit trust policy**.
1. Verifikasi bahwa hubungan kepercayaan berisi kebijakan berikut. Jika hubungan kepercayaan sesuai dengan kebijakan berikut, pilih **Cancel** (Batalkan). Jika hubungan kepercayaan tidak cocok, salin kebijakan ke jendela **Edit kebijakan kepercayaan** dan pilih **Perbarui kebijakan**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Membuat peran agen konektor Amazon EKS
Anda dapat menggunakan Konsol Manajemen AWS atau AWS CloudFormation untuk membuat peran agen konektor.
AWS CLI
1. Buat file bernama `eks-connector-agent-trust-policy.json` yang berisi JSON berikut untuk digunakan untuk peran IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Buat file bernama `eks-connector-agent-policy.json` yang berisi JSON berikut untuk digunakan untuk peran IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. Buat peran agen Amazon EKS Connector menggunakan kebijakan kepercayaan dan kebijakan yang Anda buat di item daftar sebelumnya.
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Lampirkan kebijakan ke peran agen Amazon EKS Connector Anda.
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. Simpan AWS CloudFormation template berikut ke file teks di sistem lokal Anda.
**catatan**
Template ini juga menciptakan peran terkait layanan yang seharusnya dibuat saat `registerCluster` API dipanggil. Lihat [Menggunakan peran untuk menghubungkan klaster Kubernetes ke Amazon EKS](using-service-linked-roles-eks-connector.md) untuk detail.
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. Pilih **Buat tumpukan** dengan sumber daya baru (standar).
1. Untuk **Tentukan templat**, pilih **Unggah sebuah file templat**, kemudian pilih **Pilih file**.
1. Pilih file yang telah Anda buat sebelumnya, dan kemudian pilih **Selanjutnya**.
1. Untuk **Nama tumpukan**, masukkan nama untuk peran Anda, misalnya `eksConnectorAgentRole`, kemudian pilih **Selanjutnya**.
1. Pada halaman **Konfigurasikan opsi tumpukan**, pilih **Selanjutnya**.
1. Di halaman **Tinjauan**, tinjau informasi Anda, nyatakan bahwa tumpukan dapat membuat sumber daya IAM, kemudian pilih **Buat**.
# AWS kebijakan terkelola untuk Amazon Elastic Kubernetes Service
Kebijakan AWS terkelola adalah kebijakan mandiri yang dibuat dan dikelola oleh AWS. AWS Kebijakan terkelola dirancang untuk memberikan izin bagi banyak kasus penggunaan umum sehingga Anda dapat mulai menetapkan izin kepada pengguna, grup, dan peran.
Perlu diingat bahwa kebijakan AWS terkelola mungkin tidak memberikan izin hak istimewa paling sedikit untuk kasus penggunaan spesifik Anda karena tersedia untuk digunakan semua pelanggan. AWS Kami menyarankan Anda untuk mengurangi izin lebih lanjut dengan menentukan [kebijakan yang dikelola pelanggan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) yang khusus untuk kasus penggunaan Anda.
Anda tidak dapat mengubah izin yang ditentukan dalam kebijakan AWS terkelola. Jika AWS memperbarui izin yang ditentukan dalam kebijakan AWS terkelola, pembaruan akan memengaruhi semua identitas utama (pengguna, grup, dan peran) yang dilampirkan kebijakan tersebut. AWS kemungkinan besar akan memperbarui kebijakan AWS terkelola saat AWS layanan baru diluncurkan atau operasi API baru tersedia untuk layanan yang ada.
Untuk informasi selengkapnya, lihat [Kebijakan terkelola AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dalam *Panduan Pengguna IAM*.
## AWS kebijakan terkelola: Amazoneks\$1CNI\$1Policy
Anda dapat melampirkan `AmazonEKS_CNI_Policy` ke entitas IAM Anda. Sebelum Anda membuat grup node Amazon EC2, kebijakan ini harus dilampirkan ke peran IAM [node, atau ke peran IAM](create-node-role.md) yang digunakan secara khusus oleh plugin Amazon VPC CNI untuk Kubernetes. Ini dimaksudkan agar dapat melakukan tindakan atas nama Anda. Kami menyarankan Anda melampirkan kebijakan ke peran yang hanya digunakan oleh plugin. Untuk informasi selengkapnya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md) dan [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
**Detail izin**
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`ec2:*NetworkInterface`dan `ec2:*PrivateIpAddresses`** — Memungkinkan plugin Amazon VPC CNI untuk melakukan tindakan seperti menyediakan Antarmuka Jaringan Elastis dan alamat IP untuk Pod untuk menyediakan jaringan untuk aplikasi yang berjalan di Amazon EKS.
+ **`ec2`baca tindakan** - Memungkinkan plugin Amazon VPC CNI untuk melakukan tindakan seperti mendeskripsikan instance dan subnet untuk melihat jumlah alamat IP gratis di subnet VPC Amazon Anda. VPC CNI dapat menggunakan alamat IP gratis di setiap subnet untuk memilih subnet dengan alamat IP paling gratis untuk digunakan saat membuat elastic network interface.
Untuk melihat versi terbaru dari dokumen kebijakan JSON, lihat [Amazoneks\$1CNI\$1Policy di Panduan Referensi Kebijakan](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json) Terkelola. AWS
## AWS kebijakan terkelola: EKSCluster Kebijakan Amazon
Anda dapat melampirkan `AmazonEKSClusterPolicy` ke entitas IAM Anda. Sebelum membuat klaster, Anda harus memiliki [IAM role klaster](cluster-iam-role.md) dengan kebijakan terlampir ini. Cluster Kubernetes yang dikelola oleh Amazon EKS melakukan panggilan ke AWS layanan lain atas nama Anda. Mereka melakukan ini untuk mengelola sumber daya yang Anda gunakan dengan layanan.
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`autoscaling`**— Baca dan perbarui konfigurasi grup Auto Scaling. Izin ini tidak digunakan oleh Amazon EKS tetapi tetap dalam kebijakan untuk kompatibilitas mundur.
+ **`ec2`**— Bekerja dengan volume dan sumber daya jaringan yang terkait dengan node Amazon EC2. Hal ini diperlukan agar control plane Kubernetes dapat menggabungkan instance ke klaster dan secara dinamis menyediakan serta mengelola volume Amazon EBS yang diminta oleh volume persisten Kubernetes.
+ **`ec2`**- Hapus antarmuka jaringan elastis yang dibuat oleh VPC CNI. Ini diperlukan agar EKS dapat membersihkan antarmuka jaringan elastis yang tertinggal jika VPC CNI berhenti secara tak terduga.
+ **`elasticloadbalancing`**— Bekerja dengan Elastic Load Balancers dan tambahkan node ke dalamnya sebagai target. Ini diperlukan agar bidang kendali Kubernetes dapat secara dinamis menyediakan Penyeimbang Beban Elastis yang diminta oleh layanan Kubernetes.
+ **`iam`**— Buat peran terkait layanan. Hal ini diperlukan agar control plane Kubernetes dapat secara dinamis menyediakan Elastic Load Balancer yang diminta oleh layanan Kubernetes.
+ **`kms`**— Baca kunci dari AWS KMS. Ini diperlukan untuk pesawat kontrol Kubernetes untuk mendukung [enkripsi rahasia rahasia](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) Kubernetes yang disimpan di dalamnya. `etcd`
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat Kebijakan [Amazon EKSCluster](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSDashboard ConsoleReadOnly
Anda dapat melampirkan `AmazonEKSDashboardConsoleReadOnly` ke entitas IAM Anda.
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`eks`**- Akses hanya-baca ke data dasbor EKS, sumber daya, dan informasi versi cluster. Ini memungkinkan melihat metrik terkait EKS dan detail konfigurasi cluster.
+ **`organizations`**- Akses read-only ke informasi AWS Organizations, termasuk:
+ Melihat detail organisasi dan akses layanan
+ Daftar akar organisasi, akun, dan unit organisasi
+ Melihat struktur organisasi
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSDashboard ConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSFargate PodExecutionRolePolicy
Anda dapat melampirkan `AmazonEKSFargatePodExecutionRolePolicy` ke entitas IAM Anda. Sebelum Anda dapat membuat profil Fargate, Anda harus membuat peran eksekusi Fargate Pod dan melampirkan kebijakan ini padanya. Untuk informasi selengkapnya, lihat [Langkah 2: Buat peran eksekusi Fargate Pod](fargate-getting-started.md#fargate-sg-pod-execution-role) dan [Tentukan Pod mana yang menggunakan AWS Fargate saat diluncurkan](fargate-profile.md).
Kebijakan ini memberikan peran izin yang menyediakan akses ke sumber daya AWS layanan lain yang diperlukan untuk menjalankan Pod Amazon EKS di Fargate.
**Detail izin**
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`ecr`**— Memungkinkan Pod yang berjalan di Fargate untuk menarik gambar kontainer yang disimpan di Amazon ECR.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSConnector ServiceRolePolicy
Anda tidak dapat melampirkan `AmazonEKSConnectorServiceRolePolicy` ke entitas IAM Anda. Kebijakan ini dilampirkan pada peran tertaut layanan yang mengizinkan Amazon EKS untuk melakukan tindakan atas nama Anda. Untuk informasi selengkapnya, lihat [Menggunakan peran untuk menghubungkan klaster Kubernetes ke Amazon EKS](using-service-linked-roles-eks-connector.md).
Peran ini memungkinkan Amazon EKS untuk menghubungkan cluster Kubernetes. Kebijakan terlampir memungkinkan peran untuk mengelola sumber daya yang diperlukan untuk terhubung ke klaster Kubernetes Anda yang terdaftar.
**Detail izin**
Kebijakan ini mencakup izin berikut yang memungkinkan Amazon EKS untuk menyelesaikan tugas berikut.
+ **`SSM Management`**— Buat, jelaskan, dan hapus aktivasi SSM, dan deregister instance terkelola. Ini memungkinkan operasi Systems Manager dasar.
+ **`Session Management`**— Mulai sesi SSM khusus untuk kluster EKS dan jalankan perintah non-interaktif menggunakan dokumen AmazonEks.
+ **`IAM Role Passing`**— Lulus peran IAM secara khusus ke layanan SSM, dikendalikan oleh kondisi yang membatasi peran yang diteruskan ke. `ssm.amazonaws.com`
+ **`EventBridge Rules`**— Buat EventBridge aturan dan target, tetapi hanya jika dikelola oleh`eks-connector.amazonaws.com`. Aturan secara khusus terbatas pada AWS SSM sebagai sumber acara.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSConnector ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSFor FargateServiceRolePolicy
Anda tidak dapat melampirkan `AmazonEKSForFargateServiceRolePolicy` ke entitas IAM Anda. Kebijakan ini dilampirkan pada peran tertaut layanan yang mengizinkan Amazon EKS untuk melakukan tindakan atas nama Anda. Untuk informasi selengkapnya, lihat `AWSServiceRoleforAmazonEKSForFargate`.
Kebijakan ini memberikan izin yang diperlukan kepada Amazon EKS untuk menjalankan tugas Fargate. Kebijakan ini hanya digunakan jika Anda memiliki simpul Fargate.
**Detail izin**
Kebijakan ini mencakup izin berikut yang memungkinkan Amazon EKS untuk menyelesaikan tugas berikut.
+ **`ec2`**— Buat dan hapus Antarmuka Jaringan Elastis dan jelaskan Antarmuka dan sumber daya Jaringan Elastis. Ini diperlukan agar layanan Amazon EKS Fargate dapat mengonfigurasi jaringan VPC yang diperlukan untuk Pod Fargate.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSFor FargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: EKSCompute Kebijakan Amazon
Anda dapat melampirkan `AmazonEKSComputePolicy` ke entitas IAM Anda. Anda dapat melampirkan kebijakan ini ke [peran IAM klaster](cluster-iam-role.md) Anda untuk memperluas sumber daya yang dapat dikelola EKS di akun Anda.
Kebijakan ini memberikan izin yang diperlukan Amazon EKS untuk membuat dan mengelola instans EC2 untuk kluster EKS, dan izin IAM yang diperlukan untuk mengonfigurasi EC2. Selain itu, kebijakan ini memberikan izin kepada Amazon EKS untuk membuat peran terkait layanan EC2 Spot atas nama Anda.
### Detail izin
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`ec2`Izin**:
+ `ec2:CreateFleet`dan `ec2:RunInstances` - Memungkinkan membuat instance EC2 dan menggunakan sumber daya EC2 tertentu (gambar, grup keamanan, subnet) untuk node cluster EKS.
+ `ec2:CreateLaunchTemplate`- Memungkinkan pembuatan template peluncuran EC2 untuk node cluster EKS.
+ Kebijakan ini juga mencakup ketentuan untuk membatasi penggunaan izin EC2 ini ke sumber daya yang ditandai dengan nama klaster EKS dan tag relevan lainnya.
+ `ec2:CreateTags`- Memungkinkan menambahkan tag ke sumber daya EC2 yang dibuat oleh`CreateFleet`,`RunInstances`, dan `CreateLaunchTemplate` tindakan.
+ **`iam`Izin**:
+ `iam:AddRoleToInstanceProfile`- Memungkinkan menambahkan peran IAM ke profil instance komputasi EKS.
+ `iam:PassRole`- Memungkinkan meneruskan peran IAM yang diperlukan ke layanan EC2.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat Kebijakan [Amazon EKSCompute](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: EKSNetworking Kebijakan Amazon
Anda dapat melampirkan `AmazonEKSNetworkingPolicy` ke entitas IAM Anda. Anda dapat melampirkan kebijakan ini ke [peran IAM klaster](cluster-iam-role.md) Anda untuk memperluas sumber daya yang dapat dikelola EKS di akun Anda.
Kebijakan ini dirancang untuk memberikan izin yang diperlukan bagi Amazon EKS untuk membuat dan mengelola antarmuka jaringan untuk kluster EKS, memungkinkan bidang kontrol dan node pekerja untuk berkomunikasi dan berfungsi dengan baik.
### Detail izin
Kebijakan ini memberikan izin berikut untuk mengizinkan Amazon EKS mengelola antarmuka jaringan untuk klaster:
+ **`ec2`Izin Antarmuka Jaringan**:
+ `ec2:CreateNetworkInterface`- Memungkinkan membuat antarmuka jaringan EC2.
+ Kebijakan ini mencakup ketentuan untuk membatasi penggunaan izin ini ke antarmuka jaringan yang ditandai dengan nama klaster EKS dan nama node CNI Kubernetes.
+ `ec2:CreateTags`- Memungkinkan menambahkan tag ke antarmuka jaringan yang dibuat oleh `CreateNetworkInterface` tindakan.
+ **`ec2`Izin Manajemen Antarmuka Jaringan**:
+ `ec2:AttachNetworkInterface`,`ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface` - Memungkinkan melampirkan, memodifikasi atribut antarmuka jaringan dan melepaskan antarmuka jaringan ke instans EC2.
+ `ec2:UnassignPrivateIpAddresses`,`ec2:UnassignIpv6Addresses`,`ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses` - Memungkinkan mengelola penugasan alamat IP dari antarmuka jaringan.
+ Izin ini dibatasi untuk antarmuka jaringan yang ditandai dengan nama cluster EKS.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat Kebijakan [Amazon EKSNetworking](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSBlock StoragePolicy
Anda dapat melampirkan `AmazonEKSBlockStoragePolicy` ke entitas IAM Anda. Anda dapat melampirkan kebijakan ini ke [peran IAM klaster](cluster-iam-role.md) Anda untuk memperluas sumber daya yang dapat dikelola EKS di akun Anda.
Kebijakan ini memberikan izin yang diperlukan bagi Amazon EKS untuk membuat, mengelola, dan memelihara volume dan snapshot EC2 untuk klaster EKS, memungkinkan control plane dan node worker untuk menyediakan dan menggunakan penyimpanan persisten seperti yang dipersyaratkan oleh beban kerja Kubernetes.
### Detail izin
Kebijakan IAM ini memberikan izin berikut untuk mengizinkan Amazon EKS mengelola volume dan snapshot EC2:
+ **`ec2`Izin Manajemen Volume**:
+ `ec2:AttachVolume`,`ec2:DetachVolume`,`ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores` - Memungkinkan melampirkan, melepaskan, memodifikasi, dan mengaktifkan pemulihan snapshot cepat untuk volume EC2.
+ Izin ini dibatasi untuk volume yang ditandai dengan nama cluster EKS.
+ `ec2:CreateTags`- Memungkinkan menambahkan tag ke volume EC2 dan snapshot yang dibuat oleh `CreateVolume` dan `CreateSnapshot` tindakan.
+ **`ec2`Izin Pembuatan Volume**:
+ `ec2:CreateVolume`- Memungkinkan membuat volume EC2 baru.
+ Kebijakan ini mencakup ketentuan untuk membatasi penggunaan izin ini ke volume yang ditandai dengan nama klaster EKS dan tag lain yang relevan.
+ `ec2:CreateSnapshot`- Memungkinkan membuat snapshot volume EC2 baru.
+ Kebijakan ini mencakup ketentuan untuk membatasi penggunaan izin ini pada snapshot yang ditandai dengan nama klaster EKS dan tag lain yang relevan.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSBlock StoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSLoad BalancingPolicy
Anda dapat melampirkan `AmazonEKSLoadBalancingPolicy` ke entitas IAM Anda. Anda dapat melampirkan kebijakan ini ke [peran IAM klaster](cluster-iam-role.md) Anda untuk memperluas sumber daya yang dapat dikelola EKS di akun Anda.
Kebijakan IAM ini memberikan izin yang diperlukan bagi Amazon EKS untuk bekerja dengan berbagai AWS layanan untuk mengelola Elastic Load Balancers () ELBs dan sumber daya terkait.
### Detail izin
Izin utama yang diberikan oleh kebijakan ini adalah:
+ **`elasticloadbalancing`**: Memungkinkan membuat, memodifikasi, dan mengelola Elastic Load Balancers dan Target Groups. Ini termasuk izin untuk membuat, memperbarui, dan menghapus penyeimbang beban, grup target, pendengar, dan aturan.
+ **`ec2`**: Memungkinkan pembuatan dan pengelolaan grup keamanan, yang diperlukan untuk control plane Kubernetes untuk menggabungkan instance ke klaster dan mengelola volume Amazon EBS. Juga memungkinkan mendeskripsikan dan mencantumkan sumber daya EC2 seperti instance,, Subnet VPCs, Grup Keamanan, dan sumber daya jaringan lainnya.
+ **`iam`**: Memungkinkan pembuatan peran terkait layanan untuk Elastic Load Balancing, yang diperlukan agar bidang kontrol Kubernetes dapat disediakan secara dinamis. ELBs
+ **`kms`**: Memungkinkan membaca kunci dari AWS KMS, yang diperlukan untuk control plane Kubernetes untuk mendukung enkripsi rahasia Kubernetes yang disimpan dalam etcd.
+ **`wafv2`**dan **`shield`**: Memungkinkan mengaitkan dan memisahkan Web dan ACLs membuat/menghapus perlindungan AWS Shield untuk Elastic Load Balancer.
+ **`cognito-idp`**, **`acm`**, and **`elasticloadbalancing`**: Memberikan izin untuk mendeskripsikan klien kumpulan pengguna, membuat daftar dan mendeskripsikan sertifikat, dan mendeskripsikan grup target, yang diperlukan untuk bidang kontrol Kubernetes untuk mengelola Elastic Load Balancers.
Kebijakan ini juga mencakup beberapa pemeriksaan kondisi untuk memastikan bahwa izin dicakup ke kluster EKS tertentu yang dikelola, menggunakan tag. `eks:eks-cluster-name`
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSLoad BalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSMCPRead OnlyAccess
Anda dapat melampirkan `AmazonEKSMCPReadOnlyAccess` ke entitas IAM Anda. Kebijakan ini menyediakan akses hanya-baca ke sumber daya Amazon EKS dan AWS layanan terkait, memungkinkan Server Amazon EKS Model Context Protocol (MCP) untuk melakukan operasi observabilitas dan pemecahan masalah tanpa melakukan modifikasi apa pun pada infrastruktur Anda.
**Detail izin**
Kebijakan ini mencakup izin berikut yang memungkinkan kepala sekolah menyelesaikan tugas-tugas berikut:
+ **`eks`**Memungkinkan prinsipal mendeskripsikan dan mencantumkan klaster EKS, grup node, add-on, entri akses, wawasan, dan mengakses Kubernetes API untuk operasi hanya-baca.
+ **`iam`**Memungkinkan kepala sekolah untuk mengambil informasi tentang peran IAM, kebijakan, dan lampirannya untuk memahami izin yang terkait dengan sumber daya EKS.
+ **`ec2`**Memungkinkan prinsipal untuk mendeskripsikan VPCs, subnet, dan tabel rute untuk memahami konfigurasi jaringan kluster EKS.
+ **`sts`**Memungkinkan kepala sekolah untuk mengambil informasi identitas penelepon untuk tujuan otentikasi dan otorisasi.
+ **`logs`**Memungkinkan prinsipal untuk memulai kueri dan mengambil hasil kueri dari CloudWatch Log untuk pemecahan masalah dan pemantauan.
+ **`cloudwatch`**Memungkinkan kepala sekolah untuk mengambil data metrik untuk memantau kinerja klaster dan beban kerja.
+ **`eks-mcp`**Memungkinkan prinsipal untuk menjalankan operasi MCP dan memanggil alat hanya-baca dalam Amazon EKS MCP Server.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSMCPRead OnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: EKSService Kebijakan Amazon
Anda dapat melampirkan `AmazonEKSServicePolicy` ke entitas IAM Anda. Cluster yang dibuat sebelum 16 April 2020, mengharuskan Anda untuk membuat peran IAM dan melampirkan kebijakan ini padanya. Cluster yang dibuat pada atau setelah 16 April 2020, tidak mengharuskan Anda untuk membuat peran dan tidak mengharuskan Anda untuk menetapkan kebijakan ini. Saat Anda membuat klaster menggunakan prinsipal IAM yang memiliki `iam:CreateServiceLinkedRole` izin, peran terkait layanan [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) secara otomatis dibuat untuk Anda. Peran terkait layanan memiliki [kebijakan terkelola: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) melekat padanya.
Kebijakan ini memungkinkan Amazon EKS untuk membuat dan mengelola sumber daya yang diperlukan guna mengoperasikan klaster Amazon EKS.
**Detail izin**
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut.
+ **`eks`**— Perbarui versi Kubernetes dari klaster Anda setelah Anda memulai pembaruan. Izin ini tidak digunakan oleh Amazon EKS tetapi tetap dalam kebijakan kompatibilitas mundur.
+ **`ec2`**— Bekerja dengan Antarmuka Jaringan Elastis dan sumber daya dan tag jaringan lainnya. Ini diperlukan oleh Amazon EKS untuk mengonfigurasi jaringan yang memfasilitasi komunikasi antara simpul dan bidang kendali Kubernetes. Baca informasi tentang kelompok keamanan. Perbarui tag pada grup keamanan.
+ **`route53`**— Kaitkan VPC dengan zona yang dihosting. Ini diperlukan oleh Amazon EKS untuk mengaktifkan jaringan titik akhir privat untuk server API klaster Kubernetes Anda.
+ **`logs`**— Log peristiwa. Ini diperlukan agar Amazon EKS dapat mengirimkan log pesawat kontrol Kubernetes ke. CloudWatch
+ **`iam`**— Buat peran terkait layanan. Ini diperlukan agar Amazon EKS dapat membuat peran [Izin peran tertaut layanan untuk Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) terkait layanan atas nama Anda.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat Kebijakan [Amazon EKSService](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSService RolePolicy
Anda tidak dapat melampirkan `AmazonEKSServiceRolePolicy` ke entitas IAM Anda. Kebijakan ini dilampirkan pada peran tertaut layanan yang mengizinkan Amazon EKS untuk melakukan tindakan atas nama Anda. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan untuk Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks). Saat Anda membuat klaster menggunakan prinsipal IAM yang memiliki `iam:CreateServiceLinkedRole` izin, peran terkait layanan [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) secara otomatis dibuat untuk Anda dan kebijakan ini dilampirkan padanya.
Kebijakan ini memungkinkan peran terkait layanan untuk memanggil AWS layanan atas nama Anda.
**Detail izin**
Kebijakan ini mencakup izin berikut yang memungkinkan Amazon EKS untuk menyelesaikan tugas berikut.
+ **`ec2`**— Buat dan jelaskan Antarmuka Jaringan Elastis dan instans Amazon EC2, grup keamanan klaster, dan VPC yang diperlukan untuk membuat klaster. Untuk informasi selengkapnya, lihat [Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). Baca informasi tentang kelompok keamanan. Perbarui tag pada grup keamanan. Baca informasi tentang Pemesanan Kapasitas Sesuai Permintaan. Baca konfigurasi VPC termasuk tabel rute dan jaringan ACLs untuk mendeteksi masalah konfigurasi sebagai bagian dari wawasan cluster.
+ **`ec2`Mode Otomatis** - Hentikan instans EC2 yang dibuat oleh Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Mengotomatiskan infrastruktur klaster dengan Mode Otomatis EKS](automode.md).
+ **`iam`**— Buat daftar semua kebijakan terkelola yang melekat pada peran IAM. Ini diperlukan agar Amazon EKS dapat mencantumkan dan memvalidasi semua kebijakan dan izin terkelola yang diperlukan untuk membuat klaster.
+ **Kaitkan VPC dengan zona yang dihosting** — Ini diperlukan oleh Amazon EKS untuk mengaktifkan jaringan endpoint pribadi untuk server API cluster Kubernetes Anda.
+ **Peristiwa log** - Ini diperlukan agar Amazon EKS dapat mengirimkan log pesawat kontrol Kubernetes ke. CloudWatch
+ **Masukkan metrik** - Ini diperlukan agar Amazon EKS dapat mengirimkan log pesawat kontrol Kubernetes ke. CloudWatch
+ **`eks`**- Kelola entri dan kebijakan akses klaster, memungkinkan kontrol halus atas siapa yang dapat mengakses sumber daya EKS dan tindakan apa yang dapat mereka lakukan. Ini termasuk mengaitkan kebijakan akses standar untuk operasi komputasi, jaringan, penyeimbangan beban, dan penyimpanan.
+ **`elasticloadbalancing`**- Buat, kelola, dan hapus penyeimbang beban dan komponennya (pendengar, grup target, sertifikat) yang terkait dengan kluster EKS. Lihat atribut penyeimbang beban dan status kesehatan.
+ **`events`**- Membuat dan mengelola EventBridge aturan untuk memantau EC2 dan peristiwa AWS Kesehatan yang terkait dengan kluster EKS, memungkinkan respons otomatis terhadap perubahan infrastruktur dan peringatan kesehatan.
+ **`iam`**- Kelola profil instans EC2 dengan awalan “eks”, termasuk pembuatan, penghapusan, dan asosiasi peran, yang diperlukan untuk manajemen node EKS. Memungkinkan mendeskripsikan profil instance apa pun untuk memungkinkan pengguna menentukan profil instance khusus untuk digunakan oleh node pekerja mereka.
+ **`pricing`**`shield`****- Akses informasi AWS harga dan status perlindungan Shield, memungkinkan manajemen biaya dan fitur keamanan canggih untuk sumber daya EKS.
+ **Pembersihan sumber daya** - Hapus sumber daya yang ditandai EKS dengan aman termasuk volume, snapshot, template peluncuran, dan antarmuka jaringan selama operasi pembersihan klaster.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: EKSVPCResource Pengontrol Amazon
Anda dapat melampirkan kebijakan `AmazonEKSVPCResourceController` ke identitas IAM Anda. Jika Anda menggunakan [grup keamanan untuk Pod](security-groups-for-pods.md), Anda harus melampirkan kebijakan ini ke [peran IAM klaster Amazon EKS](cluster-iam-role.md) untuk melakukan tindakan atas nama Anda.
Kebijakan ini memberikan izin peran klaster untuk mengelola Antarmuka Jaringan Elastis dan alamat IP untuk simpul.
**Detail izin**
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`ec2`**— Kelola Antarmuka Jaringan Elastis dan alamat IP untuk mendukung grup keamanan Pod dan node Windows.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [EKSVPCResourcePengontrol Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSWorker NodePolicy
Anda dapat melampirkan `AmazonEKSWorkerNodePolicy` ke entitas IAM Anda. Anda harus melampirkan kebijakan ini ke [IAM role simpul](create-node-role.md) yang Anda tentukan ketika membuat simpul Amazon EC2 yang mengizinkan Amazon EKS untuk melakukan tindakan atas nama Anda. Jika Anda membuat grup simpul menggunakan `eksctl`, ia akan membuat IAM role simpul dan melampirkan kebijakan ini ke peran secara otomatis.
Kebijakan ini memberikan izin kepada simpul Amazon EKS Amazon EC2 untuk terhubung ke klaster Amazon EKS.
**Detail izin**
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`ec2`**— Baca volume instance dan informasi jaringan. Hal ini diperlukan agar node Kubernetes dapat menjelaskan informasi tentang resource Amazon EC2 yang diperlukan node untuk bergabung dengan cluster Amazon EKS.
+ **`eks`**— Secara opsional menggambarkan cluster sebagai bagian dari node bootstrapping.
+ **`eks-auth:AssumeRoleForPodIdentity`**— Izinkan pengambilan kredensil untuk beban kerja EKS pada node. Hal ini diperlukan agar EKS Pod Identity berfungsi dengan baik.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSWorker NodeMinimalPolicy
Anda dapat melampirkan WorkerNodeMinimalPolicy AmazonEks ke entitas IAM Anda. Anda dapat melampirkan kebijakan ini ke peran IAM node yang Anda tentukan saat membuat node Amazon EC2 yang memungkinkan Amazon EKS melakukan tindakan atas nama Anda.
Kebijakan ini memberikan izin kepada simpul Amazon EKS Amazon EC2 untuk terhubung ke klaster Amazon EKS. Kebijakan ini memiliki izin yang lebih sedikit dibandingkan dengan Amazon EKSWorkerNodePolicy.
**Detail izin**
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ `eks-auth:AssumeRoleForPodIdentity`- Izinkan pengambilan kredensil untuk beban kerja EKS pada node. Hal ini diperlukan agar EKS Pod Identity berfungsi dengan baik.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: AWSService RoleForAmazon EKSNodegroup
Anda tidak dapat melampirkan `AWSServiceRoleForAmazonEKSNodegroup` ke entitas IAM Anda. Kebijakan ini dilampirkan pada peran tertaut layanan yang mengizinkan Amazon EKS untuk melakukan tindakan atas nama Anda. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan untuk Amazon EKS](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups).
Kebijakan ini mengabulkan izin peran `AWSServiceRoleForAmazonEKSNodegroup` yang memungkinkannya untuk membuat dan mengelola grup simpul Amazon EC2 di akun Anda.
**Detail izin**
Kebijakan ini mencakup izin yang memungkinkan Amazon EKS untuk menyelesaikan tugas-tugas berikut:
+ **`ec2`**— Bekerja dengan grup keamanan, tag, reservasi kapasitas, dan templat peluncuran. Ini diperlukan untuk grup node terkelola Amazon EKS untuk mengaktifkan konfigurasi akses jarak jauh dan untuk menjelaskan reservasi kapasitas yang dapat digunakan dalam grup node terkelola. Selain itu, grup simpul yang dikelola Amazon EKS membuat templat peluncuran atas nama Anda. Ini untuk mengonfigurasi grup Amazon EC2 Auto Scaling yang mendukung setiap grup simpul terkelola.
+ **`iam`**— Buat peran terkait layanan dan berikan peran. Ini diperlukan oleh grup simpul yang dikelola Amazon EKS dalam mengelola profil instans untuk peran yang diteruskan ketika membuat grup simpul terkelola. Profil instans ini digunakan oleh instans Amazon EC2 yang diluncurkan sebagai bagian dari grup simpul terkelola. Amazon EKS perlu membuat peran tertaut-layanan untuk layanan lain seperti grup Amazon EC2 Auto Scaling. Izin ini digunakan dalam pembuatan grup node terkelola.
+ **`autoscaling`**— Bekerja dengan grup Auto Scaling keamanan. Ini diperlukan oleh grup simpul yang dikelola Amazon EKS untuk mengelola grup Amazon EC2 Auto Scaling yang mendukung setiap grup simpul terkelola. Ini juga digunakan untuk mendukung fungsionalitas seperti mengusir Pod ketika node dihentikan atau didaur ulang selama pembaruan grup node dan mengelola kumpulan hangat yang dikonfigurasi pada grup node terkelola.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json)di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSDashboard ServiceRolePolicy
Anda tidak dapat melampirkan `AmazonEKSDashboardServiceRolePolicy` ke entitas IAM Anda. Kebijakan ini dilampirkan pada peran tertaut layanan yang mengizinkan Amazon EKS untuk melakukan tindakan atas nama Anda. Untuk informasi selengkapnya, lihat [Izin peran tertaut layanan untuk Amazon EKS](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard).
Kebijakan ini mengabulkan izin peran `AWSServiceRoleForAmazonEKSDashboard` yang memungkinkannya untuk membuat dan mengelola grup simpul Amazon EC2 di akun Anda.
**Detail izin**
Kebijakan ini mencakup izin berikut yang memungkinkan akses untuk menyelesaikan tugas-tugas ini:
+ **`organizations`**— Lihat informasi tentang struktur dan akun AWS Organizations Anda. Ini termasuk izin untuk mencantumkan akun di organisasi Anda, melihat unit dan akar organisasi, daftar administrator yang didelegasikan, melihat layanan yang memiliki akses ke organisasi Anda, dan mengambil informasi terperinci tentang organisasi dan akun Anda.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSDashboard ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: EBSCSIDriver Kebijakan Amazon
`AmazonEBSCSIDriverPolicy`Kebijakan ini memungkinkan driver Amazon EBS Container Storage Interface (CSI) untuk membuat, memodifikasi, menyalin, melampirkan, melepaskan, dan menghapus volume atas nama Anda. Ini termasuk memodifikasi tag pada volume yang ada dan mengaktifkan Pemulihan Snapshot Cepat (FSR) pada volume EBS. Ini juga memberikan izin driver EBS CSI untuk membuat, mengunci, memulihkan, dan menghapus snapshot, dan untuk membuat daftar instance, volume, dan snapshot Anda.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EBSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: EFSCSIDriver Kebijakan Amazon
`AmazonEFSCSIDriverPolicy`Kebijakan ini memungkinkan Amazon EFS Container Storage Interface (CSI) untuk membuat dan menghapus titik akses atas nama Anda. Ini juga memberikan izin driver Amazon EFS CSI untuk mencantumkan sistem file titik akses Anda, target pemasangan, dan zona ketersediaan Amazon EC2.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EFSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSLocal OutpostClusterPolicy
Anda dapat melampirkan kebijakan ini ke entitas IAM. Sebelum membuat klaster lokal, Anda harus melampirkan kebijakan ini ke [peran klaster](cluster-iam-role.md) Anda. Cluster Kubernetes yang dikelola oleh Amazon EKS melakukan panggilan ke AWS layanan lain atas nama Anda. Mereka melakukan ini untuk mengelola sumber daya yang Anda gunakan dengan layanan.
`AmazonEKSLocalOutpostClusterPolicy`Termasuk izin berikut:
+ **`ec2`tindakan baca** - Memungkinkan instance bidang kontrol untuk menggambarkan Availability Zone, tabel rute, instance, dan properti antarmuka jaringan. Izin yang diperlukan untuk instans Amazon EC2 agar berhasil bergabung dengan cluster sebagai instance bidang kontrol.
+ **`ssm`**— Memungkinkan koneksi Amazon EC2 Systems Manager ke instans control plane, yang digunakan oleh Amazon EKS untuk berkomunikasi dan mengelola cluster lokal di akun Anda.
+ **`logs`**— Memungkinkan instance untuk mendorong log ke Amazon CloudWatch.
+ **`secretsmanager`**— Memungkinkan instance untuk mendapatkan dan menghapus data bootstrap untuk instance control plane dengan aman dari Secrets Manager AWS .
+ **`ecr`**— Memungkinkan Pod dan kontainer yang berjalan pada instance control plane untuk menarik gambar kontainer yang disimpan di Amazon Elastic Container Registry.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## AWS kebijakan terkelola: Amazon EKSLocal OutpostServiceRolePolicy
Anda tidak dapat melampirkan kebijakan ini ke entitas IAM Anda. Saat Anda membuat klaster menggunakan prinsipal IAM yang memiliki `iam:CreateServiceLinkedRole` izin, Amazon EKS secara otomatis membuat peran terkait layanan [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) untuk Anda dan melampirkan kebijakan ini padanya. Kebijakan ini memungkinkan peran terkait layanan untuk memanggil AWS layanan atas nama Anda untuk kluster lokal.
`AmazonEKSLocalOutpostServiceRolePolicy`Termasuk izin berikut:
+ **`ec2`**— Memungkinkan Amazon EKS bekerja dengan keamanan, jaringan, dan sumber daya lainnya agar berhasil meluncurkan dan mengelola instans pesawat kontrol di akun Anda.
+ **`ssm`, `ssmmessages`** — Memungkinkan koneksi Amazon EC2 Systems Manager ke instans bidang kontrol, yang digunakan oleh Amazon EKS untuk berkomunikasi dan mengelola cluster lokal di akun Anda.
+ **`iam`**— Memungkinkan Amazon EKS mengelola profil instans yang terkait dengan instans bidang kontrol.
+ **`secretsmanager`**- Memungkinkan Amazon EKS untuk menempatkan data bootstrap untuk instance control plane ke AWS Secrets Manager sehingga dapat direferensikan dengan aman selama bootstrap instance.
+ **`outposts`**— Memungkinkan Amazon EKS mendapatkan informasi Outpost dari akun Anda agar berhasil meluncurkan cluster lokal di Outpost.
Untuk melihat versi terbaru dokumen kebijakan JSON, lihat [Amazon EKSLocal OutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) di Panduan Referensi Kebijakan AWS Terkelola.
## Amazon EKS memperbarui kebijakan AWS terkelola
Lihat detail tentang pembaruan kebijakan AWS terkelola untuk Amazon EKS sejak layanan ini mulai melacak perubahan ini.
Untuk menerima pemberitahuan semua perubahan file sumber ke halaman dokumentasi khusus ini, Anda dapat berlangganan URL berikut dengan pembaca RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| Ubah | Deskripsi | Date |
| --- | --- | --- |
| Menambahkan izin ke[AWS kebijakan terkelola: EKSNetworking Kebijakan Amazon](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | Menambahkan `ec2:ModifyNetworkInterfaceAttribute` izin di`AmazonEKSNetworkingPolicy`. Hal ini memungkinkan Amazon EKS Auto Mode Controller untuk memodifikasi atribut antarmuka jaringan yang terkait dengan instans EC2 | 3 Februari 2026 |
| Menambahkan izin ke[AWS kebijakan terkelola: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Ditambahkan `autoscaling:PutWarmPool``autoscaling:DeleteWarmPool`,, dan `autoscaling:DescribeWarmPool` izin untuk`AWSServiceRoleForAmazonEKSNodegroup`. Hal ini memungkinkan Amazon EKS Managed Nodegroups untuk mengelola sumber daya kumpulan hangat ASG yang mendasarinya di seluruh siklus hidup grup node. | Februari 17, 2026 |
| Menambahkan izin ke[AWS kebijakan terkelola: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Menghapus persyaratan awalan “eks” atas nama profil instance target untuk `iam:GetInstanceProfile` izin masuk`AmazonEKSServiceRolePolicy`. Hal ini memungkinkan Amazon EKS Auto Mode untuk memvalidasi dan menggunakan profil instans kustom NodeClasses tanpa memerlukan awalan penamaan “eks”. | 2 Februari 2026 |
| Menambahkan izin ke [EBSCSIDriverKebijakan Amazon](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Menambahkan `ec2:LockSnapshot` izin untuk mengizinkan Driver EBS CSI mengunci Snapshot EBS secara langsung. | Januari 15, 2026 |
| Diperkenalkan[AWS kebijakan terkelola: Amazon EKSMCPRead OnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess). | Amazon EKS memperkenalkan kebijakan terkelola baru `AmazonEKSMCPReadOnlyAccess` untuk mengaktifkan alat hanya-baca di Amazon EKS MCP Server untuk observabilitas dan pemecahan masalah. | November 21, 2025 |
| Menambahkan izin ke [EBSCSIDriverKebijakan Amazon](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Menambahkan `ec2:CopyVolumes` izin untuk mengizinkan Driver EBS CSI menyalin volume EBS secara langsung. | November 17, 2025 |
| Menambahkan izin ke[AWS kebijakan terkelola: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Ditambahkan `ec2:DescribeRouteTables` dan `ec2:DescribeNetworkAcls` izin untuk`AmazonEKSServiceRolePolicy`. Hal ini memungkinkan Amazon EKS mendeteksi masalah konfigurasi dengan tabel rute VPC dan jaringan ACLs untuk node hibrida sebagai bagian dari wawasan cluster. | Okt 22, 2025 |
| Menambahkan izin ke [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) | Menambahkan `ssmmessages:OpenDataChannel` izin ke `AmazonEKSConnectorServiceRolePolicy` | Oktober 15, 2025 |
| Menambahkan izin ke [AWS kebijakan terkelola: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) | Peran ini dapat melampirkan kebijakan akses baru`AmazonEKSEventPolicy`. Izin terbatas untuk `ec2:DeleteLaunchTemplate` dan`ec2:TerminateInstances`. | Agustus 26, 2025 |
| Menambahkan izin ke [AWS kebijakan terkelola: Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | Menambahkan `ssmmessages:OpenDataChannel` izin ke`AmazonEKSLocalOutpostServiceRolePolicy`. | Juni 26, 2025 |
| Menambahkan izin ke[AWS kebijakan terkelola: EKSCompute Kebijakan Amazon](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Izin sumber daya yang diperbarui untuk `ec2:CreateFleet` tindakan `ec2:RunInstances` dan untuk menyertakan reservasi ` arn:aws: ec2:*:*:capacity-reservation/*` kapasitas. Hal ini memungkinkan Amazon EKS Auto Mode untuk meluncurkan instans dengan menggunakan Reservasi Kapasitas Sesuai Permintaan EC2 di akun Anda. Ditambahkan `iam:CreateServiceLinkedRole` untuk memungkinkan Amazon EKS Auto Mode untuk membuat peran terkait layanan EC2 Spot `AWSServiceRoleForEC2Spot` atas nama Anda. | Juni 20, 2025 |
| Menambahkan izin ke [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Menambahkan `ec2:DescribeCapacityReservations` izin untuk mengizinkan Mode Otomatis Amazon EKS meluncurkan instans dengan menggunakan Reservasi Kapasitas Sesuai Permintaan EC2 di akun Anda. | Juni 20, 2025 |
| Diperkenalkan[AWS kebijakan terkelola: Amazon EKSDashboard ConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly). | Memperkenalkan `AmazonEKSDashboardConsoleReadOnly` kebijakan baru. | Juni 19, 2025 |
| Diperkenalkan[AWS kebijakan terkelola: Amazon EKSDashboard ServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). | Memperkenalkan `AmazonEKSDashboardServiceRolePolicy` kebijakan baru. | 21 Mei 2025 |
| Menambahkan izin ke [EKSClusterKebijakan Amazon](#security-iam-awsmanpol-amazoneksclusterpolicy). | Menambahkan `ec2:DeleteNetworkInterfaces` izin untuk mengizinkan Amazon EKS menghapus antarmuka jaringan elastis yang tertinggal jika VPC CNI berhenti secara tak terduga. | April 16, 2025 |
| Menambahkan izin ke [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Ditambahkan `ec2:RevokeSecurityGroupEgress` dan `ec2:AuthorizeSecurityGroupEgress` izin untuk memungkinkan AI/ML pelanggan EKS menambahkan aturan Security Group Egress ke EKS Cluster SG default yang kompatibel dengan EFA, sebagai bagian dari rilis versi EKS 1.33. | April 14, 2025 |
| Menambahkan izin ke [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Menambahkan izin untuk menghentikan instans EC2 yang dibuat oleh Mode Otomatis EKS. | Februari 28, 2025 |
| Menambahkan izin ke [EBSCSIDriverKebijakan Amazon](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Menambahkan pernyataan baru yang mengotorisasi Driver EBS CSI untuk memulihkan semua snapshot. Ini sebelumnya diizinkan oleh kebijakan yang ada tetapi pernyataan eksplisit baru diperlukan karena perubahan dalam penanganan IAM untuk. `CreateVolume` Ditambahkan kemampuan untuk EBS CSI Driver untuk memodifikasi tag pada volume yang ada. Driver EBS CSI dapat memodifikasi tag volume yang ada melalui parameter di Kubernetes. VolumeAttributesClasses Menambahkan kemampuan untuk EBS CSI Driver untuk mengaktifkan Fast Snapshot Restore (FSR) pada volume EBS. Driver EBS CSI dapat mengaktifkan FSR pada volume baru melalui parameter di kelas penyimpanan Kubernetes. | Januari 13, 2025 |
| Menambahkan izin ke[AWS kebijakan terkelola: Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Diperbarui `AmazonEKSLoadBalancingPolicy` untuk memungkinkan daftar dan menggambarkan sumber daya jaringan dan alamat IP. | Desember 26, 2024 |
| Menambahkan izin ke[AWS kebijakan terkelola: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Diperbarui `AWSServiceRoleForAmazonEKSNodegroup` untuk kompatibilitas dengan wilayah Tiongkok. | November 22, 2024 |
| Menambahkan izin ke [AWS kebijakan terkelola: Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) | Menambahkan `ec2:DescribeAvailabilityZones` izin `AmazonEKSLocalOutpostClusterPolicy` agar AWS Cloud Controller Manager pada bidang kontrol cluster dapat mengidentifikasi Availability Zone tempat setiap node berada. | November 21, 2024 |
| Menambahkan izin ke[AWS kebijakan terkelola: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | `AWSServiceRoleForAmazonEKSNodegroup`Kebijakan yang diperbarui `ec2:RebootInstances` untuk mengizinkan instance yang dibuat oleh grup simpul terkelola Amazon EKS. Membatasi `ec2:CreateTags` izin untuk sumber daya Amazon EC2. | November 20, 2024 |
| Menambahkan izin ke[AWS kebijakan terkelola: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | EKS memperbarui kebijakan AWS terkelola`AmazonEKSServiceRolePolicy`. Menambahkan izin untuk kebijakan akses EKS, manajemen penyeimbang beban, dan pembersihan sumber daya klaster otomatis. | November 16, 2024 |
| Diperkenalkan[AWS kebijakan terkelola: EKSCompute Kebijakan Amazon](#security-iam-awsmanpol-AmazonEKSComputePolicy). | EKS memperbarui kebijakan AWS terkelola`AmazonEKSComputePolicy`. Izin sumber daya yang diperbarui untuk `iam:AddRoleToInstanceProfile` tindakan tersebut. | November 7, 2024 |
| Diperkenalkan[AWS kebijakan terkelola: EKSCompute Kebijakan Amazon](#security-iam-awsmanpol-AmazonEKSComputePolicy). | AWS memperkenalkan`AmazonEKSComputePolicy`. | November 1, 2024 |
| Menambahkan izin ke `AmazonEKSClusterPolicy` | Menambahkan `ec2:DescribeInstanceTopology` izin untuk mengizinkan Amazon EKS melampirkan informasi topologi ke node sebagai label. | November 1, 2024 |
| Diperkenalkan[AWS kebijakan terkelola: Amazon EKSBlock StoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy). | AWS memperkenalkan`AmazonEKSBlockStoragePolicy`. | Oktober 30, 2024 |
| Diperkenalkan[AWS kebijakan terkelola: Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | AWS memperkenalkan`AmazonEKSLoadBalancingPolicy`. | Oktober 30, 2024 |
| Menambahkan izin ke [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Menambahkan `cloudwatch:PutMetricData` izin untuk mengizinkan Amazon EKS mempublikasikan metrik ke Amazon. CloudWatch | Oktober 29, 2024 |
| Diperkenalkan[AWS kebijakan terkelola: EKSNetworking Kebijakan Amazon](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | AWS memperkenalkan`AmazonEKSNetworkingPolicy`. | Oktober 28, 2024 |
| Menambahkan izin ke dan `AmazonEKSServicePolicy` `AmazonEKSServiceRolePolicy` | Izin tag yang ditambahkan `ec2:GetSecurityGroupsForVpc` dan terkait untuk memungkinkan EKS membaca informasi grup keamanan dan memperbarui tag terkait. | Oktober 10, 2024 |
| Memperkenalkan [Amazon EKSWorker NodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy). | AWS memperkenalkan`AmazonEKSWorkerNodeMinimalPolicy`. | Oktober 3, 2024 |
| Menambahkan izin ke [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Ditambahkan `autoscaling:ResumeProcesses` dan `autoscaling:SuspendProcesses` izin untuk mengizinkan Amazon EKS menangguhkan dan melanjutkan di grup Auto Scaling yang dikelola `AZRebalance` Amazon EKS. | Agustus 21, 2024 |
| Menambahkan izin ke [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Menambahkan `ec2:DescribeCapacityReservations` izin untuk mengizinkan Amazon EKS menjelaskan reservasi kapasitas di akun pengguna. Menambahkan `autoscaling:PutScheduledUpdateGroupAction` izin untuk mengaktifkan pengaturan penskalaan terjadwal pada grup `CAPACITY_BLOCK` node. | 27 Juni 2024 |
| [Amazoneks\$1CNI\$1POLICY - Update ke kebijakan](#security-iam-awsmanpol-amazoneks-cni-policy) yang ada | Amazon EKS menambahkan `ec2:DescribeSubnets` izin baru untuk memungkinkan plugin Amazon VPC CNI untuk Kubernetes melihat jumlah alamat IP gratis di subnet VPC Amazon Anda. VPC CNI dapat menggunakan alamat IP gratis di setiap subnet untuk memilih subnet dengan alamat IP paling gratis untuk digunakan saat membuat elastic network interface. | Maret 4, 2024 |
| [Amazon EKSWorker NodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) - Perbarui ke kebijakan yang ada | Amazon EKS menambahkan izin baru untuk mengizinkan Identitas Pod EKS. Amazon EKS Pod Identity Agent menggunakan peran node. | 26 November 2023 |
| Memperkenalkan [EFSCSIDriverKebijakan Amazon](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy). | AWS memperkenalkan`AmazonEFSCSIDriverPolicy`. | 26 Juli 2023 |
| Menambahkan izin ke [EKSClusterKebijakan Amazon](#security-iam-awsmanpol-amazoneksclusterpolicy). | Menambahkan `ec2:DescribeAvailabilityZones` izin untuk mengizinkan Amazon EKS mendapatkan detail AZ selama penemuan otomatis subnet sambil membuat penyeimbang beban. | 7 Februari 2023 |
| Ketentuan kebijakan yang diperbarui di [EBSCSIDriverKebijakan Amazon](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Menghapus kondisi kebijakan yang tidak valid dengan karakter wildcard di bidang kunci. `StringLike` Juga menambahkan kondisi `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` baru`ec2:DeleteVolume`, yang memungkinkan driver EBS CSI untuk menghapus volume yang dibuat oleh plugin in-tree. | 17 November 2022 |
| Menambahkan izin ke [Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | Ditambahkan`ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` dan `ec2:DescribeSecret` untuk memungkinkan validasi prasyarat yang lebih baik dan kontrol siklus hidup terkelola. Juga ditambahkan `ec2:DescribePlacementGroups` dan `"arn:aws: ec2:*:*:placement-group/*"` `ec2:RunInstances` untuk mendukung kontrol penempatan pesawat kontrol instans Amazon EC2 di Outposts. | 24 Oktober 2022 |
| Perbarui izin Amazon Elastic Container Registry di [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Tindakan yang dipindahkan `ecr:GetDownloadUrlForLayer` dari semua bagian sumber daya ke bagian cakupan. Menambahkan sumber daya` arn:aws: ecr:*:*:repository/eks/ `. Sumber daya yang dihapus` arn:aws: ecr:`. Sumber daya ini dicakup oleh ` arn:aws: ecr:*:*:repository/eks/*` sumber daya tambahan. | 20 Oktober 2022 |
| Menambahkan izin ke [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Menambahkan repositori ` arn:aws: ecr:*:*:repository/kubelet-config-updater` Amazon Elastic Container Registry sehingga instance bidang kontrol cluster dapat memperbarui beberapa argumen. `kubelet` | 31 Agustus 2022 |
| Memperkenalkan [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | AWS memperkenalkan`AmazonEKSLocalOutpostClusterPolicy`. | Agustus 24, 2022 |
| Memperkenalkan [Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | AWS memperkenalkan`AmazonEKSLocalOutpostServiceRolePolicy`. | 23 Agustus 2022 |
| Memperkenalkan [EBSCSIDriverKebijakan Amazon](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | AWS memperkenalkan`AmazonEBSCSIDriverPolicy`. | 4 April 2022 |
| Menambahkan izin ke [Amazon EKSWorker NodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy). | Ditambahkan `ec2:DescribeInstanceTypes` untuk mengaktifkan Amazon EKS yang dioptimalkan AMIs yang dapat menemukan properti tingkat instans secara otomatis. | Maret 21, 2022 |
| Menambahkan izin ke [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Menambahkan `autoscaling:EnableMetricsCollection` izin untuk mengizinkan Amazon EKS mengaktifkan pengumpulan metrik. | 13 Desember 2021 |
| Menambahkan izin ke [EKSClusterKebijakan Amazon](#security-iam-awsmanpol-amazoneksclusterpolicy). | Izin `ec2:DescribeAccountAttributes`, `ec2:DescribeAddresses`, dan `ec2:DescribeInternetGateways` ditambahkan agar Amazon EKS diizinkan untuk membuat peran tertaut layanan bagi Penyeimbang Beban Jaringan. | 17 Juni 2021 |
| Amazon EKS mulai melacak perubahan. | Amazon EKS mulai melacak perubahan untuk kebijakan yang AWS dikelola. | 17 Juni 2021 |
# Menyelesaikan masalah IAM
Topik ini mencakup beberapa kesalahan umum yang mungkin Anda temui saat menggunakan Amazon EKS dengan IAM dan cara yang dilakukan untuk mengatasinya.
## AccessDeniedException
Jika Anda menerima `AccessDeniedException` saat memanggil operasi AWS API, kredensyal [utama IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang Anda gunakan tidak memiliki izin yang diperlukan untuk melakukan panggilan itu.
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws: iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws: eks:region:111122223333:cluster/my-cluster
```
Dalam pesan contoh sebelumnya, pengguna tidak memiliki izin untuk memanggil operasi Amazon EKS `DescribeCluster` API. Untuk memberikan izin admin Amazon EKS ke kepala sekolah IAM, lihat. [Contoh kebijakan berbasis identitas Amazon EKS](security-iam-id-based-policy-examples.md)
Untuk informasi umum selengkapnya tentang IAM, tinjau [Mengontrol akses menggunakan kebijakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) di *Panduan Pengguna IAM*.
## Tidak dapat melihat **Node** di tab **Compute** atau apa pun di tab **Resources** dan Anda menerima kesalahan di Konsol Manajemen AWS
Anda mungkin melihat pesan kesalahan konsol yang menyatakan `Your current user or role does not have access to Kubernetes objects on this EKS cluster`. Pastikan bahwa pengguna [utama IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang Anda gunakan Konsol Manajemen AWS dengan memiliki izin yang diperlukan. Untuk informasi selengkapnya, lihat [Izin yang diperlukan](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
## aws-auth `ConfigMap` tidak memberikan akses ke cluster
[AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) tidak mengizinkan jalur dalam peran ARN yang digunakan dalam. `ConfigMap` Karena itu, sebelum Anda tentukan `rolearn`, hapus jalur. Misalnya, perubahan ` arn:aws: iam::111122223333:role/team/developers/eks-admin ` ke ` arn:aws: iam::111122223333:role/eks-admin `.
## Saya tidak berwenang untuk melakukan iam: PassRole
Jika Anda menerima kesalahan bahwa Anda tidak diizinkan untuk melakukan `iam:PassRole` tindakan, kebijakan Anda harus diperbarui agar Anda dapat meneruskan peran ke Amazon EKS.
Beberapa AWS layanan memungkinkan Anda untuk meneruskan peran yang ada ke layanan tersebut alih-alih membuat peran layanan baru atau peran terkait layanan. Untuk melakukannya, Anda harus memiliki izin untuk mendapatkan peran ke layanan.
Contoh kesalahan berikut terjadi saat pengguna IAM bernama `marymajor` mencoba menggunakan konsol tersebut untuk performa tindakan di Amazon EKS. Namun, tindakan tersebut memerlukan layanan untuk mendapatkan izin yang diberikan oleh peran layanan. Mary tidak memiliki izin untuk meneruskan peran tersebut pada layanan.
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dalam hal ini, kebijakan Mary harus diperbarui untuk memungkinkannya melakukan `iam:PassRole` tindakan.
Jika Anda memerlukan bantuan, hubungi AWS administrator Anda. Administrator Anda adalah orang yang memberi Anda kredensial masuk.
## Saya ingin mengizinkan orang di luar AWS akun saya untuk mengakses sumber daya Amazon EKS saya
Anda dapat membuat peran yang dapat digunakan pengguna di akun lain atau orang-orang di luar organisasi Anda untuk mengakses sumber daya Anda. Anda dapat menentukan siapa saja yang dipercaya untuk mengambil peran tersebut. Untuk layanan yang mendukung kebijakan berbasis sumber daya atau daftar kontrol akses (ACLs), Anda dapat menggunakan kebijakan tersebut untuk memberi orang akses ke sumber daya Anda.
Untuk mempelajari selengkapnya, konsultasikan hal berikut:
+ Untuk mempelajari apakah Amazon EKS mendukung fitur ini, lihat [Bagaimana cara Amazon EKS bekerja sama dengan IAM](security-iam-service-with-iam.md).
+ Untuk mempelajari cara menyediakan akses ke sumber daya Anda di seluruh AWS akun yang Anda miliki, lihat [Menyediakan akses ke pengguna IAM di AWS akun lain yang Anda miliki](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) di *Panduan Pengguna IAM*.
+ Untuk mempelajari cara menyediakan akses ke sumber daya Anda ke AWS akun pihak ketiga, lihat [Menyediakan akses ke AWS akun yang dimiliki oleh pihak ketiga](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) di *Panduan Pengguna IAM*.
+ Untuk mempelajari cara memberikan akses melalui federasi identitas, lihat [Menyediakan akses ke pengguna terautentikasi eksternal (federasi identitas)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dalam *Panduan Pengguna IAM*.
+ *Untuk mempelajari perbedaan antara menggunakan peran dan kebijakan berbasis sumber daya untuk akses lintas akun, lihat [Akses sumber daya lintas akun di IAM di Panduan Pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html).*
## Kontainer pod menerima kesalahan berikut: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`
Container Anda menerima kesalahan ini jika aplikasi Anda secara eksplisit membuat permintaan ke AWS STS global endpoint (`https://sts.amazonaws`) dan akun layanan Kubernetes Anda dikonfigurasi untuk menggunakan endpoint regional. Anda dapat menyelesaikan masalah dengan salah satu opsi berikut:
+ Perbarui kode aplikasi Anda untuk menghapus panggilan eksplisit ke titik akhir global AWS STS.
+ Perbarui kode aplikasi Anda untuk membuat panggilan eksplisit ke titik akhir regional seperti. `https://sts.us-west-2.amazonaws.com` Aplikasi Anda harus memiliki redundansi bawaan untuk memilih 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.
+ Konfigurasikan akun layanan Anda untuk menggunakan titik akhir global. Cluster menggunakan endpoint regional secara default. Lihat informasi yang lebih lengkap di [Konfigurasikan titik akhir Layanan Token AWS Keamanan untuk akun layanan](configure-sts-endpoint.md).
# IAM role klaster Amazon EKS
Peran IAM klaster Amazon EKS diperlukan untuk setiap cluster. Cluster Kubernetes yang dikelola oleh Amazon EKS menggunakan peran ini untuk mengelola node dan [Cloud Provider lama](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) menggunakan peran ini untuk membuat penyeimbang beban dengan Elastic Load Balancing untuk layanan.
Sebelum Anda dapat membuat klaster Amazon EKS, Anda harus membuat peran IAM dengan salah satu kebijakan IAM berikut:
+ [EKSClusterKebijakan Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ Kebijakan IAM khusus. Izin minimal yang mengikuti memungkinkan klaster Kubernetes untuk mengelola node, tetapi tidak mengizinkan [Penyedia Cloud lama](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) untuk membuat penyeimbang beban dengan Elastic Load Balancing. Kebijakan IAM kustom Anda harus memiliki setidaknya izin berikut:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**catatan**
Sebelum 3 Oktober 2023, [EKSClusterKebijakan Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) diperlukan pada peran IAM untuk setiap cluster.
Sebelum 16 April 2020, [EKSServiceKebijakan Amazon dan EKSCluster Kebijakan](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) [Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) diperlukan dan nama yang disarankan untuk peran tersebut adalah`eksServiceRole`. Dengan peran `AWSServiceRoleForAmazonEKS` terkait layanan, [EKSServicekebijakan Kebijakan Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) tidak lagi diperlukan untuk klaster yang dibuat pada atau setelah 16 April 2020.
## Periksa apakah peran klaster sudah ada
Anda dapat menggunakan prosedur berikut untuk memeriksa dan melihat apakah akun Anda sudah memiliki peran klaster Amazon EKS.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Cari daftar peran untuk `eksClusterRole`. Jika peran yang menyertakan `eksClusterRole` tidak ada, maka lihat [Membuat peran klaster Amazon EKS](#create-service-role) untuk membuat peran tersebut. Jika peran yang mencakup `eksClusterRole` ada, kemudian pilih peran untuk melihat kebijakan terlampir.
1. Pilih **Izin**.
1. Pastikan kebijakan terkelola **EKSClusterKebijakan Amazon** dilampirkan pada peran tersebut. Jika kebijakan terlampir, tandanya peran klaster Amazon EKS Anda dikonfigurasi dengan benar.
1. Pilih **Trust relationship**, lalu pilih **Edit trust policy**.
1. Verifikasi bahwa hubungan kepercayaan berisi kebijakan berikut. Jika hubungan kepercayaan sesuai dengan kebijakan berikut, pilih **Cancel** (Batalkan). Jika hubungan kepercayaan tidak cocok, salin kebijakan ke jendela **Edit kebijakan kepercayaan** dan pilih **Perbarui kebijakan**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Membuat peran klaster Amazon EKS
Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI untuk membuat peran cluster.
Konsol Manajemen AWS
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Pilih **Peran**, kemudian **Buat peran**.
1. Di bawah **Jenis entitas tepercaya**, pilih ** AWS layanan**.
1. **Dari daftar dropdown **Use case for other AWS services**, pilih EKS.**
1. Pilih **EKS - Cluster** untuk kasus penggunaan Anda, lalu pilih **Berikutnya**.
1. Pada tab **Tambahkan izin**, pilih **Berikutnya**.
1. Untuk **nama Peran**, masukkan nama unik untuk peran Anda, seperti`eksClusterRole`.
1. Untuk **Deskripsi**, masukkan teks deskriptif seperti`Amazon EKS - Cluster role`.
1. Pilih **Buat peran**.
AWS CLI
1. Salin isi berikut ke file bernama *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Buat peran. Anda dapat mengganti *eksClusterRole* dengan nama apa pun yang Anda pilih.
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Lampirkan kebijakan IAM yang diperlukan ke peran tersebut.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# IAM role simpul Amazon EKS
`kubelet`Daemon simpul Amazon EKS melakukan panggilan ke AWS APIs atas nama Anda. Simpul menerima izin untuk panggilan API ini melalui profil instans IAM dan kebijakan terkait. Sebelum Anda dapat memulai node dan mendaftarkannya ke sebuah klaster, Anda harus membuat IAM role untuk node tersebut agar digunakan saat node diluncurkan. Persyaratan ini berlaku untuk node yang diluncurkan dengan AMI Amazon EKS yang dioptimalkan yang disediakan oleh Amazon, atau dengan node lain AMIs yang ingin Anda gunakan. Selain itu, persyaratan ini berlaku untuk grup node terkelola dan node yang dikelola sendiri.
**catatan**
Anda tidak dapat menggunakan peran yang sama yang digunakan untuk membuat cluster apa pun.
Sebelum membuat node, Anda harus membuat peran IAM dengan izin berikut:
+ Izin `kubelet` untuk mendeskripsikan EC2 sumber daya Amazon di VPC, seperti yang disediakan oleh kebijakan [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html). Kebijakan ini juga memberikan izin untuk Agen Identitas Pod Amazon EKS.
+ [Izin `kubelet` untuk menggunakan gambar kontainer dari Amazon Elastic Container Registry (Amazon ECR) Registry ECR), seperti yang disediakan oleh kebijakan Amazon. EC2 ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) Izin untuk menggunakan image kontainer dari Amazon Elastic Container Registry (Amazon ECR) diperlukan karena add-on bawaan untuk pod yang menjalankan jaringan yang menggunakan image kontainer dari Amazon ECR.
+ (Opsional) Izin untuk Amazon EKS Pod Identity Agent untuk menggunakan `eks-auth:AssumeRoleForPodIdentity` action tersebut guna mengambil kredensial Pod. Jika Anda tidak menggunakan [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html), maka Anda harus memberikan izin ini selain EC2 izin untuk menggunakan EKS Pod Identity.
+ (Opsional) Jika Anda tidak menggunakan IRSA atau EKS Pod Identity untuk memberikan izin ke pod VPC CNI, maka Anda harus memberikan izin untuk VPC CNI pada peran instance. Anda dapat menggunakan kebijakan [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html)terkelola (jika Anda membuat klaster dengan `IPv4` keluarga) atau [IPv6 kebijakan yang Anda buat](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (jika Anda membuat klaster dengan `IPv6` keluarga). Namun, alih-alih melampirkan kebijakan ke peran ini, sebaiknya Anda melampirkan kebijakan tersebut ke peran terpisah yang digunakan khusus untuk add-on Amazon VPC CNI. Untuk informasi selengkapnya tentang membuat peran terpisah untuk add-on Amazon VPC CNI, lihat. [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md)
**catatan**
Grup EC2 node Amazon harus memiliki peran IAM yang berbeda dari profil Fargate. Untuk informasi selengkapnya, lihat [Peran IAM eksekusi Pod Amazon EKS](pod-execution-role.md).
## Periksa apakah peran simpul sudah ada
Anda dapat menggunakan prosedur berikut untuk memeriksa dan melihat apakah akun Anda sudah memiliki peran simpul Amazon EKS.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Cari daftar peran untuk`eksNodeRole`,`AmazonEKSNodeRole`, atau`NodeInstanceRole`. Jika peran dengan salah satu nama itu tidak ada, maka lihat [Membuat IAM role simpul Amazon EKS](#create-worker-node-role) untuk membuat peran tersebut. Jika peran yang berisi`eksNodeRole`,`AmazonEKSNodeRole`, atau `NodeInstanceRole` memang ada, maka pilih peran untuk melihat kebijakan terlampir.
1. Pilih **Izin**.
1. Pastikan kebijakan EC2 ContainerRegistryPullOnly terkelola **Amazon EKSWorker NodePolicy** **dan Amazon** dilampirkan ke peran atau kebijakan khusus dilampirkan dengan izin minimal.
**catatan**
Jika kebijakan **AmazonEKS\$1CNI\$1Policy** terlampir pada peran, sebaiknya hapus dan lampirkan kebijakan tersebut ke IAM role yang dipetakan ke akun layanan `aws-node` Kubernetes sebagai gantinya. Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
1. Pilih **Trust relationship**, lalu pilih **Edit trust policy**.
1. Verifikasi bahwa hubungan kepercayaan berisi kebijakan berikut. Jika hubungan kepercayaan sesuai dengan kebijakan berikut, pilih **Cancel** (Batalkan). Jika hubungan kepercayaan tidak cocok, salin kebijakan ke jendela **Edit kebijakan kepercayaan** dan pilih **Perbarui kebijakan**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Membuat IAM role simpul Amazon EKS
Anda dapat membuat peran IAM node dengan Konsol Manajemen AWS atau AWS CLI.
Konsol Manajemen AWS
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Pada halaman **Peran**, pilih **Buat peran**.
1. Pada halaman **Pilih entitas tepercaya**, lakukan hal berikut:
1. Di bagian **Jenis entitas tepercaya**, pilih ** AWS layanan**.
1. Di bawah **Kasus penggunaan**, pilih **EC2**.
1. Pilih **Berikutnya**.
1. Pada halaman **Tambahkan izin**, lampirkan kebijakan khusus atau lakukan hal berikut:
1. Di dalam kotak **Filter kebijakan**, masukkan `AmazonEKSWorkerNodePolicy`.
1. Pilih kotak centang di sebelah kiri **Amazon EKSWorker NodePolicy** di hasil pencarian.
1. Pilih **Hapus filter**.
1. Di dalam kotak **Filter kebijakan**, masukkan `AmazonEC2ContainerRegistryPullOnly`.
1. Pilih kotak centang di sebelah kiri **Amazon EC2 ContainerRegistryPullOnly** di hasil pencarian.
[Kebijakan terkelola **Amazoneks\$1CNI\$1Policy**, atau kebijakan yang Anda buat juga harus dilampirkan pada peran ini atau IPv6 peran lain yang dipetakan ke akun layanan Kubernetes.](cni-iam-role.md#cni-iam-role-create-ipv6-policy) `aws-node` Sebaiknya tetapkan kebijakan ke peran yang terkait dengan akun layanan Kubernetes, alih-alih menugaskannya ke peran ini. Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
1. Pilih **Berikutnya**.
1. Pada halaman **Nama, tinjau, dan buat**, lakukan hal berikut:
1. Untuk **nama Peran**, masukkan nama unik untuk peran Anda, seperti`AmazonEKSNodeRole`.
1. Untuk **Deskripsi**, ganti teks saat ini dengan teks deskriptif seperti`Amazon EKS - Node role`.
1. Di bawah **Tambahkan tag (Opsional)**, tambahkan metadata ke peran dengan melampirkan tag sebagai pasangan nilai kunci. Untuk informasi selengkapnya tentang penggunaan tanda di IAM, lihat [Menandai sumber daya IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) di *Panduan Pengguna IAM*.
1. Pilih **Buat peran**.
AWS CLI
1. Jalankan perintah berikut untuk membuat `node-role-trust-relationship.json` file.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. Buat peran IAM.
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Lampirkan dua kebijakan terkelola IAM yang diperlukan ke peran IAM.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. Lampirkan salah satu kebijakan IAM berikut ke peran IAM tergantung pada keluarga IP mana Anda membuat klaster. Kebijakan harus dilampirkan ke peran ini atau ke peran yang terkait dengan akun `aws-node` layanan Kubernetes yang digunakan untuk plugin Amazon VPC CNI untuk Kubernetes. Sebaiknya tugaskan kebijakan ke dalam peran yang terkait dengan akun layanan Kubernetes. Untuk menetapkan kebijakan ke peran yang terkait dengan akun layanan Kubernetes, lihat. [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md)
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. Salin teks berikut dan simpan ke file bernama `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Buat kebijakan IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Lampirkan kebijakan IAM ke peran IAM. Ganti *111122223333* dengan ID akun Anda.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# Peran IAM kluster Mode Otomatis Amazon EKS
Peran IAM cluster Amazon EKS diperlukan untuk setiap cluster. Cluster Kubernetes yang dikelola oleh Amazon EKS menggunakan peran ini untuk mengotomatiskan tugas rutin untuk penyimpanan, jaringan, dan komputasi penskalaan otomatis.
Sebelum Anda dapat membuat kluster Amazon EKS, Anda harus membuat peran IAM dengan kebijakan yang diperlukan untuk Mode Otomatis EKS. Anda dapat melampirkan kebijakan terkelola AWS IAM yang disarankan, atau membuat kebijakan khusus dengan izin yang setara.
+ [EKSComputeKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSBlock StoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSLoad BalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## Periksa apakah peran klaster sudah ada
Anda dapat menggunakan prosedur berikut untuk memeriksa dan melihat apakah akun Anda sudah memiliki peran klaster Amazon EKS.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Cari daftar peran untuk `AmazonEKSAutoClusterRole`. Jika peran yang menyertakan `AmazonEKSAutoClusterRole` tidak ada, lihat instruksi di bagian berikutnya untuk membuat peran. Jika peran yang mencakup `AmazonEKSAutoClusterRole` ada, kemudian pilih peran untuk melihat kebijakan terlampir.
1. Pilih **Izin**.
1. Pastikan kebijakan terkelola **EKSClusterKebijakan Amazon** dilampirkan pada peran tersebut. Jika kebijakan terlampir, tandanya peran klaster Amazon EKS Anda dikonfigurasi dengan benar.
1. Pilih **Trust relationship**, lalu pilih **Edit trust policy**.
1. Verifikasi bahwa hubungan kepercayaan berisi kebijakan berikut. Jika hubungan kepercayaan sesuai dengan kebijakan berikut, pilih **Cancel** (Batalkan). Jika hubungan kepercayaan tidak cocok, salin kebijakan ke jendela **Edit kebijakan kepercayaan** dan pilih **Perbarui kebijakan**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**catatan**
AWS tidak memerlukan nama `AmazonEKSAutoClusterRole` untuk peran ini.
## Membuat peran klaster Amazon EKS
Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI untuk membuat peran cluster.
### Konsol Manajemen AWS
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Pilih **Peran**, kemudian **Buat peran**.
1. Di bawah **Jenis entitas tepercaya**, pilih ** AWS layanan**.
1. **Dari daftar dropdown **Use case for other AWS services**, pilih EKS.**
1. Pilih **EKS - Cluster** untuk kasus penggunaan Anda, lalu pilih **Berikutnya**.
1. Pada tab **Tambahkan izin**, pilih kebijakan, lalu pilih **Berikutnya**.
+ [EKSComputeKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSBlock StoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSLoad BalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. Untuk **nama Peran**, masukkan nama unik untuk peran Anda, seperti`AmazonEKSAutoClusterRole`.
1. Untuk **Deskripsi**, masukkan teks deskriptif seperti`Amazon EKS - Cluster role`.
1. Pilih **Buat peran**.
### AWS CLI
1. Salin isi berikut ke file bernama *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Buat peran. Anda dapat mengganti *AmazonEKSAutoClusterRole* dengan nama apa pun yang Anda pilih.
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Lampirkan kebijakan IAM yang diperlukan ke peran:
**EKSClusterKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputeKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
# Peran IAM simpul Mode Otomatis Amazon EKS
**catatan**
Anda tidak dapat menggunakan peran yang sama yang digunakan untuk membuat cluster apa pun.
Sebelum membuat node, Anda harus membuat peran IAM dengan kebijakan berikut, atau izin yang setara:
+ [Amazon EKSWorker NodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [Amazon EC2 ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## Periksa apakah peran simpul sudah ada
Anda dapat menggunakan prosedur berikut untuk memeriksa dan melihat apakah akun Anda sudah memiliki peran simpul Amazon EKS.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Cari daftar peran untuk `AmazonEKSAutoNodeRole`. Jika peran dengan salah satu nama itu tidak ada, lihat instruksi di bagian berikutnya untuk membuat peran. Jika peran yang berisi `AmazonEKSAutoNodeRole` memang ada, pilih peran untuk melihat kebijakan terlampir.
1. Pilih **Izin**.
1. Pastikan bahwa kebijakan yang diperlukan di atas terlampir, atau kebijakan khusus yang setara.
1. Pilih **Trust relationship**, lalu pilih **Edit trust policy**.
1. Verifikasi bahwa hubungan kepercayaan berisi kebijakan berikut. Jika hubungan kepercayaan sesuai dengan kebijakan berikut, pilih **Cancel** (Batalkan). Jika hubungan kepercayaan tidak cocok, salin kebijakan ke jendela **Edit kebijakan kepercayaan** dan pilih **Perbarui kebijakan**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Membuat IAM role simpul Amazon EKS
Anda dapat membuat peran IAM node dengan Konsol Manajemen AWS atau AWS CLI.
### Konsol Manajemen AWS
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Pada halaman **Peran**, pilih **Buat peran**.
1. Pada halaman **Pilih entitas tepercaya**, lakukan hal berikut:
1. Di bagian **Jenis entitas tepercaya**, pilih ** AWS layanan**.
1. Di bawah **Kasus penggunaan**, pilih **EC2**.
1. Pilih **Berikutnya**.
1. Pada halaman **Tambahkan izin**, lampirkan kebijakan berikut:
+ [Amazon EKSWorker NodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [Amazon EC2 ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. Pada halaman **Nama, tinjau, dan buat**, lakukan hal berikut:
1. Untuk **nama Peran**, masukkan nama unik untuk peran Anda, seperti`AmazonEKSAutoNodeRole`.
1. Untuk **Deskripsi**, ganti teks saat ini dengan teks deskriptif seperti`Amazon EKS - Node role`.
1. Di bawah **Tambahkan tag (Opsional)**, tambahkan metadata ke peran dengan melampirkan tag sebagai pasangan nilai kunci. Untuk informasi selengkapnya tentang penggunaan tanda di IAM, lihat [Menandai sumber daya IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) di *Panduan Pengguna IAM*.
1. Pilih **Buat peran**.
### AWS CLI
**Buat Peran IAM Node**
Gunakan **node-trust-policyfile.json** dari langkah sebelumnya untuk menentukan entitas mana yang dapat mengambil peran. Jalankan perintah berikut untuk membuat Peran IAM Node:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**Perhatikan Peran ARN**
Setelah membuat peran, ambil dan simpan ARN dari Peran IAM Node. Anda akan membutuhkan ARN ini pada langkah selanjutnya. Gunakan perintah berikut untuk mendapatkan ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**Lampirkan Kebijakan yang Diperlukan**
Lampirkan kebijakan AWS terkelola berikut ke Peran IAM Node untuk memberikan izin yang diperlukan:
Untuk melampirkan Amazon EKSWorkerNodeMinimalPolicy:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
Untuk melampirkan Amazon EC2ContainerRegistryPullOnly:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
# Peran IAM kemampuan Amazon EKS
Kemampuan EKS membutuhkan peran IAM kemampuan (atau peran kemampuan) untuk dikonfigurasi. Kemampuan menggunakan peran ini untuk melakukan tindakan pada AWS layanan dan mengakses sumber daya Kubernetes di klaster Anda melalui entri akses yang dibuat secara otomatis.
Sebelum dapat menentukan peran kapabilitas selama pembuatan kapabilitas, Anda harus membuat peran IAM dengan kebijakan kepercayaan dan izin yang sesuai untuk jenis kapabilitas. Setelah peran IAM ini dibuat, itu dapat digunakan kembali untuk sejumlah sumber daya kemampuan.
## Persyaratan peran kemampuan
Peran kemampuan harus memenuhi persyaratan berikut:
+ Peran harus dalam AWS akun yang sama dengan cluster dan sumber daya kemampuan
+ Peran harus memiliki kebijakan kepercayaan yang memungkinkan layanan kemampuan EKS untuk mengambil peran
+ Peran harus memiliki izin yang sesuai untuk jenis kemampuan dan persyaratan kasus penggunaan (lihat[Izin berdasarkan jenis kemampuan](#capability-permissions))
## Kebijakan kepercayaan untuk peran kapabilitas
Semua peran kapabilitas harus mencakup kebijakan kepercayaan berikut:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
Kebijakan kepercayaan ini memungkinkan EKS untuk:
+ Asumsikan peran untuk melakukan operasi AWS API
+ Menandai sesi untuk tujuan audit dan pelacakan
## Izin berdasarkan jenis kemampuan
Izin IAM yang diperlukan bergantung pada kemampuan yang Anda gunakan dan model penerapan Anda.
**catatan**
Untuk penerapan produksi yang menggunakan Penyeleksi Peran IAM dengan ACK, atau saat menggunakan CD kro atau Argo tanpa integrasi AWS layanan, Peran Kemampuan mungkin tidak memerlukan izin IAM apa pun di luar kebijakan kepercayaan.
**kro (Orkestra Sumber Daya Kube)**
Tidak diperlukan izin IAM. Anda dapat membuat peran kapabilitas tanpa kebijakan terlampir. kro hanya membutuhkan izin Kubernetes RBAC untuk membuat dan mengelola sumber daya Kubernetes.
** AWS Pengontrol untuk Kubernetes (ACK)**
ACK mendukung dua model izin:
+ **Pengaturan sederhana (pengembangan/pengujian)**: Tambahkan izin AWS layanan langsung ke Peran Kemampuan. Ini berfungsi dengan baik untuk memulai, penerapan akun tunggal, atau ketika semua pengguna memerlukan izin yang sama.
+ **Praktik terbaik produksi**: Gunakan Penyeleksi Peran IAM untuk menerapkan akses hak istimewa paling sedikit. Dengan pendekatan ini, Peran Kemampuan hanya memerlukan `sts:AssumeRole` izin untuk mengambil peran khusus layanan. Anda tidak menambahkan izin AWS layanan (seperti S3 atau RDS) ke Peran Kemampuan itu sendiri—izin tersebut diberikan kepada peran IAM individual yang dipetakan ke ruang nama tertentu.
Penyeleksi Peran IAM mengaktifkan:
+ Isolasi izin tingkat ruang nama
+ Manajemen sumber daya lintas akun
+ Peran IAM khusus tim
+ Model keamanan dengan hak istimewa paling rendah
Contoh kebijakan Peran Kemampuan untuk pendekatan Pemilih Peran IAM:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
Untuk konfigurasi izin ACK terperinci termasuk Penyeleksi Peran IAM, lihat. [Konfigurasikan izin ACK](ack-permissions.md)
**Argo CD**
Tidak ada izin IAM yang diperlukan secara default. Izin opsional mungkin diperlukan untuk:
+ ** AWS Secrets Manager**: Jika menggunakan Secrets Manager untuk menyimpan kredensi repositori Git
+ ** AWS CodeConnections**: Jika menggunakan CodeConnections untuk otentikasi repositori Git
Contoh kebijakan untuk Secrets Manager dan CodeConnections:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Untuk persyaratan izin CD Argo terperinci, lihat[Pertimbangan Argo CD](argocd-considerations.md).
## Periksa peran kemampuan yang ada
Anda dapat menggunakan prosedur berikut untuk memeriksa apakah akun Anda sudah memiliki peran IAM kemampuan yang sesuai untuk kasus penggunaan Anda.
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Di panel navigasi sebelah kiri, pilih **Peran**.
1. Cari daftar peran untuk nama peran kemampuan Anda (misalnya, `ACKCapabilityRole` atau`ArgoCDCapabilityRole`).
1. Jika ada peran, pilih untuk melihat kebijakan terlampir dan hubungan kepercayaan.
1. Pilih **Trust relationship**, lalu pilih **Edit trust policy**.
1. Verifikasi bahwa hubungan kepercayaan sesuai dengan [kebijakan kepercayaan kemampuan](#capability-trust-policy). Jika tidak cocok, perbarui kebijakan kepercayaan.
1. Pilih **Izin** dan verifikasi bahwa peran tersebut memiliki izin yang sesuai untuk jenis kemampuan dan kasus penggunaan Anda.
## Menciptakan peran IAM kemampuan
Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI untuk membuat peran kemampuan.
** Konsol Manajemen AWS **
1. Buka konsol IAM di https://console.aws.amazon.com/iam/.
1. Pilih **Peran**, kemudian **Buat peran**.
1. Di bawah **Jenis entitas tepercaya**, pilih **Kebijakan kepercayaan khusus**.
1. Salin dan tempel [kebijakan kepercayaan kemampuan](#capability-trust-policy) ke editor kebijakan kepercayaan.
1. Pilih **Berikutnya**.
1. Pada tab **Tambahkan izin**, pilih atau buat kebijakan yang sesuai untuk jenis kemampuan Anda (lihat[Izin berdasarkan jenis kemampuan](#capability-permissions)). Untuk kro, Anda dapat melewati langkah ini.
1. Pilih **Berikutnya**.
1. Untuk **nama Peran**, masukkan nama unik untuk peran Anda, seperti`ACKCapabilityRole`,`ArgoCDCapabilityRole`, atau`kroCapabilityRole`.
1. Untuk **Deskripsi**, masukkan teks deskriptif seperti`Amazon EKS - ACK capability role`.
1. Pilih **Buat peran**.
** AWS CLI**
1. Salin [kebijakan kepercayaan kemampuan](#capability-trust-policy) ke file bernama`capability-trust-policy.json`.
1. Buat peran. Ganti `ACKCapabilityRole` dengan nama peran yang Anda inginkan.
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. Lampirkan kebijakan IAM yang diperlukan ke peran tersebut. Untuk ACK, lampirkan kebijakan untuk AWS layanan yang ingin Anda kelola. Untuk Argo CD, lampirkan kebijakan untuk Secrets Manager atau CodeConnections jika diperlukan. Untuk kro, Anda dapat melewati langkah ini.
Contoh untuk ACK dengan izin S3:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## Memecahkan masalah peran kemampuan
**Pembuatan kemampuan gagal dengan “Peran IAM tidak valid”**
Verifikasi bahwa:
+ Peran ada di akun yang sama dengan cluster
+ Kebijakan kepercayaan sesuai dengan [kebijakan kepercayaan kemampuan](#capability-trust-policy)
+ Anda memiliki `iam:PassRole` izin untuk peran
**Kemampuan menunjukkan kesalahan izin**
Verifikasi bahwa:
+ Peran memiliki izin IAM yang diperlukan untuk jenis kemampuan
+ Entri akses ada di cluster untuk peran tersebut
+ Izin Kubernetes tambahan dikonfigurasi jika diperlukan (lihat) [Izin Kubernetes tambahan](capabilities-security.md#additional-kubernetes-permissions)
**Sumber daya ACK gagal dengan kesalahan “izin ditolak”**
Verifikasi bahwa:
+ Peran memiliki izin IAM yang diperlukan untuk kasus penggunaan Anda
+ Untuk pengontrol ACK yang mereferensikan rahasia, pastikan Anda telah mengaitkan kebijakan entri `AmazonEKSSecretReaderPolicy` akses yang dicakup ke ruang nama yang sesuai.
Untuk panduan pemecahan masalah lainnya, lihat. [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)