Het beveiligen van machine-identiteiten in Kubernetes in een zero-trustwereld

In Kubernetes zijn machine-identiteiten de certificaten, service-accounttokens en cryptografische sleutels die niet-menselijke componenten zoals pods, nodes, services en controllers identificeren. Het beveiligen ervan in een Zero Trust-model betekent dat elke workload bij elk verzoek zijn identiteit bewijst in plaats van te vertrouwen op basis van zijn netwerklocatie.

Om machine-identiteiten in Kubernetes te beveiligen onder Zero Trust , moet je elke workload een kortstondige, verifieerbare authenticatiecode geven, elke verbinding authenticeren met wederzijdse TLS, RBAC (Role-Based Access Control) met minimale privileges afdwingen en de uitgifte en rotatie van certificaten automatiseren. Kubernetes ondersteunt dit van nature via gebonden serviceaccounttokens, en tools zoals cert-manager en SPIFFE breiden dit uit naar workloadcertificaten.

Key Takeaways

• Volgens de CyberArk 2025 Identity Security Landscape-studie zijn er nu 82 keer zoveel machine-identiteiten als menselijke identiteiten, en Kubernetes-clusters zijn een van de snelste bronnen van die groei.
• Zero Trust, geformaliseerd in NIST SP 800-207 (augustus 2020) vervangt het vertrouwen in netwerklocatie door authenticatie en autorisatie per aanvraag voor elke workload.
• Sinds Kubernetes 1.24 maakt het controlepaneel niet langer automatisch langdurige, op Secrets gebaseerde service-accounttokens aan; gebonden, tijdsgebonden tokens (stabiel in 1.22) zijn de standaard.
• cert-manager (CNCF-gecertificeerd, november 2024) en SPIFFE/SPIRE (CNCF-gecertificeerd, september 2022) automatiseren de uitgifte van certificaten en workload-identiteiten binnen Kubernetes.
• De door het CA/Browser Forum gefaseerde verkorting van de geldigheidsduur van openbare TLS-certificaten tot 47 dagen in maart 2029 maakt geautomatiseerd certificaatbeheer verplicht voor alles wat een cluster publiekelijk beschikbaar stelt.

Wat zijn machine-identiteiten in Kubernetes?

In Kubernetes zijn machine-identiteiten de referenties waarmee niet-menselijke componenten worden geauthenticeerd: X.509-certificaten, service-accounttokens en cryptografische sleutels.

Knooppunten authenticeren zich bij de API-server met kubelet-clientcertificaten. Pods authenticeren zich met serviceaccounttokens die in hun bestandssysteem zijn opgeslagen. Services presenteren TLS-certificaten om hun identiteit te bewijzen, en frameworks zoals SPIFFE kennen aan elke workload een verifieerbaar identiteitsdocument (een SVID) toe. Al deze digitale certificaten en tokens doen hetzelfde als een badge voor een medewerker: ze bewijzen de identiteit voordat toegang wordt verleend.

De schaal is het lastigste. Pods kunnen maar enkele minuten bestaan, dus identiteiten moeten in hetzelfde tempo worden uitgegeven, geroteerd en verlopen. De CyberArk 2025 Identity Security Landscape-studie schat de verhouding tussen machine-identiteiten en menselijke identiteiten op 82 op 1, en gecontaineriseerde workloads zijn daar een belangrijke oorzaak van. Handmatige certificaatverwerking kan een dergelijke snelle verandering niet bijbenen.

Wat Zero Trust betekent voor een Kubernetes-cluster

Zero Trust is een beveiligingsmodel, geformaliseerd in NIST Special Publication 800-207 (augustus 2020), waarbij geen enkele gebruiker of workload standaard wordt vertrouwd en elk verzoek wordt geverifieerd en geautoriseerd. De Zero Trust-aanpak wordt vaak samengevat als "nooit vertrouwen, altijd verifiëren".

Een standaard Kubernetes-podnetwerk is plat: zodra een aanvaller één pod heeft gecompromitteerd, kan hij vaak elke andere pod bereiken. Zero Trust dicht die kloof door identiteit, en niet netwerkpositie, de basis voor toegang te maken. Beleid wordt op een gedetailleerd niveau afgedwongen, per workload en per verzoek, op basis van de geverifieerde identiteit van de workload, de namespace, de rol en de gevoeligheid van de resource die wordt aangeroepen. Het principe van minimale bevoegdheden beperkt vervolgens hoe ver een gecompromitteerde identiteit zich kan verspreiden.

