CI/CD SECRETS MANAGEMENT

Bir geliştirici hafta sonu çalışırken AWS anahtarını test amacıyla repo'nun .env dosyasına yazıyor. Pazartesi sabah commit ediliyor, GitHub'a push'lanıyor. Botlar public repo'ları sürekli tarar; saatler içinde anahtar başka birinin elinde, EC2 instance'ları kripto madenciliği için ayağa kalkıyor, fatura 80.000 dolara dayanıyor. Bu uydurma bir senaryo değil — her ay onlarcası farklı şirketin başına geliyor. Secret management, CI/CD pipeline'larının en kritik fakat en çok ihmal edilen alanıdır. Bu yazı API anahtarları, veritabanı parolaları ve servis token'larının pipeline içinde güvenli yönetiminin nasıl kurulduğunu pratik örneklerle anlatır. Backend geliştiricisinden DevOps mühendisine, ürün yöneticisinden sistem güvenliğiyle ilgilenen herkesin bu konuda net bir zihin haritası taşıması artık zorunluluk.

1. Pipeline'da Secret Sızıntısının Gerçek Maliyeti

Sızan bir secret yalnızca AWS faturası değildir. Kredi kartı sağlayıcı API anahtarı çalındığında binlerce müşteri kaydı dış sisteme akabilir. Veritabanı kimliği sızdığında bir gece içinde tüm üretim verisi şifrelenip fidye notu bırakılabilir. SSH özel anahtarı git geçmişinde unutulduğunda saldırgan production sunucularına serbestçe bağlanır.

Sızıntı çoğu zaman tek bir hatadan değil, birkaç ihmalin üst üste binmesinden çıkar: secret düz metin tutuluyor, repo public'e çevriliyor, eski branch'ler silinmiyor, log'lara secret değeri basılıyor. GitGuardian'ın yıllık raporu yalnızca GitHub'da günde yaklaşık 30.000 yeni secret leak'i tespit edildiğini gösterir. Sayı 2020'den bu yana her yıl artıyor.

2. Asla Yapılmaması Gerekenler

Secret yönetiminde "ne yapılır"dan önce "ne yapılmaz" netleşmelidir. Yaygın kötü pratikler:

• Hardcoded anahtar: .env, config.json veya doğrudan kod içinde düz metin secret. Tek satır git push hepsini açar.
• Repo'ya commit edilen .env: .gitignore eklenmeden işe başlanmış proje. Git geçmişinden temizlemek günler sürer.
• Slack/email üzerinden paylaşılan parola: Mesaj geçmişi şirket dışı bir entegrasyona açılırsa secret de açılır.
• Aynı secret'ın her ortamda kullanılması: Dev, staging ve production aynı anahtarla çalışırsa dev sızıntısı production'ı düşürür.
• Süresiz secret: 2019'da oluşturulmuş, hiç döndürülmemiş anahtar. Şirketten ayrılan eski çalışan hâlâ kullanabilir.
• Log'a basılan secret: Hata ayıklarken environment variable'ı print etmek, sonra unutmak. Log toplayıcı tüm geçmişi saklar.

Bu listenin en az ikisi neredeyse her ekipte canlı durumdadır. Önce mevcut durumun ne olduğu açıkça çıkarılmalı, sonra düzeltme adımları sıraya konulmalıdır.

3. Secret Yönetiminin Beş Temel İlkesi

Sağlıklı bir secret yönetim sistemi beş prensip üzerine kurulur. Bunlar araç seçiminden bağımsızdır; kullanılan platform Vault, AWS Secrets Manager veya GitHub Actions native secrets olsun fark etmez.

1. Tek merkez (single source of truth): Tüm secret'lar tek bir yerde tutulur. Vault, AWS Secrets Manager, Azure Key Vault veya GCP Secret Manager gibi merkezi bir kasa.
2. En az ayrıcalık (least privilege): Her pipeline yalnızca ihtiyacı olan secret'lara erişir. Build job'u database parolasını okuyamamalı.
3. Şifrelenmiş depolama (encryption at rest): Disk üzerinde yazılı her secret AES-256 veya muadili ile şifrelenir.
4. Şifrelenmiş aktarım (encryption in transit): Secret'ın pipeline'a aktarımı TLS üzerinden olur. HTTP üzerinden API çağrısı yasak.
5. Denetlenebilirlik (audit log): Hangi pipeline, ne zaman, hangi secret'ı okudu — sorgulanabilir kayıt tutulur.

Bu prensiplerin pratik uygulamasını sağlam bir DevOps temeli üzerine oturtmak gerekir. CI/CD DevOps eğitimi hem pipeline kurulum hem secret yönetimini uygulamalı senaryolarla ele alır.

4. Yaygın Secret Management Araçları

Pratikte yaygın görülen çözümler üç kategoride toplanır:

Platform-Native Secrets

