Cloud & IT Cert Prep · Lektion

Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed

Konfigurér Kubernetes RBAC-roller, håndhæv netværkspolitikker, der begrænser trafik mellem pods, og anvend pod-sikkerhedsstandarder for at begrænse rettighedseskalering.

Lektion 2 af 413 trin

Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed er en gratis Cloud & IT Cert Prep-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Cloud & IT Cert Prep, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

Oversigt over Kubernetes' angrebsflade

Kubernetes orkestrerer containeriserede workloads i stor skala, men kompleksiteten skaber en omfattende angrebsflade. Vigtige komponenter, der skal sikres, omfatter: API-serveren (det centrale kontrolplan — et kompromis her giver kontrol over hele klyngen), etcd (databasen med klyngetilstanden — gemmer hemmeligheder i base64 og skal krypteres ved lagring), kubelet (nodeagent — en ikke-godkendt kubelet-API giver mulighed for vilkårlig kørsel af pods), container-runtime (Docker/containerd) samt det netværk, der forbinder alle pods. Security+-kandidater bør forstå, at fejlkonfigurationer i Kubernetes er blandt de mest almindelige fund inden for cloud-sikkerhed.

RBAC: Rollebaseret adgangskontrol i Kubernetes

Kubernetes RBAC (Role-Based Access Control) styrer, hvilke brugere, servicekonti og processer der må udføre hvilke handlinger på hvilke API-ressourcer. Modellen har fire objekter: Role (tilladelser inden for et namespace), ClusterRole (tilladelser i hele klyngen), RoleBinding (tildeler en Role til en aktør i et namespace) og ClusterRoleBinding (tildeler en ClusterRole til en aktør i hele klyngen). Hver kubectl-kommando oversættes til et API-kald, der kontrolleres op imod RBAC-reglerne. Hvis RBAC ikke er konfigureret, kan enhver godkendt bruger (eller servicekonto) have administrativ adgang.

# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [''] 
  resources: ['pods']
  verbs: ['get', 'list', 'watch']

Servicekonti og mindst mulige privilegier

Alle pods i Kubernetes kører under en servicekonto — en identitet, der bruges til API-godkendelse. Som standard bruger pods servicekontoen default i deres namespace, og den kan have omfattende tilladelser. Princippet om mindst mulige privilegier kræver, at du opretter dedikerede servicekonti til hver applikation med kun de tilladelser, den har brug for. Derudover forhindrer indstillingen automountServiceAccountToken: false på pods, der ikke har brug for API-adgang, at servicekontotokenet monteres i pod-filsystemet, hvor en kompromitteret applikation kan bruge det til at foretage API-kald.

# Pod spec: disable service account token auto-mount
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: myapp-sa
  automountServiceAccountToken: false
  containers:
  - name: myapp
    image: myapp:v1.0

Netværkspolitikker: Afvis som standard

Som standard kan alle pods kommunikere med alle andre pods i ethvert namespace i Kubernetes. En kompromitteret pod kan straks forsøge at få adgang til databaser, interne API'er og andre mikrotjenester. Kubernetes-ressourcer af typen NetworkPolicy definerer regler, der begrænser trafik mellem pods baseret på labels, namespaces og porte. Den anbefalede tilgang er en netværkspolitik med 'afvis alt som standard' i hvert namespace, efterfulgt af eksplicitte tilladelsesregler for de nødvendige kommunikationsveje. Bemærk, at NetworkPolicy kræver et CNI-plugin, der understøtter funktionen (Calico, Cilium, Weave) — standard-Kubernetes ignorerer NetworkPolicy uden et kompatibelt CNI.

# Default deny all ingress and egress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Sikkerhedsstandarder for pods: PSP erstattes

Pod Security Standards (PSS), der blev introduceret i Kubernetes 1.23 og blev stabile i 1.25, erstatter den forældede Pod Security Policy (PSP) med tre indbyggede profiler, der håndhæves på namespace-niveau: Privileged (ubegrænset, til systemkomponenter), Baseline (forhindrer kendte privilegieeskaleringer som privilegerede containere og adgang til værtsnetværket) og Restricted (hærdet, kræver brugere, der ikke er root, fjerner alle funktioner og håndhæver skrivebeskyttede root-filsystemer). Namespaces mærkes for at håndhæve et politikniveau, og pods, der overtræder det, afvises ved optagelsen.

# Label namespace to enforce 'restricted' pod security
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Håndtering af hemmeligheder i Kubernetes

Kubernetes Secrets gemmer følsomme data som adgangskoder, tokens og TLS-certifikater. Som standard gemmes Secrets i etcd som base64-kodede værdier — de er ikke krypterede. Alle, der kan læse etcd eller har tilstrækkelige RBAC-tilladelser, kan uden videre afkode dem. Bedste praksis omfatter: aktivering af kryptering ved lagring for etcd med AES-GCM og en nøgle, der gemmes i en KMS (AWS KMS, GCP KMS), integration med en ekstern secrets manager som HashiCorp Vault eller AWS Secrets Manager via Secrets Store CSI Driver samt begrænsning af adgangen til Secrets via RBAC, så kun de servicekonti, der har brug for dem, kan læse dem.

# Enable etcd encryption at rest (encryption configuration)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>

Admission-controllere: Sikkerhedsgates