In een Zero Trust-cluster wordt de identiteit uitgegeven en geverifieerd, nooit aangenomen.

Hoe Kubernetes machine-identiteiten uitgeeft en beheert.

Kubernetes geeft machine-identiteiten uit via serviceaccounttokens en certificaatondertekeningsverzoeken, en breidt deze uit met tools zoals cert-manager, SPIFFE/SPIRE en service meshes.

De grootste verandering van de afgelopen jaren is de verschuiving weg van tokens met een lange levensduur. Gebonden service-accounttokens werden stabiel in Kubernetes 1.22: ze zijn tijdsgebonden, doelgroepgebonden en gekoppeld aan een specifieke pod, en de kubelet roteert ze automatisch. Sinds Kubernetes 1.24 maakt het controlepaneel niet langer automatisch een niet-verlopende, op Secrets gebaseerde token aan voor elk nieuw service-account, en een cleaner die ongebruikte, verouderde tokens ongeldig maakt en verwijdert, werd stabiel in Kubernetes 1.30.

Kenmerk	Legacy Secret-gebaseerd token	Gebonden serviceaccounttoken
Levensduur	Onbeperkte geldigheidsduur; geldig tot handmatige intrekking.	Tijdsgebonden (doorgaans 1 uur); wordt geroteerd door de kubelet.
Toehoorders	Geaccepteerd door alles wat de clusterondertekeningssleutel vertrouwt.	Gebonden aan een specifiek publiek; elders afgewezen.
Bindend	Gekoppeld aan het serviceaccount	Gekoppeld aan het serviceaccount en de pod; verloopt tegelijk met de pod.
Impact van diefstal	Permanente API-toegang tot de intrekking	De toegang vervalt na de geldigheidsduur van het token.
Standaardstatus	Wordt niet automatisch aangemaakt sinds Kubernetes 1.24	Standaardprojectie sinds 1.22 (stabiel)

Naast de ingebouwde mechanismen automatiseert cert-manager de uitgifte en verlenging van X.509-certificaten binnen het cluster en werd het in november 2024 als CNCF-project erkend. SPIFFE en SPIRE, die in september 2022 als CNCF-project werden erkend, geven elke workload een platformonafhankelijke identiteit die werkt in clusters en clouds. Service meshes zoals Istio en Linkerd gebruiken deze kortstondige certificaten om wederzijdse TLS (mTLS) tussen services af te dwingen, zodat elke verbinding wordt geauthenticeerd en versleuteld. Een certificeringsinstantie vormt de basis van dit alles: elk certificaat verwijst naar een CA die het cluster vertrouwt.

Waarom de beveiliging van machine-identiteit belangrijk is

Met één gecompromitteerde machine-identiteit kan een aanvaller zich voordoen als een vertrouwde workload, verkeer onderscheppen en zich lateraal door het cluster bewegen.

Aanvallers richten zich op machine-identiteiten omdat deze permanente toegang bieden: een gestolen token of sleutel maakt man-in-the-middle-aanvallen, API-misbruik en het zich voordoen als legitieme services mogelijk. De NSA en CISA Kubernetes Hardening Guide (versie 1.2, augustus 2022) plaatst identiteitsbeheer centraal in de aanbevelingen: sterke authenticatie, RBAC met minimale privileges en regelmatige audits. Containerplatformen kennen dezelfde risico's als beschreven in de handleiding voor het beveiligen van containers, waarbij identiteit de verbindende laag vormt.

De regelgeving wijst allemaal dezelfde kant op. HIPAA, PCI DSS en GDPR vereisen allemaal gecontroleerde toegang tot gevoelige gegevens, versleuteling tijdens overdracht en opslag, en traceerbare gegevens over wie toegang heeft gehad tot welke gegevens. Machine-identiteitsbeheer ondersteunt al deze vereisten: certificaten en sleutels zorgen voor versleutelde, geauthenticeerde verbindingen; gecentraliseerde uitgifte en intrekking houden de inloggegevens actueel; en logboeken op identiteitsniveau bieden auditors een traceerbaar overzicht van machine-interacties.

