Tata kelola end-to-end di Azure saat menggunakan CI/CD

Saat mengembangkan model tata kelola untuk organisasi Anda, penting untuk diingat bahwa Azure Resource Manager hanyalah salah satu cara untuk mengelola sumber daya. Azure DevOps dan integrasi berkelanjutan dan otomatisasi pengiriman berkelanjutan (CI/CD) dapat menjadi pintu belakang keamanan yang tidak disengaja jika tidak diamankan dengan benar. Sumber daya ini harus dilindungi dengan mencerminkan model kontrol akses berbasis peran (RBAC) yang digunakan untuk Resource Manager.

Konsep tata kelola end-to-end bersifat independen dari vendor mana pun. Implementasi yang dijelaskan di sini menggunakan Azure DevOps, tetapi alternatif juga disebutkan secara singkat.

Kemungkinan kasus penggunaan

Implementasi referensi dan demo ini bersumber terbuka dan dimaksudkan untuk digunakan sebagai alat pengajaran bagi organisasi yang baru menggunakan DevOps dan perlu membuat model tata kelola untuk disebarkan ke Azure. Harap baca skenario ini dengan cermat untuk memahami keputusan di balik model yang digunakan dalam repositori sampel ini.

Model tata kelola apa pun harus terkait dengan aturan bisnis organisasi, yang tercermin dalam implementasi teknis kontrol akses apa pun. Contoh model ini menggunakan perusahaan fiktif dengan skenario umum berikut (dengan persyaratan bisnis):

• Grup Microsoft Entra yang selaras dengan domain bisnis dan model perizinan
  Organisasi ini memiliki banyak domain bisnis vertikal, seperti "buah-buahan" dan "sayuran," yang beroperasi sebagian besar secara independen. Di setiap domain bisnis, ada dua tingkat atau hak akses, yang dipetakan ke grup Microsoft Entra *-admins atau *-devs yang berbeda. Ini memungkinkan pengembang untuk ditargetkan saat mengonfigurasi izin di cloud.

• Lingkungan penyebaran
  Setiap tim memiliki dua lingkungan:

  • Produksi. Hanya admin yang memiliki hak istimewa yang ditingkatkan.
  • Non-produksi aktif. Semua pengembang memiliki hak istimewa yang ditingkatkan (untuk mendorong eksperimen dan inovasi).

• Tujuan automasi
  Setiap aplikasi harus menerapkan Azure DevOps tidak hanya untuk integrasi berkelanjutan (CI), tetapi juga untuk penyebaran berkelanjutan (CD). Misalnya, penyebaran dapat secara otomatis dipicu oleh perubahan pada repositori Git.

• Perjalanan cloud sejauh ini
  Organisasi dimulai dengan model proyek terisolasi untuk mempercepat perjalanan ke cloud. Tetapi sekarang mereka mengeksplorasi opsi untuk memecahkan silo dan mendorong kolaborasi dengan membuat proyek "kolaborasi" dan "supermarket".

Diagram yang disederhanakan ini menunjukkan bagaimana cabang dalam repositori Git dipetakan ke lingkungan pengembangan, staging, dan produksi.

Unduh SVG diagram ini.

Architecture

Diagram ini menunjukkan cara menautkan dari Resource Manager dan CI/CD ke MICROSOFT Entra ID adalah kunci untuk memiliki model tata kelola end-to-end.

Unduh SVG dari arsitektur ini.

Nota

Untuk membuat konsep lebih mudah dipahami, diagram hanya mengilustrasikan domain "veggies" . Domain "buah-buahan" akan terlihat mirip dan menggunakan konvensi penamaan yang sama.

Alur kerja

Penomoran mencerminkan urutan di mana administrator TI dan arsitek perusahaan memikirkan dan mengonfigurasi sumber daya cloud mereka.

1. Microsoft Entra ID

   Kami mengintegrasikan Azure DevOps dengan Microsoft Entra ID agar dapat menyediakan satu bidang untuk pengelolaan identitas. Ini berarti pengembang menggunakan akun Microsoft Entra yang sama untuk Azure DevOps dan Resource Manager. Pengguna tidak ditambahkan satu per satu. Sebagai gantinya, keanggotaan ditetapkan oleh grup Microsoft Entra sehingga kami dapat menghapus akses pengembang ke sumber daya dalam satu langkah—dengan menghapus keanggotaan grup Microsoft Entra mereka. Untuk setiap domain, kami membuat:

   • Grup Microsoft Entra. Dua grup per domain (dijelaskan lebih lanjut di langkah 4 dan 5 di akhir artikel ini).
   • Perwakilan layanan. Satu prinsipal layanan eksplisit per lingkungan.

