Säkra maskinidentiteter i Kubernetes i en värld utan förtroende

Maskinidentiteter i Kubernetes är certifikat, tjänstkontotokens och kryptografiska nycklar som identifierar icke-mänskliga komponenter som poddar, noder, tjänster och styrenheter. Att säkra dem i en Zero Trust-modell innebär att varje arbetsbelastning bevisar sin identitet vid varje begäran istället för att vara betrodd av sin nätverksplats.

För att säkra maskinidentiteter i Kubernetes under Zero Trust , utfärda varje arbetsbelastning en kortlivad, verifierbar autentiseringsuppgift, autentisera varje anslutning med ömsesidig TLS, tillämpa RBAC med minsta behörighet och automatisera utfärdande och rotation av certifikat. Kubernetes stöder detta inbyggt genom bundna tjänstkontotokens, och verktyg som cert-manager och SPIFFE utökar det till arbetsbelastningscertifikat.

Key Takeaways

• Enligt studien CyberArk 2025 Identity Security Landscape överstiger maskinidentiteter nu mänskliga identiteter med 82 procent, och Kubernetes-kluster är en av de snabbaste källorna till den tillväxten.
• Nollförtroende, formaliserat i NIST SP 800-207 (augusti 2020), ersätter nätverksplatsförtroende med autentisering per begäran och auktorisering av varje arbetsbelastning.
• Sedan Kubernetes 1.24 skapar kontrollplanet inte längre automatiskt långlivade hemlighetsbaserade tjänstkontotokens; bundna, tidsbegränsade tokens (stabila i 1.22) är standard.
• cert-manager (CNCF tog examen i november 2024) och SPIFFE/SPIRE (CNCF tog examen i september 2022) automatiserar utfärdande av certifikat och arbetsbelastningsidentiteter i Kubernetes.
• CA/Browser Forums etappvisa minskning av offentliga TLS-certifikats livslängd till 47 dagar senast i mars 2029 gör automatiserad certifikathantering obligatorisk för allt som ett kluster exponerar offentligt.

Vad är maskinidentiteter i Kubernetes?

Maskinidentiteter i Kubernetes är de autentiseringsuppgifter som autentiserar icke-mänskliga komponenter: X.509-certifikat, tjänstkontotokens och kryptografiska nycklar.

Noder autentiserar sig mot API-servern med kubelet-klientcertifikat. Podar autentiserar sig med tjänstkontotokens som projiceras i deras filsystem. Tjänster presenterar TLS-certifikat för att bevisa vilka de är, och ramverk som SPIFFE tilldelar varje arbetsbelastning ett verifierbart identitetsdokument (ett SVID). Alla dessa är digitala certifikat och tokens som gör samma jobb som en bricka gör för en anställd: bevisa identitet innan åtkomst beviljas.

Skalan är den svåra delen. Poddar kan leva i minuter, så identiteter måste utfärdas, roteras och löpa ut i samma takt. CyberArk 2025 Identity Security Landscape-studien uppskattar förhållandet mellan maskinidentiteter och mänskliga identiteter till 82 till 1, och containerbaserade arbetsbelastningar är en viktig drivkraft för den siffran. Manuell certifikathantering kan inte hålla jämna steg med den här omsättningen.

Vad noll förtroende innebär för ett Kubernetes-kluster

Zero Trust är en säkerhetsmodell, formaliserad i NIST Special Publication 800-207 (augusti 2020), där ingen användare eller arbetsbelastning är betrodd som standard och varje begäran autentiseras och auktoriseras. Zero Trust-metoden sammanfattas ofta som "lita aldrig, verifiera alltid".

Ett standardnätverk för Kubernetes-podar är platt: när en angripare komprometterar en pod kan de ofta nå alla andra pods. Nollförtroendet stänger den klyftan genom att göra identitet, inte nätverksposition, till grund för åtkomst. Policyn tillämpas på en detaljerad nivå, per arbetsbelastning och per begäran, baserat på arbetsbelastningens verifierade identitet, dess namnrymd, dess roll och känsligheten hos den resurs den anropar. Minsta privilegium begränsar sedan hur långt en komprometterad identitet kan färdas.

I ett Zero Trust-kluster utfärdas och verifieras identitet, den antas aldrig.

Hur Kubernetes utfärdar och hanterar maskinidentiteter

Kubernetes utfärdar maskinidentiteter genom tjänstkontotokens och certifikatsigneringsförfrågningar, och utökar dem med verktyg som cert-manager, SPIFFE/SPIRE och tjänstnät.

Den största förändringen under de senaste åren är övergången från långlivade tokens. Bundna servicekontotokens blev stabila i Kubernetes 1.22: de är tidsbegränsade, publikbundna och knutna till en specifik pod, och kubeleten roterar dem automatiskt. Sedan Kubernetes 1.24 skapar kontrollplanet inte längre automatiskt en icke-utgången hemlighetsbaserad token för varje nytt servicekonto, och en rensare som ogiltigförklarar och tar bort oanvända äldre tokens blev stabil i Kubernetes 1.30.