De rol van HSM's en TPM's

Hardwarebeveiligingsmodules (HSM's) en vertrouwde platformmodules (TPM's) beschermen de privésleutels die de machine-identiteit verankeren in fraudebestendige hardware.

De meest waardevolle sleutels in een cluster zijn de sleutels van de certificeringsinstantie (CA) die elk workloadcertificaat ondertekenen. Door deze op te slaan in een FIPS 140-3 gevalideerde HSM, on-premises of via een cloudservice zoals AWS CloudHSM, Azure Key Vault Managed HSM of Google Cloud HSM, wordt voorkomen dat een softwarecompromis leidt tot een CA-compromis. TPM's werken op knooppuntniveau: de chip bevestigt dat een machine ongewijzigd is opgestart voordat deze zich bij het cluster mag aansluiten. Samen zorgen ze voor een hardwarematige vertrouwensbasis in de identiteitsketen. HSM-as-a-Service biedt dezelfde zekerheid zonder dat uw team de hardware zelf hoeft te beheren.

Wat volgt: kortere certificaten en post-quantum handtekeningen

Machine-identificatieprogramma's staan ​​voor twee achterhaalde mijlpalen: de verkorting van de geldigheidsduur van openbare TLS-certificaten tot 47 dagen en de overstap naar post-kwantumalgoritmen.

Het CA/Browser Forum heeft een gefaseerde verlaging van de maximale geldigheidsduur van openbare TLS-certificaten goedgekeurd: 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Elk publiek bereikbaar eindpunt dat een cluster bedient, zoals een ingress controller, zal in de laatste fase ongeveer acht keer per jaar certificaten vernieuwen. Deze frequentie sluit handmatige processen uit.

De migratie naar een tijdperk na de kwantumtechnologie volgt dezelfde logica van vroegtijdige voorbereiding. NIST publiceerde op 13 augustus 2024 FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA), de eerste post-kwantumstandaarden voor digitale handtekeningen. Digitale handtekeningen beschermen de vertrouwensketen achter elke machine-identiteit, en de CNSA 2.0-richtlijnen van de NSA streven al naar exclusieve kwantumresistente ondertekening voor Amerikaanse nationale veiligheidssoftware en -firmware vanaf 2027.

Het is een praktische eerste stap om nu al cryptografische flexibiliteit in de certificaatinfrastructuur in te bouwen, zodat algoritmes kunnen worden uitgewisseld zonder de architectuur opnieuw te hoeven ontwerpen. De groei van AI-agenten, die elk hun eigen referenties hebben, zal het aantal machine-identiteiten alleen maar verder doen toenemen.

Beste werkwijzen voor het beveiligen van machine-identiteiten in Kubernetes

Vijf werkwijzen dekken het grootste deel van het risico met betrekking tot machine-identiteit in een Kubernetes-cluster af.

1. Handhaaf het principe van minimale bevoegdheden binnen RBAC: Geef elke gebruiker en elk serviceaccount de minimaal benodigde machtigingen en controleer de roltoewijzingen volgens een vast schema, aangezien machtigingen kunnen veranderen naarmate clusters evolueren.
2. Gebruik één serviceaccount per workload: Door speciale serviceaccounts te gebruiken, blijven de machtigingen beperkt. Het instellen van automountServiceAccountToken op false voor pods die de API-server nooit aanroepen, verwijdert een overbodige authenticatiecode volledig.
3. Zorg ervoor dat inloggegevens niet lang geldig zijn: Gebruik gekoppelde serviceaccounttokens in plaats van handmatig aangemaakte geheime tokens, en automatiseer de uitgifte en verlenging van certificaten met cert-manager, zodat de vervaldatum nooit afhankelijk is van een herinnering in de agenda.
4. Versleutel service-naar-service-verkeer met mTLS: Een service mesh zoals Istio of Linkerd authenticeert beide uiteinden van elke verbinding en versleutelt het verkeer ertussen zonder dat de applicatie hoeft te worden aangepast.
5. Gebruik van identiteiten monitoren en controleren: Kubernetes-auditlogboeken registreren welke identiteit wat heeft gedaan; er wordt een waarschuwing gegenereerd bij afwijkende patronen, zoals een serviceaccount dat API's aanroept die het nog nooit heeft gebruikt. De NSA/CISA Kubernetes Hardening Guide (v1.2) dient als referentie.

