Rehber: Jenkins'in statik AWS anahtarlarını OIDC federasyonu ve kapsamlı trust policy'lerle değiştirmek

Statik anahtarlar çıkıyor, OIDC giriyor

Oleksandr Kuryzhev'in dev.to'da yayımladığı, özgün olarak kuryzhev.cloud blogu için yazdığı kılavuz, Jenkins'teki uzun ömürlü AWS erişim anahtarlarının OpenID Connect federasyonuyla değiştirilmesini adım adım anlatıyor. Yazar, bu kalıbı üç ayrı Jenkins filosuna uyguladığını ve aynı yapılandırma hatalarının ekipler arasında tekrar tekrar ortaya çıktığını söylüyor.

Değişim nasıl çalışıyor

Jenkins, bir IAM kullanıcısının erişim anahtarını credential store'da tutmak yerine, her çalıştırmada kimliğini kanıtlar. OIDC destekli bir plugin üzerinden; repository, branch, build ID gibi yapılandırdığınız claim'leri içeren imzalı bir JWT üretir. Jenkins'in issuer URL'sini OIDC identity provider olarak güvenecek şekilde yapılandırılmış AWS, bu token'ı doğrular ve AssumeRoleWithWebIdentity ile geçici kimlik bilgilerine dönüştürür.

Güven modeli, erişim anahtarından temelden farklıdır. Statik bir anahtar bearer credential'dır: süre sonu yoktur, belirli bir pipeline'a bağlı değildir, kimin çağırdığına dair kriptografik bir kanıt taşımaz ve elle iptal edilene kadar her yerden geçerlidir. OIDC token ise kısa ömürlüdür, belirli bir subject claim'e bağlıdır ve bir sızıntı fark edilmediğinde bile kendi kendine sona erer. En önemlisi, Jenkins'te hiçbir AWS secret'ı saklanmaz — assertion runtime'da üretilir ve STS herhangi bir şey vermeden önce bir trust policy ile doğrulanır; yani çalınacak bekleyen bir şey yoktur.

Faydayı ortadan kaldıran hatalar

Yazıya göre en yaygın hata, aşırı geniş bir trust policy'dir: yalnızca audience claim'e koşul koymak veya subject claim'i wildcard ile açmak, böylece herhangi bir repository'deki herhangi bir branch'teki herhangi bir job'ın, production deploy'ları için tasarlanmış bir role'ü üstlenebilmesi. Bu, yerine konulan statik anahtarın riskini yeniden üretir.

Diğer tekrarlayan sorunlar:

• Jenkins issuer URL'sini kalıcı sanmak. Yeni bir load balancer, domain veya sertifika, OIDC discovery ve JWKS uç noktalarını değiştirir; bu yüzden eski issuer'a referans veren her trust policy sessizce eşleşmemeye başlar. Pipeline'lar daha sonra, kimsenin altyapı değişikliğiyle ilişkilendirmediği, anlaşılmaz AccessDenied hatalarıyla AssumeRoleWithWebIdentity çağrısında başarısız olur.
• Tek bir paylaşımlı IAM role. Deploy job'ları ve salt-okunur lint job'ları aynı izinleri alır; böylece güvenliği aşılmış düşük güvenli bir job — örneğin kurcalanmış bir pipeline script'iyle çalışan bir PR build'i — production'a kadar ulaşabilir.
• HTTPS gereksinimleri. AWS, JWKS belgesini geçerli HTTPS üzerinden almak zorundadır. Yalnızca iç ağdaki Jenkins kurulumları veya self-signed sertifikalar token doğrulamasını sessizce başarısız kılar; kurulum sırasında hata verilmez, sadece ilk kullanımda gizemli auth hataları ortaya çıkar.

Production'da ayakta kalan yapılandırma

Önce Jenkins'i, herkese açık HTTPS discovery URL'sini kullanarak bir IAM OIDC identity provider olarak kaydedin. AWS bu uç noktadan JWKS parmak izini alır ve önbelleğe koyar; bu, AWS hesabı başına tek seferlik bir kayıttır, role başına değil.