Attribut	Äldre hemlighetsbaserad token	Bunden tjänstkontotoken
Livslängd	Giltig tills den återkallas manuellt	Tidsbegränsad (vanligtvis 1 timme); roteras av kubeleten
publik	Accepteras av allt som litar på klustersigneringsnyckeln	Bunden till en specifik publik; avvisad någon annanstans
Bindning	Endast knuten till servicekontot	Kopplat till tjänstkontot och podden; upphör att gälla med podden
Stöldpåverkan	Permanent API-åtkomst tills den återkallas	Åtkomsten upphör med tokenens livslängd
Standardstatus	Inte automatiskt skapad sedan Kubernetes 1.24	Standardprojektion sedan 1.22 (stabil)

Utöver de inbyggda mekanismerna automatiserar cert-manager utfärdande och förnyelse av X.509-certifikat inom klustret och tog examen som ett CNCF-projekt i november 2024. SPIFFE och SPIRE, CNCF tog examen i september 2022, ger varje arbetsbelastning en plattformsoberoende identitet som fungerar över kluster och moln. Tjänstenätverk som Istio och Linkerd använder dessa kortlivade certifikat för att upprätthålla ömsesidig TLS (mTLS) mellan tjänster, så att varje anslutning autentiseras och krypteras. En certifikatutfärdare förankrar allt detta: varje certifikat är kopplat tillbaka till en CA som klustret litar på.

Varför maskinidentitetssäkerhet är viktigt

En enda komprometterad maskinidentitet låter en angripare imitera en betrodd arbetsbelastning, fånga upp trafik och röra sig i sidled genom klustret.

Angripare riktar in sig på maskinidentiteter eftersom de har permanent åtkomst: en stulen token eller nyckel möjliggör man-in-the-middle-avlyssning, API-missbruk och personifiering av legitima tjänster. NSA och CISA Kubernetes Hardening Guide (version 1.2, augusti 2022) gör identitetskontroller centrala i sina rekommendationer: stark autentisering, RBAC med minsta behörighet och regelbundna granskningar. Containerplattformar ärver samma risker som täcks av hur man säkrar en container, med identitet som det sammanbindande lagret.

Reglering pekar i samma riktning. HIPAA, PCI DSS och GDPR kräver alla kontrollerad åtkomst till känsliga data, kryptering under överföring och i vila, och granskningsbara register över vem som åtkom vad. Maskinidentitetshantering stöder varje krav: certifikat och nycklar framtvingar krypterade, autentiserade anslutningar; centraliserad utfärdande och återkallelse håller inloggningsuppgifterna aktuella; och loggar på identitetsnivå ger granskare en spårbar registrering av maskininteraktioner.

HSM:ernas och TPM:ernas roll

Hårdvarusäkerhetsmoduler (HSM) och betrodda plattformsmoduler (TPM) skyddar de privata nycklarna som förankrar maskinidentitet i manipulationssäker hårdvara.

De mest värdefulla nycklarna i ett kluster är certifikatutfärdarnycklarna som signerar varje arbetsbelastningscertifikat. Att lagra dem i en FIPS 140-3-validerad HSM, lokalt eller via en molntjänst som AWS CloudHSM, Azure Key Vault Managed HSM eller Google Cloud HSM, förhindrar att en programvarukompromittering blir en CA-kompromittering. TPM:er fungerar på nodnivå: chipet intygar att en maskin startade omanipulerad innan den tillåts ansluta till klustret. Tillsammans ger de identitetskedjan en hårdvarurot av förtroende. HSM-as-a-Service erbjuder samma garanti utan att ditt team äger hårdvaran.

Vad som kommer härnäst: Kortare certifikat och postkvantumsignaturer

Maskinidentifieringsprogram står inför två daterade milstolpar: minskningen av livslängden för offentliga TLS-certifikat till 47 dagar och migreringen till postkvantalgoritmer.

CA/Browser Forum har godkänt en stegvis minskning av den maximala giltighetstiden för publika TLS-certifikat: 200 dagar från och med den 15 mars 2026, 100 dagar från och med den 15 mars 2027 och 47 dagar från och med den 15 mars 2029. Varje offentligt nåbar slutpunkt som ett kluster betjänar, såsom en ingress-kontroller, kommer att förnya certifikaten ungefär åtta gånger om året i det sista steget. Den takten utesluter manuella processer.

Post-kvantmigrering följer samma logik med tidig förberedelse. NIST publicerade FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), sina första standarder för post-kvantsignering, den 13 augusti 2024. Signaturer skyddar förtroendekedjan bakom varje maskinidentitet, och NSA:s CNSA 2.0-riktlinjer riktar sig redan mot exklusiv kvantresistent signering för amerikansk nationell säkerhetsprogramvara och firmware från 2027.

Att bygga in kryptoagilitet i certifikatinfrastrukturen nu, så att algoritmer kan bytas ut utan omarkitektur, är det praktiska första steget. Tillväxten av AI-agenter, som var och en bär sina egna inloggningsuppgifter, kommer bara att driva upp antalet maskinidentiteter.

Bästa praxis för att säkra maskinidentiteter i Kubernetes

