GitHub Actions'taki statik AWS anahtarlarının OIDC ile değiştirilmesi: pratik bir geçiş rehberi

Depolarınız hâlâ AWS_ACCESS_KEY_ID ve AWS_SECRET_ACCESS_KEY değerlerini GitHub Actions secrets olarak saklıyorsa, bu kimlik bilgileri süresiz olarak orada durur — sızdırılana kadar. dev.to'da yayımlanan bir rehber alternatifi ortaya koyuyor: OpenID Connect (OIDC) federasyonu, her workflow çalışmasının çalınacak, ekran görüntüsü alınacak ya da döndürmesi unutulacak statik bir secret olmadan kısa ömürlü AWS kimlik bilgileri edinmesini sağlıyor.

OIDC secret alışverişini nasıl değiştiriyor

dev.to gönderisine göre GitHub'ın token servisi bir job'a imzalı bir JSON Web Token veriyor ve AWS bunu kabul ediyor; çünkü hesaptaki IAM identity provider, sts.amazonaws.com audience olarak kayıtlı olacak şekilde token.actions.githubusercontent.com adresine güvenecek şekilde yapılandırılmış. Ortada el değiştiren bir secret yok. AWS STS ardından geçici kimlik bilgilerini döndürüyor ve configure-aws-credentials action'ı bunları workflow'a sunuyor. Oturumlar varsayılan olarak bir saat sürüyor ve rolün yapılandırılmış maksimum oturum süresine kadar uzatılabiliyor.

Her AWS hesabı için tek identity provider

Provider kaynağı, hesaptaki bir role geçen her workflow tarafından paylaşılıyor ve gönderi yaygın bir hataya dikkat çekiyor: bunu her proje için yeniden oluşturmak. AWS aynı URL'ye sahip yinelenen bir provider'ı reddediyor ve zaten bir tane istemenin de anlamı yok. Terraform'un AWS provider'ının son sürümleri (v5.81.0 ve sonrası) thumbprint listesini atlamanıza izin veriyor; çünkü AWS artık GitHub'ın provider'ını güvenilir sertifika otoritesi kitaplığına göre doğruluyor. Yıllar önce açık bir thumbprint ile oluşturulmuş provider'lar çalışmaya devam ediyor; bu yüzden tavsiye, sıfırdan yeniden inşa etmiyorsanız onlara dokunmamak.

Asıl işi trust policy yapıyor

IAM rolünün trust policy'si başlıca güvenlik kontrolü. Token'ın sub claim'i depoyu bir branch, tag, environment veya pull request bağlamıyla birlikte kodluyor ve gönderi, kuruluştan gelen her şeye güvenmek yerine bunun birebir eşleştirilmesini öneriyor — örneğin repo:my-org/my-repo:environment:production. repo:my-org/* gibi bir wildcard, kuruluştaki herhangi bir deponun — yeni oluşturulan veya zayıf korunan depolar dahil, ya da ele geçirilmiş bir üçüncü taraf action çalıştıran depolar dahil — rolü üstlenmesine izin veriyor. Koşulu onay isteyen bir GitHub environment ile eşleştirmek, token eşleşmesinin üzerine bir onay adımı ekliyor ve StringLike yalnızca wildcard bilinçli olarak kullanıldığında görünmeli.

Federasyon geniş izinler için bir bahaneye dönüşmemeli

Dar bir trust policy, "Action": "*" ve "Resource": "*" şeklinde bir permissions policy'yi haklı çıkarmıyor. Gönderiye göre üstlenilen rol, pipeline'ın yaptığı işi tam olarak kapsamalı — tek bir ECR deposuna push yapmak, tek bir ECS servisini güncellemek ya da tek bir S3 bucket'ına yazmak — çünkü OIDC kurulumları, federasyonun kendisinin sınır olduğu varsayımıyla genellikle gevşek izinlere kayıyor. Yazı ayrıca staging ve production için ayrı roller, terraform plan çalıştıran bir pull request workflow'u (çoğunlukla okuma erişimi artı state backend'i) ve terraform apply çalıştıran bir merge-to-main workflow'u için ayrı roller öneriyor; bu da kötü niyetli bir pull request'in yapabileceği zararı sınırlıyor.

İnsanları en çok zorlayan workflow ayarları

Job veya workflow'un permissions: id-token: write değerine ihtiyacı var; aksi halde token isteği doğrudan başarısız oluyor — gönderinin belirttiği sık bir kurulum hatası. Herhangi bir permissions bloğu bildirmek, listelenmeyen kapsamları none yapar; bu yüzden checkout için contents: read gerekiyor. configure-aws-credentials action'ını @main olarak referans göstermek, o action'a yönelik bir supply-chain saldırısına cloud kimlik bilgilerine doğrudan erişim verir; major sürüm etiketleri daha iyi ama değiştirilebilir, bu yüzden tam bir commit SHA'ya sabitlemek ve bir dependency bot ile güncellemek en güçlü seçenek. role-session-name değerini github.run_id'den türetilmiş bir şeye ayarlamak da her CloudTrail kaydını belirli bir workflow çalışmasına kadar izlenebilir kılıyor; oturum adları kısıtlı bir karakter kümesinden 2 ile 64 karakter arasında olur ve eğik çizgiye izin verilmez.

İki hata durumu, iki farklı neden

Gönderi, ekiplerin genellikle karşılaştığı iki hatayı ayırıyor. Eksik bir ACTIONS_ID_TOKEN_REQUEST_URL environment değişkeni, token'ın hiç istenmediği anlamına gelir — id-token izni yoktur. Bir Not authorized to perform sts:AssumeRoleWithWebIdentity hatası ise token'ın AWS'ye ulaştığını ama reddedildiğini gösterir; tipik olarak trust policy'de bir sub veya aud uyuşmazlığı ya da yanlış bir rol ARN'i söz konusudur. Bir şeyi değiştirmeden önce mesajı okumak hata ayıklama süresini kısaltır.

Kademeli bir geçiş planlayın

dev.to gönderisi, gerçek kuruluşların nadiren her depoyu tek bir pull request ile taşıdığını kabul ediyor; dolayısıyla bazı depoların hâlâ statik anahtarlara dayandığı bir geçiş dönemi bekleyin. Hangilerinin geçtiğini takip edin ve temizliğin kendiliğinden bittiğini varsaymak yerine GitHub ayarlarındaki arta kalan secrets'ları denetleyin.

Neden önemli

CI secrets'a gömülü uzun ömürlü erişim anahtarları duran bir hedef: loglarda, ekran görüntülerinde, klonlanmış depolarda ve ele geçirilmiş üçüncü taraf action'larda ortaya çıkıyor ve biri döndürene kadar geçerli kalıyorlar. Bunları çalışma başına STS kimlik bilgileriyle değiştirmek, bu risk sınıfının tamamını AWS ve GitHub'ın zaten sunduğu mekanizmalarla ortadan kaldırıyor; oturum adlandırması ise "bir değişikliği kim dağıttı" gibi olay sorularını hızlı bir CloudTrail sorgusuna dönüştürüyor. dev.to gönderisinin merkezdeki uyarısı akılda tutulmaya değer: kurulumun gerçekte ne kadar güvenli olduğunu, federasyon protokolünün kendisi değil, trust ve permissions policy'lerindeki sağlamlaştırma çalışması belirliyor.