Hoe encryptieconsultancy kan helpen

CertSecure Manager is het platform voor certificaatlevenscyclusbeheer van Encryption Consulting. Het automatiseert de uitgifte, verlenging en intrekking van machine-identiteiten voor certificeringsinstanties op locatie en in de cloud vanuit één dashboard. Het platform handhaaft het uitgiftebeleid via goedkeuringsworkflows, CSR-beperkingen en op rollen gebaseerde toegang tot certificaatsjablonen, en verstuurt vervalwaarschuwingen via Teams, e-mail en ServiceNow. Deze combinatie voorkomt dat certificaatverloop in Kubernetes leidt tot storingen of auditbevindingen. CertSecure Manager is gebaseerd op ISO/IEC 27001:2022 en SOC 2-gecertificeerde werkwijzen.

Veelgestelde Vragen / FAQ

Wat is een machine-identiteit in Kubernetes?

Een machine-identiteit in Kubernetes is een authenticatiemiddel waarmee een niet-menselijk component, zoals een pod, node, service of controller, wordt geverifieerd. De meest voorkomende vormen zijn X.509-certificaten, gekoppelde service-accounttokens en cryptografische sleutels. Elke workload presenteert zijn identiteit zodat de API-server en andere services kunnen controleren wie de aanroep doet voordat toegang wordt verleend.

Hoe is Zero Trust van toepassing op Kubernetes?

Zero Trust, zoals gedefinieerd in NIST SP 800-207, elimineert vertrouwen op basis van netwerklocatie. Toegepast op Kubernetes betekent dit dat elke verbinding tussen pods, tussen pods en API-servers, en tussen cluster en externe omgeving bij elk verzoek wordt geverifieerd en geautoriseerd, meestal met wederzijdse TLS en RBAC met minimale privileges, in plaats van alles zomaar te vertrouwen omdat het binnen het clusternetwerk draait.

Wat heeft de lang bestaande service-accounttokens in Kubernetes vervangen?

Gebonden serviceaccounttokens hebben ze vervangen. Gebonden tokens werden stabiel in Kubernetes 1.22: ze zijn tijdsgebonden, doelgroepgebonden en gekoppeld aan een specifieke pod, en de kubelet roteert ze automatisch. Sinds Kubernetes 1.24 maakt het controlepaneel niet langer automatisch langlevende, op Secrets gebaseerde tokens aan voor nieuwe serviceaccounts, en een cleaner voor ongebruikte legacy-tokens werd stabiel in 1.30.

Heb ik een service mesh nodig om machine-identiteiten in Kubernetes te beveiligen?

Nee, maar een service mesh maakt wederzijdse TLS op grote schaal praktisch. Meshes zoals Istio en Linkerd geven kortstondige certificaten uit aan elke workload en versleutelen het verkeer tussen services zonder dat de applicatie hoeft te worden aangepast. Zonder een mesh kunt u nog steeds cert-manager gebruiken voor certificaatautomatisering, gebonden serviceaccounttokens, RBAC en netwerkbeleid om de meeste risico's met betrekking tot machine-identiteit af te dekken.

Welke gevolgen hebben TLS-certificaten met een geldigheidsduur van 47 dagen voor Kubernetes-clusters?

Het CA/Browser Forum verlaagt de maximale geldigheidsduur van openbare TLS-certificaten in stappen: 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Elk certificaat dat een cluster openbaar beschikbaar stelt, zoals ingress-endpoints, moet automatisch worden uitgegeven en verlengd, omdat handmatige rotatie een cyclus van 47 dagen niet kan bijhouden.

Automatiseer de levenscyclus van machine-identiteiten in uw clusters.

Bekijk CertSecure Manager in actie met uw eigen certificatenportfolio, of neem contact op met een PKI-adviseur om Zero Trust-identiteitscontroles toe te passen op uw Kubernetes-clusters. ISO/IEC 27001:2022 gecertificeerd.