Memberi akses perwakilan layanan ke Azure

  • 6 menit

Dengan sendirinya, perwakilan layanan tidak dapat melakukan apa pun di lingkungan Azure Anda. Ini seperti bagaimana pengguna tidak dapat bekerja dengan sumber daya Azure Anda kecuali mereka diizinkan untuk melakukannya. Di unit ini, Anda akan mempelajari cara mengotorisasi perwakilan layanan untuk menyebarkan dan mengonfigurasi sumber daya Azure, sambil menghindari pemberian izin yang tidak perlu.

Catatan

Perintah dalam unit ini ditampilkan untuk mengilustrasikan konsep. Jangan jalankan perintah terlebih dahulu. Anda akan segera mempraktikkan apa yang Anda pelajari di sini.

Otorisasi perwakilan layanan

Hingga saat ini, Anda telah berfokus pada apa itu perwakilan layanan dan bagaimana perwakilan layanan tersebut dapat digunakan untuk membuktikan identitas alur ke ID Microsoft Entra. Ini semua tentang autentikasi.

Setelah ID Microsoft Entra mengautentikasi perwakilan layanan, pertanyaan berikutnya menjadi: apa yang dapat dilakukan perwakilan layanan ini? Ini adalah konsep otorisasi. Ini adalah tanggung jawab sistem kontrol akses berbasis peran (RBAC) Azure, terkadang disebut manajemen akses dan identitas (IAM). Dengan menggunakan Azure RBAC, Anda dapat memberikan akses utama layanan ke grup sumber daya, langganan, atau grup manajemen tertentu.

Catatan

Semua yang Anda lakukan di sini menggunakan sistem Azure RBAC untuk memberikan akses guna membuat dan mengelola sumber daya Azure, seperti akun penyimpanan, paket App Service, dan jaringan virtual Anda. MICROSOFT Entra ID juga memiliki sistem perannya sendiri, yang terkadang disebut peran direktori. Anda menggunakan peran ini untuk memberikan izin bagi perwakilan layanan untuk mengelola ID Microsoft Entra. Modul ini tidak membahas subjek ini secara mendalam, namun perlu diketahui bahwa istilah peran dapat digunakan untuk kedua situasi dalam beberapa dokumentasi.

Memilih penetapan peran yang tepat untuk alur Anda

Penetapan peran memiliki tiga bagian utama: kepada siapa peran tersebut diberikan (penerima tugas), apa yang dapat dilakukan (peran), dan sumber daya atau sumber daya apa yang diterapkan oleh penetapan peran (cakupan).

Penerima tugas

Saat Anda bekerja dengan perwakilan layanan, Anda menetapkan peran untuk perwakilan layanan tersebut. Anda menggunakan ID aplikasi perwakilan layanan untuk mengidentifikasi perwakilan layanan yang benar untuk penerima tugas tersebut.

Role

Mungkin perlu sedikit lebih banyak pekerjaan untuk mencari tahu peran mana yang harus ditetapkan. Di Azure, ada beberapa peran umum:

  • Pembaca, yang memungkinkan penerima tugas untuk membaca informasi tentang sumber daya tetapi tidak mengubah atau menghapusnya.
  • Kontributor, yang memungkinkan penerima tugas untuk membuat sumber daya, dan untuk membaca dan mengubah sumber daya yang ada. Namun, kontributor tidak dapat memberikan akses kepada perwakilan layanan lain ke sumber daya.
  • Pemilik, yang memungkinkan kontrol penuh atas sumber daya, termasuk memberikan akses kepada perwakilan layanan lainnya.

Perhatian

Anda hanya boleh memberikan izin minimum yang diperlukan perwakilan layanan untuk melakukan pekerjaannya. Sering kali, peran Pemilik terlalu permisif untuk alur penyebaran.

Ada juga banyak peran khusus yang menyediakan akses hanya ke sebagian fungsi. Anda juga dapat membuat definisi peran kustom Anda sendiri untuk menentukan daftar izin yang tepat yang ingin Anda tetapkan.

Catatan

Definisi peran kustom dapat menjadi cara yang ampuh untuk memberikan izin untuk sumber daya Azure Anda, tetapi definisi peran kustom bisa sulit untuk digunakan. Tidak selalu mudah untuk menentukan dengan tepat izin mana yang perlu Anda tambahkan ke definisi peran kustom, dan Anda mungkin secara tidak sengaja membuat definisi peran terlalu ketat atau terlalu permisif. Jika Anda tidak yakin apa yang harus dilakukan, sebaiknya gunakan salah satu definisi peran bawaan. Definisi peran kustom berada di luar cakupan modul ini.

