Parhaat Kubernetes Secrets Management -työkalut vuonna 2026: Vault, ESO, Sealed Secrets ja paljon muuta

Jokainen Kubernetes-klusteri toimitetaan sisäänrakennetun “Secret” -objektin kanssa. Se näyttää turvallisuudesta. Se tuntuu turvalta. Se ei ole turvallisuutta.

Kubernetes Secret on oletusarvoisesti vain base64-koodattu merkkijono, joka on tallennettu etcd:hen. Se on kaikkien klusterikäyttöisten ja triviaalisti purettavissa yksirivisen avulla: echo "c2VjcmV0" | base64 -d. Ellet ole nimenomaisesti ottanut salausta käyttöön (ja useimmat tiimit eivät ole), tietokannan salasanasi, API-tunnuksesi ja TLS-yksityiset avaimesi ovat salaamattomina klusterin ohjaustason tietovarastossa. Tee Gitille Kubernetes-luettelo, joka sisältää “salaisuuden”, ja tämä valtuustieto säilyy arkistosi historiassa ikuisesti.

Tämä on ongelma, jonka ratkaisemiseksi on syntynyt uuden sukupolven salaisuuksien hallintatyökaluja – ja vuonna 2026 ekosysteemi on kypsynyt merkittävästi. Tämä opas kattaa kuusi tärkeintä työkalua salaisuuksien hallintaan Kubernetes-ympäristöissä: mitä he tekevät, mitä he eivät tee ja mikä sopii tiimisi kypsyystasoon.

Aiheeseen liittyvää luettavaa: Jos olet huolissasi salaisuuksista, jotka vuotavat CI/CD-putkisi kautta, katso parhaat CI/CD-putkistotyökalut. Katso laajempi säilön suojauskuva haavoittuvuuden tarkistustyökalujen oppaastamme.

Miksi Kubernetesin oletussalaisuudet jäävät vajaaksi

Ennen kuin sukellat työkaluihin, kannattaa olla tarkka siitä, mitä Kubernetes Secretsiltä puuttuu – koska aukon ymmärtäminen auttaa sinua valitsemaan oikean ratkaisun.

Ei salausta oletuksena. etcd tallentaa Kubernetes Secretsin base64-muodossa, ei salata. [Encryption at Rest] (https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) ottaminen käyttöön on klusteritason määritysvaihe, jossa hallinnoidut Kubernetes-palveluntarjoajat (EKS, GKE, AKE) käsittelevät eri tavalla, ja monet itsehallitut klusterit ohittavat sen kokonaan.

Ei salaista kiertoa. Kubernetes Secretissä ei ole sisäänrakennettua mekanismia, joka tietäisi, että sen taustatiedot ovat muuttuneet. Kierrät tietokannan salasanaa ulkoisesti, ja podisi käyttää vanhaa salasanaa, kunnes päivität salaisuuden manuaalisesti ja käynnistät uudelleen kyseiset podit.

Ei valvontalokia salaiselle käytölle. Vakio Kubernetes-tarkastuksen lokitietueet Salaiset objektien muutokset, mutta useimmat kokoonpanot eivät kirjaa yksittäisiä lukuja. Tämä tarkoittaa, että et voi vastata kysymykseen “mikä palvelu käytti tätä merkkiä ja milloin?”

Suunnitellusti vihollinen Git. Vakioohje on “älä koskaan sitoudu salaisuuksiin Gitiin”. Mutta GitOps-maailmassa, jossa kaikki koodina on tavoite, se on tuskallinen poikkeus säilyttää.

RBAC tylsänä välineenä. Kubernetes RBAC:n avulla voit myöntää tai estää pääsyn salaisiin objekteihin nimiavaruuden tasolla. Se ei voi ilmaista “Palvelu A voi lukea salaista X, mutta ei salaista Y” tai “tämä salaisuus vanhenee 24 tunnin kuluttua”.

Mikään näistä ei ole syy hylätä Kubernetes – ne ovat syitä käyttää omistettuja salaisuuksien hallintatyökaluja sen lisäksi.

TL;DR — Ominaisuuden vertailu

⚠️ = vaatii lisäkomponentteja

1. HashiCorp Vault – Yrityssalaisuuksien kultainen standardi

