# 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://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.

## Kısa cevap

Asıl mesele: kalıcı bir anahtarı bir yerde saklamak yerine, her çalışmada anlık üretilen geçici bir kimlik kullanmak. Workflow'un kendisini kurmayı [GitHub Actions yazısında](/tr/blog/biri-github-actions-mi-dedi/) anlatmıştım; buradaki tek değişiklik, o pipeline'a artık hiçbir anahtar gömmemek.

## Neden

1. **Uzun ömürlü anahtar, sürekli açık duran kalıcı bir kimliktir.** Sızar, rotasyonu zordur, merkezî takibi güçtür; GitHub Secrets bunu bir yere kadar çözer ama anahtarın kendisi hâlâ bir yerde durmaya devam eder.

2. **OIDC, "bu workflow gerçekten sizin reponuzdan mı geliyor?" sorusunu kriptografik olarak cevaplatır.** AWS, GitHub'ın imzaladığı token'lara güvenir; trust policy'deki koşullar tutmadığı sürece bir fork ya da rastgele bir PR bu role'ü üstlenemez.

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ü.

## Ne yapmalı

1. **GitHub Actions'ı AWS IAM'de OIDC identity provider olarak tanımlayın.** Bu, AWS'in GitHub'ın imzaladığı token'lara güvenmesini sağlayan tek seferlik kurulumdur.

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 role'ü yalnızca sizin tanımladığınız kaynak alabilir.

3. **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://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://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://muhammetsafak.com/tr/sor-bakalim/self-hosted-ci-cd-runner-izolasyonu-ve-ephemeral-ortam/) — Sor Bakalım