Fem metoder täcker det mesta av maskinidentitetsrisken i ett Kubernetes-kluster.

1. Tillämpa RBAC med lägst behörighet: Ge varje användare och tjänstkonto de lägsta behörigheter som behövs och granska rollbindningar enligt ett schema, eftersom behörigheterna ändras allt eftersom kluster utvecklas.
2. Använd ett tjänstkonto per arbetsbelastning: Dedikerade tjänstkonton håller behörigheterna begränsade, och om du anger automountServiceAccountToken till falskt för poddar som aldrig anropar API-servern tas onödiga autentiseringsuppgifter bort helt.
3. Håll inloggningsuppgifterna kortlivade: Förlita dig på bundna tjänstkontotokens snarare än manuellt skapade hemliga tokens och automatisera certifikatutfärdande och förnyelse med cert-manager så att utgångsdatumet aldrig är beroende av en kalenderpåminnelse.
4. Kryptera tjänst-till-tjänst-trafik med mTLS: Ett servicenät som Istio eller Linkerd autentiserar båda ändar av varje anslutning och krypterar trafiken mellan dem utan applikationsändringar.
5. Övervaka och granska identitetsanvändning: Kubernetes granskningsloggar registrerar vilken identitet som gjorde vad; varnar för avvikande mönster, till exempel ett tjänstkonto som anropar API:er som det aldrig har använt. NSA/CISA Kubernetes Hardening Guide (v1.2) är referensbaslinjen.

Hur krypteringskonsulting hjälper

CertSecure Manager är Encryption Consultings plattform för hantering av certifikatlivscykeln. Den automatiserar utfärdande, förnyelse och återkallelse av maskinidentiteter hos lokala och molnbaserade certifikatutfärdare från en enda instrumentpanel, upprätthåller utfärdandepolicyer genom godkännandeflöden, CSR-begränsningar och rollbaserad åtkomst till certifikatmallar, och skickar utgångsmeddelanden via Teams, e-post och ServiceNow. Den kombinationen förhindrar att certifikatbortfall i Kubernetes leder till avbrott eller granskningsresultat. Stöds av ISO/IEC 27001:2022- och SOC 2-certifierade metoder.

Vanliga frågor om partihandel med mat och dryck

Vad är en maskinidentitet i Kubernetes?

En maskinidentitet i Kubernetes är en autentiseringsuppgift som autentiserar en icke-mänsklig komponent, såsom en pod, nod, tjänst eller kontrollant. De vanligaste formerna är X.509-certifikat, bundna tjänstkontotokens och kryptografiska nycklar. Varje arbetsbelastning presenterar sin identitet så att API-servern och andra tjänster kan verifiera vem som anropar innan åtkomst beviljas.

Hur tillämpas Zero Trust på Kubernetes?

Nollförtroende, definierat i NIST SP 800-207, tar bort förtroende baserat på nätverksplats. Tillämpat på Kubernetes innebär det att varje pod-till-pod, pod-till-API-server och kluster-till-extern-anslutning autentiseras och auktoriseras vid varje begäran, vanligtvis med ömsesidig TLS och RBAC med minsta behörighet, istället för att lita på något bara för att det körs inuti klusternätverket.

Vad ersatte långlivade tjänstkontotokens i Kubernetes?

De ersattes av bundna tjänstkontotokens. Bundna tokens blev stabila i Kubernetes 1.22: de är tidsbegränsade, publikbundna och knutna till en specifik pod, och kubeleten roterar dem automatiskt. Sedan Kubernetes 1.24 skapar kontrollplanet inte längre automatiskt långlivade hemlighetsbaserade tokens för nya tjänstkonton, och en rensare för oanvända äldre tokens blev stabil i 1.30.

Behöver jag ett service mesh för att säkra maskinidentiteter i Kubernetes?

Nej, men ett servicemesh gör ömsesidig TLS praktiskt i stor skala. Meshes som Istio och Linkerd utfärdar kortlivade certifikat till varje arbetsbelastning och krypterar trafik mellan tjänster utan applikationsändringar. Utan ett mesh kan du fortfarande kombinera cert-manager för certifikatautomation, bundna servicekontotokens, RBAC och nätverkspolicyer för att täcka de flesta maskinidentitetsrisker.

Hur kommer 47-dagars TLS-certifikat att påverka Kubernetes-kluster?

CA/Browser Forum minskar den maximala giltighetstiden för offentliga TLS-certifikat i etapper: 200 dagar från 15 mars 2026, 100 dagar från 15 mars 2027 och 47 dagar från 15 mars 2029. Alla certifikat som ett kluster exponerar offentligt, till exempel ingångsslutpunkter, kommer att behöva automatisk utfärdande och förnyelse, eftersom manuell rotation inte kan hålla jämna steg med en 47-dagarscykel.

Automatisera maskinidentitetslivscykler i dina kluster

Se CertSecure Manager i praktiken mot din egen certifikattillgång, eller prata med en PKI-rådgivare om att införa Zero Trust-identitetskontroller i dina Kubernetes-kluster. ISO/IEC 27001:2022-certifierad.