HashiCorp Vault on vertailukohta, johon kaikki muut salaisuuksien hallintatyökalut mitataan. Sitä on testattu yritysympäristöissä lähes vuosikymmenen ajan, ja sen ominaisuudet heijastavat tätä syvyyttä.

Holvin ydinominaisuus on dynaamiset salaisuudet – tunnistetiedot, jotka luodaan pyynnöstä ja vanhenevat automaattisesti. Staattisen PostgreSQL-salasanan tallentamisen sijaan Holvi luo yksilöllisen käyttäjätunnuksen/salasana-parin kullekin pyytävälle palvelulle, joka on voimassa määritettävän vuokra-ajan (esim. tunnin). Kun vuokrasopimus päättyy, valtakirja peruutetaan. Tämä eliminoi kokonaisia ​​valtuustietojen hajautusluokkia ja tekee rikkomusten hallinnasta huomattavasti helpompaa.

Kubernetesille integrointipolut ovat Vault Agent Injector tai Vault Secrets Operator. Injektori toimii mutatoituvana webhookina, joka automaattisesti lisää Holvi-agentin koteloihisi, joka todentaa Holvin käyttämällä podin Kubernetes-palvelutiliä ja kirjoittaa salaisuudet jaettuun muistitaltioon. Vault Secrets Operator (VSO), uudempi lähestymistapa, synkronoi Vaultin salaisuudet alkuperäisiin Kubernetes Secret -objekteihin – jotka ovat operaattoreille tutumpia, jne.:ssä hetkellisesti olemassa olevien salaisuuksien kustannuksella.

Holvin salaiset moottorit kattavat vaikuttavan valikoiman:

• Tietokannan tunnistetiedot (PostgreSQL, MySQL, MongoDB ja muut)
• AWS, GCP, Azure dynaamiset kirjautumistiedot
• PKI- ja TLS-varmenteiden luominen
• SSH-sertifikaatin allekirjoitus
• Kubernetes-palvelutilin tunnukset

Mitä Holvi tekee hyvin: Dynaamiset kirjautumistiedot, hienorakeiset käyttökäytännöt, kattava tarkastusloki ja kehittynyt laajennusekosysteemi. Jos tarvitset vaatimustenmukaisuustason salaista hallintaa, jossa on täydellinen jäljitys siitä, kuka käytti mitä-milloin, Holvi on usein ainoa järkevä vaihtoehto.

Mitä varoa: Holvin toiminta on monimutkaista. Sen käyttäminen korkean käytettävyyden tilassa vaatii tarkkaa huomiota tallennustaustajärjestelmiin (Raft on nyt suositeltu valinta), sulkemistoimenpiteisiin ja päivityspolkuihin. Oppimiskäyrä on todellinen. Budjetti alustan suunnitteluaikaan.

Hinnoittelu: Avoimen lähdekoodin versio on ilmainen ja kattaa useimmat tarpeet. HashiCorp Cloud Platform (HCP) -holvi on hallittu tarjonta, jonka hinnoittelu perustuu klusterin tunteihin ja salaisiin toimintoihin. BSL-lisenssimuutos vuonna 2023 johti OpenTofu-haarukkaan Terraformille, mutta Holvin haarukkavastaava (OpenBao) on vielä kypsymässä.

📚 Suositeltua luettavaa: Andrew Martinin ja Michael Hausenblasin Hacking Kubernetes – erinomainen kattavuus Kubernetesin hyökkäyspinnoille, mukaan lukien salaiset suodatusskenaariot.

2. External Secrets Operator (ESO) — K8s-Native Integration Layer

External Secrets Operator ottaa täysin erilaisen arkkitehtonisen asenteen: sen sijaan, että se olisi salaisuuksien myymälä, se on silta Kubernetesin ja minkä tahansa ulkoisen myymälän välillä. ESO synkronoi salaisuudet AWS Secrets Managerista, GCP Secret Managerista, Azure Key Vaultista, HashiCorp Vaultista, 1Passwordista, Dopplerista ja kasvavasta luettelosta muista taustaohjelmista alkuperäisiksi Kubernetes Secret -objekteiksi.

