Table of Contents

Docker containers hebben een revolutie in de moderne toepassing implementatie door het verstrekken van lichtgewicht, draagbare en efficiënte omgevingen voor het uitvoeren van software. Als organisaties steeds meer containerisatie om hun ontwikkeling en implementatie workflows te stroomlijnen, de veiligheid van deze containers is uitgegroeid tot een kritische zorg. Misconfigured containers en blootgestelde beelden behoren tot de top oorzaken van cloud data-inbreuken, en terwijl Docker vereenvoudigt ontwikkeling en implementatie, het breidt ook de aanval oppervlak. Deze uitgebreide gids verkent de essentiële beste praktijken, ontwerpstrategieën en veiligheidsmaatregelen die nodig zijn om veilige Docker containers in productie-omgevingen implementeren.

Begrijpen Docker Container Security Fundamentals

Docker heeft zijn eigen set van veiligheid uitdagingen, en het waarborgen van de veiligheid van Docker containers is niet alleen een kwestie van versterking van de toepassing, maar impliceert een uitgebreide aanpak die het hele ecosysteem omvat. Voordat het implementeren van specifieke veiligheidsmaatregelen, is het essentieel om Docker's beveiligingsmodel te begrijpen en hoe het verschilt van traditionele virtualisatie benaderingen.

Docker's Security Architecture

Docker's benadering van beveiliging is verschillend van traditionele virtualisatiemethoden, voornamelijk vanwege zijn afhankelijkheid van de host OS kernel. Docker gebruikt kernel namespaces voor procesisolatie. Namespaces bieden de eerste en meest eenvoudige vorm van isolatie. Processen die in een container draaien kunnen geen processen zien, en nog minder beïnvloeden, die in een andere container of in het hostsysteem draaien.

Docker containers zijn lichtgewicht en draagbaar. Echter, ze delen de kernel van het host besturingssysteem. Deze architectuur creëert unieke beveiligingsuitdagingen. Het begrijpen van dit gedeelde kernelmodel is cruciaal omdat kwetsbaarheden in de kernel van de host alle containers die op dat systeem draaien kunnen beïnvloeden.

Elke container krijgt ook zijn eigen netwerk stack, wat betekent dat een container geen bevoorrechte toegang tot de sockets of interfaces van een andere container krijgt. Natuurlijk, als het host systeem is dienovereenkomstig ingesteld, containers kunnen communiceren met elkaar via hun respectieve netwerk interfaces . . net zoals ze kunnen communiceren met externe hosts.

Het model voor gedeelde verantwoordelijkheid

Docker security omvat het aanbieden van functies zoals Docker Compose, namespaces en Docker Content Trust (DCT) om de beveiliging te verbeteren, met behulp van beveiligde configuraties voor container runtime, netwerken en opslag, regelmatig containerbeelden scannen en bekende kwetsbaarheden aanpakken, en runtime activiteiten monitoren en role-based toegangscontrole (RBAC) uitvoeren om onbevoegde toegang te beperken.

Een mislukking aan beide zijden van dit gedeelde verantwoordelijkheidsmodel kan zorgen voor een blootstelling aan verdichte werkbelasting. Gebruikers die hun omgevingen niet harden of hun componenten niet up-to-date houden lopen vooral risico op uitbuiting. Organisaties moeten begrijpen dat Docker de tools en platforms levert, maar de uitvoering van veiligheidsmaatregelen is de verantwoordelijkheid van de ontwikkelings- en operationele teams.

Essentiële beste praktijken voor het beveiligen van Docker Containers

Container beveiliging is niet een enkele tool of een eenmalige audit. Het is een set van praktijken gelaagd over uw hele pijpleiding . . vanuit de Dockerfile die u schrijft, aan de CI die het bouwt, aan de runtime die het uitvoert. De uitvoering van uitgebreide beveiliging vraagt aandacht voor meerdere lagen van de containerization stack.

Minimale en vertrouwde basisafbeeldingen gebruiken

Bouw altijd containers vanaf geverifieerde, minimale basisafbeeldingen. Officiële en geharde beelden zijn veiliger startpunten. De keuze van basisafbeelding heeft een significante invloed op de beveiliging van uw container. Grotere afbeeldingen bevatten meer pakketten, bibliotheken en mogelijke kwetsbaarheden die aanvallers zouden kunnen benutten.

Alpine bevat minder pakketten, die CVE vermindert en verbetert scanresultaten. Overweeg het gebruik van distroless beelden of Alpine Linux als basisafbeeldingen om het aanvalsoppervlak te minimaliseren. Distroless beelden bevatten alleen uw toepassing en de runtime afhankelijkheden, met uitzondering van pakketbeheerders, schelpen en andere hulpprogramma's die niet nodig zijn voor de productie.

Het gebruik van officiële Docker-beelden is van cruciaal belang voor het behoud van de veiligheid, aangezien deze beelden regelmatig worden bijgewerkt en gepatcht door betrouwbare entiteiten. Deze aanpak vermindert aanzienlijk het risico van het inzetten van containers met bestaande kwetsbaarheden of kwaadaardige code. Controleer altijd de bron van uw basisbeelden en de voorkeur aan officiële beelden van Docker Hub of andere vertrouwde registers.

Afbeeldingsversies pinnen en laatste tags vermijden

Het gebruik van de nieuwste maakt builds onvoorspelbaar. Het kan een bijgewerkte versie die breekt wijzigingen of kwetsbaarheden introduceert zonder waarschuwing. In plaats van het gebruik van de Laatst tag, altijd pin specifieke versies van basisafbeeldingen met behulp van hun vertakking of versie tags.

Het vastzetten van afbeeldingsversies zorgt voor reproduceerbaarheid en voorkomt onverwachte veiligheidsregressies. Wanneer u een exacte versie of vertakking opgeeft, garandeert u dat uw bouwt steeds dezelfde basisafbeelding zal gebruiken, waardoor het gemakkelijker wordt om kwetsbaarheden te volgen en updates systematisch te beheren.

# Bad practice
FROM node:latest

