Kubernetes-säkerhet

Rollbaserad åtkomstkontroll (RBAC) i Kubernetes styr vem som kan utföra vilka åtgärder på vilka resurser i API:t. Roles definierar en uppsättning tillåtna verb (get, list, create, update, delete) på specifika API-grupper och resurstyper, avgränsade till en enda namnrymd. ClusterRoles är identiska men gäller klusterövergripande. RoleBindings kopplar en Role till en användare, grupp eller service account inom en namnrymd.

Principen om minsta privilegium gäller strikt för RBAC. En utvecklare som behöver läsa loggar och exec:a in i Pods i sitt teams namnrymd behöver inte list-åtkomst till Secrets eller create-åtkomst till deployments i andra namnrymder. Väldesignat RBAC mappar till faktiska jobbfunktioner snarare än till organisationsschematitlar.

Vanliga RBAC-misstag inkluderar att binda subjekt till cluster-admin ClusterRole (som ger obegränsad åtkomst till allt), att använda wildcard-verb ('*') eller wildcard-resurser ('*') i Role-definitioner och att ge 'create' eller 'update' på ClusterRoleBindings till arbetslaster (vilket möjliggör privilegieskalering).

Granskning av RBAC är möjlig med 'kubectl auth can-i --as=system:serviceaccount:namnrymd:namn verb resurs', som visar vad ett specifikt service account är tillåtet att göra. Verktyg som rbac-lookup och kubectl-who-can gör det enklare att visualisera vilka behörigheter som finns och vem som har dem.

Service accounts är den identitet som används av arbetslaster för att autentisera mot Kubernetes API. Varje Pod körs under ett service account, och som standard monteras det service account:ts token automatiskt in i Podens filsystem. En container kan använda den token för att autentisera mot API-servern och utföra vilken åtgärd som helst som service account:ts RBAC-behörigheter tillåter.

Standardservice account:t i varje namnrymd har minimala behörigheter, men många operatörer beviljar bredare behörigheter utan att inse hur brett de behörigheterna tillämpas. Om ett service account med 'list secrets'-behörighet binds till standardservice account:t i en namnrymd ärver varje Pod i den namnrymden den behörigheten.

Arbetslaster som inte behöver anropa Kubernetes API bör inaktivera automatisk tokenmounting. Detta görs genom att ange automountServiceAccountToken: false antingen i ServiceAccount-specifikationen eller i enskilda Pod/Deployment-specifikationer. Att inaktivera automatisk montering innebär att en komprometterad container inte kan använda sin token för att sondera klustrets API.

För arbetslaster som verkligen behöver interagera med molntjänster är det moderna mönstret att använda molnleverantörens identitetsintegration snarare än långlivade autentiseringsuppgifter. AWS IRSA (IAM Roles for Service Accounts) och GKE Workload Identity tillåter ett Kubernetes service account att anta en molnbaserad IAM-roll utan att lagra molnautentiseringsuppgifter i klustret.

Utan NetworkPolicies kan alla Pods i ett Kubernetes-kluster kommunicera med alla andra Pods på vilken port som helst. Denna platta nätverksmodell är bekväm för utveckling men katastrofal för säkerhet i produktion. En komprometterad applikation kan ansluta till vilken databas, kö eller internt API som helst i klustret oavsett namnrymd eller avsedd funktion.

NetworkPolicies tillämpas av CNI-plugin:et (Container Network Interface), inte av Kubernetes i sig. Inte alla CNI-plugins stöder NetworkPolicy-tillämpning. Vanliga plugins som gör det inkluderar Calico, Cilium och Antrea. Om ett kluster använder ett CNI-plugin som inte stöder NetworkPolicies kan NetworkPolicy-objekt skapas men har ingen effekt. En farlig falsk känsla av säkerhet.

Det effektivaste mönstret är standardnekande. Skapa en NetworkPolicy som väljer alla Pods i en namnrymd och nekar all ingress och all egress. Lägg sedan till specifika tillståndspolicyer för den trafik som ska tillåtas. Detta inverterar standardinställningen från 'allt är tillåtet om det inte uttryckligen nekas' till 'allt är nekat om det inte uttryckligen tillåts.'

Utan NetworkPolicies kan en komprometterad frontend nå databasen direkt. Med riktade NetworkPolicies på plats är det bara backend-tjänsten som har nätverksväg till databasen. Vilket minskar explosionsradien av en frontenddkompromitering avsevärt.

En säkerhetskontext definierar säkerhetsinställningar på operativsystemnivå för en Pod eller en specifik container. Dessa inställningar är oberoende av containerimagen. Imagen definierar vilken kod som körs, men säkerhetskontexten definierar hur den koden får köras. Nyckelfält inkluderar. RunAsUser, runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation och capabilities.

Pod Security Admission (PSA) är den inbyggda Kubernetes-mekanismen för att tillämpa säkerhetskontextkrav på namnrymdsnivå. Det ersatte den föråldrade PodSecurityPolicy i Kubernetes 1.25. PSA definierar tre policynivåer. Privileged (inga begränsningar), Baseline (förhindrar känd privilegieskalering) och Restricted (starkast härdning, kräver icke-root, skrivskyddat filsystem, borttagna capabilities).

