Düzenle

Aracılığıyla paylaş

CI/CD kullanırken Azure'da uçtan uca idare

Microsoft Entra ID
Azure DevOps
Azure Pipelines
Azure Resource Manager

Kuruluşunuz için bir idare modeli geliştirirken, Azure Resource Manager'ın kaynakları yönetmenin yalnızca bir yolu olduğunu unutmamanız önemlidir. Azure DevOps ve sürekli tümleştirme ve sürekli teslim (CI/CD) otomasyonu, düzgün bir şekilde güvenli hale getirilmemesi durumunda istenmeyen bir güvenlik arka kapısı olabilir. Bu kaynaklar Resource Manager için kullanılan rol tabanlı erişim denetimi (RBAC) modeli yansıtılarak korunmalıdır.

Uçtan uca idare kavramı satıcıdan bağımsızdır. Burada açıklanan uygulamada Azure DevOps kullanılır, ancak alternatiflerden de kısaca bahsedilir.

Olası kullanım örnekleri

Bu başvuru uygulaması ve tanıtımı açık kaynak ve DevOps'u kullanmaya yeni katılan ve Azure'a dağıtmak için bir idare modeli oluşturması gereken kuruluşlar için bir öğretim aracı olarak kullanılmak üzere tasarlanmıştır. Bu örnek depoda kullanılan modelin arkasındaki kararları anlamak için lütfen bu senaryoyu dikkatle okuyun.

Tüm idare modelleri, erişim denetimlerinin teknik uygulamalarına yansıtılan kuruluşun iş kurallarına bağlı olmalıdır. Bu örnek model, aşağıdaki yaygın senaryoya (iş gereksinimleriyle) sahip kurgusal bir şirket kullanır:

  • İş etki alanları ve izin modelleri ile uyumlu Microsoft Entra grupları
    Kuruluşun büyük ölçüde bağımsız olarak çalışan "meyveler" ve "sebzeler" gibi birçok dikey iş alanı vardır. Her iş etki alanında, ayrı *-admins veya Microsoft Entra gruplarına eşlenen iki düzey veya *-devs ayrıcalık vardır. Bu, bulutta izinleri yapılandırırken geliştiricilerin hedeflenmesine olanak tanır.

  • Dağıtım ortamları
    Her ekibin iki ortamı vardır:

    • Üretim. Yalnızca yöneticilerin yükseltilmiş ayrıcalıkları vardır.
    • Üretim dışı. Tüm geliştiricilerin yükseltilmiş ayrıcalıkları vardır (denemeleri ve yenilikleri teşvik etmek için).

  • Otomasyon hedefleri
    Her uygulama, Azure DevOps'u yalnızca sürekli tümleştirme (CI) için değil, aynı zamanda sürekli dağıtım (CD) için de uygulamalıdır. Örneğin, dağıtımlar Git deposunda yapılan değişikliklerle otomatik olarak tetiklenebilir.

  • Şimdiye kadarki bulut yolculuğu
    Kuruluş, bulut yolculuğunu hızlandırmak için yalıtılmış bir proje modeliyle başladı. Ancak şimdi siloları kırmak ve "işbirliği" ve "süpermarket" projeleri oluşturarak işbirliğini teşvik etmek için seçenekleri araştırıyorlar.

Bu basitleştirilmiş diyagramda Git deposundaki dalların geliştirme, hazırlama ve üretim ortamlarına nasıl eşlenmesi gösterilmektedir:

Çeşitli web ortamlarına eşlenen Git deposu dallarının basitleştirilmiş diyagramı
Bu diyagramın SVG'sini indirin.

Mimari

Bu diyagramda Resource Manager ve CI/CD'den Microsoft Entra Id'ye bağlanmanın uçtan uca idare modeline sahip olmanın anahtarı olduğu gösterilmektedir.

Merkezde Microsoft Entra Id ile uçtan uca idareye genel bakış
Bu mimarinin SVG'sini indirin.

Not

Kavramın anlaşılmasını kolaylaştırmak için diyagramda yalnızca "veggies" etki alanı gösterilir. "Fruits" etki alanı benzer görünür ve aynı adlandırma kurallarını kullanır.

İş Akışı