# Good practice - pin specific version
FROM node:18.16.0-alpine

# Best practice - use digest for immutability
FROM node:18.16.0-alpine@sha256:a1e4e58...

Containers uitvoeren als niet-rootgebruikers

Het is een Dockerfile beste praktijk om het uitvoeren van containers als root (UID 0) te vermijden. Er zijn zeer weinig gebruiks gevallen waarin de container moet worden uitgevoerd als root, dus vergeet niet om de instructies van de GEBRUIKER om de standaard effectieve UID te wijzigen. Het uitvoeren van containers als root brengt aanzienlijke veiligheidsrisico's omdat als een aanvaller de container compromitteert, ze krijgen root-level toegang.

Het uitvoeren als niet-root kan een paar extra stappen in uw Dockerbestand vereisen, omdat u nu ervoor moet zorgen dat de gebruiker die in de gebruikershandleiding is gespecificeerd, in de container aanwezig is en passende bestandssysteemmachtigingen moet geven op de locaties waar het proces zal worden gelezen of geschreven.

FROM alpine:3.18

# Create a non-root user
RUN addgroup -g 1000 appgroup &&
 adduser -D -u 1000 -G appgroup appuser

# Set ownership of application directories
RUN chown -R appuser:appgroup /app

# Switch to non-root user
USER appuser

WORKDIR /app
COPY --chown=appuser:appgroup . .

CMD ["./myapp"]

Bovendien kan uw uitvoeringsomgeving containers die standaard root draaien blokkeren (Openshift vereist extra beveiligingscontextbeperkingen). Veel Kubernetes distributies en containerplatforms dwingen niet-root beleid af, waardoor deze praktijk essentieel is voor compatibiliteit.

Alleen-lezen bestandssystemen implementeren

Uitvoeren met alleen-lezen root-bestandssysteem waar --read-only maakt dat het gehele containerbestandssysteem alleen-lezen en --tmpfs in-geheugen schrijfbare mappen biedt voor runtime behoeften. Deze beveiligingsmaatregel voorkomt dat aanvallers bestanden in de container kunnen wijzigen, zelfs als ze toegang krijgen.

Dit manifest verplicht de regel van het alleen-lezen bestandssysteem. Onthoud wanneer u een container alleen-lezen maakt, kan de app niet meer naar de schijf schrijven. Als uw app tijdelijke bestanden moet schrijven (zoals logs of cache), moet u een tijdelijk volume mounten.

docker run -d
 --read-only
 --tmpfs /tmp:rw,noexec,nosuid,size=64m
 --tmpfs /var/run:rw,noexec,nosuid,size=32m
 nginx:alpine

Voor toepassingen die persistente opslag vereisen, gebruik de naam van de volumes voor specifieke mappen terwijl u het root bestandssysteem alleen-lezen behoudt. Deze aanpak biedt de nodige schrijftoegang terwijl u de beveiligingsgrenzen behoudt.

Niet-nodige Linux-capaciteiten laten vallen

Mogelijkheden maken van de binaire "root/non-root" dichotomie een fijnkorrelig toegangscontrolesysteem. Processen (zoals webservers) die alleen maar hoeven te binden op een poort onder 1024 hoeven niet als root te draaien: ze kunnen alleen maar de net bind service-mogelijkheid krijgen. En er zijn vele andere mogelijkheden, voor bijna alle specifieke gebieden waar root privileges meestal nodig zijn.

De beste praktijk voor gebruikers zou zijn om alle mogelijkheden te verwijderen, behalve die expliciet vereist voor hun processen. Linux mogelijkheden zijn fijnkorrelige machtigingen die de oude root/non-root binaire vervangen. Docker geeft containers een standaard set die de meeste toepassingen niet nodig hebben.

docker run -d
 --cap-drop=ALL
 --cap-add=NET_BIND_SERVICE
 --security-opt=no-new-privileges:true
 myapp:latest

De vlag no-new-privileges voorkomt dat processen extra privileges krijgen via setuid of setgid binaire bestanden, waardoor er een andere laag van bescherming tegen privilege escalatieaanvallen wordt toegevoegd.

Geavanceerde beveiligingsontwerpstrategieën

Veel van deze overhead kan worden voorkomen door linkse beveiliging te verschuiven, potentiële problemen zo snel mogelijk aan te pakken in uw ontwikkelingswerk. De implementatie van beveiliging vroeg in de ontwikkelingscyclus vermindert risico's en vereenvoudigt de sanering.

Containerafbeelding scannen uitvoeren

Regelmatig container kwetsbaarheid scannen is essentieel. In een veilige pijplijn, Docker kwetsbaarheid scannen moet een verplichte stap van uw CI / CD proces en elk beeld moet worden gescand en goedgekeurd voordat ooit het invoeren van "Running" staat in de productie clusters.

Verschillende krachtige tools zijn beschikbaar voor het scannen van Docker-afbeeldingen:

  • Trivy: Een alles-in-één kwetsbaarheidsscanner voor containerbeelden, bestandssystemen en Git repositories. Het is populair om zijn eenvoud, snelheid en breedte van dekking, inclusief ondersteuning voor het scannen van infrastructuur als code (IaC) templates en toepassing afhankelijkheden.
  • Docker Scout: geïntegreerd in Docker Desktop en de Docker CLI. Het biedt kwetsbaarheid inzichten, CVE samenvattingen, en directe links naar herstel begeleiding.
  • Ankeren Engine: Een open-source Docker beeldscanner die containerbeelden controleert op kwetsbaarheden, configuratieproblemen en beleidsovertredingen. Het maakt het creëren van aangepaste beveiligingsbeleid mogelijk.
  • Snyk Container: Een kwetsbaarheidsscanner die integreert met CI/CD-pijpleidingen om kwetsbaarheden automatisch op te sporen en te repareren.
  • Clair: Scant containerbeelden voor bekende kwetsbaarheden die zijn opgenomen in databases zoals de database van de Gemeenschappelijke Kwetsbaarheid en Blootstellingen (CVE).