Cakupan

Anda perlu menentukan seberapa luas Anda menetapkan peran. Keputusan ini memengaruhi jumlah sumber daya yang dapat diubah oleh perwakilan layanan. Cakupan umum meliputi:

  • Sumber daya tunggal: Anda dapat memberikan akses hanya ke sumber daya tertentu. Biasanya, alur penyebaran tidak menggunakan cakupan ini karena alur membuat sumber daya yang belum ada, atau mengonfigurasi ulang beberapa sumber daya.
  • Grup sumber daya: Anda dapat memberikan akses ke semua sumber daya dalam grup sumber daya. Kontributor dan Pemilik juga dapat membuat sumber daya dalam grup. Ini adalah pilihan yang baik untuk banyak alur penyebaran.
  • Langganan: Anda dapat memberikan akses ke semua sumber daya dalam langganan. Jika Anda memiliki beberapa aplikasi, beban kerja, atau lingkungan dalam satu langganan, Anda dapat memberikan izin ke cakupan langganan. Ini biasanya terlalu permisif untuk alur penyebaran. Sebagai gantinya, Anda harus mempertimbangkan untuk mencakup penetapan peran Anda ke grup sumber daya, kecuali alur kerja penyebaran Anda sendiri perlu membuat grup sumber daya.

Ingat bahwa penetapan peran diwariskan. Jika Anda menetapkan peran di langganan, penerima tugas akan memiliki akses ke setiap grup sumber daya dan sumber daya di dalam langganan tersebut.

Memilih penetapan peran yang tepat

Sekarang setelah Anda memahami komponen penetapan peran, Anda dapat memutuskan nilai yang sesuai untuk skenario Anda. Berikut adalah beberapa panduan umum untuk dipertimbangkan:

  • Gunakan peran paling tidak permisif yang Anda bisa. Jika alur Anda hanya akan menyebarkan templat Bicep dasar dan tidak akan mengelola penetapan peran, jangan gunakan peran Pemilik.
  • Gunakan cakupan tersempit yang Anda bisa. Sebagian besar alur hanya perlu menyebarkan sumber daya ke grup sumber daya, sehingga alur tidak boleh diberikan penetapan peran yang tercakup dalam langganan.
  • Untuk banyak alur, opsi default yang baik untuk penetapan peran adalah peran Kontributor pada cakupan grup sumber daya.
  • Pertimbangkan semua yang dilakukan alur Anda, dan semua yang mungkin dilakukannya di masa depan. Misalnya, Anda mungkin mempertimbangkan untuk membuat definisi peran kustom untuk alur penyebaran situs web Anda dan hanya memberikan izin untuk App Service dan Application Insights. Bulan depan, Anda mungkin perlu menambahkan akun Azure Cosmos DB ke file Bicep Anda, tetapi peran kustom akan memblokir pembuatan sumber daya Azure Cosmos DB. Sebagai gantinya, sering kali lebih baik menggunakan peran bawaan, atau kombinasi peran bawaan, untuk menghindari keharusan mengubah definisi peran Anda berulang kali. Pertimbangkan untuk menggunakan Azure Policy untuk memberlakukan persyaratan pemerintahan Anda untuk layanan, SKU, dan lokasi yang diizinkan.
  • Uji alur untuk memverifikasi bahwa penetapan peran berfungsi.

Mencampur dan mencocokkan penetapan peran

Anda dapat membuat beberapa penetapan peran yang memberikan izin berbeda pada cakupan yang berbeda. Misalnya, Anda dapat menetapkan perwakilan layanan peran Pembaca dengan cakupan seluruh langganan, dan kemudian secara terpisah menetapkan perwakilan layanan yang sama peran Kontributor untuk grup sumber daya tertentu. Saat perwakilan layanan mencoba bekerja dengan grup sumber daya, penetapan yang lebih permisif diterapkan.

Bekerja dengan beberapa lingkungan

Anda mungkin bekerja dengan beberapa lingkungan, seperti lingkungan pengembangan, pengujian, dan produksi untuk aplikasi Anda. Sumber daya untuk setiap lingkungan harus disebarkan ke grup sumber daya atau langganan yang berbeda.

Anda harus membuat perwakilan layanan terpisah untuk setiap lingkungan, dan memberikan setiap perwakilan layanan kumpulan izin minimum yang diperlukan untuk penyebarannya. Berhati-hatilah untuk menghindari pencampuran izin untuk penyebaran produksi dengan izin untuk penyebaran ke lingkungan non-produksi.

