# CI/CD'de OIDC ve IAM Role ile şifresiz (secretless) AWS erişimini nasıl kurarım?

> GitHub Secrets'taki uzun ömürlü AWS anahtarlarını silip repo ve branch'e scope'lu bir IAM role'ü OIDC ile üstlenin; bulut dışı secret'ı runtime'da çekin.

- Soruldu: 2026-06-12
- Yanıtlandı: 2026-06-12
- Soran: Doruk
- Etiketler: ci-cd, guvenlik, altyapi
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/ci-cd-de-secret-yonetimi-ve-oidc-ile-sifresiz-erisim/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** GitHub Actions workflow'larımızda AWS erişim anahtarları ve üretim DB şifreleri gerekiyor. Bunları repoya koymak büyük açık; GitHub Secrets bir yere kadar çözüyor ama anahtar rotasyonu ve merkezi takip zor.

Pipeline'ımızın AWS IAM Role'leri ve OIDC kullanarak şifresiz (secretless) şekilde AWS kaynaklarına erişmesini nasıl sağlarım?


Kısa cevap: GitHub Secrets'taki uzun ömürlü AWS anahtarları tam olarak **yok etmeniz** gereken şey — sızar, rotasyonu zordur, sürekli açık duran kalıcı kimliklerdir. OIDC bunları ortadan kaldırır.

Asıl mesele: kalıcı bir anahtarı bir yerde saklamak yerine, her çalışmada anlık üretilen geçici bir kimlik kullanmak.

1. **GitHub Actions'ı AWS IAM'de OIDC identity provider olarak tanımlayın.** Bu, AWS'in GitHub'ın imzaladığı token'lara güvenmesini sağlar. Artık AWS, "bu workflow gerçekten sizin reponuzdan mı geliyor?" sorusunu kriptografik olarak doğrulayabilir.
2. **Trust policy'si dar scope'lu bir IAM role oluşturun.** Role'ün trust policy'sinde `sub` koşulunu belirli **repo + branch + environment**'a sabitleyin. Böylece bir fork ya da rastgele bir PR bu role'ü üstlenemez; sadece sizin tanımladığınız kaynak alabilir.
3. **Workflow runtime'da geçici STS credential alır.** Çalışma anında, kısa ömürlü GitHub OIDC token'ını AWS STS ile takas eder; varsayılan olarak bir saat içinde geçersiz olan geçici credential'lar üretir. Hiçbir yerde saklanan kalıcı secret yok — sızsa bile çok kısa ömürlü.
4. **Least privilege + prod için environment koruması uygulayın.** Role'ü minimum yetkiyle sınırlayın. Prod erişimi için GitHub Environments + zorunlu reviewer kullanın. Aynı yaklaşım her bulutta var: GCP ve Azure'da da Workload Identity Federation aynı işi görür.

**Sonuç:** Ben olsam AWS için OIDC + dar scope'lu IAM role kurardım — sıfır saklanan anahtar, sıkı trust koşulları, prod'da environment koruması. Bulut dışı secret'lar (DB şifresi gibi) için bunları GitHub Secrets'a koymak yerine runtime'da bir secrets manager'dan çekin. Kural net: standing credential'ı imkânsız kılmak için kimliği anlık ve kısa ömürlü üretin.

## İlgili Yazılar

- [Docker imaj boyutunu multi-stage build ve distroless ile nasıl küçültürüm?](https://www.muhammetsafak.com.tr/sor-bakalim/docker-imaj-boyutunu-multi-stage-ve-distroless-ile-kucultmek/) — Sor Bakalım
- [Hassas finansal veriyi şifrelerken anahtarı .env'de tutmak neden riskli — KMS/Vault ne sağlar?](https://www.muhammetsafak.com.tr/sor-bakalim/hassas-finansal-veriyi-sifrelemek-ve-anahtar-yonetimi-kms/) — Sor Bakalım
- [Self-hosted CI/CD runner'larını nasıl izole eder, her çalışmadan sonra temizlenen (ephemeral) ortamı nasıl kurarım?](https://www.muhammetsafak.com.tr/sor-bakalim/self-hosted-ci-cd-runner-izolasyonu-ve-ephemeral-ortam/) — Sor Bakalım