Voordat u afbeeldingen, moet u altijd scannen op kwetsbaarheden. Gereedschap zoals Trivy maken dit eenvoudig. Trivy rapporteert kwetsbaarheden, hun ernst, en aanbevolen oplossingen.

# Scan an image with Trivy
trivy image myapp:latest

# Scan and fail on high/critical vulnerabilities
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest

Softwarerekeningen van materialen (SBOM) genereren en onderhouden

Een SBOM geeft u een complete inventaris van alles wat in uw container zit. Wanneer de volgende zero-day valt, kunt u direct controleren of u getroffen bent. De EU Cyber Resilience Act (september 2026) zal de SBOM-generatie opdracht geven voor alle software die in de EU-markt wordt verkocht . Dit is niet langer een leuke-to-have.

Afbeelding Bewijs documenteert de oorsprong en geschiedenis van containerbeelden om traceerbaarheid en integriteit te garanderen. SBOM Generation creëert een Software Bill of Materials (SBOM) voor elk beeld, waarin alle componenten, bibliotheken en afhankelijkheden voor transparantie en kwetsbaarheidsbeheer worden beschreven.

Grype ondersteunt het scannen van softwarefacturen van materialen (SBOMs). Een SBOM biedt een database van alle metadata, componenten, bibliotheken en pakketten die een container vormen. Tools zoals Syft kunnen automatisch SBOM's genereren, die vervolgens kunnen worden gescand op kwetsbaarheden.

Docker Content Trust en afbeeldingsondertekening inschakelen

Docker Engine kan worden geconfigureerd om alleen ondertekende afbeeldingen uit te voeren. De functie Docker Content Trust handtekening verificatie is direct ingebouwd in de dockerd binaire. Dit zorgt ervoor dat afbeeldingen niet zijn geknoeid met en afkomstig zijn van vertrouwde bronnen.

Cosign v3 (huidig: v3.0.5) standaard voor sleutelloze verificatie via Sigstore's certificaatautoriteit en transparantielogboek. Dit is eenvoudiger en veiliger dan het zelf beheren van ondertekeningssleutels.

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1

# Sign an image with Cosign
cosign sign myregistry.io/myapp:v1.0.0

# Verify a signed image
cosign verify myregistry.io/myapp:v1.0.0

Beeldondertekening biedt cryptografische bewijs van authenticiteit en integriteit, beschermen tegen supply chain aanvallen waar kwaadaardige actoren kunnen besmette beelden in uw register injecteren.

Netwerksegmentatie en isolatie implementeren

Netwerksegmentatie is een kritieke verdedigings-diepte strategie die de straal van mogelijke veiligheidsinbreuken beperkt. Door containers te isoleren in afzonderlijke netwerken op basis van hun functie en vertrouwensniveau, kunt u zijdelingse beweging door aanvallers voorkomen.

Maak aangepaste Docker-netwerken voor verschillende toepassingsniveaus:

# Create isolated networks
docker network create --driver bridge frontend-net
docker network create --driver bridge backend-net
docker network create --driver bridge database-net

# Run containers on specific networks
docker run -d --name web --network frontend-net nginx:alpine
docker run -d --name api --network backend-net myapi:latest
docker run -d --name db --network database-net postgres:14

# Connect API to both frontend and backend networks
docker network connect frontend-net api

Docker Engine 28 heeft een gerelateerd probleem aangepakt: ongepubliceerde containerpoorten zijn nu standaard geblokkeerd voor toegang tot LAN. Dit voorkomt dat per ongeluk diensten worden blootgesteld die niet via het netwerk toegankelijk zouden moeten zijn.

Gebruik netwerkbeleid in Kubernetes omgevingen om het verkeer tussen de pods verder te beperken. Bepaal in- en uitstapregels die expliciet alleen de nodige communicatiepaden toestaan.

Gebruik Runtime Security profielen

De Runtime beveiligingsprofielen bieden extra beschermingslagen door te beperken wat containers kunnen doen tijdens de uitvoering. Er zijn drie primaire mechanismen beschikbaar:

Profielen van Seccomp

Seccomp (Secure Computing Mode) filtert systeemaanroepen die containers naar de kernel kunnen maken. Door beschikbare systeemaanroepen te beperken, verklein je het aanvalsoppervlak aanzienlijk.

# Run container with custom seccomp profile
docker run --security-opt seccomp=/path/to/seccomp-profile.json myapp:latest

Profielen van AppArmor

Laad het AppArmor-profiel en voer container uit met AppArmor-profiel. AppArmor biedt verplichte toegangscontrole door de mogelijkheden van programma's te beperken met per-programma-profielen.

# Load AppArmor profile
sudo apparmor_parser -r /etc/apparmor.d/docker-webapp

# Run container with AppArmor
docker run --security-opt apparmor=docker-webapp myapp:latest

SELinux-integratie

SELinux Integration biedt een extra beveiligingslaag door verplichte toegangscontrole op containers en hun interacties met het hostsysteem af te dwingen. SELinux labels bieden fijnkorrelige toegangscontrole voor containerprocessen en resources.

Geheimenbeheer en gevoelige gegevensbescherming

Hard-coderen geheimen in afbeeldingen of omgeving variabelen is een van de meest voorkomende fouten ontwikkelaars maken. We moeten bewaren en injecteren geheimen veilig. Eigen geheimen beheer is cruciaal voor het behoud van de veiligheid van containerized toepassingen.

Geheimen nooit in afbeeldingen insluiten

Wachtwoorden, API-sleutels en tokens mogen nooit worden opgeslagen in de afbeelding, binnen de omgeving variabelen blootgesteld in logs of in de Git repositories. In plaats daarvan, beveilig ze als Docker geheimen, Kubernetes geheimen, of externe gewelven (AWS Secrets Manager, HashiCorp Vault) moet worden gebruikt.

Vaak voorkomende fouten te vermijden:

  • Hardcoding-gegevens in Dockerfiles
  • .env-bestanden met geheimen committen aan versiebeheer
  • Geheimen doorgeven als bouwargumenten (ze blijven in beeldgeschiedenis)
  • Geheimen tonen in omgevingsvariabelen zichtbaar in logs