Sonra trust policy'yi belirli claim'lere sabitleyin; production'a dokunan her şey için wildcard'lı StringLike değil, daima StringEquals kullanın:

{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/jenkins.example.com/oidc" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "jenkins.example.com/oidc:aud": "sts.amazonaws.com", "jenkins.example.com/oidc:sub": "repo:my-org/infra:ref:refs/heads/main" } } }

Pipeline içinde oidcIdToken plugin adımı token'ı üretir ve AWS CLI'ya doğrudan bir çağrı onu kimlik bilgilerine dönüştürür (örnek 900 saniyelik bir süre kullanıyor). Bu kimlik bilgileri yalnızca stage süresince job'ın ortamında var olur ve credential store'a asla dokunmaz.

Yazarın taviz vermediği kural: her güven sınırı için bir role. Sadece plan ve apply, staging ve production, salt-okunur ve deploy — her biri kendi role'ünü, kendi trust policy'sini ve dar bir izin setini alır; böylece güvenliği aşılmış bir job asla en küçük meşru ihtiyacını aşamaz.

İleri desenler ve işletme maliyetleri

Çok hesaplı kurulumlarda, tek bir çapraz hesap provider'ı kurmaya çalışmak yerine, Jenkins'e güvenmesi gereken her hesap için OIDC provider'ı bir kez kaydedin. Her hesap, subject claim'i yine belirli bir job yoluna kısıtlar; böylece Jenkins hiçbir zaman hesap genelinde erişim elde etmez.

Branch ve PR kapsamı, OIDC'nin statik anahtarlardan üstün olduğu alandır: branch'i veya tag'i subject claim'e kodlayın, böylece yalnızca main'e yapılan merge'lar deploy role'ünü üstlenebilirken, PR build'leri ayrı kapsamlı, genellikle salt-okunur bir role alır. Bu, pipeline koşullarında değil trust policy'de zorunlu tutulmalıdır — bir PR pipeline script'ini kendisi düzenleyebilir ama başka bir hesaptaki IAM trust policy'yi düzenleyemez.

Session tag'leri bir denetim boşluğunu kapatır: assume-role çağrısında job adı, istek sahibi ve git SHA'sını geçirmek, CloudTrail'in hangi API çağrısını hangi pipeline çalıştırmasının yaptığını genel bir role kaydı yerine tam olarak göstermesini sağlar. Permission boundary'leri, trust policy incelemesi ekip büyümesinin gerisinde kaldığında derinlemesine savunma sağlar.

Maliyet konusunda: değişim, çalıştırma başına kabaca bir ekstra ağ gidiş-dönüşü ekler; yazıya göre tipik olarak 100–300 milisaniye. STS çağrıları ücretsizdir, ama binlerce gece build'i bütçelenmesi gereken gerçek bir CloudTrail hacmi üretir. Token'lar varsayılan olarak yaklaşık 15 dakika ile bir saat arası yaşar; bu yüzden saatler süren Terraform apply'ları gibi uzun süreli job'ların role'ü yeniden üstlenmesi veya role'leri zincirlemesi gerekir.

Neden önemli

Sızdırılmış statik bir CI anahtarı, biri hatırlayıp rotate edene kadar — ki yazarın da belirttiği gibi bu nadirdir — her yerde çalışmaya devam eder. Federasyon, saklanan secret'ı tamamen ortadan kaldırır ve güvenlik sorusunu incelenebilir bir IAM yapılandırmasına dönüştürür. Ama fayda koşulludur: wildcard'lı bir subject claim veya paylaşılan bir role, eski sorunu sessizce yeniden yaratır. AWS'ye karşı Jenkins çalıştıran ekipler için, kılavuzun sessiz hata modları listesi — JWKS alma sorunları, altyapı değişiklikleri sonrası issuer kayması — kurulum adımlarının kendisi kadar değerlidir.