Containersikkerhed under kørsel

Som standard kører processer i en Docker-container som brugeren root, der har fulde administrative rettigheder i containeren.

• Risiko: Hvis en angriber får kontrol over en container med root-rettigheder, kan vedkommende muligvis udnytte sårbarheder i Docker-dæmonen eller kernen til at få root-adgang på værtssystemet.
• Bedste praksis: Kør altid dine containerprocesser som en bruger, der ikke er root.

Du kan angive en bruger (med navn eller UID) til din containerproces ved hjælp af flaget --user sammen med docker run. Her kører vi kommandoen id i en Alpine-container som bruger 1000.

Hvis bruger 1000 ikke findes, bruger Docker stadig dette UID.

Traditionelle Linux-systemer har en root-bruger, hvor det er alt eller intet. Linux-funktioner opdeler root-brugerens kraftfulde rettigheder i mindre, adskilte enheder.

Det gør det muligt for en proces kun at have de specifikke root-lignende beføjelser, den har brug for (f.eks. binding til lave porte og rå netværksadgang), uden at have fulde root-rettigheder.

Docker-containere kører som standard med et stort sæt funktioner. Du kan fjerne unødvendige funktioner ved hjælp af --cap-drop for yderligere at begrænse, hvad en container kan gøre.

Her fjerner vi funktionen NET_RAW. Kommandoen ping, som kræver NET_RAW, vil derefter mislykkes, hvilket viser begrænsningen.

Containere deler værtens kerne og ressourcer. Ukontrolleret ressourceforbrug fra én container kan føre til et denial-of-service-angreb (DoS) mod andre containere eller selve værten.

• CPU-begrænsninger: Forhindrer en container i at beslaglægge CPU-cyklusserne.
• Hukommelsesbegrænsninger: Forhindrer en container i at bruge al tilgængelig RAM og dermed skabe ustabilitet i systemet.

Du kan angive begrænsninger for CPU og hukommelse direkte med docker run. Dette eksempel begrænser hukommelsen til 128 MB og CPU-forbruget til 0,5 (halvdelen af én CPU-kerne).

Det sikrer, at din container opfører sig korrekt og ikke udsulter andre processer.

Mange applikationer behøver ikke at skrive til deres rodfilsystem efter opstart. Ved at gøre filsystemet skrivebeskyttet opnår du betydelige sikkerhedsfordele:

• Forhindrer manipulation: En angriber kan ikke ændre eksisterende filer eller skrive nye, skadelige filer.
• Begrænser vedvarende ændringer: Alle ændringer er midlertidige og går tabt, når containeren genstartes.
• Håndhæver uforanderlighed: Fremmer et design, hvor containere kan kasseres, og konfigurationen er ekstern.

Brug flaget --read-only, når du kører en container. Ethvert forsøg på at skrive til containerens filsystem (bortset fra specifikt monterede diskenheder) vil mislykkes.

Prøv at oprette en fil i denne skrivebeskyttede container:

Godt klaret! Du har lært, hvordan du forbedrer containersikkerheden, mens containerne kører:

• Mindst mulige rettigheder: Tildel kun de nødvendige tilladelser.
• Brugere, der ikke er root: Undgå at køre processer som root.
• Funktioner: Fjern unødvendige Linux-funktioner.
• Ressourcebegrænsninger: Styr CPU- og hukommelsesforbruget.
• Skrivebeskyttet: Gør filsystemer uforanderlige for at forhindre skrivning.

Disse metoder reducerer angrebsfladen og konsekvenserne af mulige kompromitteringer betydeligt. Bliv ved med at øve dig!