Gebruik Docker-geheimen voor zwermmodus

Docker biedt een ingebouwde geheimen functie voor gecodeerde opslag. Docker Swarm omvat inheemse geheimen beheer dat geheimen versleutelt in rust en in transit.

# Create a secret
echo "my-db-password" | docker secret create db_password -

# Use secret in service
docker service create
 --name myapp
 --secret db_password
 myapp:latest

In de container worden geheimen als bestanden in /run/secrets/ gemount, waardoor ze alleen toegankelijk zijn voor het containerproces zonder ze in omgevingsvariabelen of logs te tonen.

Externe geheimenbeheeroplossingen integreren

Hashicorp Vault: Een gecentraliseerd geheim management tool die kan worden gebruikt om geheimen veilig op te slaan en te beheren in container-omgevingen. Voor productie-omgevingen, vooral in Kubernetes, overwegen met behulp van speciale geheimen management oplossingen.

Populaire opties zijn:

  • HashiCorp Vault: Biedt dynamische geheimen, encryptie als een dienst, en gedetailleerde audit logs
  • AWS Secrets Manager: Native integratie met AWS-diensten en automatische rotatie
  • Azure sleutelkluis: gecentraliseerd geheimbeheer voor Azure werklast
  • Google Secret Manager: Veilige opslag voor API sleutels, wachtwoorden en certificaten in GCP

Terwijl Docker Secrets over het algemeen een veilige manier om gevoelige gegevens in Docker-omgevingen te beheren bieden, wordt deze aanpak niet aanbevolen voor Kubernetes, waar geheimen worden opgeslagen in platte tekst standaard. In Kubernetes, overwegen met behulp van extra beveiligingsmaatregelen zoals etcd encryptie, of third-party tools.

Beveiliging en onderhoud van het gastsysteem

Om te beschermen tegen bekende container ontsnapping kwetsbaarheden zoals Leaky schepen, die meestal resulteren in de aanvaller krijgen root toegang tot de host, is het van essentieel belang om zowel de host en Docker up-to-date te houden. Dit omvat regelmatig het bijwerken van de host kernel en de Docker Engine.

Systemen bijwerken en op de map zetten

Dit is te wijten aan het feit dat containers de kernel van de host delen. Als de kernel van de host kwetsbaar is, zijn de containers ook kwetsbaar. Bijvoorbeeld, de kernel privilege escalatie exploit, Dirty COW, uitgevoerd in een goed geïsoleerde container zou nog steeds leiden tot root toegang op een kwetsbare host.

Container runtime motoren zoals Docker vaak hun software bijwerken met fixes en functies. U kunt de kwetsbaarheden te verminderen door het toepassen van de nieuwste updates.

Het uitvoeren van de docker pull eenmaal en vergeten over het betekent het verschepen van beelden met maanden oude kwetsbaarheden. Automatiseer updates met Renovate Bot's container beelddatabron .Het creëert PR's wanneer basisbeelden updates hebben, paren met uw CI scannen pijplijn voor automatische sanering.

Beveiligde hosttoegang en authenticatie

Alle aanmeldingscontrole direct aan het besturingssysteem moet worden gecontroleerd en geregistreerd. U dient alleen toegang te verlenen aan de juiste gebruikers en sleutels te gebruiken voor externe logins. En u moet firewalls implementeren en alleen toegang geven op vertrouwde netwerken.

Beste praktijken voor de beveiliging van gasten zijn onder meer:

  • Wachtwoordauthenticatie voor SSH uitschakelen, alleen sleutelgebaseerde authenticatie gebruiken
  • Multifactor-authenticatie implementeren voor bevoorrechte toegang
  • Bastion hosts of jump servers gebruiken voor toegang tot productiesystemen
  • Controleloggen voor alle administratieve handelingen inschakelen
  • De toegang tot Docker daemon socket beperken tot alleen geautoriseerde gebruikers

De Docker Daemon Socket nooit ontmaskeren

Dit is een slechte praktijk die u moet vermijden omdat een aanvaller zou in staat zijn om een commando dat de Docker-service kan uitvoeren en potentieel toegang krijgen tot het hele host-systeem, omdat de Docker-service loopt als root.

Het monteren van de Docker socket (/var/run/docker.sock) in een container geeft die container volledige controle over de Docker daemon, effectief het verlenen van root toegang tot de gastheer. Als u moet bieden Docker toegang tot containers, overwegen alternatieven zoals:

  • Het gebruik van Docker-in-Docker (Dind) met een goede isolatie
  • Gebruik van rootless Docker-modus
  • Gebruik van container runtime API's met beperkte toegangsrechten
  • Kubernetes CRI in plaats van directe Docker toegang

Docker in rootless-modus uitvoeren

Rootless Docker maakt het mogelijk om de Docker daemon en containers als een niet-root gebruiker te draaien, waardoor de impact van potentiële container breakout kwetsbaarheden aanzienlijk vermindert. Deze modus elimineert de noodzaak van root privileges op het host systeem.

# Install rootless Docker
dockerd-rootless-setuptool.sh install

# Run Docker commands as non-root user
docker run -d nginx:alpine

Hoewel rootless modus zorgt voor verbeterde beveiliging, heeft het enkele beperkingen, zoals beperkte netwerkmogelijkheden en prestatieoverwegingen. Evaluatieer of deze afwegingen aanvaardbaar zijn voor uw use case.

Monitoring en detectie van de veiligheid tijdens de vlucht

Statische beveiliging vangt problemen voordat implementatie. Runtime beveiliging vangt wat er gebeurt na. Zelfs als beelden veilig zijn, containers kunnen nog steeds worden aangevallen op runtime. De implementatie van runtime beveiliging monitoring is essentieel voor het detecteren en reageren op bedreigingen in productie-omgevingen.

Hulpmiddelen voor het uitvoeren van de Runtime Security