Numaralandırma, BT yöneticilerinin ve kurumsal mimarların bulut kaynaklarını düşünme ve yapılandırma sırasını yansıtır.

  1. Microsoft Entra ID

    Kimlik için tek bir düzleme sahip olmak için Azure DevOps'u Microsoft Entra ID ile tümleştiririz. Bu, bir geliştiricinin hem Azure DevOps hem de Resource Manager için aynı Microsoft Entra hesabını kullandığı anlamına gelir. Kullanıcılar tek tek eklenmez. Bunun yerine, üyelik Microsoft Entra grupları tarafından atanır, böylece bir geliştiricinin kaynaklara erişimini microsoft Entra grup üyeliklerini kaldırarak tek bir adımda kaldırabiliriz. Her etki alanı için şunları oluştururuz:

    • Microsoft Entra grupları. Etki alanı başına iki grup (bu makalenin sonraki 4. ve 5. adımında daha ayrıntılı olarak açıklanmıştır).
    • Hizmet sorumluları. Ortam başına bir açık hizmet sorumlusu.

  2. Üretim ortamı

    Dağıtımı basitleştirmek için bu başvuru uygulaması, üretim ortamını temsil eden bir kaynak grubu kullanır. Uygulamada farklı bir abonelik kullanmanız gerekir.

    Bu ortama ayrıcalıklı erişim yalnızca yöneticilerle sınırlıdır.

  3. Geliştirme ortamı

    Dağıtımı basitleştirmek için bu başvuru uygulaması, geliştirme ortamını temsil eden bir kaynak grubu kullanır. Uygulamada farklı bir abonelik kullanmanız gerekir.

  4. Resource Manager'da rol atamaları

    Microsoft Entra grup adlarımız bir rol anlamına gelse de, bir rol ataması yapılandırılana kadar erişim denetimleri uygulanmaz. Bu, belirli bir kapsam için Microsoft Entra sorumlusuna bir rol atar. Örneğin, geliştiriciler üretim ortamında Katkıda Bulunan rolüne sahiptir.

    Microsoft Entra sorumlusu Geliştirme ortamı (Resource Manager) Üretim ortamı (Resource Manager)
    veggies-devs-group Sahibi Okuyucu
    veggies-admins-group Sahip Sahip
    veggies-ci-dev-sp Özel Rol * –
    veggies-ci-prod-sp – Özel Rol *

    * Dağıtımı basitleştirmek için bu başvuru uygulaması rolü hizmet sorumlularına atar Owner . Ancak üretimde, bir hizmet sorumlusunın kaynaklarınıza yerleştirdiğiniz yönetim kilitlerini kaldırmasını engelleyen özel bir rol oluşturmanız gerekir. Bu, kaynakların veritabanı silme gibi yanlışlıkla oluşan hasarlara karşı korunmasına yardımcı olur.

    Tek tek rol atamalarının ardındaki mantığı anlamak için bu makalenin devamında yer alan önemli noktalar bölümüne bakın.

  5. Azure DevOps'ta güvenlik grubu atamaları

    Güvenlik grupları Resource Manager'daki roller gibi çalışır. Yerleşik rollerden yararlanın ve geliştiriciler için varsayılan olarak Katkıda Bulunan'ı seçin. Yöneticiler yükseltilmiş izinler için Proje Yöneticisi güvenlik grubuna atanır ve bu sayede güvenlik izinlerini yapılandırabilir.

    Azure DevOps ve Resource Manager'ın farklı izin modellerine sahip olduğunu unutmayın:

    Bu nedenle ve -devs gruplarına -admins üyelik birbirini dışlamalıdır. Aksi takdirde, etkilenen kişiler Azure DevOps'ta beklenenden daha az erişime sahip olur.

    Grup adı Resource Manager rolü Azure DevOps rolü
    fruits-all – –
    fruits-devs Katılımcı Katılımcı
    fruits-admins Sahip Proje Yöneticileri
    veggies-all – –
    veggies-devs Katılımcı Katılımcı
    veggies-admins Sahip Proje Yöneticileri
    infra-all – –
    infra-devs Katılımcı Katılımcı
    infra-admins Sahip Proje Yöneticileri

    Meyve ekibini tek bir depo üzerinde işbirliği yapmaya davet eden meyve ekibi gibi sınırlı işbirliği senaryosunda veggies-all grubu kullanırlar.

    Bireysel rol atamalarının ardındaki mantığı anlamak için bu makalenin devamında yer alan önemli noktalar bölümüne bakın.

  6. Hizmet bağlantıları

    Azure DevOps'ta Hizmet Bağlantısı, kimlik bilgilerinin etrafındaki genel bir sarmalayıcıdır. Hizmet sorumlusu istemci kimliğini ve istemci gizli dizisini tutan bir hizmet bağlantısı oluştururuz. Proje Yöneticileri gerektiğinde, örneğin dağıtımdan önce insan onayı gerektiğinde bu korumalı kaynağa erişimi yapılandırabilir. Bu başvuru mimarisinin hizmet bağlantısında iki en düşük koruma vardır:

  7. Git depoları

    Hizmet bağlantılarımız dal denetimleri aracılığıyla dallara bağlı olduğundan Git depolarına yönelik izinleri yapılandırmak ve dal ilkeleri uygulamak kritik önem taşır. CI derlemelerinin geçirilmesini gerektirmeye ek olarak, çekme isteklerinin en az iki onaylayana sahip olmasını da gerektirir.