2. Lingkungan produksi

   Untuk menyederhanakan penyebaran, implementasi referensi ini menggunakan grup sumber daya untuk mewakili lingkungan produksi. Dalam praktiknya, Anda harus menggunakan langganan yang berbeda.

   Akses istimewa ke lingkungan ini hanya terbatas pada administrator.

3. lingkungan Pengembangan

   Untuk menyederhanakan penyebaran, implementasi referensi ini menggunakan grup sumber daya untuk mewakili lingkungan pengembangan. Dalam praktiknya, Anda harus menggunakan langganan yang berbeda.

4. Penetapan peran di Resource Manager

   Meskipun nama grup Microsoft Entra kami menyiratkan peran, kontrol akses tidak diterapkan hingga penetapan peran dikonfigurasi. Ini memberikan peran kepada prinsipal Microsoft Entra untuk cakupan tertentu. Misalnya, pengembang memiliki peran Kontributor pada lingkungan produksi.

   Entitas Utama Microsoft Entra	Lingkungan pengembangan (Resource Manager)	Lingkungan produksi (Resource Manager)
   veggies-devs-group	Owner	Pembaca
   veggies-admins-group	Pemilik	Pemilik
   veggies-ci-dev-sp	Peran Khusus *	–
   veggies-ci-prod-sp	–	Peran Kustom *

   * Untuk menyederhanakan penyebaran, implementasi referensi ini menetapkan peran Owner kepada perwakilan layanan. Namun, dalam produksi, Anda harus membuat peran kustom yang mencegah perwakilan layanan menghapus kunci manajemen apa pun yang telah Anda tempatkan pada sumber daya Anda. Ini membantu melindungi sumber daya dari kerusakan yang tidak disengaja, seperti penghapusan database.

   Untuk memahami penalaran di balik penetapan peran individual, lihat bagian pertimbangan nanti di artikel ini.

5. Penetapan grup keamanan di Azure DevOps

   Grup keamanan berfungsi seperti peran di Resource Manager. Manfaatkan peran bawaan dan atur default ke Kontributor untuk pengembang. Admin ditetapkan ke grup keamanan Administrator Proyek untuk izin yang ditinggikan, memungkinkan mereka mengonfigurasi izin keamanan.

   Perhatikan bahwa Azure DevOps dan Resource Manager memiliki model izin yang berbeda :

   • Azure Resource Manager menggunakan model izin aditif .
   • Azure DevOps menggunakan model izin paling sedikit .

   Untuk alasan ini, keanggotaan dalam grup -admins dan -devs harus saling eksklusif. Jika tidak, orang yang terpengaruh akan memiliki akses yang lebih sedikit dari yang diharapkan di Azure DevOps.

   Nama grup	Tugas Resource Manager	Peran Azure DevOps
   fruits-all	–	–
   fruits-devs	Kontributor	Kontributor
   fruits-admins	Pemilik	Administrator Proyek
   veggies-all	–	–
   veggies-devs	Kontributor	Kontributor
   veggies-admins	Pemilik	Administrator Proyek
   infra-all	–	–
   infra-devs	Kontributor	Kontributor
   infra-admins	Pemilik	Administrator Proyek

   Dalam skenario kolaborasi terbatas, seperti tim buah yang mengundang tim sayuran untuk berkolaborasi dalam satu repositori, mereka akan menggunakan grup veggies-all.

   Untuk memahami penalaran di balik penetapan peran individual, lihat bagian pertimbangan nanti di artikel ini.

6. Koneksi layanan

   Di Azure DevOps, Koneksi Layanan adalah pembungkus generik di sekitar kredensial. Kami membuat koneksi layanan yang menyimpan ID klien perwakilan layanan dan rahasia klien. Administrator Proyek dapat mengonfigurasi akses ke sumber daya yang dilindungi ini saat diperlukan, seperti saat memerlukan persetujuan manusia sebelum menyebarkan. Arsitektur referensi ini memiliki dua perlindungan minimum pada koneksi layanan:

   • Admin harus mengonfigurasi izin alur untuk mengontrol alur mana yang dapat mengakses kredensial.
   • Admin juga harus mengonfigurasi pemeriksaan kontrol cabang sehingga hanya pipeline yang berjalan dalam konteks cabang production dapat menggunakan prod-connection.

7. Repositori Git

   Karena koneksi layanan kami terkait dengan cabang melalui kontrol cabang, sangat penting untuk mengonfigurasi izin ke repositori Git dan menerapkan kebijakan cabang. Selain mengharuskan build CI lulus, kami juga memerlukan permintaan pull untuk memiliki setidaknya dua pemberi persetujuan.

Components

• Azure DevOps
• Microsoft Entra ID
• Manajer Sumber Daya Azure
• Azure Repos
• Azure Pipeline

Alternatives