Falco 0.43.0 (januari 2026) . . Detecteert abnormale syscalls, bestandstoegang en netwerkverbindingen. Het nieuwe drop-enter initiatief verwijderd syscall enter events uit de pijplijn, aanzienlijk verbeteren van de prestaties. De nalatenschap eBPF sonde wordt ten gunste van de moderne eBPF driver.

Falco is een open-source runtime security tool die eBPF gebruikt om containergedrag te monitoren en verdachte activiteiten te detecteren.

  • Onverwachte procesuitvoering
  • Ongeautoriseerde bestandswijzigingen
  • Verdachte netwerkverbindingen
  • Privilege escalatie pogingen
  • Schelpbroeden in verpakkingen inhoudende
# Example Falco rule for detecting shell in container
- rule: Shell Spawned in Container
 desc: Detect shell process started in container
 condition: >
 spawned_process and
 container and
 proc.name in (bash, sh, zsh)
 output: >
 Shell spawned in container (user=%user.name container=%container.name
 shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
 priority: WARNING

Uitvoeren van uitgebreide logging en monitoring

Docker gebeurtenissen bieden native audit stream voor container lifecycle, Prometheus + cAdvisor track resource use tracking per container. Onverwachte proces uitvoering, netwerkverbindingen, of bestand wijzigingen leiden tot onmiddellijke waarschuwingen.

Een alomvattende houtkapstrategie opstellen die het volgende omvat:

  • Containerlogs: Toepassingsuitvoer en foutmeldingen
  • Doker daemon logs: Container lifecycle events and daemon operations
  • Systeemlogs opslaan: Kernelberichten en systeemgebeurtenissen
  • Auditlogs: Veiligheidsrelevante gebeurtenissen en toegangpogingen

Centraliseer logs met behulp van tools zoals de ELK stack (Elasticsearch, Logstash, Kibana), Loki met Grafana, of cloud-native oplossingen zoals AWS CloudWatch of Azure Monitor. Gecentraliseerde logging maakt correlatie van gebeurtenissen tussen meerdere containers en hosts, waardoor het gemakkelijker om verspreide aanvallen te detecteren.

# Configure Docker to use JSON file logging driver with rotation
{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10m",
 "max-file": "3",
 "labels": "production_status",
 "env": "os,customer"
 }
}

Resourcelimieten instellen om DoS-aanvallen te voorkomen

Resource limits voorkomen ontkenning van serviceaanvallen en uitputting van hulpbronnen. Zonder de juiste middelen beperkingen, een gecompromitteerde of misdragen container zou alle beschikbare systeembronnen te verbruiken, die andere containers en de gastheer.

# Docker Compose with resource limits
version: "3.9"
services:
 app:
 image: myapp:latest
 deploy:
 resources:
 limits:
 cpus: "2.0"
 memory: 512M
 pids: 100
 reservations:
 cpus: "0.5"
 memory: 256M
 ulimits:
 nofile:
 soft: 65536
 hard: 65536
 nproc:
 soft: 100
 hard: 200

De beperkingen van de hulpbronnen moeten worden vastgesteld op basis van de toepassingsvereisten en de capaciteitsplanning.

Integratie van de beveiliging van de pijpleiding door CI/CD

CI/CD pijpleidingen zijn een cruciaal onderdeel van de software ontwikkeling levenscyclus en moeten verschillende beveiligingscontroles, zoals pluis controles, statische code analyse, en container scannen omvatten. Veel problemen kunnen worden voorkomen door het volgen van een aantal beste praktijken bij het schrijven van de Dockerfile. Echter, het toevoegen van een beveiligingslinter als een stap in de bouw pijplijn kan een lange weg gaan in het voorkomen van verdere hoofdpijn.

Dockerbestands linting implementeren

Dockerfile linters analyseren uw Dockerfiles voor gemeenschappelijke fouten, veiligheidsproblemen, en beste praktijken schendingen voordat afbeeldingen worden gebouwd. Tools zoals Hadolint kunnen problemen vroeg in het ontwikkelingsproces vangen.

# Run Hadolint on Dockerfile
docker run --rm -i hadolint/hadolint < Dockerfile

# Example output showing issues
DL3008: Pin versions in apt get install
DL3009: Delete the apt-get lists after installing
DL3015: Avoid additional packages by specifying --no-install-recommends

Beveiligingsscannen automatiseren in CI/CD

Container scanners zijn vooral belangrijk als onderdeel van een succesvolle veiligheidsstrategie. Ze kunnen bekende kwetsbaarheden, geheimen en verkeerde configuraties in containerbeelden detecteren en een verslag van de bevindingen met aanbevelingen over hoe ze te repareren.

Door Docker Scout in uw CI/CD-pijpleiding te integreren kunt u automatisch controleren of de beelden die zijn gebouwd van Docker Harded Images tijdens het bouwproces vrij blijven van bekende kwetsbaarheden. Deze proactieve aanpak zorgt voor de voortdurende integriteit van uw beelden gedurende de hele ontwikkelingscyclus.

# GitHub Actions workflow example
name: Container Security Scan

on:
 push:
 branches: [ main ]
 pull_request:
 branches: [ main ]

jobs:
 security-scan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3

 - name: Build image
 run: docker build -t myapp:${{ github.sha }} .

 - name: Run Trivy vulnerability scanner
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: myapp:${{ github.sha }}
 format: 'sarif'
 output: 'trivy-results.sarif'
 severity: 'CRITICAL,HIGH'
 exit-code: '1'

 - name: Upload Trivy results to GitHub Security
 uses: github/codeql-action/upload-sarif@v2
 if: always()
 with:
 sarif_file: 'trivy-results.sarif'

 - name: Push image if scan passes
 if: success()
 run: |
 docker tag myapp:${{ github.sha }} myregistry.io/myapp:latest
 docker push myregistry.io/myapp:latest

Uitvoering van de handhaving van het beleid

Beleidshandhaving zorgt ervoor dat alleen conforme beelden worden ingezet voor de productie. Tools zoals Open Policy Agent (OPA) en Kyverno kunnen organisatorische beleid automatisch af te dwingen.