Bileşenler

Alternatifler

Uçtan uca idare kavramı satıcıdan bağımsızdır. Bu makale Azure DevOps'a odaklansa da, Azure DevOps Server şirket içi yerine kullanılabilir. Alternatif olarak, Jenkins ve GitLab gibi seçenekleri kullanarak açık kaynak CI/CD geliştirme işlem hattı için bir dizi teknoloji de kullanabilirsiniz.

Hem Azure Repos hem de GitHub, açık kaynak Git sürümü denetim sistemini kullanacak şekilde oluşturulmuş platformlardır. Özellik kümeleri biraz farklı olsa da, her ikisi de CI/CD için genel idare modelleriyle tümleştirilebilir. GitLab, güçlü CI/CD özellikleri sağlayan başka bir Git tabanlı platformdur.

Bu senaryoda Terraform, kod olarak altyapı (IaC) aracı olarak kullanılır. Alternatifler arasında Jenkins, Ansible ve Chef yer alır.

Dikkat edilmesi gereken noktalar

Azure'da uçtan uca idare elde etmek için, geliştiricinin bilgisayarından üretime giden yolun güvenlik ve izin profilini anlamak önemlidir. Aşağıdaki diyagramda Azure DevOps ile temel CI/CD iş akışı gösterilmektedir. Kırmızı kilit simgesi , kullanıcı tarafından yapılandırılması gereken güvenlik izinlerini gösterir. İzinlerin yapılandırılmaması veya yanlış yapılandırılmaması, iş yüklerinizi savunmasız bırakır.

Azure DevOps ile temel CI/CD iş akışını gösteren diyagram
Bu iş akışının SVG'sini indirin.

İş yüklerinizin güvenliğini başarıyla sağlamak için iş akışınızda güvenlik izni yapılandırmalarının ve insan denetimlerinin bir birleşimini kullanmanız gerekir. Tüm RBAC modellerinin hem işlem hatlarına hem de koda genişletilmeli olması önemlidir. Bunlar genellikle ayrıcalıklı kimliklerle çalışır ve istenirse iş yüklerinizi yok eder. Bunun olmasını önlemek için, otomasyon işlem hatlarını tetikleyen değişiklikleri kabul etmeden önce deponuzdaki dal ilkelerini insan onayı gerektirecek şekilde yapılandırmanız gerekir.

Dağıtım aşamaları Sorumluluk Açıklama
Çekme istekleri User Mühendisler, İşlem Hattı kodunun kendisi de dahil olmak üzere çalışmalarını gözden geçirmelidir.
Dal koruması Shared Azure DevOps'u CI denetimleri ve eş gözden geçirmeleri (çekme istekleri aracılığıyla) gibi belirli standartlara uymayan değişiklikleri reddedecek şekilde yapılandırın.
Kod olarak işlem hattı User İşlem hattı kodu bunu yapması için talimat verirse bir derleme sunucusu üretim ortamınızın tamamını siler. Çekme isteklerinin ve insan onayı gibi dal koruma kurallarının bir bileşimini kullanarak bunu önlemeye yardımcı olun.
Hizmet bağlantıları Shared Bu kimlik bilgilerine erişimi kısıtlamak için Azure DevOps'yi yapılandırın.
Azure Kaynakları Shared Resource Manager'da RBAC'yi yapılandırın.

Bir idare modeli tasarlarken aşağıdaki kavramlar ve soruların dikkate alınması önemlidir. Bu örnek kuruluşun olası kullanım örneklerini aklınızda bulundurun.

1. Dal ilkeleriyle ortamlarınızı koruma

Kaynak kodunuz dağıtımları tanımlayıp tetiklediğinden, ilk savunma hattınız kaynak kod yönetimi (SCM) deponuzun güvenliğini sağlamaktır. Uygulamada bu, kod kabul edilmeden önce denetimleri ve gereksinimleri tanımlayan dal ilkeleriyle birlikte Çekme İsteği iş akışı kullanılarak elde edilir.

Uçtan uca idare modelinizi planlarken, dal korumasını yapılandırmak ayrıcalıklı kullanıcılardan (veggies-admins) sorumludur. Dağıtımlarınızın güvenliğini sağlamak için kullanılan yaygın dal koruma denetimleri şunlardır:

  • Ci derlemesinin geçirilmesini gerektir. Kod lint, birim testleri ve hatta virüs ve kimlik bilgisi taramaları gibi güvenlik denetimleri gibi temel kod kalitesini oluşturmak için kullanışlıdır.

  • Eş gözden geçirme gerektir Kodun istendiği gibi çalıştığını bir kez daha kontrol edin. İşlem hattı kodunda değişiklik yapıldığında çok dikkatli olun. Eş incelemelerini daha az sıkıcı hale getirmek için CI derlemeleriyle birleştirin.

