Resource Access Management:Pelacakan dan kontrol akses dengan SourceIdentity

Persyaratan format

• Nilai harus terdiri dari 2 hingga 64 karakter.

• Nilai dapat berisi huruf, angka, dan karakter khusus berikut: =, ,, ., @, -, dan _.

• Anda tidak boleh menggunakan awalan yang dicadangkan oleh Alibaba Cloud, seperti acs:, aliyun:, atau alibabacloud:.

Aksi

Contoh konfigurasi aksi

Untuk mengizinkan suatu identitas (pengguna RAM atau peran) menetapkan SourceIdentity saat memanggil AssumeRole, Anda harus memberikan izin sts:SetSourceIdentity baik dalam kebijakan berbasis identitas pihak yang berwenang maupun dalam kebijakan kepercayaan peran target. Hal ini dilakukan dengan menambahkan sts:SetSourceIdentity ke blok Action.

• Contoh kebijakan berbasis identitas (diberikan kepada pemanggil):

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/TARGET_ROLE"
      }
    ]
  }

• Contoh kebijakan kepercayaan (dikonfigurasi pada peran yang akan diasumsikan):

  {
    "Statement": [
      {
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Effect": "Allow",
        "Principal": {
          "RAM": [
            "acs:ram::ACCOUNT_ID:root"
          ]
        }
      }
    ],
    "Version": "1"
  }

Konfigurasi aksi SSO berbasis peran

Saat mengasumsikan peran dengan memanggil operasi AssumeRoleWithSAML atau AssumeRoleWithOIDC, berikan izin sts:SetSourceIdentity hanya dalam kebijakan kepercayaan peran target. Kebijakan berikut merupakan contoh untuk SSO berbasis peran SAML:

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "saml:recipient": [
            "https://signin.aliyun.com/saml-role/sso"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "Federated": [
          "acs:ram::ACCOUNT_ID:saml-provider/PROVIDER_NAME"
        ]
      }
    }
  ],
  "Version": "1"
}

Kunci kondisi

Perbedaan antara kunci kondisi sts:SourceIdentity dan acs:SourceIdentity adalah sebagai berikut:

• sts:SourceIdentity mencocokkan atribut SourceIdentity dalam permintaan asumsi peran.

• acs:SourceIdentity mencocokkan atribut SourceIdentity yang ada dalam sesi peran (termasuk token STS) setelah asumsi peran berhasil.

Untuk asumsi peran awal, Anda harus menggunakan kunci kondisi sts:SourceIdentity dalam kebijakan Anda, termasuk kebijakan berbasis identitas dan kebijakan kepercayaan. Pada tahap ini, belum ada sesi peran yang valid, sehingga penggunaan kunci kondisi acs:SourceIdentity akan menyebabkan asumsi gagal.

Contoh kontrol kondisi

Dengan menggunakan kunci kondisi sts:SourceIdentity dalam blok Condition kebijakan, Anda dapat mewajibkan nilai SourceIdentity tertentu saat mengasumsikan peran. Anda dapat mengonfigurasi kondisi dalam salah satu atau kedua jenis kebijakan berikut:

• Tetapkan kondisi dalam kebijakan berbasis identitas: Membatasi identitas untuk menetapkan nilai SourceIdentity tertentu saat mengasumsikan peran tertentu.

• Tetapkan kondisi dalam kebijakan kepercayaan: Membatasi semua identitas untuk menetapkan nilai SourceIdentity tertentu saat mengasumsikan peran ini.

Aksi sts:SetSourceIdentity juga harus disertakan dalam blok Action kebijakan agar kondisi tersebut berlaku.

Asumsikan terdapat peran RAM dengan hak istimewa tinggi untuk lingkungan produksi bernama prod-role. Administrator perlu menerapkan kontrol berikut:

1. Hanya pengguna RAM Alice dan Bob yang dapat mengasumsikan prod-role.

2. Saat mengasumsikan prod-role, SourceIdentity harus ditetapkan, dan nilainya harus sesuai dengan username pengguna yang mengasumsikan peran tersebut. Misalnya, saat Alice mengasumsikan peran, ia dapat menetapkan nilai ke alice atau alice@exampledomain.com.

Langkah 1: Konfigurasikan kebijakan kepercayaan untuk prod-role