Gemeenschappelijke beleidsmaatregelen die moeten worden uitgevoerd, zijn onder meer:

  • Afbeeldingen moeten worden gescand en geen kritieke kwetsbaarheden hebben
  • Afbeeldingen moeten door vertrouwde autoriteiten worden ondertekend
  • Containers moeten als niet-rootgebruikers draaien
  • Containers mogen geen bevoorrechte modus gebruiken
  • Er moeten grenzen aan hulpbronnen worden vastgesteld
  • Beelden moeten afkomstig zijn van erkende registers

Kubernetes-specifieke veiligheidsoverwegingen

Kubernetes beveiliging wordt essentieel bij het beheer van clusters. Zwakke role-based toegangscontrole (RBAC) of blootgesteld dashboards verhogen het risico. Bij het uitvoeren van Docker containers in Kubernetes, zijn extra veiligheidsmaatregelen nodig.

Tenuitvoerlegging van Pod-beveiligingsstandaarden

Kubernetes Pod Security Standards definiëren drie niveaus van beveiligingsbeleid: Priviged, Baseline, en Beperkt. Het Beperkte beleid dwingt de strengste beveiligingseisen en moet worden gebruikt voor productie werklast wanneer mogelijk.

apiVersion: v1
kind: Pod
metadata:
 name: secure-app
 labels:
 app: myapp
spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 1000
 fsGroup: 1000
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: myapp:latest
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 capabilities:
 drop:
 - ALL
 runAsNonRoot: true
 runAsUser: 1000
 resources:
 limits:
 cpu: "1"
 memory: "512Mi"
 requests:
 cpu: "100m"
 memory: "128Mi"
 volumeMounts:
 - name: tmp
 mountPath: /tmp
 volumes:
 - name: tmp
 emptyDir: {}

Netwerkbeleid instellen

Kubernetes Network Policies bieden fijnkorrelige controle over pod-to-pod communicatie. Standaard kunnen alle pods communiceren met elkaar, wat in strijd is met het principe van de minst privileges.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-network-policy
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: api
 policyTypes:
 - Ingress
 - Egress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: frontend
 ports:
 - protocol: TCP
 port: 8080
 egress:
 - to:
 - podSelector:
 matchLabels:
 app: database
 ports:
 - protocol: TCP
 port: 5432

Toegangscontroleurs gebruiken

Toegangscontrollers onderscheppen verzoeken om de Kubernetes API-server voordat objecten worden aangehouden, zodat u beleid en validatie configuraties. Tools zoals OPA Gatekeeper en Kyverno bieden beleids-as-code mogelijkheden.

Voorbeeld van het te implementeren beleid:

  • Alle afbeeldingen moeten afkomstig zijn van goedgekeurde registers
  • De beperkingen van alle containers op te leggen
  • Voorkom dat er speciale containers worden aangemaakt
  • Specifieke labels op alle bronnen nodig
  • Beveiligingscontexten valideren die aan minimumeisen voldoen

Naleving en regelgevingsoverwegingen

Organisaties die actief zijn in gereglementeerde industrieën moeten ervoor zorgen dat hun containerinzet voldoet aan specifieke nalevingseisen.

  • CIS Docker Benchmark: Biedt een prescriptieve leidraad voor het instellen van een veilige configuratiehouding voor Docker
  • CIS Kubernetes Benchmark: Veiligheidsaanbevelingen voor Kubernetes-implementaties
  • PCI DSS: Vereisten voor organisaties die betalingsgegevens verwerken
  • HIPAA: Normen voor de bescherming van gevoelige gezondheidsinformatie van patiënten
  • SOC 2: Kader voor het beheer van klantgegevens op basis van vijf vertrouwensbeginselen
  • GDPR: Gegevensbescherming en privacyvereisten voor EU-ingezetenen

Gereedschappen zoals Docker Bench for Security en Kube-bench kunnen uw omgeving automatisch beoordelen op basis van deze benchmarks en bieden herstel begeleiding.

# Run Docker Bench for Security
docker run --rm --net host --pid host --userns host --cap-add audit_control
 -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST
 -v /var/lib:/var/lib
 -v /var/run/docker.sock:/var/run/docker.sock
 -v /usr/lib/systemd:/usr/lib/systemd
 -v /etc:/etc --label docker_bench_security
 docker/docker-bench-security

# Run kube-bench for Kubernetes
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Container Registry Security

Containerregisters zijn cruciale onderdelen van de container supply chain. Door uw registers te beveiligen, wordt ongeoorloofde toegang tot beelden voorkomen en wordt bescherming geboden tegen aanvallen van de toeleveringsketen.

Privé-registers gebruiken

Terwijl openbare registers zoals Docker Hub handig zijn, moeten productiewerkbelastingswaarden privéregisters gebruiken met de juiste toegangscontrole. Opties zijn onder andere:

  • Harbor: Open-source register met kwetsbaarheid scannen, beeld ondertekening, en RBAC
  • AWS ECR: Beheerd register geïntegreerd met AWS-diensten
  • Azure Container Register: Beheerd register voor Azure workloads
  • Google Container Registry: Beheerd register voor GCP
  • JFrog Artificial: Universele artefactenopslag met geavanceerde beveiligingsfuncties

Registry Access Controls implementeren

Authenticatie en autorisatie voor registertoegang configureren:

  • Serviceaccounts gebruiken met minimale machtigingen voor CI/CD-pijpleidingen
  • Role-based access control (RBAC) voor verschillende teams implementeren
  • Controleloggen inschakelen voor alle registerbewerkingen
  • Gebruik korte-levende tokens in plaats van lange termijn referenties
  • IP-whitlisting implementeren voor toegang tot het register

Automatische kwetsbaarheidsscanning inschakelen

Met Docker Hub kunt u point-in-time statische kwetsbaarheidsscannen uitvoeren of altijd up-to-date beeldanalyse met behulp van Docker Scout. Na het inschakelen van Docker Scout beeldanalyse, analyseert Docker Scout automatisch afbeeldingen in uw Docker Hub repository. Afbeeldingsanalyse haalt de Software Bill of Material (SBOM) en andere beeldmetadata uit en evalueert deze tegen kwetsbaarheidsgegevens van beveiligingsadviseurs.

