ESO en Previder Vault: controle over secrets in Kubernetes

In moderne DevOps teams draait veel om automatisering, betrouwbaarheid en security. Toch blijft één onderdeel in de praktijk vaak achter: secretbeheer. Denk aan API keys, certificaten, wachtwoorden en tokens die essentieel zijn voor applicaties, deployments en CI/CD processen.

Kubernetes biedt hiervoor een ingebouwd Secret object, maar dat is in veel omgevingen niet voldoende veilig of beheersbaar op schaal. Zeker niet wanneer je werkt met meerdere clusters, teams en omgevingen. In deze blog leg ik uit waarom dat zo is, waarom de External Secrets Operator, kortweg ESO, hiervoor een sterke oplossing is, en hoe je hem implementeert in combinatie met de Previder Vault dienst.

De voorbeelden en visuals in deze blog komen uit de presentatie die ik op 12 februari gaf tijdens TechFuse 2026.

Waarom Kubernetes Secrets niet genoeg zijn

Hoewel Kubernetes een ingebouwde Secret resource biedt, kent deze aanpak duidelijke beperkingen. Native Kubernetes Secrets zijn bruikbaar als runtime mechanisme, maar niet als volwassen oplossing voor centraal secretbeheer.

Een aantal knelpunten zie je in de praktijk steeds terug:

• Secrets worden standaard alleen base64 encoded opgeslagen. Dat is geen echte beveiliging.
• Secrets zijn via de Kubernetes API nog steeds op te vragen voor wie toegang heeft.
• Teams plaatsen secrets per ongeluk toch in Git repositories of manifests.
• Handmatige injectie in CI/CD pipelines vergroot het risico op fouten en blootstelling.
• Rotatie van secrets is omslachtig en vaak foutgevoelig.
• Centrale governance ontbreekt.
• Auditing is beperkt.
• Multi cluster gebruik wordt al snel complex en inconsistent.

Voor kleine omgevingen lijkt dat soms nog beheersbaar. Maar zodra je Kubernetes serieuzer inzet, wordt traditioneel secretbeheer al snel een operationeel en securityvraagstuk.

Enter: External Secrets Operator (ESO)

De External Secrets Operator is een Kubernetes operator die secrets automatisch synchroniseert vanuit een externe, beveiligde bron naar native Kubernetes Secrets. In plaats van secretwaarden zelf in Kubernetes te beheren, werk je met een centrale bron van waarheid en laat je ESO de synchronisatie verzorgen.

Dat maakt secretbeheer beter schaalbaar en sluit bovendien goed aan op een declaratieve, GitOps vriendelijke manier van werken. Ondersteunde secret providers zijn onder andere:

• Previder Secure Vault
• Azure Key Vault
• AWS Secrets Manager
• HashiCorp Vault
• Google Secret Manager
• 1Password, Bitwarden en meer

De volledige lijst is te vinden op https://external-secrets.io/.

Voordelen van ESO voor DevOps

Security
Met ESO staan secrets niet meer in Git, maar alleen nog referenties. De daadwerkelijke waarden blijven in een externe vault. Dat verlaagt het risico op onbedoelde blootstelling aanzienlijk. Daarnaast kun je toegang centraal regelen via IAM, RBAC of tokens, afhankelijk van de gebruikte provider. Auditing vindt plaats in de vault zelf (zoals Previder Vault), waar secretbeheer ook thuishoort.

Automatische rotatie
Wijzigingen in de vault kunnen automatisch worden doorgevoerd in Kubernetes. Daardoor hoef je secrets niet handmatig op meerdere plekken aan te passen. ESO zorgt voor de synchronisatie. Afhankelijk van hoe een workload secrets gebruikt, kan daarna nog wel een pod restart nodig zijn om de nieuwe waarde actief te maken.

Schaalbaarheid
ESO maakt het mogelijk om één centrale secretbron te gebruiken voor meerdere clusters en omgevingen. Dat zorgt voor meer consistentie en minder handmatig beheer. Voor platformteams is dat een stuk beter beheersbaar dan losse secrets per cluster of per pipeline.

Developer Experience
Voor developers en DevOps teams betekent dit minder handmatig werk en minder risico rondom secretinjectie in CI/CD. Je definieert declaratief welke secret nodig is en ESO verzorgt de rest. Dat past goed in GitOps workflows en maakt deployments reproduceerbaarder.