Keskeinen abstraktio on “ExternalSecret” mukautettu resurssi:

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 tarkkailee tätä resurssia, hakee salaisuuden AWS Secrets Managerista (tai mistä tahansa) ja luo tavallisen Kubernetes Secretin. Sovelluksesi lukee `db-creds’ aivan kuten mikä tahansa muu Kubernetes Secret - koodia ei tarvitse muuttaa. Kun “refreshInterval” rastittaa, ESO hakee salaisuuden uudelleen ja päivittää sen automaattisesti.

Miksi ESO on niin suosittu vuonna 2026: Se toimii hyvin olemassa olevien sijoitusten kanssa. Organisaatiossasi on jo AWS Secrets Manager (tai Holvi tai GCP Secret Manager) – ESO tekee nämä salaisuudet vain kulutettaviksi Kubernetesissa muuttamatta sovelluskoodiasi tai olemassa olevia salaisia ​​kiertotyönkulkujasi.

ESO vai Vault Secrets Operator? Jos käytät Vaultia, VSO:ssa on tiukempi Holvikohtainen integraatio (Vault Dynamic Secrets, Vault PKI). Jos käytät pilvipalveluntarjoajan alkuperäistä salakauppaa, ESO on selkeämpi valinta. Monet tiimit käyttävät molempia – ESO:ta pilveen tallennettuja staattisia salaisuuksia varten, VSO:ta Holvin hallinnoimia dynaamisia tunnistetietoja varten.

Hinnoittelu: ESO on ilmainen ja avoimen lähdekoodin (Apache 2.0), jota ylläpitää CNCF-hiekkalaatikkoprojekti, jolla on vahva yhteisön tuki.

3. Suljetut salaisuudet — GitOps-ystävälliset salatut salaisuudet

Bitnamin Sealed Secrets ratkaisee tietyn ongelman: kuinka Kubernetes Secret -luettelot tallennetaan Gitiin tallentamatta varsinaista selkeää tekstiä? Vastaus on epäsymmetrinen salaus.

Sealed Secrets -ohjain toimii klusterissasi ja sisältää yksityisen avaimen. “Kubeseal” CLI salaa Kubernetes Secret -luettelon klusterin julkisella avaimella ja tuottaa “SealedSecret” CRD:n. Tämä salattu luettelo voidaan sitoa Gitiin turvallisesti – vain klusterin yksityinen avain voi purkaa sen salauksen, ja se voidaan purkaa vain kyseisessä klusterissa (oletusarvoisesti salateksti on sidottu nimiavaruuteen + nimi).

# 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

Kun käytät “SealedSecret” -toimintoa klusteriin, ohjain purkaa sen salauksen ja luo vastaavan “Secret”-objektin.

Mitä Sealed Secrets tekee hyvin: GitOps-työnkulut. Jos käytät Argo CD:tä tai Fluxia ja haluat, että kaikki klusteriresurssit (myös salaisuudet) tallennetaan deklaratiivisesti Gitiin, Sealed Secrets sopii tähän malliin täydellisesti. Se ei vaadi ulkoisia riippuvuuksia klusterin sisäisen ohjaimen ulkopuolella.

Mitä se ei tee: Rotaatio, dynaamiset tunnistetiedot tai tarkastusloki tavallisten Kubernetes-tapahtumien ulkopuolella. Sealed Secrets on Git-tallennusratkaisu, ei täydellinen salaisuuksien hallintaalusta. Jos salasanasi muuttuu, salaat uudelleen ja sitoudut uudelleen.

Yksityisen avaimen varmuuskopiointi on kriittinen. Jos kadotat ohjaimen yksityisen avaimen, menetät mahdollisuuden purkaa sinetöityjä salaisuuksiasi. Varmuuskopioi “suljettujen salaisuuksien avain” -salaisuus erilliseen, suojattuun sijaintiin.

Hinnoittelu: Täysin ilmainen ja avoimen lähdekoodin (Apache 2.0).

4. AWS Secrets Manager Kubernetesin kanssa

Jos työkuormasi suoritetaan ensisijaisesti EKS:llä (tai vahvasti yhteydessä AWS-palveluihin), AWS Secrets Manager ja [Secrets Store CSI Driver] (https://secrets-store-csi-driver.sigs.k8s.io/) tai External fit Secrets Operator. Säilytät salaisuudet AWS:n hallitussa, salatussa, tarkastukseen kirjatussa varastossa ja vedät ne Kubernetesiin tarvittaessa.

Secrets Store CSI Driver (SSCSID) on CNCF:n ylläpitämä lähestymistapa: salaisuudet liitetään suoraan podeihin tiedostoina CSI-taltion kautta, eikä niitä koskaan kirjoiteta etcd:hen Kubernetes Secret -objekteina. Tämä on turvallisin polku – salaisuudet ovat pod-muistissa, mutta eivät Kubernetes Secret -kaupassa.

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

AWS Secrets Managerin alkuperäisiin ominaisuuksiin kuuluvat tuettujen palveluiden automaattinen kierto (RDS, Redshift, DocumentDB ja Lambda mukautettua kiertoa varten), tilien välinen käyttö ja syvällinen CloudTrail-integraatio vaatimustenmukaisuuden kirjausketjuja varten.

Huomio: AWS Secrets Manager veloittaa salaisuutta kuukaudessa ja API-kutsua kohti. Suurille laivastoille, joilla on monia pieniä salaisuuksia, kustannukset voivat kasvaa. Katso pilvikustannusten optimointioppaastamme strategioita salaisiin AWS-kulujen hallintaan.

Paras: EKS-alkuperäisryhmille, jotka ovat jo investoineet AWS-ekosysteemiin ja jotka haluavat tiiviin IAM-integraation ja alkuperäisen RDS-tunnistetietojen vaihdon.

5. Doppler — Kehittäjä-First SaaS Secrets Platform

Doppler käyttää SaaS-first-lähestymistapaa, joka asettaa kehittäjän kokemuksen toiminnan monimutkaisuuden edelle. Määrität salaisuudet Dopplerin käyttöliittymässä (tai CLI/API:n kautta), järjestät ne ympäristön mukaan (kehittäjä, lavastus, tuotanto), ja Doppler Kubernetes -operaattori synkronoi ne Kubernetes Secrets -tietoihin automaattisesti.

Operaattori kysyy Dopplerilta muutoksia ja päivittää vastaavan Kubernetes Secretin, mahdollisesti laukaisee pod-käynnistyksen uudelleen salaisuuksien muuttuessa. Asennus on yksi Helm chart -asennus:

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

Missä Doppler loistaa: Paikallinen kehitys ja CI/CD-integraatio Kubernetesin rinnalla. Doppler-CLI korvaa ympäristötiedostot kokonaan (“doppler run - your-command”) ja antaa samat salaisuudet paikallisissa, CI- ja tuotantoympäristöissä. CI/CD-putkien Dopplerin alkuperäiset integraatiot GitHub Actionsin, CircleCI:n ja muiden kanssa poistavat tarpeen kopioida salaisuuksia liukuhihnan ympäristömuuttujiin.

Mitä Doppler ei kata: Dynaamiset tietokannan tunnistetiedot. Doppler on staattinen salaisuusvarasto, jossa on versiohistoria ja tarkastusloki – se ei ole salaisuussukupolvi, kuten Vault.

Hinnoittelu: Doppler tarjoaa ilmaisen tason pienille ryhmille. Maksulliset suunnitelmat lisäävät kertakirjautumista, käyttöpyyntöjä ja vaatimustenmukaisuusominaisuuksia. Tarkista [Dopplerin hinnoittelusivulta] (https://www.doppler.com/pricing) nykyiset tasot (hinnoittelumuutokset; tarkista ennen budjetointia).

6. Infisical — avoimen lähdekoodin holvivaihtoehto

Infisical on Vault/Doppler-duopolin vahvin avoimen lähdekoodin haastaja. Se tarjoaa verkkokäyttöliittymän, CLI:n, SDK:t ja Kubernetes-operaattorin – käyttöönotettavissa itseisännöitynä tai pilvipalveluna käytettävänä.

Infisicalin lisätty dynaamisten salaisuuksien tuki vuonna 2024, joka kohdistuu tietokannan tunnistetietojen luomiseen, joka on samanlainen kuin Vaultin tietokannan salaisuudet. Infisical Kubernetes -operaattori synkronoi “InfisicalSecret” CRD:t alkuperäisiin Kubernetes Secrets -tietoihin määritettävillä päivitysväleillä.

Tiimille, jotka haluavat SaaS-tason UX:n (web-dashboard, pääsypyyntöjen työnkulku, tarkastuslokit), mutta jotka eivät voi käyttää ulkoista SaaS-palvelua vaatimustenmukaisuusvaatimusten vuoksi, Infisicalin itseisännöinti on pakottavaa. Sitä on huomattavasti helpompi käyttää kuin Holvia, ja siinä on kehittäjäystävällisempi käyttöönottokokemus.

Hinnoittelu: Avoimen lähdekoodin ydin on ilmainen. Pilvipalvelussa isännöidyssä versiossa on ilmainen taso ja maksulliset lisäominaisuudet. Itseisännöity yrityslisenssi on saatavilla vaativiin ympäristöihin.

📚 Syvemmälle Kubernetesin tietoturva-arkkitehtuuriin: Kubernetes Security and Observability Amazonissa kattaa salaisuudet, RBAC:n, verkkokäytännöt ja ajonaikaisen tietoturvan yhdessä yhtenäisessä kehyksessä.

Käyttöönottovinkkejä

Aloita salauksella. Ennen kuin lisäät lisätyökaluja, ota Kubernetes etcd -salaus käyttöön lepotilassa. Hallittujen klustereiden kohdalla tämä on usein yksi valintaruutu. Noudata itsehallinnoituja klustereita virallista opasta. Tämä kohentaa välittömästi perusturva-asentoasi.

Ota käyttöön vähiten etuoikeutettu RBAC salaisuuksille. Tarkista, millä palvelutileillä on “get”-, “list”- tai “watch”-oikeudet salaisille objekteille. Monien Helm-kaavioiden oletuspalvelutilit ovat ylivaroitettuja. Kiristä RBAC ennen kuin siirrät sen ulkoiseen varastoon.

Suunnittele salaiset nimeämiskäytännöt ajoissa. Salaisuudet lisääntyvät nopeasti. Johdonmukainen hierarkia ({env}/{service}/{credential-type}) yksinkertaistaa automaatiota, RBAC-käytäntöjä ja rotaatiotyönkulkua dramaattisesti kaikissa työkaluissa.

Älä ohita salaisia ​​kiertotestauksia. Valitse minkä tahansa työkalun, suorita kiertohara ennen kuin tarvitset sitä. Varmista, että sovelluksesi kerää uudet tunnistetiedot ilman seisokkeja. Dynaamiset salaisuudet Vaultin tai ESO:n kanssa tekevät tästä huomattavasti helpompaa kuin manuaalisesti päivitetyt staattiset salaisuudet.

Seuraa salaista leviämistä. Kun alustasi kasvaa, salaisuuksia kertyy. Integroi salaisuuksien hallinnan raportointi alustan suunnittelun hallintapaneeleihin. Katso Kubernetes-valvontatyökalujen oppaasta havainnointityökaluista, jotka voivat seurata salaisia ​​käyttömalleja.

Mikä työkalu mille joukkueelle?

Pieni tiimi, pilvipohjainen (AWS/GCP/Azure): Aloita External Secrets Operatorilla, joka muodostaa yhteyden pilvipalveluntarjoajasi alkuperäiseen salaiseen varastoon. Pienet käyttökustannukset, kiinteä auditointiintegraatio, ilmainen.

GitOps-ensimmäinen tiimi (Argo CD / Flux): Suljetut salaisuudet GitOpsiin tallennetuille määrityksille yhdistettynä ESO:n kanssa arkaluontoisten ajonaikaisten tunnistetietojen saamiseksi, joiden ei pitäisi olla Gitissä edes salattuja.

Yritys, jolla on vaatimustenmukaisuusvaatimukset (SOC 2, PCI, HIPAA): HashiCorp Vault – joko itseisännöity Raft-klusteri tai hallittu HCP Vault. Tarkastuslokia, dynaamisia tunnistetietoja ja hienojakoista käytäntömoottoria on vaikea kopioida muualle.

Kehittäjäkokemukseen keskittyvä, sekaympäristö (K8s + paikallinen + CI/CD): Doppler yhtenäistä DX:tä varten eri ympäristöissä tai Infisical itseisännöity, jos datan asuinpaikalla on merkitystä.

Suuri alustatiimi, joka hallitsee moniklusteriympäristöjä: External Secrets Operator K8s-puolen abstraktiokerroksena, jota tukee Holvi tai pilvipohjainen kauppa. Totuuden lähteen keskittäminen yhteen kauppaan samalla kun ESO:ta käytetään universaalina sovittimena klusterien välillä on hyvin todistettu malli vuonna 2026.

Aiheeseen liittyvä: Katso tietoturvariskeistä, joita tekoälykoodaustyökalut tuovat Kubernetes-luetteloihisi ja CI/CD-putkiin, oppaastamme [vibe coding security risk in 2026] (/posts/vibe-coding-security-risks-2026/).

UKK

Onko Kubernetes Secrets oletusarvoisesti salattu?

Ei. Kubernetes Secrets on oletuksena base64-koodattu – koodaus, ei salaus. Tiedot tallennetaan etcd:hen ilman salausta, ellet ole erikseen ottanut käyttöön Encryption at Rest. Tarkista aina klusterin kokoonpano ja harkitse ulkoisia salaisuuksien hallintatyökaluja tuotantotyökuormituksia varten.

Mitä eroa on Sealed Secrets ja External Secrets Operatorin välillä?

Sealed Secrets salaa Secret-luettelot turvalliseen Git-tallennustilaan – se on GitOps-ratkaisu. External Secrets Operator hakee elävät salaisuudet ulkoisista kaupoista (Holvi, AWS Secrets Manager jne.) ja luo niistä alkuperäisiä Kubernetes-salaisuuksia. Ne ratkaisevat erilaisia ​​ongelmia ja niitä käytetään usein yhdessä.

Mitä ovat dynaamiset salaisuudet ja miksi niillä on merkitystä?

Dynaamiset salaisuudet ovat pyynnöstä luotuja tunnistetietoja, joiden voimassaolo päättyy automaattisesti – sen sijaan, että staattisia salasanoja säilytetään toistaiseksi. HashiCorp Vault on Kubernetesin dynaamisten salaisuuksien ensisijainen lähde. Jos dynaaminen valtuustieto vaarantuu, se vanhenee oman aikataulunsa mukaisesti. Tämä rajoittaa räjähdyksen sädettä dramaattisesti pitkäikäisiin staattisiin salaisuuksiin verrattuna.

Pitäisikö minun käyttää Doppleria tai HashiCorp Vaultia Kubernetesille?

Doppler voittaa kehittäjäkokemuksen ja nopean käyttöönoton. Holvi voittaa yrityksen vaatimustenmukaisuuden – dynaamiset kirjautumistiedot, yksityiskohtaiset tarkastuslokit ja tarkka käytäntö. Pienille ja keskikokoisille ryhmille Doppler on usein nopeampi tapa. SOC 2-, PCI DSS- tai HIPAA-ympäristöissä Vault on yleensä puolustettavissa oleva valinta.

Kuinka estän salaisuuksia vuotamasta konttilokeihin?

Liitä salaisuudet tiedostoina ympäristömuuttujien sijaan (ympäristömuuttujat voidaan paljastaa /proc- ja debug-päätepisteiden kautta). Ohita etcd kokonaan käyttämällä Secrets Storen CSI-ohjainta. Etsi vahingossa tapahtuneita salaisia ​​sitoumuksia CI/CD-putkistosta Trivy’s Secret -skannerin kaltaisilla työkaluilla – katso [haavoittuvuuden tarkistustyökalujen oppaasta] (/posts/vulnerability-scanning-tools-devops-2026/) lisätietoja asennuksesta.

Mikä on paras salaisuuksien hallintatyökalu pienelle Kubernetes-tiimille?

Aloita External Secrets Operatorilla, jota tukee pilvipalveluntarjoajasi alkuperäinen salainen varasto. Minimaaliset käyttökustannukset, kiinteä tarkastusloki, ilmainen. Lisää Dopplerin ilmainen taso, jos haluat myös yhtenäisen dev/CI/production secrets -kokemuksen.

Kuinka voin integroida AWS Secrets Managerin Kubernetesiin?

Käytä External Secrets Operatoria ClusterSecretStoren kanssa, joka osoittaa AWS Secrets Manageriin. Käytä EKS:ssä IRSA:ta (IAM Roles for Service Accounts) pod-tason IAM-todennusta varten – staattisia tunnistetietoja ei tarvita. Käytä muissa kuin EKS-klustereissa IAM-käyttäjää, jonka secretsmanager:GetSecretValue on kohdistettu tiettyihin salaisiin ARN-numeroihisi.