De meeste moderne registers bieden geïntegreerde kwetsbaarheid scannen die automatisch scant beelden wanneer ze worden geduwd. Configureer uw register naar:

  • Scan alle afbeeldingen automatisch bij duwen
  • Afbeeldingen continu opnieuw scannen voor nieuw ontdekte kwetsbaarheden
  • Blokkeer de inzet van beelden met kritieke kwetsbaarheden
  • Notificatieberichten verzenden wanneer kwetsbaarheden worden gedetecteerd
  • Advies voor sanering van geïdentificeerde kwesties

Incidentrespons en -herstel

Ondanks de implementatie van uitgebreide beveiligingsmaatregelen, kunnen incidenten nog steeds optreden. Het hebben van een duidelijk omschreven responsplan voor incidenten is cruciaal voor het minimaliseren van schade en het snel herstellen.

Ontwikkelen van een incidentresponsplan

Uw reactieplan voor incidenten moet het volgende omvatten:

  • Detection: Mechanismen voor het identificeren van veiligheidsincidenten door monitoring en waarschuwing
  • Behoud: Procedures voor het isoleren van de getroffen containers en het voorkomen van verspreiding
  • Onderzoek: Stappen voor het analyseren van het incident en het bepalen van de oorzaak
  • Eradicatie: Processen voor het verwijderen van bedreigingen en het sluiten van kwetsbaarheden
  • Recovery: Procedures voor het herstellen van diensten en het valideren van de veiligheid
  • Post-incident beoordeling: Analyse van wat er gebeurd is en hoe herhaling te voorkomen

Uitvoeren Container Forensische Mogelijkheden

Container forensisch kan worden uitdagend als gevolg van de kortstondige aard van containers. Implementeren van deze praktijken ter ondersteuning van onderzoeken:

  • Behoud containerstatus door snapshots te maken voor beëindiging
  • Instandhouding van uitgebreide logboeken met voldoende bewaartermijnen
  • Gebruik onveranderlijke infrastructuur om manipulatie van bewijsmateriaal te voorkomen
  • Controleloggen uitvoeren voor alle containerbewerkingen
  • Behoud herkomst van afbeeldingen en bouwgeschiedenis

Praktijken voor herstel van rampen

Test regelmatig uw noodherstelprocedures:

  • Voer tafelbladoefeningen uit om beveiligingsincidenten te simuleren
  • Test back-up en herstel procedures voor containergegevens
  • Valideren dat u omgevingen vanaf nul kunt herbouwen
  • Zorgen dat de documentatie actueel en toegankelijk is
  • Leden van het treinteam over procedures voor incidentenrespons

Beveiligingscontrolelijst voor productie-inzetmogelijkheden

Begin met de high-impact items: minimale afbeeldingen, niet-root gebruikers, CI scannen en verteren pinning. Laag in runtime monitoring, netwerk segmentatie en geheimen management. Gebruik deze uitgebreide checklist om ervoor te zorgen dat uw Docker containers voldoen aan de veiligheidseisen voordat de productie inzet:

Afbeeldingsbeveiliging

  • Gebruik minimale basisafbeeldingen (alpine, distroless)
  • Speld specifieke afbeeldingsversies met behulp van vertakkingen
  • Scan afbeeldingen op kwetsbaarheden in CI/CD-pijpleiding
  • Beelden tekenen met Docker Content Trust of Cosign
  • Genereren en onderhouden SBOM's voor alle afbeeldingen
  • Verwijder onnodige pakketten en bestanden
  • Meertrapsbouwen gebruiken om de uiteindelijke afbeeldingsgrootte te minimaliseren
  • Nooit geheimen in afbeeldingen opnemen