GitHub Actions, GitLab CI, Bitbucket Pipelines ve Azure DevOps kendi secret deposunu sunar. UI üzerinden secret eklenir, pipeline içinde environment variable olarak referans verilir. Küçük ve orta ölçekli ekipler için yeterlidir. Sınırlar: secret bir kez yazıldıktan sonra okunamaz (sadece üzerine yazılır), platform dışına taşıma zordur, çoklu repo arasında paylaşım pratik değildir.

Cloud Provider Vault'ları

AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Cloud altyapısı zaten kullanılıyorsa doğal seçim. IAM ile entegre; rotation otomatikleştirilebilir; audit log CloudTrail/Activity Log'a otomatik düşer. Maliyet secret başı aylıktır, yüzlerce secret olan ekipte fatura görünür hale gelir.

HashiCorp Vault

Cloud-agnostic, açık kaynak. On-premise data center'larda veya multi-cloud kurulumlarda standart sayılır. Dynamic secrets özelliği güçlü — pipeline çalışırken kısa ömürlü veritabanı kullanıcısı üretip iş bitince siler. Operasyonel yükü cloud-managed seçeneklerden yüksektir; Vault cluster'ı kurmak ve unseal süreçlerini yönetmek operasyon ekibi gerektirir. Aracın ürün sayfası ve dokümantasyonu derli toplu bir başlangıç için iyi bir referanstır: açık kaynak vault belgeleri.

5. GitHub Actions Üzerinde Uygulamalı Örnek

Pipeline'da secret tüketiminin pratiği bir GitHub Actions workflow'u üzerinde nasıl görünür? Aşağıdaki örnek bir Node.js projesinin Docker imajını AWS ECR'e push eden basit bir workflow'tur:

name: Build and Push
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-1
      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2
      - name: Build and push
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push myapp:${{ github.sha }}

Burada dikkat edilmesi gereken noktalar: secret değeri hiçbir yerde düz yazılmamıştır, sadece ad ile referans verilmiştir. GitHub workflow log'unda secret değeri otomatik maskelenir (***). env bloğu üzerinden secret tanımlandığında script içinde echo edilse bile log'a basılmaz. Bu önlemi atlatmak için secret'ı base64'e çevirip yazdırma denemesi yapan saldırgan davranışı düşünülmüştür; modern platformlar maskelemeyi byte düzeyinde uygular.

Container içine secret aktarımı ayrı bir konudur. Docker imajına secret katıştırmak yasak — imaj çekilebilir ve katmanlardan okunabilir. Docker eğitimi kapsamında BuildKit secrets ve runtime injection pratikleri ayrıntılı işlenir.

6. Secret Rotation ve Sızıntı Sonrası

Hiçbir secret sonsuza kadar güvenli kalmaz. Rotation (döndürme) sürecinin politikası yazılı olmalıdır. Tipik bir rotation takvimi:

• API anahtarları: 90 günde bir.
• Veritabanı parolaları: 60-90 günde bir, kritik veritabanlarında 30 gün.
• SSH özel anahtarları: Her yıl, çalışan ayrıldığında derhal.
• Servis token'ları (CI bot user): 6 ayda bir.
• Sızıntı şüphesi durumunda: Hemen, beklemeden.

Cloud secret manager'ların büyük çoğunluğu rotation'ı otomatikleştirir. AWS Secrets Manager bir Lambda fonksiyonu üzerinden RDS parolasını otomatik döndürür; uygulama değişikliği gerekmez çünkü uygulama her seferinde Secrets Manager'dan parolayı çeker.

Sızıntı tespit edildiğinde tepki süresi kritiktir. İlk on dakika içinde anahtar revoke edilmeli, audit log incelenmeli, etkilenen kaynaklar izole edilmelidir. Önceden hazırlanmış incident playbook bu süreyi belirgin biçimde kısaltır. Sızıntı sonrası "sadece anahtarı değiştirdik" diyerek olayı kapatmak hata — saldırgan zaten erişmişse kalıcı bir backdoor bırakmış olabilir. Etkilenen tüm sistemler taranır.

7. Pre-Commit ve Secret Scanning

En iyi savunma secret'ın hiç push edilmemesidir. Bunun için iki katman kurulur. Birincisi pre-commit hook: git commit yapılmadan önce yerel dosyalar taranır, secret pattern'i bulunursa commit reddedilir. detect-secrets, gitleaks veya git-secrets bu işi yapan açık kaynak araçlardır.

İkincisi sunucu tarafında secret scanning: GitHub Advanced Security, GitGuardian veya benzeri bir araç repo'ya push edilen her commit'i tarar, secret bulursa ekibe uyarı gönderir ve ilgili anahtarın bağlı olduğu servis sağlayıcıya da bildirim yapar. AWS bu uyarıyı aldığında ilgili anahtarı otomatik karantinaya alabilir.

Bu iki katman birlikte çalışınca sızıntı oranı belirgin biçimde düşer. Tek başına hiçbiri yeterli değil — pre-commit atlatılabilir, secret scanning ise hata gerçekleştikten sonra devreye girer.