Gizli Anahtarları Git'te Saklamak Neden Risklidir ve Semaphore Key Store Bu Sorunu Nasıl Çözer?

Geliştiriciler hâlâ API belirteçlerini, parolaları ve diğer kimlik bilgilerini kaynak koduna veya .env dosyalarına sabit olarak kodlayıp Git’e göndermektedir. Bu durum hem yan projelerde hem de üretim sistemlerinde yaşanmaktadır.

Bu model tanıdıktır: otomasyon ve dağıtım işlem hatlarına gizli dizileri (secrets) iletmenin basit bir yolu yoksa, Git bunları saklamak için tek kalıcı yer gibi görünmeye başlar. Ekipler daha sonra temizleyeceklerini söylerler. Pratikte, bir gizli dizi işlendikten (commit) sonra, onu geçmişten tamamen kaldırmak neredeyse imkansızdır.

Gizli Diziler İçin Git Neden Tehlikelidir? #

Git her revizyonu saklar. Bir belirteci bir dalın en sonundan silebilirsiniz, ancak eski commit’ler onu içermeye devam eder. Klonlar, çatallar (forks), yansımalar, CI kontrolleri ve yedek kopyaların tümü bu geçmişi yayar. Bir gizli dizi bir commit’e girdiği anda, doğrudan kontrolünüzden çıktığını varsaymalısınız.

Depoyu kimlerin okuyabileceği de genellikle beklenenden daha geniştir — yükleniciler, kısa süreli katkıda bulunanlar, dahili çatallar — bunların herhangi biri asla görmemesi gereken kimlik bilgilerini görebilir.

GitHub ve GitLab gizli dizi taraması yapar. Bir sağlayıcı bir belirteci işaretlerse, bunu sızdırılmış olarak kabul edin: belirteci iptal edin ve ona bağlı olan her şeyi yenileyin (rotate).

Git Yerine Gizli Diziler Nereye Ait? #

Bir gizli dizi, ağaçtaki sıradan bir dosya değildir. Deponun dışında yaşaması, yalnızca doğru sorumlular tarafından okunabilmesi, rotasyonu desteklemesi ve ortama göre (geliştirme, hazırlık, üretim) farklılık göstermesi gereken bir kimlik bilgisidir.

Vault veya OpenBao’yu kendi sunucunuzda barındırmak geçerli bir yaklaşımdır, ancak çalıştırılması, yamalanması ve izlenmesi gereken ek bir altyapı getirir.

Semaphore, doğrudan otomasyona bağlanan bir Key Store (Anahtar Deposu) içerir. Gizli dizileri şu konumlarda tutabilirsiniz:

• Semaphore’un şifrelenmiş deposu (varsayılan)
• Harici bir arka uç, örneğin:
  • HashiCorp Vault — kimlik bilgilerini Semaphore’un veritabanı yerine kendi Vault dağıtımınızda saklayın; değerler bir işin bunlara ihtiyacı olduğunda okunur (Pro).
  • OpenBao — topluluk tarafından sürdürülen, Vault uyumlu çatal; Vault ile aynı entegrasyon yolu üzerinden bağlanır (Pro).
  • Devolutions Server — Enterprise kurulumları için Vault ile aynı mantıkta Devolutions’ı gizli dizi arka ucu olarak kullanın (Enterprise).

Hızlı bir yol için yerleşik depoyu kullanın veya mevcut kurumsal gizli dizi sisteminizi bağlayın. Her ikisi de özel bir yapıştırıcı koda ihtiyaç duymadan iş akışlarıyla entegre olur.

Key Store’da Neler Saklayabilirsiniz? #

• API belirteçleri (tokens)
• SSH anahtarları
• Parolalar
• Ortam değişkenleri
• JSON ve diğer yapılandırma yükleri

Değerler asla depoda yaşamaz; çalışma zamanında işlere iletilir. Ortam başına farklı girdiler kullanabilir ve her gizli diziyi kimin veya hangi iş akışlarının kullanabileceğini kısıtlayabilirsiniz.

Pratikte Nasıl Çalışır? #

Bir Key Store girdisi oluşturur, gizli dizileri ona ekler ve bu girdiye görev yapılandırmanızdan başvurursunuz. Semaphore, iş çalıştığında değerleri çözer ve enjekte eder.

Örneğin, bir AWS dağıtımı sırasında erişim anahtarları yalnızca o işin ömrü boyunca, onu yürüten aracıda (agent) bulunur. Geliştiricilerin kendi yerel kopyalarında buna ihtiyacı yoktur ve Git’e hassas hiçbir şeyin commit edilmesi gerekmez.

Örnek #

Kullanıcı arayüzünde Secrets → New Secret bölümünü açın ve aşağıdaki gibi değişkenleri tanımlayın:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

İş akışınızda gizli diziye adıyla başvurun. Semaphore, o iş için değerleri ortam değişkenleri olarak gösterir:

blocks:
  - name: Deploy
    task:
      secrets:
        - name: aws-credentials
      jobs:
        - name: deploy
          commands:
            - aws s3 sync ./dist s3://my-bucket

SSH için özel anahtarı bir gizli dizide saklayın; Semaphore bunu iş için ~/.ssh/ altına yerleştirebilir:

blocks:
  - name: Deploy via SSH
    task:
      secrets:
        - name: production-ssh-key
      jobs:
        - name: deploy
          commands:
            - ssh deploy@production-server "cd /app && git pull"

Key Store ve Diğer Yaklaşımlar #

Ayrıca uygulama kodunu düzenlemeden rotasyon, role veya ekibe göre erişim sınırları ve ortamlar arasında temiz bir ayrım elde edersiniz.

Sonuç #

Git’e commit edilmiş herhangi bir belirteci güvenliği ihlal edilmiş olarak kabul edin. Geçmiş, makineler ve kuruluşlar arasında dağılır; her fazladan kopya, bir saldırganın bakabileceği başka bir yerdir.

Key Store, materyalleri depoların dışında tutar, yalnızca yürütme anında iletir ve size rotasyon ile erişim kontrolü için kaldıraçlar sağlar. Ansible, Terraform, OpenTofu veya PowerShell tabanlı otomasyonlar için bu isteğe bağlı bir cila değildir — güvenli bir şekilde çalışmanın asgari standardıdır.