Container Runtime Security

  • Containers als niet-root-gebruikers uitvoeren
  • Alleen-lezen-bestandssystemen gebruiken
  • Alle mogelijkheden laten vallen en alleen de benodigde toevoegen
  • No-new-privileges-vlag inschakelen
  • Seconcomp, AppArmor of SELinux-profielen toepassen
  • Resourcelimieten instellen (CPU, geheugen, PID's)
  • Netwerksegmentatie implementeren
  • Gebruik particuliere netwerken voor communicatie tussen containers

Host- en infrastructuurbeveiliging

  • Hou host OS en kernel op de hoogte
  • Docker Engine regelmatig bijwerken
  • Docker daemon socket nooit bloot
  • Gebruik rootless Docker indien mogelijk
  • Op host gebaseerde firewalls implementeren
  • Accountloggen inschakelen
  • SSH-toegang beperken met sleutelgebaseerde authenticatie
  • Bastion hosts gebruiken voor productietoegang

Geheimen en configuratiebeheer

  • Gebruik Docker Secrets of externe gewelven
  • Nooit hardcode-gegevens
  • Geheimen regelmatig roteren
  • Gebruik van korte-levende tokens en referenties
  • Geheimen versleutelen in rust en in transit
  • Geheime toegang tot audit

Monitoring en loggen

  • Uitvoeren van runtime security monitoring (Falco)
  • Logboeken uit alle containers centraliseren
  • Docker-daemon-loggen inschakelen
  • Bewaak het gebruik van hulpbronnen
  • Opzetten van signaleringen voor verdachte activiteiten
  • Voldoende logbehoud behouden
  • Controlespoorten uitvoeren om de naleving te garanderen

CI/CD Pijpleidingbeveiliging

  • Lint Dockerfiles met Hadolint
  • Afbeeldingen scannen in CI-pijplijn
  • Fail bouwt voort op kritieke kwetsbaarheden
  • Uitvoering van de handhaving van het beleid
  • Gebruik aparte registers voor dev/staging/prod
  • Beveiligingstests automatiseren
  • Vereiste code beoordeling voor wijzigingen in Dockerbestand

Kubernetes-Specific (indien van toepassing)

  • Tenuitvoerlegging van Pod-beveiligingsstandaarden
  • Netwerkbeleid instellen
  • Gebruik de toegangsverantwoordelijken voor de handhaving van het beleid
  • RBAC inschakelen met minder privilege
  • Beveilig de Kubernetes API-server
  • Versleutel etcd data in rust
  • CIS Kubernetes Benchmarkcontroles uitvoeren

Containerbeveiliging blijft evolueren met nieuwe technologieën en benaderingen. Blijf op de hoogte van opkomende trends:

Beveiliging van de bevoorradingsketen

De incidenten van de terugzending van backdoored basisbeelden verzenden voor maanden, duizenden productiegegevens gelekt via Dockerfiles . Bewijs dat de basisprincipes nog steeds belangrijk zijn. Supply chain aanvallen gericht op container ecosystemen worden steeds groter. Implementeren SLSA (Supply-chain Levels voor Software Artifacts) kaderprincipes om de integriteit van uw software supply chain te verifiëren.

Zero Trust Architecture

Gebruik nul vertrouwen principes op containeromgevingen door het aannemen van inbreuk en het verifiëren van elke aanvraag. Implementeren service mesh technologieën zoals Istio of Linkerd om wederzijdse TLS-authenticatie, fijnkorrelige autorisatie, en opmerkbaarheid voor container-tot-container communicatie te bieden.

Beveiliging op basis van eBPF

Extended Berkeley Packet Filter (eBPF) technologie maakt krachtige runtime security monitoring mogelijk met minimale prestaties overhead. Gereedschappen die eBPF gebruiken kunnen een diepe zichtbaarheid bieden in containergedrag zonder kernelmodules of containeraanpassingen nodig te hebben.

Vertrouwelijke berekening

Vertrouwelijke computertechnologieën beschermen gegevens in gebruik door het uitvoeren van berekeningen in vertrouwde uitvoeringsomgevingen (TEE's) op hardware gebaseerde systemen. Deze nieuwe aanpak kan gevoelige werkbelasting beschermen, zelfs tegen bevoorrechte gebruikers en besmette hostsystemen.

Aanbevolen hulpmiddelen en middelen

Het bouwen van een uitgebreide container beveiliging programma vereist het gebruik van de juiste tools. Hier zijn aanbevolen middelen georganiseerd per categorie:

Kwetsbaarheidsscanning

  • Trivy (Open Bron): Snelle, uitgebreide kwetsbaarheidsscanner
  • Docker Scout: Geïntegreerd scannen met Docker Desktop en CLI
  • Versterk de motor (open bron): Beleidsgebaseerde scanning en naleving
  • Snyk Container: Ontwikkelaargericht scannen met aanbevelingen voor fix
  • Clair (Open Bron): Statische analyse van kwetsbaarheden

Runtime Security

  • Falco (open bron): Runtime dreiging detectie met behulp van eBPF
  • Aqua Security: Uitgebreide containerbeveiligingsplatform
  • Sysdig Secure: Runtime security and forensics

Beleid en naleving

  • Open Policy Agent (Open Source): Policy-as-code engine
  • Kyverno (open bron): Kubernetes-native policy management
  • Dokterbank voor veiligheid (open bron): CIS Docker Benchmark controles
  • kube-bench (open bron): CIS Kubernetes Benchmarkcontroles

Geheim beheer

  • HashiCorp Vault: Enterprise secrets management
  • AWS Secrets Manager: Cloud-native geheimen voor AWS
  • Azure sleutelkluis: geheimbeheer voor Azure
  • Google Secret Manager: Secrets management for GCP

Aanvullende middelen

Conclusie

Containerbeveiliging is een continu proces dat verschillende aspecten omvat, waaronder beeldcreatie, geheime behandeling, runtime gedrag en continue monitoring. Beveiliging is een continu proces. Controleer regelmatig uw configuraties, update basisbeelden, en blijf op de hoogte van nieuwe kwetsbaarheden. De inspanning die u vandaag investeert in containerbeveiliging beschermt uw infrastructuur morgen.

De implementatie van veilige Docker containers vereist een uitgebreide, gelaagde aanpak die de veiligheid in elke fase van de container levenscyclus behandelt. Van het kiezen van minimale basisbeelden en draaien als niet-root gebruikers tot het implementeren van runtime monitoring en het handhaven van naleving, elke veiligheidsmaatregel draagt bij aan een robuuste verdediging-diepte strategie.

Docker containers bieden krachtige tools voor moderne ontwikkeling, maar vereisen zorgvuldige toezicht om ervoor te zorgen dat ze veilig blijven. Door het aanpakken van de risico's in verband met Docker-beelden, container privileges, en host systemen, organisaties kunnen de kans op inbreuken te minimaliseren en de betrouwbaarheid van hun containerized omgevingen maximaliseren.

De sleutel tot succesvolle containerbeveiliging is het niet als een eenmalige implementatie behandelen, maar als een voortdurende praktijk geïntegreerd in uw ontwikkeling cultuur. Automatiseer veiligheidscontroles in uw CI / CD-pijpleidingen, continu monitoren van looptijd gedrag, regelmatig update componenten, en blijf op de hoogte over opkomende bedreigingen en beste praktijken. Door het volgen van de strategieën en aanbevelingen die in deze gids, kunt u bouwen en onderhouden veilige container toepassingen die de activa van uw organisatie beschermen, terwijl het mogelijk maken van de wendbaarheid en efficiëntie die containers bieden.

Vergeet niet dat veiligheid is een gedeelde verantwoordelijkheid. Terwijl Docker en container orkestratie platforms bieden de tools en mogelijkheden, is het aan de ontwikkeling en operationele teams om veiligheidsmaatregelen consequent te implementeren en te handhaven. Investeer in de opleiding van uw team, het vaststellen van duidelijke beveiligingsbeleid, en het bevorderen van een cultuur waar veiligheid is iedereens verantwoordelijkheid. Met de juiste combinatie van tools, praktijken en waakzaamheid, kunt u de volledige kracht van containerisatie benutten met behoud van een sterke beveiligingshouding.