**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.

# Pertimbangan keamanan untuk Kemampuan EKS
<a name="capabilities-security"></a>

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
<a name="_capability_iam_role"></a>

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
<a name="_eks_access_entries"></a>

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
<a name="additional-kubernetes-permissions"></a>

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.

<a name="kro-resource-permissions"></a> **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
<a name="_iam_permissions_required_by_capability"></a>

 **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
<a name="_security_best_practices"></a>

### Hak istimewa IAM paling sedikit
<a name="_iam_least_privilege"></a>

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
<a name="_namespace_isolation_for_argo_cd_secrets"></a>

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
<a name="_kubernetes_rbac"></a>

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
<a name="_audit_logging"></a>

 **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
<a name="_network_access_and_vpc_endpoints"></a>

#### Akses API CD Argo pribadi
<a name="_private_argo_cd_api_access"></a>

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
<a name="_deploying_to_private_clusters"></a>

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
<a name="_compliance"></a>

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
<a name="_next_steps"></a>
+  [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