Previder Secure Vault als centrale bron

De Previder Vault biedt een centrale en veilige plek voor het opslaan en beheren van secrets. In combinatie met ESO vormt dit een sterke basis voor organisaties die secretbeheer professioneler willen inrichten. De Previder Vault biedt onder meer:

• gecentraliseerde en veilige opslag van secrets
• token based toegang
• audit logging en governance
• secret lifecycle management, zoals rotatie en regeneratie
• integratie met de Previder Portal en CLI tools zoals vault-cli (te verkrijgen via https://github.com/previder/va...)

Daarmee verplaats je secretbeheer uit het cluster naar een plek waar opslag, toegang en lifecycle beter beheersbaar zijn.

Implementatie: ESO en Previder Vault

Hieronder beschrijf ik stap‑voor‑stap hoe de implementatie eruit ziet.

1. Voorbeeld deployment.
   We starten met een eenvoudige NGINX‑deployment die een environment variable HELLO gebruikt.
   
   
   
   
   
   Later wordt deze waarde automatisch gevuld door ESO.
   
   
2. Installatie van de External Secrets Operator
   Via Helm installeer je ESO in het cluster
   
   helm repo add external-secrets https://charts.external-secret...
   helm install external-secrets \
   external-secrets/external-secrets \
   -n external-secrets --create-namespace
   
   

   ESO draait daarna in het cluster en kan SecretStore en ExternalSecret resources verwerken.
   
   

3. Previder Vault token aanmaken
   In de Previder Portal maak je een vault aan en genereer je een Read-Crite token. Dat token gebruikt ESO om secrets uit de vault op te halen. Sla het token vervolgens op in Kubernetes als Secret.
   
   Shell
   kubectl create secret generic previder-vault-token \
   --from-literal=token=<TOKEN>
   
   
4. SecretStore configureren
   Met een SecretStore geef je ESO door waar de Previder Vault bereikbaar is en hoe authenticatie plaatsvindt.
   
   
   
   De SecretStore vormt daarmee de koppeling tussen het cluster en de externe secretprovider.
   
   
5. ExternalSecret mapping
   Met een ExternalSecret definieer je welke waarde uit de vault opgehaald moet worden en hoe die lokaal in Kubernetes beschikbaar komt.
   
   
   
   
   
   
   

   ESO haalt nu automatisch de hello key op uit de Previder Vault en maakt daar een Kubernetes Secret van.
   Via deze ExternalSecret wordt ook de secret example-secret beheerd, met daarin een key genaamd hello. Voor deze demo staat de refreshInterval bewust laag ingesteld, zodat wijzigingen vrijwel direct zichtbaar worden in het cluster.
   
   

6. Automatische updates
   Pas je de secret aan in de Previder Vault (bijv. van world naar TechFuse!), dan:
   1. Detecteert ESO de wijziging automatisch.
   2. Update het Kubernetes Secret.
   3. Gebruiken nieuwe of nieuw gestarte pods de bijgewerkte waarde
      
   
   
   

   
   Laten we het gaan updaten naar TechFuse!

   
   
   
7. Secret regeneratie
   Wanneer je een secret verwijdert en opnieuw aanmaakt in de vault, kan ESO deze ook opnieuw ophalen en de Kubernetes Secret opnieuw aanmaken.

   Dat betekent in de praktijk:

   • de nieuwe secret wordt automatisch opgehaald
   • Kubernetes Secrets worden opnieuw opgebouwd
   • workloads kunnen met de nieuwe waarde verder

   De demo eindigt met de waarde: TechFuse 2026 – Maarssen

   
   
   
   
   

Conclusie

De combinatie van External Secrets Operator en Previder Vault biedt DevOps teams een veel sterkere manier om secrets in Kubernetes te beheren.

• Betere security
• Minder handmatig werk
• Automatische synchronisatie en rotatie
• Geen secrets meer in Git
• Audit‑ en governance‑mogelijkheden
• Multi‑cluster integratie
• Volledig declaratieve workflows die goed aansluiten op GitOps

Wie Kubernetes serieus inzet, kan eigenlijk niet meer zonder ESO. Het maakt secret‑beheer veiliger, consistenter en veel eenvoudiger.