GitHub Actions OIDC'de güvenlik: claims kontrolü nasıl çalışır

GitHub Actions, bulut ortamlarına erişmek için uzun vadeli gizli anahtarlar saklamak yerine kısa ömürlü OpenID Connect token'ları kullanabilir. Ama bu kolaylık, güvenliği bulut sağlayıcısının dış tarafındaki trust policy'sine taşıyor. O policy, hangi token'ların hangi role'ü üstlenebileceğine karar veriyor.

Token'ın subject claim'i, iş akışının kimliğini belirleyen bir beyan. GitHub bunu varsayılan olarak repository ve context bilgisiyle oluşturur, ama özelleştirebilirsin. Örneğin job_workflow_ref gibi ek claim'ler ekleyebilirsin. Audience claim'i ise bulut sağlayıcısının hangi servisine erişim izni vereceğini kontrol eder.

Here's the catch: subject sadece repository adı değildir. Pull request'ler, scheduled workflow'lar, tag push'ları, farklı tetikleyiciler farklı subject claim'leri üretir. Eğer policy çok geniş bir pattern kabul ederse, role sahibinin hiç düşünmediği workflow'lar da erişim alabilir. Mesela `refs/heads/*` pattern'i, tüm branch'lerdeki workflow'lara izin verir; bu çok riskli olabilir.

Doğru yaklaşım, trust policy'ni mümkün olduğunca dar tutmak. Spesifik workflow dosyasını, belirli branch'i, hatta job ID'sini belirtebilirsin. Kaynak yazıda bu detaylar ayrıntılı açıklanıyor.

Pratik tavsiye: AWS, Azure veya GCP'de trust policy oluştururken, claim'leri en kısıtlayıcı şekilde ayarla. Her claim'i sorgulanabilir hale getir, sadece o iş akışı, o branch, o ortam için. Böylece bir saldırgan ya da hatalı bir workflow bile sınırlı hasara yol açabilir.