2026'nın En İyi Kubernetes Sırları Yönetim Araçları: Vault, ESO, Mühürlü Sırlar ve Daha Fazlası

Her Kubernetes kümesi yerleşik bir “Gizli” nesneyle birlikte gelir. Güvenlik gibi görünüyor. Güvenlik hissi veriyor. Güvenlik değil.

Kubernetes Sırrı, varsayılan olarak, etcd’de saklanan base64 kodlu bir dizedir; küme erişimi olan herkes tarafından okunabilir ve tek satırlık bir kodla kolayca çözülebilir: `echo “c2VjcmV0” | base64 -d’. Kullanımda olmayan şifrelemeyi açık bir şekilde etkinleştirmediğiniz sürece (ve çoğu ekip bunu yapmamıştır), veritabanı parolalarınız, API belirteçleriniz ve TLS özel anahtarlarınız kümenizin kontrol düzlemi veri deposunda şifrelenmemiş olarak durur. Git’e bir “Sır” içeren bir Kubernetes bildirimi gönderin ve bu kimlik bilgisi, deponuzun geçmişinde sonsuza kadar yaşar.

Bu, yeni nesil sır yönetimi araçlarının çözmek için ortaya çıktığı sorundur ve 2026’da ekosistem önemli ölçüde olgunlaşmıştır. Bu kılavuz, Kubernetes ortamlarındaki gizli dizileri yönetmeye yönelik en önemli altı aracı kapsar: Ne yaparlar, ne yapmazlar ve hangisinin ekibinizin olgunluk düzeyine uygun olduğunu.

İlgili okumalar: Gizli bilgilerin CI/CD ardışık düzeninizden sızmasından endişeleniyorsanız en iyi CI/CD ardışık düzen araçları özetimize bakın. Daha geniş konteyner güvenliği resmi için güvenlik açığı tarama araçları kılavuzumuza göz atın.

Kubernetes’in Varsayılan Sırları Neden Yetersiz Kalıyor?

Araçlara dalmadan önce Kubernetes Secrets’ta neyin eksik olduğu konusunda net olmakta fayda var; çünkü boşluğu anlamak, doğru çözümü seçmenizi sağlayan şeydir.

Varsayılan olarak beklemedeyken şifreleme yoktur. etcd, Kubernetes Secret’larını şifrelenmemiş olarak base64 olarak saklar. Kullanılmayan Şifrelemenin etkinleştirilmesi, yönetilen Kubernetes sağlayıcılarının (EKS, GKE, AKE) farklı şekilde ele aldığı, küme düzeyinde bir yapılandırma adımıdır ve kendi kendini yöneten birçok küme bu adımı tamamen atlar.

Gizli rotasyon yoktur. Bir Kubernetes Secret’ın, destek kimlik bilgilerinin değiştiğini bilmesini sağlayacak yerleşik bir mekanizma yoktur. Bir veritabanı parolasını harici olarak döndürürsünüz ve siz Sırrı manuel olarak güncelleyene ve etkilenen bölmeleri yeniden başlatana kadar bölmeleriniz eski şifreyi kullanmaya devam eder.

Gizli erişim için denetim günlüğü yok. Standart Kubernetes denetim günlüğü, Gizli nesne değişikliklerini kaydeder, ancak çoğu yapılandırma bireysel okumaları günlüğe kaydetmez; bu, “bu belirtece hangi hizmetin ne zaman eriştiği?” sorusunu yanıtlayamayacağınız anlamına gelir.

Tasarım gereği Git’e düşman. Standart tavsiye şu: “Asla Sırları Git’e teslim etmeyin.” Ancak her şeyin kod olarak hedeflendiği GitOps dünyasında, bunun sürdürülmesi acı verici bir istisnadır.

Kör bir araç olarak RBAC. Kubernetes RBAC, Gizli nesnelere ad alanı düzeyinde erişim izni vermenizi veya reddetmenizi sağlar. “Hizmet A, gizli X’i okuyabilir ancak gizli Y’yi okuyamaz” veya “bu Gizli Anahtarın süresi 24 saat içinde dolacaktır” ifadesini ifade edemez.

Bunların hiçbiri Kubernetes’ten vazgeçmek için neden değil; bunlar, bunun üzerine özel sır yönetimi araçlarını kullanmak için nedenler.

TL;DR — Özellik Karşılaştırması

⚠️ = ek bileşenler gerektirir

1. HashiCorp Kasası — Kurumsal Sırların Altın Standardı

HashiCorp Vault, diğer tüm gizli bilgi yönetimi araçlarının ölçüldüğü referans noktasıdır. Yaklaşık on yıldır kurumsal ortamlarda testlerden geçirilmiştir ve özellik seti bu derinliği yansıtmaktadır.

Vault’un temel yeteneği dinamik sırlar, yani isteğe bağlı olarak oluşturulan ve otomatik olarak süresi dolan kimlik bilgileridir. Vault, statik bir PostgreSQL şifresini depolamak yerine, talep eden her hizmet için, yapılandırılabilir bir kiralama süresi (ör. bir saat) boyunca geçerli olan benzersiz bir kullanıcı adı/şifre çifti oluşturur. Kira süresi sona erdiğinde, kimlik bilgisi iptal edilir. Bu, kimlik bilgilerinin yayılmasının tüm sınıflarını ortadan kaldırır ve ihlallerin kontrol altına alınmasını önemli ölçüde kolaylaştırır.

Kubernetes için, Vault Agent Injector veya Vault Secrets Operator entegrasyon yollarıdır. Enjektör, bir Vault aracısını otomatik olarak bölmelerinize gönderen, bölmenin Kubernetes hizmet hesabını kullanarak Vault’ta kimlik doğrulaması yapan ve sırları paylaşılan bir bellek içi birime yazan, mutasyona uğrayan bir web kancası olarak çalışır. Daha yeni bir yaklaşım olan Vault Secrets Operator (VSO), Vault sırlarını yerel Kubernetes Secret nesneleri ile senkronize eder; bu, operatörlerin daha aşina olduğu, etcd’de kısaca mevcut olan sırların maliyetine mal olur.

Vault’un gizli motorları etkileyici bir yelpazeyi kapsamaktadır:

• Veritabanı kimlik bilgileri (PostgreSQL, MySQL, MongoDB ve daha fazlası)
• AWS, GCP, Azure dinamik kimlik bilgileri
• PKI ve TLS sertifika üretimi
• SSH sertifikası imzalama
• Kubernetes hizmet hesabı jetonları

Vault’un iyi yaptığı şeyler: Dinamik kimlik bilgileri, ayrıntılı erişim politikaları, kapsamlı bir denetim günlüğü ve olgun bir eklenti ekosistemi. Kimin neye ne zaman eriştiğinin tam izini içeren uyumluluk düzeyinde gizli yönetime ihtiyacınız varsa, Vault genellikle tek makul seçenektir.

Dikkat edilmesi gerekenler: Apps Kasası’nın operasyonel karmaşıklığı vardır. Yüksek kullanılabilirlik modunda çalıştırmak, depolama arka uçlarına (Raft artık önerilen seçimdir), mühür açma prosedürlerine ve yükseltme yollarına dikkatli bir şekilde dikkat edilmesini gerektirir. Öğrenme eğrisi gerçektir. Platform mühendisliği süresi için bütçe.

Fiyatlandırma: Açık kaynak sürümü ücretsizdir ve çoğu ihtiyacı karşılar. HashiCorp Bulut Platformu (HCP) Kasası, küme saatlerine ve gizli işlemlere dayalı fiyatlandırmaya sahip yönetilen bir tekliftir. 2023’teki BSL lisans değişikliği, Terraform için OpenTofu çatalına yol açtı, ancak Vault’un çatal eşdeğeri (OpenBao) hâlâ olgunlaşıyor.

📚 Önerilen okuma: Andrew Martin ve Michael Hausenblas tarafından yazılan Kubernetes’i Hacklemek — gizli sızma senaryoları da dahil olmak üzere Kubernetes saldırı yüzeylerini mükemmel şekilde ele alıyor.

2. Dış Sırlar Operatörü (ESO) — K8s-Yerel Entegrasyon Katmanı

Harici Sırlar Operatörü temel olarak farklı bir mimari duruşa sahiptir: Kendisi bir sır deposu olmaktan ziyade, Kubernetes ile halihazırda sahip olduğunuz harici mağaza arasında bir köprüdür. ESO, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler ve sayıları giderek artan diğer arka uçlardan gelen sırları yerel Kubernetes Secret nesnelerine senkronize eder.

Temel soyutlama “ExternalSecret” özel kaynağıdır:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

ESO bu kaynağı izler, sırrı AWS Secrets Manager’dan (veya herhangi bir yerden) alır ve standart bir Kubernetes Secret oluşturur. Uygulamanız tıpkı diğer Kubernetes Secret’lar gibi “db-creds” okur; kod değişikliği gerekmez. ‘refreshInterval’ işaretlendiğinde, ESO Sırrı otomatik olarak yeniden getirir ve günceller.

ESO’nun 2026’da neden bu kadar popüler olduğu: Mevcut yatırımlarla iyi bir performans sergiliyor. Kuruluşunuzda zaten AWS Secrets Manager (veya Vault veya GCP Secret Manager) bulunmaktadır; ESO, uygulama kodunuzu veya mevcut gizli dizi rotasyonu iş akışlarınızı değiştirmeden bu gizli dizileri Kubernetes’te kullanılabilir hale getirir.

ESO mu yoksa Vault Secrets Operator mı? Vault’u çalıştırıyorsanız VSO’nun Vault’a özel entegrasyonu daha sıkıdır (Vault dinamik gizli dizileri, Vault PKI). Bir bulut sağlayıcının yerel gizli deposundaysanız ESO daha temiz bir seçimdir. Birçok ekip her ikisini de çalıştırıyor: bulutta depolanan statik sırlar için ESO, Vault tarafından yönetilen dinamik kimlik bilgileri için VSO.

Fiyatlandırma: ESO ücretsiz ve açık kaynaktır (Apache 2.0), güçlü topluluk desteğine sahip bir CNCF korumalı alan projesi tarafından sürdürülmektedir.

3. Mühürlü Sırlar — GitOps Dostu Şifrelenmiş Sırlar

Bitnami’nin sunduğu Sealed Secrets belirli bir sorunu çözüyor: Gerçek düz metni saklamadan Kubernetes Secret manifestlerini Git’te nasıl saklarsınız? Cevap asimetrik şifrelemedir.

Mühürlü Sırlar denetleyicisi kümenizde çalışır ve özel bir anahtara sahiptir. “Kubeseal” CLI, bir Kubernetes Secret bildirimini kümenin genel anahtarıyla şifreleyerek bir “SealedSecret” CRD üretir. Bu şifrelenmiş bildirim Git’e güvenli bir şekilde kaydedilebilir; yalnızca kümenin özel anahtarı şifresini çözebilir ve yalnızca söz konusu kümede şifresi çözülebilir (varsayılan olarak şifreli metin ad alanı + isme bağlıdır).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

Kümeye ‘SealedSecret’ uyguladığınızda, denetleyici bunun şifresini çözer ve karşılık gelen ‘Secret’ nesnesini oluşturur.

Sealed Secrets’ın en iyi yaptığı şey: GitOps iş akışları. Argo CD veya Flux kullanıyorsanız ve her küme kaynağının (gizliler dahil) Git’te bildirimli olarak saklanmasını istiyorsanız, Mühürlü Sırlar bu modele mükemmel şekilde uyar. Küme içi denetleyicinin ötesinde sıfır harici bağımlılık gerektirir.

Ne yapmaz: Standart Kubernetes olaylarının ötesinde rotasyon, dinamik kimlik bilgileri veya denetim günlüğü kaydı. Sealed Secrets, tam bir sır yönetimi platformu değil, bir Git depolama çözümüdür. Şifreniz değişirse yeniden şifreler ve tekrar taahhütte bulunursunuz.

Özel anahtar yedeklemesi kritik öneme sahiptir. Denetleyicinin özel anahtarını kaybederseniz, mühürlü sırlarınızın şifresini çözme yeteneğinizi kaybedersiniz. ‘Mühürlü sırlar-anahtarı’ sırrını ayrı, güvenli bir konuma yedekleyin.

Fiyatlandırma: Tamamen ücretsiz ve açık kaynak (Apache 2.0).

4. Kubernetes ile AWS Secrets Manager

İş yükleriniz öncelikli olarak EKS üzerinde çalışıyorsa (veya ağırlıklı olarak AWS hizmetlerine bağlanıyorsa), AWS Secrets Manager Secrets Store CSI Driver veya Harici Secrets Operatörü ile eşleştirilmiş olması doğal bir seçimdir. Sırları AWS’nin yönetilen, şifrelenmiş, denetim günlüğüne kaydedilen deposunda saklar ve gerektiğinde bunları Kubernetes’e çekersiniz.

Secrets Store CSI Sürücüsü (SSCSID), CNCF tarafından korunan bir yaklaşımdır: sırlar, bir CSI birimi aracılığıyla dosyalar halinde doğrudan bölmelere eklenir, asla Kubernetes Gizli nesneleri olarak vbd’ye yazılmaz. Bu en yüksek güvenlikli yoldur; sırlar bölme belleğinde bulunur ancak Kubernetes Gizli deposunda bulunmaz.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

AWS Secrets Manager’ın yerel yetenekleri arasında desteklenen hizmetler için otomatik rotasyon (RDS, Redshift, DocumentDB ve özel rotasyon için Lambda aracılığıyla), hesaplar arası erişim ve uyumluluk denetim izleri için derin CloudTrail entegrasyonu yer alır.

Maliyet değerlendirmesi: AWS Secrets Manager, gizli dizi başına ve API çağrısı başına ücret alır. Birçok küçük sır içeren büyük filolar için maliyetler artabilir. Gizli bilgilerle ilgili AWS harcamalarını yönetmeye ilişkin stratejiler için bulut maliyeti optimizasyon kılavuzumuza bakın.

Şunlar için en iyisi: Sıkı IAM entegrasyonu ve yerel RDS kimlik bilgisi rotasyonu isteyen EKS yerel ekipleri zaten AWS ekosistemine yatırım yaptı.

5. Doppler — Geliştiricinin İlk SaaS Sırları Platformu

Doppler, operasyonel karmaşıklıktan ziyade geliştirici deneyimine öncelik veren SaaS öncelikli bir yaklaşım benimser. Doppler’in kullanıcı arayüzünde (veya CLI/API aracılığıyla) gizli dizileri tanımlarsınız, bunları ortama göre (geliştirme, hazırlama, üretim) düzenlersiniz ve Doppler Kubernetes operatörü bunları otomatik olarak Kubernetes Gizli Dizileriyle senkronize eder.

Operatör, ilgili Kubernetes Gizli Dizini’nde yapılan değişiklikler ve güncellemeler için Doppler’ı yoklar ve isteğe bağlı olarak gizli diziler değiştiğinde bölmenin yeniden başlatılmasını tetikler. Kurulum tek bir Helm grafiği kurulumudur:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

Doppler’in parladığı yer: Kubernetes’in yanı sıra yerel geliştirme ve CI/CD entegrasyonu. Doppler CLI, ortam dosyalarını tamamen değiştirerek (“doppler çalıştırması – sizin komutunuz”) yerel, CI ve üretim ortamlarında aynı sırları verir. CI/CD işlem hatları için Doppler’in GitHub Actions, CircleCI ve diğerleriyle yerel entegrasyonları, gizli dizileri ardışık düzen ortam değişkenlerine kopyalama ihtiyacını ortadan kaldırır.

Doppler’in kapsamadığı konular: Dinamik veritabanı kimlik bilgileri. Doppler, sürüm geçmişini ve denetim günlüklerini içeren statik bir sır deposudur; Vault gibi gizli oluşturma motoru değildir.

Fiyatlandırma: Doppler küçük ekipler için ücretsiz bir katman sunar. Ücretli planlar SSO, erişim istekleri ve uyumluluk özellikleri ekler. Mevcut katmanlar (fiyatlandırma değişiklikleri; bütçelemeden önce doğrulayın) için Doppler fiyatlandırma sayfasını kontrol edin.

6. Infisical — Açık Kaynak Kasa Alternatifi

Infisical, Vault/Doppler ikilisinin en güçlü açık kaynak rakibidir. Kendi kendine barındırılabilen veya bulut hizmeti olarak tüketilebilen bir web kullanıcı arayüzü, CLI, SDK’lar ve bir Kubernetes operatörü sağlar.

Infisical, Vault’un veritabanı sırları motoruna benzer şekilde veritabanı kimlik bilgileri oluşturmayı hedefleyerek 2024’te dinamik sırlar desteğini ekledi. Infisical Kubernetes operatörü, yapılandırılabilir yenileme aralıklarıyla “InfisicalSecret” CRD’lerini yerel Kubernetes Secret’larıyla senkronize eder.

SaaS düzeyinde UX (web kontrol paneli, erişim isteği iş akışları, denetim günlükleri) isteyen ancak uyumluluk gereklilikleri nedeniyle harici SaaS kullanamayan ekipler için Infisical, kendi kendine barındırılan caziptir. Kullanımı Vault’a göre çok daha kolaydır ve geliştirici dostu bir ilk katılım deneyimine sahiptir.

Fiyatlandırma: Açık kaynak çekirdeği ücretsizdir. Bulutta barındırılan sürüm, gelişmiş özellikler için ücretsiz bir katmana ve ücretli planlara sahiptir. Kendi kendine barındırılan kurumsal lisans, uyumluluk açısından yoğun ortamlar için mevcuttur.

📚 Kubernetes güvenlik mimarisine daha derinlemesine bakmak için: Amazon’daki Kubernetes Güvenlik ve Gözlemlenebilirlik gizli dizileri, RBAC’yi, ağ politikasını ve çalışma zamanı güvenliğini tek bir uyumlu çerçevede kapsar.

Uygulama İpuçları

Kullanım sırasında şifrelemeyle başlayın. Herhangi bir ek araç eklemeden önce, kullanımda olmayan Kubernetes vbd şifrelemesini etkinleştirin. Yönetilen kümeler için bu genellikle tek bir onay kutusudur. Kendi kendine yönetilen kümeler için resmi kılavuzu izleyin. Bu, temel güvenlik duruşunuzu anında yükseltir.

Gizler için en az ayrıcalıklı RBAC’yi benimseyin. Hangi hizmet hesaplarının Gizli nesneler üzerinde “alma”, “listeleme” veya “izleme” izinlerine sahip olduğunu denetleyin. Birçok Helm grafiğindeki varsayılan hizmet hesaplarının provizyonu aşırıdır. Harici bir depoya dönmeden önce RBAC’yi sıkın.

Gizli adlandırma kurallarınızı erkenden planlayın. Sırlar hızla çoğalır. Tutarlı bir hiyerarşi ({env}/{service}/{credential-type}) otomasyonu, RBAC politikalarını ve rotasyon iş akışlarını tüm araçlarda önemli ölçüde basitleştirir.

Gizli rotasyon testini atlamayın. Hangi aracı seçerseniz seçin, ihtiyaç duymadan önce rotasyon tatbikatını çalıştırın. Uygulamanızın kesinti olmadan yeni kimlik bilgilerini aldığını doğrulayın. Vault veya ESO ile dinamik sırlar, bunu manuel olarak güncellenen statik sırlardan önemli ölçüde kolaylaştırır.

Gizli yayılmayı izleyin. Platformunuz büyüdükçe sırlar birikir. Gizli dizi yönetimi raporlarını platform mühendisliği kontrol panellerinize entegre edin. Gizli erişim düzenlerini izleyebilen gözlemlenebilirlik araçları için Kubernetes izleme araçları kılavuzumuza bakın.

Hangi Takım İçin Hangi Araç?

Küçük ekip, bulutta yerel (AWS/GCP/Azure): Bulut sağlayıcınızın yerel gizli deposuna bağlanan Harici Gizli Sırlar Operatörü ile başlayın. Minimum operasyonel ek yük, sağlam denetim entegrasyonu, ücretsiz.

GitOps-first ekibi (Argo CD / Flux): GitOps’ta depolanan yapılandırma için Mühürlü Sırlar, Git’te şifrelenmemiş olsa bile hassas çalışma zamanı kimlik bilgileri için ESO ile birleştirilmiştir.

Uyumluluk gereksinimlerine sahip kurumsal (SOC 2, PCI, HIPAA): HashiCorp Vault — şirket içinde barındırılan Raft kümesi veya HCP Vault tarafından yönetilen. Denetim günlüğünün, dinamik kimlik bilgilerinin ve ayrıntılı politika motorunun başka bir yerde kopyalanması zordur.

Geliştirici deneyimi odaklı, karma ortam (K8’ler + yerel + CI/CD): Ortamlar arası birleşik DX için Doppler veya veri yerleşimi önemliyse Infisical’ın kendi kendine barındırılması.

Çoklu küme ortamlarını yöneten büyük platform ekibi: Vault veya bulutta yerel bir mağaza tarafından desteklenen, K8s tarafı soyutlama katmanı olarak Harici Sırlar Operatörü. ESO’yu kümeler arasında evrensel bir adaptör olarak kullanırken gerçeğin kaynağını tek bir mağazada merkezileştirmek, 2026’da kanıtlanmış bir modeldir.

İlgili: Yapay zeka kodlama araçlarının Kubernetes bildirimlerinize ve CI/CD ardışık düzenlerinize getirdiği güvenlik riskleri için 2026’da titreşim kodlama güvenlik riskleri hakkındaki kılavuzumuza bakın.

SSS

Kubernetes Sırları varsayılan olarak şifrelenir mi?

Hayır. Kubernetes Secret’ları varsayılan olarak base64 ile kodlanmıştır; şifreleme değil kodlamadır. Veriler, Kullanımda Olmayan Şifrelemeyi açıkça etkinleştirmediğiniz sürece, şifreleme olmadan vbd’de saklanır. Her zaman küme yapılandırmanızı doğrulayın ve üretim iş yükleri için harici gizli dizi yönetimi araçlarını göz önünde bulundurun.

Mühürlü Sırlar ile Dış Sırlar Operatörü arasındaki fark nedir?

Sealed Secrets, güvenli Git depolaması için Secret bildirimlerini şifreler; bu bir GitOps çözümüdür. Harici Sırlar Operatörü, harici depolardan (Vault, AWS Secrets Manager vb.) canlı sırları alır ve onlardan yerel Kubernetes Sırları oluşturur. Farklı sorunları çözerler ve sıklıkla birlikte kullanılırlar.

Dinamik sırlar nelerdir ve neden önemlidirler?

Dinamik sırlar, süresiz olarak saklanan statik şifreler yerine, otomatik süre sonu ile isteğe bağlı olarak oluşturulan kimlik bilgileridir. HashiCorp Vault, Kubernetes için dinamik sırların birincil kaynağıdır. Dinamik bir kimlik bilgisi tehlikeye girerse kendi zamanlamasına göre sona erer. Bu, uzun ömürlü statik sırlarla karşılaştırıldığında ihlal patlama yarıçapını önemli ölçüde sınırlar.

Kubernetes için Doppler veya HashiCorp Vault kullanmalı mıyım?

Doppler, geliştirici deneyimi ve hızlı benimseme açısından avantajlıdır. Vault kurumsal uyumluluk konusunda kazanır; dinamik kimlik bilgileri, ayrıntılı denetim günlükleri ve ayrıntılı politika. Küçük ve orta ölçekli ekipler için Doppler genellikle daha hızlı yoldur. SOC 2, PCI DSS veya HIPAA ortamları için Vault genellikle daha savunulabilir bir seçimdir.

Gizli bilgilerin kapsayıcı günlüklerine sızmasını nasıl önleyebilirim?

Gizli dizileri ortam değişkenleri yerine dosyalar olarak bağlayın (ortam değişkenleri `/proc’ ve hata ayıklama uç noktaları aracılığıyla açığa çıkarılabilir). Etcd’yi tamamen atlamak için Secrets Store CSI Sürücüsünü kullanın. Trivy’nin gizli tarayıcısı gibi araçlarla CI/CD işlem hattınızda yanlışlıkla yapılan gizli işlemeleri tarayın. Kurulum ayrıntıları için güvenlik açığı tarama araçları kılavuzumuza bakın.

Küçük bir Kubernetes ekibi için en iyi gizli bilgi yönetimi aracı nedir?

Bulut sağlayıcınızın yerel gizli deposu tarafından desteklenen Harici Sırlar Operatörü ile başlayın. Minimum işlem yükü, sağlam denetim kaydı, ücretsiz. Birleşik bir geliştirme/CI/üretim sırları deneyimi de istiyorsanız Doppler’in ücretsiz katmanını ekleyin.

AWS Secrets Manager’ı Kubernetes’e nasıl entegre edebilirim?

Harici Gizli Diziler Operatörünü, AWS Secrets Manager’ı işaret eden bir ClusterSecretStore ile kullanın. EKS’de, kapsül düzeyinde IAM kimlik doğrulaması için IRSA’yı (Hizmet Hesapları için IAM Rolleri) kullanın; statik kimlik bilgilerine gerek yoktur. EKS olmayan kümelerde, kapsamı belirli gizli ARN’lerinize ayarlanmış secretsmanager:GetSecretValue özelliğine sahip bir IAM kullanıcısı kullanın.