Når IT-afdelingen driver en containerplatform, fx Kubernetes, til interne systemer eller til programmer fra leverandører, er platformen et testområde for sig. Den har sine egne administratorer, sine egne regler for netværk og sine egne steder at gemme adgangskoder og nøgler. En test af platformen afprøver, om den opsætning holder, og om et kompromitteret program kan nå mere end sin egen container. Svaret hviler på de anbefalinger, som platformens eget projekt og den amerikanske standardiseringsmyndighed har udgivet om containere. Er containerne en del af et softwareprodukt, I sælger til kunder, er det en anden opgave. → Egne softwareprodukter
Hvad der er nyt i forhold til servere
En container minder om en lille, afgrænset server, men den deler styresystemets kerne med de andre containere på samme maskine. Platformen rundt om bestemmer, hvor containerne kører, hvad de må, og hvem der kan ændre dem. Det giver tre lag, som testen ser på:
- Platformen · administrationsfladen, roller og de maskiner, containerne kører på.
- Containerne · de billeder, de er bygget fra, og de rettigheder, de kører med.
- Forbindelserne · netværksreglerne mellem containere og ud til resten af virksomheden.
NIST beskriver i sin vejledning om containersikkerhed, at containere gør programmer lettere at flytte og automatisere, men også giver nye risici, som skal håndteres særskilt. Det er de risici, en test kan konkretisere.
Hvad testen afprøver
En test af en containerplatform i driften dækker typisk:
- Adgang til administrationen · hvem der kan styre platformen, og om administrationsfladen kan nås fra flere steder end nødvendigt. Kubernetes’ egen tjekliste nævner, at platformens administrationsflader ikke bør være offentligt tilgængelige.
- Roller i platformen · om brugere, programmer og automatik har flere rettigheder end opgaven kræver, særligt retten til at oprette og ændre containere.
- Adskillelse mellem containere · om der er netværksregler, der begrænser, hvad en container kan tale med, eller om alt kan nå alt. → Segmentering i dybden
- Containerens rettigheder · om containere kører med flere rettigheder på maskinen, end de har brug for.
- Hemmeligheder · hvordan adgangskoder og nøgler gives til containerne, og hvem der kan læse dem. → Nøgler og hemmeligheder i cloud
- Billederne · om de er opdaterede, og hvor de kommer fra.
Det centrale spørgsmål er det samme som ved andre testområder: hvis et program i én container bliver kompromitteret, hvor langt rækker det så?
Når platformen leveres som en tjeneste
Mange kører ikke Kubernetes på egne maskiner, men bruger en færdig tjeneste i Azure eller AWS. Så driver udbyderen en del af platformen, typisk selve styringen, mens I står for resten. Fordelingen afhænger af tjenesten og skal læses i udbyderens egen dokumentation, før testen planlægges.
For testen betyder det to ting. Den del, udbyderen driver, er ikke jeres at teste, og udbydernes regler for test gælder også her. Da teksten blev gennemgået, stod to af AWS’ containertjenester på listen over tjenester, kunder kan teste uden forhåndsgodkendelse, men ikke alle AWS’ tjenester til containere. Tjek derfor, om netop den tjeneste, I bruger, står på den gældende liste. → AWS’ politik for penetrationstest Til gengæld bliver forbindelsen mellem platformen og resten af cloudmiljøet vigtigere. En container, der har fået en rolle i abonnementet eller kontoen, kan række ud over platformen, og den rolle er jeres ansvar. Rollerne uden for platformen hører derfor med i testen på lige fod med dem inden for.
Hvad driften forbereder
- ☐ Oversigt over platforme og klynger med ejer og formål.
- ☐ Liste over, hvilke programmer der kører, og hvem der er ansvarlig for hvert.
- ☐ Beskrivelse af, hvordan platformen administreres, og af hvem.
- ☐ Testadgang: en rolle med læseadgang til opsætningen og eventuelt en almindelig programrolle.
- ☐ Oplysning om, hvor billederne bygges og hentes fra.
- ☐ Aftale om, hvilke dele af platformen der er produktion, og hvad der ikke må påvirkes.
Den sidste aftale er vigtig. En containerplatform kan genstarte og flytte programmer automatisk, og en test, der ændrer noget ved et uheld, kan få følger for flere systemer. Afgræns derfor testen tydeligt, aftal hvem der kan stoppe den, hvis noget opfører sig uventet, og overvej om en del af afprøvningen kan ske i et miljø, der ligner produktion.
Fundtyper, der går igen
- Administrationsflade, der kan nås bredt · platformens styring kan nås fra hele kontornettet eller udefra.
- Brede roller · programmer eller brugere med ret til at oprette containere med høje rettigheder.
- Ingen netværksregler · alle containere kan tale med alle, også dem, der ikke har noget med hinanden at gøre.
- Containere med for mange rettigheder · de kører med adgang til værtsmaskinen, som de ikke har brug for.
- Hemmeligheder, der er for synlige · nøgler i opsætningsfiler eller tilgængelige for flere end det program, der bruger dem.
- Gamle billeder · containere bygget på grundbilleder med kendte svagheder, fordi ingen genbygger dem. → Opdateringsstatus på klienter og servere
Prioritering og rettelser
Prioriter efter, hvad fundet giver adgang til. Fund, der giver kontrol over platformen eller de maskiner, den kører på, kommer først, for de rammer alle programmer på én gang. Derefter fund, der lader én container nå andre eller nå data uden for platformen.
Rettelserne følger kendte principper, sat i platformens sprog:
- Færre, der kan administrere · og administrationsfladen kun tilgængelig fra der, hvor den skal bruges.
- Snævre roller · programmer får kun de rettigheder, de har brug for i platformen.
- Afvis som udgangspunkt · netværksregler, der kun tillader de forbindelser, programmerne skal bruge.
- Standarder for containere · platformen håndhæver, at containere ikke kører med flere rettigheder end nødvendigt.
- Genbygning · billeder bygges jævnligt forfra på opdaterede grundbilleder.
Mange rettelser hører hjemme i de skabeloner, platformen og programmerne udrulles fra. Rettes de kun i den kørende platform, kommer fejlen tilbage ved næste udrulning. → Infrastruktur som kode
Det skal I lade være med
- At teste containerne og glemme platformen. Den, der styrer platformen, styrer alle containere.
- At lade alle containere tale med alle. Det gør én svaghed til en vej ind i alt.
- At give programmer administratorroller for nemheds skyld. Det kan være det alvorligste fund.
- At teste uden en klar grænse for produktion. Platformen reagerer selv på ændringer.
- At rette i den kørende opsætning alene. Rettelsen skal ind i skabelonerne.
Hvad kan og ikke kan konkluderes
Testen viser, hvordan den aftalte platform og de udvalgte programmer holdt på testtidspunktet, og hvor langt en kompromitteret container kunne nå. Den siger ikke noget om kvaliteten af koden i programmerne, og platforme eller klynger uden for aftalen er ikke dækket. En containerplatform ændres ofte, så resultatet holder kun, hvis rettelserne også ligger i det, der udrulles fremover. Kubernetes’ egen tjekliste understreger selv, at en tjekliste alene ikke er nok til god sikkerhed.
Kilder
- NIST SP 800-190: Application Container Security Guide: containere som pakning af programmer med delt styresystem, de særlige risici ved containere og anbefalinger til at håndtere dem.
- Kubernetes: Security Checklist: grundlæggende tjekliste for klynger, herunder roller, netværksregler for alle programmer, administrationsflader, der ikke er offentlige, og forbeholdet om, at en tjekliste ikke er nok alene.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Segmentering i dybden · Kodeopbevaring og byggeservere
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