Restricted PSA-nivån återspeglar hur en välhärdad Pod ser ut. Kör som en icke-root-användare, med ett oföränderligt rotfilsystem, ingen privilegieskalering tillåten, alla capabilities borttagna och en seccomp-profil tillämpad. Många legitima applikationer kan uppfylla dessa krav med minimala ändringar.

Ett vanligt misstag är att ange privileged: true som en snabb lösning för en container som misslyckas starta på grund av behörighetsproblem. Detta ger containern nästan värdnivåfunktioner och kringgår nästan all isolering. Det rätta tillvägagångssättet är att identifiera den specifika behörighet eller capability som containern faktiskt behöver och bara bevilja det.

Admissionskontroller fångar upp förfrågningar till Kubernetes API innan objekt lagras i etcd. De kan validera (acceptera eller avvisa en förfrågan baserat på dess innehåll), mutera (ändra en förfrågan innan den lagras, till exempel för att injicera standardsäkerhetsinställningar) eller båda. ValidatingAdmissionWebhook och MutatingAdmissionWebhook tillåter externa policy-motorer att hantera admissionsbeslut.

OPA/Gatekeeper och Kyverno är de två dominerande policy-motorerna för Kubernetes admissionskontroll. Gatekeeper använder OPAs Rego-språk för att uttrycka policyer. Kyverno använder ett YAML-baserat policyspråk som är närmare Kubernetes-resursyntax. Båda kan tillämpa krav som 'alla containrar måste ha resursgränser' och 'images måste komma från det godkända registryt'.

Admissionskontroll löser en kategori av problem som RBAC ensamt inte kan. RBAC kontrollerar vem som kan skapa eller ändra objekt, admissionskontroll kontrollerar vad dessa objekt får innehålla. En utvecklare med behörighet att skapa Deployments kan skapa en med privileged: true om inte en admissionskontroller förhindrar det.

Muterande admissionskontroller används för att tillämpa säkra standardvärden. Injicera sidecars, ange standardresursgränser, lägga till obligatoriska etiketter eller automatiskt montera hemligheter. Mutationer bör vara transparenta, ingenjörer bör veta vad klustret lägger till i deras arbetslaster, och bör dokumenteras.

Kubernetes granskningsloggar registrerar varje förfrågan till API-servern. Vem som gjorde förfrågan, vilken åtgärd som begärdes, på vilken resurs och vad resultatet blev. Granskningspolicyn definierar vilka förfrågningar som loggas och på vilken detaljnivå. En fullständig granskningspolicy balanserar att fånga säkerhetsrelevanta händelser mot den loggvolym som skulle göra analys opraktisk.

Säkerhetsrelevanta händelser att bevaka inkluderar åtkomst till Secrets (särskilt från oväntade service accounts), skapande eller ändring av ClusterRoleBindings (privilegieskalering), exec in i Pods (indikerar direktåtkomst till en körande container), ändringar av admissionswebhokar (kan inaktivera säkerhetskontroller) och API-anrop från system:anonymous.

Granskningsloggar är bara värdefulla om de samlas in och analyseras. Klustret bör skicka granskningsloggar till ett externt logghanteringssystem snarare än att lagra dem bara på API-servernoderna, där de kan gå förlorade eller manipuleras. Larm om prioriterade händelser bör konfigureras.

Ett vanligt misslyckande är att aktivera granskningsloggning men aldrig definiera vad 'intressant' ser ut. Utan larmregler och en process för att granska misstänkta händelser blir granskningsloggar ett stort arkiv som bara konsulteras efter att en incident redan identifierats på andra sätt.

Klusterhärdning är processen att stänga gap mellan klustrets standardkonfiguration och en säker operativ basnivå. CIS Kubernetes Benchmark är den mest använda referensen och täcker API-server, kontrollhanterare, schemaläggare, etcd, kubelet och konfigurationen av arbetarnoder. Att köra kube-bench-verktyget mot ett kluster rapporterar vilka CIS-kontroller som passerar och misslyckas.

etcd är den känsligaste komponenten i Kubernetes kontrollplan. Den lagrar allt klustertillstånd, inklusive Secrets i base64-kodad form. Åtkomst till etcd bör begränsas till API-servern, direktåtkomst av människor eller andra system bör kräva stark autentisering. etcd bör använda TLS för all kommunikation och vara krypterad i vila.

API-servern exponerar flera alternativ som minskar attackytan. Inaktivering av anonym autentisering, krav på klientcertifikatautentisering för intern komponentkommunikation, aktivering av granskningsloggning och begränsning av tillåtna admissionsplugins. Många hanterade Kubernetes-tjänster konfigurerar vissa av dessa korrekt som standard, men självhanterade kluster kräver explicit uppmärksamhet.

På nodernivå lägger AppArmor och seccomp-profiler till obligatorisk åtkomstkontroll och systemanropsfiltrering till containerprocesser. Seccomp-profiler begränsar vilka systemanrop en container kan göra. RuntimeDefault-profilen blockerar många systemanrop som sällan behövs av applikationer men ofta används av exploits. Båda kräver explicit konfiguration i Podens säkerhetskontext för att tillämpas.