En containerplatform kan gennemgås med platformens egne offentlige standarder som målestok. Kubernetes beskriver tre sikkerhedsprofiler for pods, gode råd om rettigheder og en tjekliste for selve platformen. Gennemgangen holder opsætningen op imod dem i tre lag: hvad der må køre, hvem der må hvad, og hvem der kan nå platformens kerne.
Det er Kubernetes’ egne anbefalinger for egen platform. Andre containerplatforme har deres egne, som ikke er læst her.
De tre profiler
Kubernetes’ Pod Security Standards har tre politikker, der bygger oven på hinanden:
- Privileged er ubegrænset og tillader kendte måder at få flere rettigheder på. Den er tænkt til system- og infrastrukturopgaver, som styres af betroede brugere.
- Baseline er minimalt restriktiv. Den forhindrer kendte rettighedsforøgelser og tillader standardopsætningen af en pod.
- Restricted er stærkt begrænset efter nuværende praksis for hærdning af pods.
Kubernetes har en indbygget kontrol, Pod Security admission, der håndhæver standarderne pr. navnerum. Det sker med en etiket på navnerummet i formen pod-security.kubernetes.io/<MODE>: <LEVEL>. MODE kan være enforce, som afviser pods, der bryder politikken, audit, som skriver bruddet i revisionsloggen, og warn, som giver en advarsel.
Kontrollen af profilerne
Gennemgangen læser etiketterne på alle navnerum og laver en tabel: navnerum, profil og tilstand. Spørgsmålene er:
- Hvilke navnerum står uden etiket, og hvad gælder så?
- Hvilke navnerum står med Privileged, og kører der kun system- og infrastrukturopgaver?
- Hvor står profilen i warn eller audit uden enforce, og er det en overgang med en slutdato?
Kubernetes beskriver Privileged som tænkt til opgaver, som betroede brugere styrer. Et navnerum med almindelige applikationer og Privileged er derfor en afvigelse fra platformens egen beskrivelse. At Restricted bør være målet for applikationer, er en vurdering, som afhænger af, hvad de skal kunne.
Rettigheder i platformen
Kubernetes’ gode råd om rollebaseret adgangskontrol, RBAC, giver kontrolpunkterne for rettigheder:
- Undgå rettigheder med jokertegn, der giver adgang til alt.
- Brug ikke rollen cluster-admin, undtagen hvor det er nødvendigt.
- Tilføj ikke brugere til gruppen system:masters.
- Gennemgå bindinger for gruppen system:unauthenticated.
- Gennemgå RBAC-indstillingerne periodisk.
Udtrækket er en liste over roller og bindinger på tværs af platformen. Gennemgangen leder efter brede roller, bindinger til grupper, der omfatter mange, og konti fra personer eller systemer, der ikke bruger dem mere. Kubernetes siger “periodisk” og giver intet interval. Hvor ofte I gennemgår, er jeres eget valg.
Servicekonti i platformen hører med. Programmer, der kører i platformen, har deres egne identiteter, og deres rettigheder er lige så vigtige som personernes. Den generelle kontrol af servicekonti står i servicekonti.
Platformens kerne
Kubernetes’ sikkerhedstjekliste har punkter om de dele, der styrer alt:
- Kubernetes-API’et, kubelet-API’et og etcd er ikke eksponeret mod internettet.
- Adgangen til etcd er begrænset.
- Revisionsloggen er beskyttet, hvis den er slået til.
- Kryptering i hvile er slået til for Secret-API’et.
Kontrollen af det første punkt er netopsætningen og firewallreglerne foran platformen. Det andet og fjerde læses i platformens opsætning. Er platformen en tjeneste i en offentlig sky, ligger nogle af svarene hos udbyderen, og andre i jeres opsætning af tjenesten. Den fordeling skal stå klart i rapporten.
Billeder og afhængigheder
Hvilke containerbilleder der må køres, og hvor de hentes fra, er et kontrolpunkt i mange gennemgange. Vi har ikke læst en kilde, der beskriver det som standard, og nævner det som praksis. Spørgsmålet er, om der er en liste over godkendte kilder, og om platformen håndhæver den.
Hvem kan nå platformens API
Ud over rettighederne i platformen er det værd at se på, hvem der overhovedet kan forbinde til API’et. Det er udviklernes maskiner, kæden, der udruller, og måske et overvågningssystem. Hver af dem har typisk en konfigurationsfil med legitimation. Det er praksis at spørge, hvor disse filer ligger, hvor længe legitimationen gælder, og om den er personlig.
En gennemgang kan desuden se, om platformens revisionslog er slået til, og hvor den sendes hen. Kubernetes’ tjekliste nævner, at loggen skal beskyttes, hvis den er slået til. Om den skal slås til, er jeres valg, men uden den kan ændringer af roller og bindinger ikke føres tilbage til en person.
Hvad det kræver, og hvad det koster at lade være
Det kræver læseadgang til platformens API, så navnerum, etiketter, roller og bindinger kan trækkes, og adgang til opsætningen af kernen. Udtrækkene kan laves med platformens egne kommandoer. Rettelserne kan være tunge, fordi applikationer kan holde op med at virke, når profilen strammes. Platformens warn-tilstand er netop lavet til at se det, før det sker.
Uden kontrollen kan én bred binding eller ét navnerum med Privileged give adgang til hele platformen. Og en platform, hvor API’et kan nås udefra, er et problem, uanset hvor godt resten er sat op.
Det skal I lade være med
- At lade navnerum stå uden profil · sæt en profil, også hvis det er Baseline til at begynde med.
- At give cluster-admin til daglig drift · giv de roller, opgaven kræver.
- At skifte direkte til enforce på et travlt navnerum · start med warn, og læs advarslerne.
Det skal gennemgangen kunne vise
- ☐ En tabel over navnerum med profil og tilstand.
- ☐ Begrundelse for hvert navnerum med Privileged.
- ☐ Roller og bindinger med jokertegn, cluster-admin og system:masters.
- ☐ Bindinger for system:unauthenticated.
- ☐ Netadgang til API, kubelet og etcd og status for kryptering af Secrets.
Kilder
- Kubernetes, Pod Security Standards, læst 13. november 2026.
- Kubernetes, Pod Security Admission, læst 13. november 2026.
- Kubernetes, RBAC Good Practices, læst 13. november 2026.
- Kubernetes, Security Checklist, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk etiketterne på alle navnerum, og lav en tabel med profil og tilstand for hvert.
Læs også: Infrastruktur som kode · Nøgler og hemmeligheder i skyen
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