Kebijakan ini memastikan hanya Alice dan Bob yang dapat mengasumsikan peran ini, dan permintaan harus menyertakan nilai SourceIdentity yang diawali dengan alice atau bob.

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": [
            "alice*",
            "bob*"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::ACCOUNT_ID:user/alice",
          "acs:ram::ACCOUNT_ID:user/bob"
        ]
      }
    }
  ],
  "Version": "1"
}

Langkah 2: Konfigurasikan kebijakan berbasis identitas untuk pengguna Alice dan Bob

Kebijakan berikut memberikan izin kepada Alice dan Bob untuk mengasumsikan prod-role dan mewajibkan mereka menetapkan SourceIdentity yang sesuai dengan username masing-masing dalam permintaan.

• Kebijakan berbasis identitas untuk Alice

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/prod-role",
        "Condition": {
          "StringLike": {
            "sts:SourceIdentity": [
              "alice*"
            ]
          }
        }
      }
    ]
  }

• Kebijakan berbasis identitas untuk Bob

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/prod-role",
        "Condition": {
          "StringLike": {
            "sts:SourceIdentity": [
              "bob*"
            ]
          }
        }
      }
    ]
  }

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "saml:recipient": [
            "https://signin.aliyun.com/saml-role/sso"
          ],
          "sts:SourceIdentity": [
            "employeeid-alice",
            "employeeid-bob"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "Federated": [
          "acs:ram::ACCOUNT_ID:saml-provider/PROVIDER_NAME"
        ]
      }
    }
  ],
  "Version": "1"
}

Skenario

Alat otomatisasi CI/CD seperti Jenkins berjalan dengan peran RAM bernama automation-role. Peran ini dapat diasumsikan oleh developer seperti Alice dan Bob.

Seorang developer, seperti Alice, menggunakan alat tersebut untuk menerapkan aplikasi ke Bucket OSS di lingkungan produksi. Tindakan penerapan ini memerlukan asumsi peran dengan hak istimewa lebih tinggi, yaitu deploy-role, yang memiliki izin menulis ke Bucket OSS.

Alice, Bob, dan automation-role berada di Akun Alibaba Cloud A, sedangkan deploy-role berada di Akun Alibaba Cloud B.

Kebutuhan bisnis dan alur kerja

Tujuannya adalah mengizinkan automation-role mengasumsikan deploy-role hanya jika Alice adalah pemanggil awal. Permintaan dari pengguna lain, seperti Bob, harus ditolak.

Alur kerjanya sebagai berikut:

1. Alice memanggil operasi AssumeRole untuk mengasumsikan automation-role dan menetapkan SourceIdentity ke alice dalam permintaan.

2. Setelah automation-role memperoleh token STS, ia memanggil operasi AssumeRole lagi untuk mengasumsikan deploy-role. Nilai SourceIdentity secara otomatis diteruskan.

3. Kebijakan kepercayaan deploy-role memeriksa apakah SourceIdentity masuk bernilai alice. Jika validasi berhasil, asumsi peran diizinkan.

Langkah konfigurasi kebijakan

Langkah 1: Modifikasi kebijakan kepercayaan deploy-role

Kebijakan ini hanya mengizinkan permintaan asumsi dari automation-role di akun A, dan hanya jika nilai SourceIdentity adalah alice.

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "acs:SourceIdentity": [
            "alice"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::ACCOUNT_A_ID:role/automation-role"
        ]
      }
    }
  ],
  "Version": "1"
}

Langkah 2: Modifikasi kebijakan izin dan kepercayaan automation-role

• Kebijakan berbasis identitas: Mengizinkan peran automation-role mengasumsikan peran deploy-role di akun B.

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_B_ID:role/deploy-role"
      }
    ]
  }

• Kebijakan kepercayaan: Mengizinkan Alice dan Bob mengasumsikan automation-role.

  {
    "Statement": [
      {
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Effect": "Allow",
        "Principal": {
          "RAM": [
            "acs:ram::ACCOUNT_A_ID:user/alice",
            "acs:ram::ACCOUNT_A_ID:user/bob"
          ]
        }
      }
    ],
    "Version": "1"
  }

Langkah 3: Modifikasi kebijakan berbasis identitas untuk Alice dan Bob

Izinkan mereka mengasumsikan peran automation-role dan wajibkan mereka menetapkan nilai SourceIdentity yang persis sesuai dengan username mereka.

• Kebijakan berbasis identitas untuk Alice

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_A_ID:role/automation-role",
        "Condition": {
          "StringEquals": {
            "sts:SourceIdentity": [
              "alice"
            ]
          }
        }
      }
    ]
  }