Membuat penetapan peran untuk perwakilan layanan

Untuk membuat penetapan peran untuk perwakilan layanan, gunakan perintah az role assignment create. Anda perlu menentukan penerima tugas, peran, dan cakupan:

az role assignment create \
  --assignee b585b740-942d-44e9-9126-f1181c95d497 \
  --role Contributor \
  --scope "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Mari kita lihat setiap argumen:

  • --assignee menentukan perwakilan layanan. Untuk menghindari ambiguitas, ini adalah praktik yang baik untuk menggunakan ID aplikasi.
  • --role menentukan peran. Jika Anda menggunakan peran bawaan, Anda dapat menentukannya berdasarkan nama. Jika Anda menggunakan definisi peran kustom, tentukan ID definisi peran lengkap.
  • --scope menentukan cakupan. Ini biasanya merupakan ID sumber daya untuk sumber daya tunggal, grup sumber daya, atau langganan.
  • --description adalah deskripsi penetapan peran yang dapat dibaca manusia.

Untuk membuat penetapan peran untuk perwakilan layanan, gunakan cmdlet New-AzRoleAssignment. Anda perlu menentukan penerima tugas, peran, dan cakupan:

New-AzRoleAssignment `
  -ApplicationId b585b740-942d-44e9-9126-f1181c95d497 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Mari kita lihat setiap argumen:

  • -ApplicationId menentukan ID pendaftaran aplikasi perwakilan layanan.
  • -RoleDefinitionName menentukan nama peran bawaan. Jika Anda menggunakan definisi peran kustom, tentukan ID definisi peran lengkap menggunakan argumen -RoleDefinitionId sebagai gantinya.
  • -Scope menentukan cakupan. Ini biasanya merupakan ID sumber daya untuk sumber daya tunggal, grup sumber daya, atau langganan.
  • -Description adalah deskripsi penetapan peran yang dapat dibaca manusia.

Tip

Ini adalah praktik yang baik untuk memberikan pembenaran untuk penetapan peran Anda dengan menentukan deskripsi. Deskripsi membantu siapa saja yang meninjau tugas peran nanti untuk memahami tujuan mereka, dan untuk memahami bagaimana Anda memutuskan penerima tugas, peran, dan cakupan.

Catatan

Penetapan peran dapat memakan waktu beberapa menit untuk aktif.

Membuat perwakilan layanan dan penetapan peran dalam satu operasi

Anda juga dapat membuat penetapan peran pada saat yang sama saat Anda membuat perwakilan layanan. Kode ini mirip dengan perintah yang Anda gunakan untuk membuat perwakilan layanan di unit sebelumnya, tetapi dengan beberapa argumen tambahan:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

Memberikan akses menggunakan Bicep

Penetapan peran adalah sumber daya Azure. Ini berarti Anda dapat membuat penetapan peran menggunakan Bicep. Anda mungkin melakukan ini jika Anda menginisialisasi grup sumber daya Anda menggunakan Bicep, lalu menyebarkan sumber daya ke dalam grup sumber daya menggunakan perwakilan layanan. Berikut adalah contoh definisi Bicep untuk penetapan peran di atas:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Mari kita lihat setiap argumen:

  • name adalah pengidentifikasi unik untuk penetapan peran. Ini harus dalam bentuk pengidentifikasi unik global (GUID). Ini adalah praktik yang baik untuk menggunakan fungsi guid() di Bicep untuk membuat GUID, dan menggunakan ID utama, ID definisi peran, dan cakupan sebagai argumen benih untuk fungsi guna memastikan Anda membuat nama yang unik untuk setiap penetapan peran.
  • principalType harus ditetapkan ke ServicePrincipal.
  • roleDefinitionId adalah ID sumber daya yang sepenuhnya memenuhi syarat untuk definisi peran yang Anda tetapkan. Sebagian besar Anda akan bekerja dengan peran bawaan, dan Anda akan menemukan ID definisi peran dalam dokumentasi peran bawaan Azure. Misalnya, peran Kontributor memiliki ID definisi peran b24988ac-6180-42a0-ab88-20f7382dd24c. Saat Anda menetapkannya dalam file Bicep, Anda mengungkapkannya menggunakan ID sumber daya yang sepenuhnya memenuhi syarat, seperti /subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.
  • principalId adalah ID objek perwakilan layanan. Pastikan Anda tidak menggunakan ID aplikasi atau ID objek pendaftaran aplikasi.
  • description adalah deskripsi penetapan peran yang dapat dibaca manusia.