När jag arbetar med Kubernetes-säkerhet försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. Kubernetes-säkerhet är ett lagerproblem: identitet, namespace, RBAC, nätverk och pod-konfiguration behöver stödja varandra för att en komprometterad workload inte ska få fri rörelse.
Kubernetes-säkerhet i praktiken
Första byggstenen: Service accounts bör vara separata per workload när behörigheterna skiljer sig. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: RBAC ska begränsa verbs och resources. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: NetworkPolicy kan begränsa öst-västtrafik där CNI stöder den. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Pod Security-inställningar kan stoppa privileged, hostPath och andra riskabla egenskaper. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Inventera workloads och service accounts.
- Reducera cluster-wide roller till namespace-scope där det går.
- Inför default-deny network policy och lägg explicita undantag.
- Förbjud privileged och host namespaces för normala workloads.
- Testa både API-behörighet och nätverksåtkomst från en testpod.
För Kubernetes-säkerhet håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Exempel från ett driftperspektiv
Ett frontend behöver normalt inte lista Secrets i hela klustret. Jag testar därför dess service account med kubectl auth can-i och ett faktiskt API-anrop från podden innan jag betraktar RBAC som färdig.
Fallgropar jag försöker undvika
- Att ge cluster-admin till automationskonton av bekvämlighet.
- Att ha NetworkPolicy-objekt utan att kontrollera att CNI faktiskt enforcerar dem.
- Att mounta service account token där applikationen aldrig använder Kubernetes API.
Kontrollpunkter
För Kubernetes-säkerhet vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Workload kan endast läsa avsedda resurser.
- Förbjuden namespace-trafik stoppas.
- Privileged pod nekas enligt policy.
Ett negativt test hör också till Kubernetes-säkerhet: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Kubernetes-säkerhet – namespace, RBAC, nätverkspolicy och workload-identitet handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.