Konsep tata kelola end-to-end tidak bergantung pada vendor tertentu. Meskipun artikel ini berfokus pada Azure DevOps, Azure DevOps Server dapat digunakan sebagai pengganti lokal. Atau, Anda juga dapat menggunakan serangkaian teknologi untuk alur pengembangan CI/CD sumber terbuka menggunakan opsi seperti Jenkins dan GitLab.

Azure Repos dan GitHub adalah platform yang dibangun untuk menggunakan sistem kontrol versi Git sumber terbuka. Meskipun set fitur mereka agak berbeda, keduanya dapat diintegrasikan ke dalam model tata kelola global untuk CI/CD. GitLab adalah platform berbasis Git lain yang menyediakan kemampuan CI/CD yang kuat.

Skenario ini menggunakan Terraform sebagai alat infrastructure as code (IaC). Alternatifnya termasuk Jenkins, Ansible, dan Chef.

Pertimbangan

Untuk mencapai tata kelola end-to-end di Azure, penting untuk memahami profil keamanan dan izin jalur dari komputer pengembang ke produksi. Diagram berikut mengilustrasikan alur kerja CI/CD garis besar dengan Azure DevOps. Ikon kunci merah menunjukkan izin keamanan yang harus dikonfigurasi oleh pengguna. Tidak mengonfigurasi atau salah mengonfigurasi izin akan membuat beban kerja Anda rentan.

Unduh SVG alur kerja ini.

Agar beban kerja berhasil diamankan, Anda harus menggunakan kombinasi konfigurasi izin keamanan dan pemeriksaan manusia di alur kerja Anda. Penting bahwa setiap model RBAC juga harus mencakup rangkaian proses dan kode. Ini sering berjalan dengan identitas istimewa dan akan menghancurkan beban kerja Anda jika diinstruksikan untuk melakukannya. Untuk mencegah hal ini terjadi, Anda harus mengonfigurasi kebijakan cabang di repositori Anda untuk memerlukan persetujuan manusia sebelum menerima perubahan yang memicu alur otomatisasi.

Tahap penyebaran	Tanggung Jawab	Description
Permintaan penarikan	Pengguna	Insinyur harus melakukan tinjauan sebaya terhadap pekerjaan mereka, termasuk kode Pipeline itu sendiri.
Perlindungan cabang	Bersama	Konfigurasikan Azure DevOps untuk menolak perubahan yang tidak memenuhi standar tertentu, seperti pemeriksaan CI dan tinjauan serekan (melalui permintaan pull).
Pipeline sebagai kode	Pengguna	Server build akan menghapus seluruh lingkungan produksi Anda jika kode alur menginstruksikannya untuk melakukannya. Bantu cegah ini dengan menggunakan kombinasi permintaan pull dan aturan perlindungan cabang, seperti persetujuan manusia.
Koneksi layanan	Bersama	Konfigurasikan Azure DevOps untuk membatasi akses ke kredensial ini.
Sumber Daya Azure	Bersama	Mengonfigurasi RBAC pada Manajer Sumber Daya.

Konsep dan pertanyaan berikut penting untuk dipertimbangkan saat merancang model tata kelola. Ingatlah potensi kasus penggunaan dari contoh organisasi ini.

1. Lindungi lingkungan Anda dengan kebijakan cabang

Karena kode sumber Anda menentukan dan memicu penyebaran, garis pertahanan pertama Anda adalah mengamankan repositori manajemen kode sumber (SCM). Dalam praktiknya, ini dicapai dengan menggunakan alur kerja Permintaan Pull dalam kombinasi dengan kebijakan cabang, yang menentukan pemeriksaan dan persyaratan sebelum kode dapat diterima.

Saat merencanakan model tata kelola end-to-end Anda, pengguna istimewa (veggies-admins) akan bertanggung jawab untuk mengonfigurasi perlindungan cabang. Pemeriksaan perlindungan cabang umum yang digunakan untuk mengamankan penyebaran Anda meliputi:

• Memerlukan build CI untuk berhasil. Berguna untuk menetapkan kualitas kode dasar, seperti kode linting, pengujian unit, dan bahkan pemeriksaan keamanan seperti pemindaian virus dan kredensial.

• Memerlukan tinjauan rekan Minta seseorang untuk memeriksa ulang bahwa kode berfungsi sesuai dengan yang diinginkan. Berhati-hatilah ketika perubahan dilakukan pada kode alur. Gabungkan dengan build CI untuk membuat ulasan rekan menjadi lebih mudah.

Apa yang terjadi jika pengembang mencoba mendorong langsung ke produksi?

Ingatlah bahwa Git adalah sistem SCM terdistribusi. Pengembang dapat berkomitmen langsung ke cabang lokal production mereka. Tetapi ketika Git dikonfigurasi dengan benar, dorongan seperti itu akan secara otomatis ditolak oleh server Git. Contohnya:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Perhatikan bahwa alur kerja dalam contoh adalah agnostik vendor. Fitur permintaan pull dan perlindungan cabang tersedia dari beberapa penyedia SCM, termasuk Azure Repos, GitHub, dan GitLab.

