İçeriğe geç
Ibrahim Halil KoyuncuMühendislik ve Ürün Stüdyosu
Eğitim amaçlı demo

Altyapı · Cloud-Native

Şifreleri ve anahtarları kodunuzdan uzak tutun — hangi kasayı kullanırsanız kullanın

Uygulamalar ihtiyaç duydukları kimlik bilgilerini doğrudan güvenli bir kasadan (HashiCorp Vault, AWS ya da Azure) alır; secret'lar asla kaynak kodda ya da konfigürasyon dosyalarında durmaz.

Proof of concept: Kubernetes için harici secret'lar: Vault, AWS ve Azure

Nerede işe yarar

  • Güvenlik incelemelerinden ve denetimlerden geçmek
  • Birden fazla bulut kullanan kurumlar
  • Uygulamaları yeniden deploy etmeden kimlik bilgilerini değiştirmek

Sayfanın devamı teknik detaylar: nasıl geliştirildiği ve sınırlarının neler olduğu.

Teknik problem

Uygulamaların kimlik bilgilerine ihtiyacı var; ancak secret'ları kodda ya da düz manifest'lerde tutmak risklidir ve birçok kurum birden fazla secret yöneticisi kullanır.

Mimari nasıl çalışıyor

  1. 01 · Kurulum

    Terraform; Vault'u (Kubernetes auth ile), AWS Secrets Manager'ı ya da Azure Key Vault'u yapılandırır.

  2. 02 · Bağlantı

    Bir SecretStore, External Secrets Operator'a her sağlayıcıda nasıl kimlik doğrulayacağını söyler.

  3. 03 · Senkronizasyon

    ExternalSecret kaynakları sağlayıcıdaki secret'ları native Kubernetes secret'larına eşler.

Neyi araştırıyorduk

Secret'ların kaynağı değişirken uygulama tarafının nasıl aynı kalabileceğini — Vault, AWS ve Azure'un bir arada bulunduğu hibrit ve çoklu bulut ortamları için faydalı.

Neler geliştirildi

Her sağlayıcı için Terraform, sağlayıcı başına SecretStore ve ExternalSecret manifest'leri ve Helm değerleriyle bir Vault kurulumu; iki bölümlük bir makaleyle birlikte.

Sınırlamalar ve sonraki adımlar

  • Senkronizasyona odaklanır; rotasyon politikaları ve denetim kapsam dışıdır.
  • Örnek kimlik bilgileri ve auth yöntemleri yerel gösterim için sadeleştirilmiştir.

Bunu kendi ortamınızda uygulamak ister misiniz?