Mimari ve çalışma modeli
Workload identity federation, CI/CD işinin uzun ömürlü bulut anahtarı saklamak yerine OIDC sağlayıcısından kısa ömürlü kimlik tokenı almasını sağlar. Bulutun STS veya kimlik platformu issuer, audience, subject ve ek claim'leri doğrular; ardından sınırlı süreli erişim kimliği üretir. Bu model anahtar rotasyonu yükünü azaltır fakat güven ilişkisi ve IAM izinleri yanlışsa geniş erişim oluşturabilir.
Google Cloud workload identity pool/provider ve attribute mapping/condition kullanır. AWS IAM, OIDC provider'ı bir role trust policy içinde principal olarak tanır ve claim koşullarıyla AssumeRoleWithWebIdentity erişimini sınırlar. Microsoft Entra uygulama kaydı veya user-assigned managed identity üzerinde federated identity credential kullanır; issuer, subject ve audience değerleri tokenla büyük-küçük harf dâhil eşleşmelidir. Ürün adları farklı olsa da ortak sınır token claim'leridir.
Paylaşılan issuer kullanan sistemlerde yalnız issuer'a güvenmek tehlikelidir. Kuruluş, depo, branch, environment ve workflow kimliği için değişmez claim seçin. `main` branch'e izin vermek tek başına yeterli olmayabilir; pull request kodunun güvenilen workflow'u veya reusable workflow'u değiştirme yetkisini inceleyin. Audience hedef buluta özgü olmalı, IAM rolü de yalnız gerekli kaynak ve eylemlere erişmelidir.
Geçişte önce salt okunur bir pilot rol oluşturun. Pipeline'ın ID token claim'lerini sır değerlerini loglamadan kaydedin, trust condition ile tam eşleştirin ve kısa oturum süresi seçin. Yanlış repository, branch, audience ve fork senaryolarının reddedildiğini test edin. Sonra secret tabanlı kimliği kaldırın; secretı açık bırakmak federasyonun risk azaltımını tamamlamaz.
- 1CI/CD işinin OIDC tokenı
- 2Issuer/audience/subject doğrulaması
- 3Bulut STS kısa ömürlü kimlik
- 4Sınırlı IAM eylemi ve audit
Tasarım parametreleri
- Issuer ve audience
- Sağlayıcının gerçek issuer URL'sini ve hedef bulut için beklenen audience değerini sabitleyin.
- Subject sınırı
- Kuruluş, repository, branch/environment ve workflow claim'lerinden değişmez bir bileşim seçin.
- IAM kapsamı
- Federasyon kimliğini geniş yönetici rolüne değil, kaynak ve eylem bazlı ayrı deploy rolüne bağlayın.
- Oturum ömrü
- Pipeline süresini karşılayacak kısa süre seçin; yenileme ve yarıda kesilme davranışını sınayın.
- Denetim
- Token değerini kaydetmeden issuer, subject, role, session ve bulut audit olayını bir run ID ile eşleyin.
Hesap ve uygulama örneği
Üretim deploy işi 18 dakika sürüyor ve p95 süre 24 dakikaysa 30 dakikalık oturum başlangıç için yeterli marj verebilir. İki saatlik token kullanmak kolay görünür fakat sızıntı penceresini büyütür. Uzayan adımın yeniden kimlik alıp alamadığını test edin; süreyi sağlayıcı üst sınırı veya varsayılanı sanmadan ölçün.
Bir kuruluşta 40 repository varsa tek trust condition ile tüm kuruluşa izin vermek saldırı yüzeyini büyütür. Üretim rolünü `org/app`, `refs/heads/main` ve `environment=production` gibi doğrulanmış claim'lerle sınırlandırın. Test rolünü ayrı tutun. Bulut sağlayıcılarının claim sözdizimi farklıdır; aynı politika amacını üç ayrı yerel kuralda doğrulayın.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Sağlayıcıdan bağımsız kontrol örneği
claims=$(cat oidc-claims.json)
jq '{iss,aud,sub,repository,ref,environment}' oidc-claims.json
# Güven koşulu ilkesi
# iss == EXPECTED_ISSUER
# aud == CLOUD_STS_AUDIENCE
# repository == 'org/app'
# ref == 'refs/heads/main'
# environment == 'production'Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Token exchange audience hatası | Pipeline tokenındaki aud ile bulut sağlayıcısının beklediği değer farklı olabilir. | Token içeriğini güvenli biçimde çözümleyip aud değerini provider/credential kaydıyla karşılaştırın. |
| Bazı branch'ler beklenmeden yetki alıyor | Subject veya attribute condition repository/branch kapsamını yeterince daraltmıyor olabilir. | Başarılı audit olayındaki subject claim'i ve trust policy koşulunu eşleyin. |
| Federasyon çalışıyor fakat deploy 403 alıyor | Trust başarılı, resource IAM rolü eksik veya yanlış scope'ta olabilir. | STS başarısı ile reddedilen API eylemini ayırın; role/permission kararını audit logdan bulun. |
Kabul ve doğrulama kontrolleri
- Issuer, audience ve subject claim'lerini gerçek pilot tokenıyla doğrulayın.
- Repository, branch, environment ve fork reddetme testlerini çalıştırın.
- Bulut rolünü yalnız gerekli kaynak ve eylemlerle sınırlandırın.
- Oturum süresini p95 pipeline süresi ve yenileme davranışıyla test edin.
- Run ID ile CI/CD ve bulut audit olayını eşleştirin.
- Doğrulama sonrası eski uzun ömürlü secretı devre dışı bırakın.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.