Setelah kode diterima ke cabang yang dilindungi, lapisan kontrol akses berikutnya akan diterapkan oleh server build (seperti Azure Pipelines).

2. Akses apa yang dibutuhkan perwakilan keamanan?

Di Azure, perwakilan keamanan dapat berupa prinsipal pengguna atau prinsipal tanpa kepala, seperti perwakilan layanan atau identitas terkelola. Di semua lingkungan, prinsip keamanan harus mengikuti prinsip hak istimewa paling sedikit. Meskipun entitas keamanan mungkin telah memperluas akses di lingkungan pra-produksi, lingkungan Azure produksi harus meminimalkan izin tetap, mendukung akses just-in-time (JIT) dan Akses Bersyarat Microsoft Entra. Buat penetapan peran Azure RBAC Anda untuk prinsipal pengguna agar selaras dengan prinsipal hak istimewa paling sedikit ini.

Penting juga untuk memodelkan Azure RBAC secara berbeda dari Azure DevOps RBAC. Tujuan dari alur adalah untuk meminimalkan akses langsung ke Azure. Kecuali untuk kasus khusus seperti inovasi, pembelajaran, dan resolusi masalah, sebagian besar interaksi dengan Azure harus dilakukan melalui alur yang dibuat khusus dan terjaga.

Untuk perwakilan layanan Azure Pipeline, pertimbangkan untuk menggunakan peran kustom yang mencegahnya menghapus kunci sumber daya dan melakukan tindakan merusak lainnya di luar cakupan untuk tujuannya.

3. Buat peran kustom untuk perwakilan layanan yang digunakan untuk mengakses produksi

Ini adalah kesalahan umum memberikan peran dan izin Pemilik kepada agen yang membangun CI/CD. Izin kontributor tidaklah cukup jika pipeline Anda juga perlu melakukan penetapan peran identitas atau operasi penting lainnya seperti manajemen kebijakan Azure Key Vault.

Tetapi Agen Build CI/CD akan menghapus seluruh lingkungan produksi Anda jika disuruh melakukannya. Untuk menghindari perubahan destruktif yang tidak dapat diubah, kami membuat peran kustom yang:

• Menghapus kebijakan akses Key Vault
• Menghapus kunci manajemen yang menurut desain harus mencegah sumber daya dihapus (persyaratan umum dalam industri yang diatur)

Untuk melakukan ini, kami membuat peran kustom dan menghapus tindakan Microsoft.Authorization/*/Delete.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Jika itu menghapus terlalu banyak izin untuk tujuan Anda, lihat daftar lengkap dalam dokumentasi resmi untuk operasi penyedia sumber daya Azure dan sesuaikan definisi peran Anda sesuai kebutuhan.

Menyebarkan skenario ini

Skenario ini melampaui Resource Manager. Inilah sebabnya mengapa kami menggunakan Terraform, yang memungkinkan kami juga membuat prinsipal di ID Microsoft Entra dan bootstrap Azure DevOps menggunakan satu infrastruktur sebagai alat kode.

Untuk kode sumber dan instruksi terperinci, kunjungi Tata Kelola repositori GitHub di Azure Demo - dari DevOps ke ARM.

Pricing

Biaya Azure DevOps bergantung pada jumlah pengguna di organisasi Anda yang memerlukan akses, bersama dengan faktor lain seperti jumlah build/rilis bersamaan yang diperlukan dan jumlah pengguna. Azure Repos dan Azure Pipelines adalah fitur layanan Azure DevOps. Untuk informasi selengkapnya, lihat harga Azure DevOps.

Di ID Microsoft Entra, jenis manajemen akses grup yang diperlukan untuk skenario ini disediakan dalam edisi Premium P1 dan Premium P2. Harga untuk tingkat ini dihitung berdasarkan per pengguna. Untuk informasi selengkapnya, lihat Harga Microsoft Entra.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Julie Ng | Insinyur Layanan Senior

Langkah selanjutnya

• Kunjungi repositori kode untuk skenario ini di Tata Kelola di Demo Azure - dari DevOps ke ARM.
• Tinjau panduan tata kelola cloud dari Cloud Adoption Framework.
• Apa itu kontrol akses berbasis peran Azure (Azure RBAC)?
• Cloud Adoption Framework: Manajemen akses sumber daya di Azure
• Peran Azure Resource Manager
  • Pemilik (bawaan)
  • Kontributor (bawaan)
  • Pembaca (bawaan)
  • Peran Khusus
• Grup keamanan Azure DevOps
  • Administrator Proyek
  • Contributor
  • Reader