Admission-controllere er plugins i Kubernetes API-serveren, der opfanger API-anmodninger efter godkendelse og autorisation, men før objekterne gemmes. Dermed kan de validere, ændre eller afvise anmodninger. Sikkerhedsrelevante admission-controllere omfatter: PodSecurity (håndhæver Pod Security Standards), ImagePolicyWebhook (muliggør ekstern kontrol af image-signaturer), AlwaysPullImages (tvinger nye image-downloads igennem for at forhindre brug af lokalt cachede ondsindede images) og OPA/Gatekeeper (Open Policy Agent — den mest fleksible løsning, som tillader brugerdefinerede politikker udtrykt i sproget Rego for at håndhæve enhver organisatorisk sikkerhedsregel).

Hærdning af klyngekomponenter

Det er kritisk at hærde Kubernetes-kontrolplanets komponenter: API-serveren bør have --anonymous-auth=false for at deaktivere adgang uden godkendelse, --audit-log-path konfigureret til at registrere al API-aktivitet samt TLS for alle forbindelser. kubelet bør have --authorization-mode=Webhook (ikke AlwaysAllow), og anonym godkendelse bør være deaktiveret. etcd bør have TLS-kryptering af forbindelser mellem peers og klienter, begrænset netværksadgang (kun tilgængelig for API-serveren) samt kryptering af data ved lagring. CIS Kubernetes Benchmark indeholder en omfattende tjekliste over alle komponentindstillinger.

# Check kubelet configuration for security issues
kubectl get --raw /api/v1/nodes/nodename/proxy/configz | jq '.kubeletconfig | {anonymousAuth: .authentication.anonymous.enabled, authorization: .authorization.mode}'

Namespace-isolation og multi-tenancy

Kubernetes-namespaces giver en logisk adskillelse af ressourcer, men udgør ikke i sig selv en stærk sikkerhedsgrænse — de giver primært organisatorisk isolation. Ægte isolation mellem lejere (f.eks. workloads for forskellige kunder) kræver yderligere kontroller: netværkspolitikker til at blokere trafik på tværs af namespaces, ressourcekvoter til at forhindre DoS fra støjende naboer, separate node-pools til stærkt isolerede lejere eller dedikerede klynger pr. lejer. Mange organisationer bruger Hierarchical Namespaces eller kommercielle løsninger som vCluster for stærkere multi-tenancy i en enkelt klynge.

Revisionslogning og overvågning under kørsel

Kubernetes revisionslogning registrerer alle API-anmodninger: hvem der foretog dem, hvorfra de kom, hvilken handling der blev anmodet om, og hvilken ressource der var målet. Revisionslogge er afgørende for retsmedicinsk undersøgelse efter en sikkerhedshændelse og for at opdage unormal adfærd som usædvanlige rolletilknytninger, adgang til hemmeligheder eller exec-kommandoer i produktionspods. Revisionslogge bør streames til et centraliseret SIEM. Falco leverer overvågning af containeres adfærd under kørsel, mens cloudadministrerede Kubernetes-tjenester (EKS, GKE, AKS) leverer indbygget integration af revisionslogge med deres respektive logningsplatforme.

# Check recent kubectl exec events in audit log
grep '"verb":"create".*"resource":"pods".*"subresource":"exec"' /var/log/kubernetes/audit.log | tail -20

Sikkerhed i forsyningskæden: Imageproveniens

Sikkerhed i forsyningskæden for Kubernetes sikrer, at kun betroede og verificerede images når frem til produktion. CNCF's anbefalinger til sikkerhed i forsyningskæden omfatter: verificering af imagesignaturer med Cosign før udrulning (håndhævet via admission-controllere), generering og verificering af SBOM'er (softwarestyklister) for alle containerimages for at spore komponenternes oprindelse, fastlåsning af images til digestværdier (myimage@sha256:abc123) i stedet for mutable tags samt scanning af alle tredjeparts-Helm-charts for fejlkonfigurationer og sårbarheder før udrulning.

# Pin image to digest for immutability
# Instead of:
image: nginx:latest
# Use:
image: nginx@sha256:a3e2a7a3d7f94e...  # immutable digest

Hurtig kontrol

Test din forståelse af begreberne fra CompTIA Security+ (SY0-701) i denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion har du lært, at Kubernetes RBAC styrer API-adgang via Roles, ClusterRoles og Bindings — anvend altid mindst mulige privilegier på servicekonti, at standardafvisningskonfigurationer med NetworkPolicy forhindrer lateral bevægelse mellem pods og namespaces, og at Pod Security Standards håndhæver hærdning af containere på namespace-niveau ved at blokere privilegerede containere, adgang til værtsnetværket og kørsel som root. Nu går vi videre til sikkerhed i serverless-miljøer og angrebsflader på funktionsniveau.

Gratis at komme i gang

Lær Cloud & IT Cert Prep med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 150
Lektioner: 600

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed” gratis?

Ja — hele teksten til “Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Cloud & IT Cert Prep-kurset, skal du opgradere til CoddyKit PRO. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed”?

Konfigurér Kubernetes RBAC-roller, håndhæv netværkspolitikker, der begrænser trafik mellem pods, og anvend pod-sikkerhedsstandarder for at begrænse rettighedseskalering. Du øver dig i Cloud & IT Cert Prep med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Cloud & IT Cert Prep?

Der kræves ingen tidligere erfaring. Cloud & IT Cert Prep på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Cloud & IT Cert Prep-lektion?

Ja. Alle Cloud & IT Cert Prep-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Containersikkerhed: hærdning af images og runtime-beskyttelse
Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed
Serverless- og funktionssikkerhed
Sikkerhedsscanning af Infrastructure as Code

← Tilbage til Cloud & IT Cert Prep