Bir geliştirici doğrudan üretime göndermeye çalışırsa ne olur?

Git'in dağıtılmış bir SCM sistemi olduğunu unutmayın. Bir geliştirici doğrudan kendi yerel production dalı için işleyebilir. Ancak Git düzgün yapılandırıldığında, bu tür bir gönderim Git sunucusu tarafından otomatik olarak reddedilir. Örneğin:

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'

Örnekteki iş akışının satıcıdan bağımsız olduğunu unutmayın. Çekme isteği ve dal koruma özellikleri Azure Repos, GitHub ve GitLab gibi birden çok SCM sağlayıcısından kullanılabilir.

Kod korumalı bir dala kabul edildikten sonra, sonraki erişim denetimleri katmanı derleme sunucusu (Azure Pipelines gibi) tarafından uygulanır.

2. Güvenlik sorumluları hangi erişime ihtiyaç duyar?

Azure'da güvenlik sorumlusu, hizmet sorumlusu veya yönetilen kimlik gibi bir kullanıcı sorumlusu veya başsız sorumlu olabilir. Tüm ortamlarda, güvenlik sorumluları en az ayrıcalık ilkesini izlemelidir. Güvenlik sorumluları üretim öncesi ortamlarda genişletilmiş erişime sahip olsa da üretim Azure ortamları, tam zamanında (JIT) erişimi ve Microsoft Entra Koşullu Erişim'i destekleyerek ayakta durma izinlerini en aza indirmelidir. Kullanıcı sorumlularının bu en az ayrıcalık sorumlularıyla uyumlu olması için Azure RBAC rol atamalarınızı oluşturun.

Azure RBAC'yi Azure DevOps RBAC'den ayrı olarak modellemek de önemlidir. İşlem hattının amacı Azure'a doğrudan erişimi en aza indirmektir. Yenilik, öğrenme ve sorun çözme gibi özel durumlar dışında, Azure ile etkileşimlerin çoğu amaca yönelik ve geçitli işlem hatlarıyla yapılmalıdır.

Azure Pipeline hizmet sorumluları için, kaynak kilitlerini kaldırmasını ve amacı doğrultusunda kapsam dışında başka yıkıcı eylemler gerçekleştirmesini engelleyen özel bir rol kullanmayı göz önünde bulundurun.

3. Üretime erişmek için kullanılan hizmet sorumlusu için özel bir rol oluşturma

CI/CD derleme aracılarına Sahip rolleri ve izinleri vermek yaygın bir hatadır. İşlem hattınızın kimlik rolü atamaları veya Key Vault ilke yönetimi gibi diğer ayrıcalıklı işlemleri gerçekleştirmesi gerekiyorsa katkıda bulunan izinleri yeterli değildir.

Ancak bir CI/CD Derleme Aracısı, bunu yapmanız gerekirse üretim ortamınızın tamamını siler. Geri alınamaz yıkıcı değişikliklerden kaçınmak için şu özel rolü oluştururuz:

Bunu yapmak için özel bir rol oluşturur ve eylemleri kaldırırız 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}"
  ]
}

Bu, amaçlarınız için çok fazla izni kaldırırsa, Azure kaynak sağlayıcısı işlemleri için resmi belgelerdeki tam listeye bakın ve rol tanımınızı gerektiği gibi ayarlayın.

Bu senaryoyu dağıtın

Bu senaryo Resource Manager'ın ötesine uzanır. Bu nedenle Terraform'u kullanarak Microsoft Entra ID'de sorumlular oluşturmamıza ve kod aracı olarak tek bir altyapı kullanarak Azure DevOps'u önyüklememize olanak tanır.

Kaynak kodu ve ayrıntılı yönergeler için DevOps'tan ARM'ye Azure Demo'da GitHub deposu İdaresi'ni ziyaret edin.

Fiyatlandırma

Azure DevOps maliyetleri, kuruluşunuzda erişim gerektiren kullanıcı sayısına ve gerekli eşzamanlı derleme/yayın sayısı ve kullanıcı sayısı gibi diğer faktörlere bağlıdır. Azure Repos ve Azure Pipelines, Azure DevOps hizmetinin özellikleridir. Daha fazla bilgi için bkz . Azure DevOps fiyatlandırması.

Microsoft Entra Id'de, bu senaryo için gereken grup erişim yönetiminin türü Premium P1 ve Premium P2 sürümlerinde sağlanır. Bu katmanların fiyatlandırması kullanıcı başına hesaplanır. Daha fazla bilgi için bkz. Microsoft Entra fiyatlandırması.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

Sonraki adımlar