**Bantu meningkatkan 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 GitHub ** tautan ** Edit halaman ini di 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/).