Kāpēc ir uzskatāms par sliktu praksi palaist konteineru kā root lietotāju Kubernetes?

Konteineru palaide no lietotāja root Kubernetesā rada paaugstinātus drošības riskus:

• Augsta privilēģiju līmenis: Ja konteineris tiek kompromitēts, ļaundaris iegūst root tiesības konteinerā. Tas var ļaut palielināt privilēģijas uz host sistēmas vai piekļūt citiem klastera resursiem.
• Piekļuve host failu sistēmai: Bez atbilstošiem ierobežojumiem, root process konteinerā var piekļūt mezgla failu sistēmai, kas palielina nelegālas izmaiņas vai datu noplūdes risku.
• Kodola ievainojamības: Root lietotājs konteinerā var izmantot Linux kodola ievainojamības, lai izietu no konteineriem un iegūtu kontroli pār host.
• Auditēšanas grūtības: Root lietotāja darbību uzraudzība ir grūtāka, kas apgrūtina drošības incidentu atklāšanu un izmeklēšanu.
• Privilēģiju mantošana: Ja no galvenā lietotāja tiek palaisti citi procesi, tiem arī būs augsts privilēģiju līmenis.

Ieteicams ievērot minimālo privilēģiju principu, palaist konteinerus no neprivilegēta lietotāja. To var konfigurēt poda manifestā, izmantojot securityContext:

securityContext:
  runAsUser: 1000  # Izmantojot neprivilegētu lietotāju ar ID 1000
  runAsGroup: 3000 # Piederība grupai ar ID 3000 (pēc izvēles)
  allowPrivilegeEscalation: false # Atļaut privilēģiju eskalāciju nē
readOnlyRootFilesystem: true # Aizliegt rakstīt galvenajā failu sistēmā

Papildu var izmantot:

• Pod Security Policies / Pod Security Admission: drošības politiku piemērošanai pod līmenī.
• AppArmor / SELinux: papildu izolācijai.
• Izmantojot konteineru attēlus ar skaidri norādītu neprivilegētu lietotāju: Dockerfile ar USER instrukciju:

# Piemērs Dockerfile ar lietotāja norādi
FROM ubuntu:latest
# Izveidot neprivilegētu lietotāju
RUN useradd -ms /bin/bash myuser
# Pārsūtīt uz izveidoto lietotāju
USER myuser
CMD ["/bin/bash"]