• Kebijakan berbasis identitas untuk Bob

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_A_ID:role/automation-role",
        "Condition": {
          "StringEquals": {
            "sts:SourceIdentity": [
              "bob"
            ]
          }
        }
      }
    ]
  }

Skenario 1: Masalah kebijakan berbasis identitas

Pesan Error:

{
  "RequestId": "AC9DDEC1-3E1F-50B8-A2D1-BAA155FD****",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. You should be authorized by RAM.",
  "AccessDeniedDetail": {
    "PolicyType": "AccountLevelIdentityBasedPolicy",
    "AuthAction": "sts:SetSourceIdentity",
    ...
  }
}

Penyebab:

• "PolicyType": "AccountLevelIdentityBasedPolicy" menunjukkan bahwa error disebabkan oleh kebijakan berbasis identitas pemanggil.

• "AuthAction": "sts:SetSourceIdentity" menunjukkan bahwa izin untuk aksi sts:SetSourceIdentity tidak tersedia.

Solusi: Minta administrator Anda memeriksa kebijakan berbasis identitas pemanggil dan pastikan hal-hal berikut:

1. Kebijakan mencakup "Action": "sts:SetSourceIdentity".

2. Cakupan Resource kebijakan mencakup peran target yang ingin diasumsikan.

3. Jika kebijakan berisi Condition, pastikan nilai SourceIdentity dalam permintaan Anda memenuhi kondisi tersebut.

Skenario 2: Masalah kebijakan kepercayaan

Pesan Error:

{
  "RequestId": "ECC91EE1-0EB0-5E79-B3F5-E54FD8B9****",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. You should be authorized by RAM.",
  "AccessDeniedDetail": {
    "PolicyType": "AssumeRolePolicy",
    "AuthAction": "sts:SetSourceIdentity",
    ...
  }
}

Penyebab:

• "PolicyType": "AssumeRolePolicy" menunjukkan bahwa error disebabkan oleh kebijakan kepercayaan peran target.

• "AuthAction": "sts:SetSourceIdentity" menunjukkan bahwa peran target tidak mempercayai aksi sts:SetSourceIdentity.

Solusi: Minta administrator Anda memeriksa kebijakan kepercayaan peran target dan pastikan hal-hal berikut:

1. Kebijakan mencakup "Action": "sts:SetSourceIdentity".

2. Jika kebijakan berisi Condition, pastikan nilai SourceIdentity dalam permintaan Anda memenuhi kondisi tersebut.

Saran troubleshooting umum

1. Persempit cakupan: Jika Anda mengalami masalah izin saat menetapkan SourceIdentity, coba hapus parameter SourceIdentity dan asumsikan peran kembali. Jika tindakan berhasil, kemungkinan besar masalahnya terletak pada pengaturan izin terkait SourceIdentity.

2. Analisis pesan error: Baca bagian AccessDeniedDetail dari pesan error, terutama bidang PolicyType. Informasi ini dapat membantu Anda dengan cepat menentukan apakah masalah berasal dari kebijakan berbasis identitas atau kebijakan kepercayaan.

3. Gunakan alat diagnostik: Jika Anda hanya memiliki RequestId, Anda dapat menggunakan alat OpenAPI Explorer. Masukkan RequestId, dan sistem akan mengembalikan informasi diagnostik terperinci untuk membantu Anda mengidentifikasi masalah izin. Contohnya:

   Hasil diagnostik menunjukkan ErrorCode NoPermission dan ErrorMessage You are not authorized to do this action. You should be authorized by RAM.. Kesimpulan pemeriksaan izin adalah Tidak diizinkan oleh kebijakan berbasis identitas (tingkat akun) untuk aksi sts:SetSourceIdentity. Solusinya menyarankan pemberian kebijakan sistem AliyunSTSAssumeRoleAccess kepada pengguna RAM, yang terkait dengan sts:SetSourceIdentity, atau membuat kebijakan kustom.

4. Bandingkan kebijakan dan permintaan: Setelah menemukan kebijakan yang relevan, periksa apakah pengaturan Resource dan Condition sesuai dengan parameter permintaan API Anda, seperti ARN peran target dan nilai SourceIdentity.

Untuk informasi lebih lanjut tentang troubleshooting masalah izin, lihat Cara troubleshooting error akses ditolak.