**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.
# Otentikasi ke akun lain dengan IRSA
Anda dapat mengonfigurasi izin IAM lintas akun baik dengan membuat penyedia identitas dari klaster akun lain atau dengan menggunakan operasi berantai. `AssumeRole` Dalam contoh berikut, *Akun A* memiliki klaster Amazon EKS yang mendukung peran IAM untuk akun layanan. Pod yang berjalan di klaster tersebut harus mengasumsikan izin IAM dari *Akun* B.
+ **Opsi 1** lebih sederhana tetapi membutuhkan Akun B untuk membuat dan mengelola penyedia identitas OIDC untuk klaster Akun A.
+ **Opsi 2** membuat manajemen OIDC di Akun A tetapi membutuhkan rantai peran melalui dua panggilan. `AssumeRole`
## Opsi 1: Buat penyedia identitas dari cluster akun lain
Dalam contoh ini, Akun A menyediakan Akun B dengan URL penerbit OpenID Connect (OIDC) dari klaster mereka. Akun B mengikuti petunjuk dalam [Membuat penyedia IAM OIDC untuk klaster Anda](enable-iam-roles-for-service-accounts.md) dan [Tetapkan peran IAM ke akun layanan Kubernetes](associate-service-account-role.md) menggunakan URL penerbit OIDC dari klaster Akun A. Kemudian, administrator klaster memberi anotasi pada akun layanan di klaster Akun A untuk menggunakan peran dari Akun B (){{444455556666}}.
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
```
## Opsi 2: Gunakan operasi berantai `AssumeRole`
Dalam pendekatan ini, setiap akun membuat peran IAM. Peran Akun B mempercayai Akun A, dan peran Akun A menggunakan federasi OIDC untuk mendapatkan kredensi dari klaster. Pod kemudian menghubungkan kedua peran tersebut bersama-sama menggunakan profil AWS CLI.
### Langkah 1: Buat peran target di Akun B
Akun B ({{444455556666}}) membuat peran IAM dengan izin yang dibutuhkan Pod di klaster Akun A. Akun B melampirkan kebijakan izin yang diinginkan ke peran ini, lalu menambahkan kebijakan kepercayaan berikut.
**Kebijakan kepercayaan untuk peran Akun B** — Kebijakan ini memungkinkan peran IRSA spesifik Akun A untuk mengambil peran ini.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**penting**
Untuk hak istimewa terkecil, ganti `Principal` ARN dengan peran spesifik ARN dari Akun A alih-alih menggunakan root akun (). `arn:aws:iam::111122223333:root` Menggunakan root akun memungkinkan *setiap* prinsipal IAM di Akun A untuk mengambil peran ini.
### Langkah 2: Buat peran IRSA di Akun A
Akun A ({{111122223333}}) membuat peran dengan kebijakan kepercayaan yang mendapatkan kredensional dari penyedia identitas yang dibuat dengan alamat penerbit OIDC klaster.
**Kebijakan kepercayaan untuk peran Akun A (federasi OIDC)** — Kebijakan ini memungkinkan penyedia OIDC klaster EKS untuk mengeluarkan kredensi untuk peran ini.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**penting**
Untuk sedikit hak istimewa, tambahkan `StringEquals` kondisi untuk `sub` klaim untuk membatasi peran ini ke akun layanan Kubernetes tertentu. Tanpa `sub` syarat, akun layanan apa pun di cluster dapat mengambil peran ini. `sub`Nilai menggunakan format`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Misalnya, untuk membatasi ke akun layanan bernama `my-service-account` di `default` namespace:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### Langkah 3: Lampirkan AssumeRole izin ke peran Akun A
Akun A melampirkan kebijakan izin ke peran yang dibuat di Langkah 2. Kebijakan ini memungkinkan peran untuk mengambil peran Akun B.
**Kebijakan izin untuk peran Akun A** — Kebijakan ini memberikan `sts:AssumeRole` peran target Akun B.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### Langkah 4: Konfigurasikan Pod ke peran rantai
Kode aplikasi untuk Pod untuk mengambil peran Akun B menggunakan dua profil: `account_b_role` dan`account_a_role`. Profil `account_b_role` menggunakan profil `account_a_role` sebagai sumbernya. Untuk AWS CLI, `~/.aws/config` file ini mirip dengan yang berikut ini.
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws: iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws: iam::111122223333:role/account-a-role
```
Untuk menentukan profil berantai untuk lainnya AWS SDKs, lihat dokumentasi SDK yang Anda gunakan. Untuk informasi selengkapnya, lihat [Alat untuk Dibangun AWS](https://aws.amazon.com/developer/tools/).