Otentikasi ke akun lain dengan IRSA - Amazon EKS
Opsi 1: Buat penyedia identitas dari cluster akun lainOpsi 2: Gunakan operasi berantai AssumeRole

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 dan Tetapkan peran IAM ke akun layanan Kubernetes 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. subNilai menggunakan formatsystem: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 danaccount_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.