Docker-proxy: de complete gids om containers te laten werken achter bedrijfsfirewalls

De meeste bedrijfsnetwerken gebruiken proxyservers om internetverkeer te monitoren en te filteren. Dat vormt obstakels wanneer Docker images uit registries probeert te pullen. Je krijgt te maken met timeouts bij verbindingen, authenticatiefouten en mislukte builds die thuis wél werken. Deze proxygerelateerde problemen kunnen ontwikkelteams ontsporen die geen toegang hebben tot de basisimages die ze nodig hebben.

Docker-proxyconfiguratie lost deze verbindingsproblemen op, verbetert prestaties via caching en voldoet aan bedrijfsbrede beveiligingseisen. Zodra alles is ingesteld, kunnen je containers images pullen ongeacht netwerkbeperkingen.

In deze tutorial laat ik je zien hoe je proxy-instellingen voor de Docker-daemon instelt, omgevingsvariabelen voor containers configureert en proxyconfiguratie afhandelt in Docker Compose.

Nieuw met Docker en overweldigd door alle netwerkconcepten? Begin met de Docker-basisprincipes en bouw stap voor stap zelfvertrouwen op.

De proxyarchitectuur van Docker begrijpen

Verschillende onderdelen van het Docker-ecosysteem hebben op verschillende lagen proxyconfiguratie nodig.

Proxies fungeren als tussenlaag tussen je Docker-onderdelen en externe netwerken. Wanneer Docker images moet pullen, containers internettoegang nodig hebben of builds externe resources vereisen, controleren en monitoren proxyservers deze verbindingen. Ze zitten tussen je gecontaineriseerde applicaties en de buitenwereld en filteren verzoeken en responsen.

Organisaties gebruiken proxies met Docker voor prestaties, beveiliging en compliance.

Prestatievoordeel komt door het cachen van vaak gebruikte resources zoals basisimages, waardoor downloadtijden voor je team dalen. Beveiligingsvoordelen zijn onder meer verkeersfiltering, malware-scanning en het blokkeren van ongeautoriseerde sites. Voor compliance is vereist dat al het netwerkverkeer door bewaakte kanalen gaat met de juiste toegangscontroles en audittrails.

Docker-proxyconfiguratie vindt plaats op vier lagen:

• Clientproxy: beïnvloedt Docker-CLI-commando’s zoals docker pull en docker push

• Daemonproxy: bepaalt hoe de Docker-daemon externe registries benadert  

• Proxy voor containerruntime: stelt proxyvariabelen in voor applicaties binnen containers

• Build-time proxy: regelt proxy-instellingen tijdens docker build-operaties wanneer Dockerfiles internettoegang nodig hebben

Elke laag heeft een doel en vraagt om een eigen configuratieaanpak.

Docker-netwerken begrijpen begint met begrijpen hoe containers communiceren. 

Docker configureren voor gebruik met een proxy

Om Docker met je bedrijfsproxy te laten werken, moet je zowel de Docker-daemon als de client instellen.

Waarom? Omdat ze verschillende soorten netwerkverzoeken afhandelen. 

De daemon beheert pulls, pushes en registry-authenticatie, terwijl de client CLI-bewerkingen en API-calls afhandelt. Als een van beide ontbreekt, ontstaan er hiaten waardoor Docker-bewerkingen kunnen falen met verbindingsfouten.

Hoe je de Docker-daemon configureert

De Docker-daemon leest proxy-instellingen uit /etc/docker/daemon.json. Maak dit bestand aan als het niet bestaat:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}Mogelijk gemaakt door

Het veld noProxy bevat adressen die de proxy moeten omzeilen. Neem hier je interne registrydomeinen en localhost-adressen in op.

systemd-serviceoverrides instellen

Op Linux-systemen met systemd moet je ook de Docker-service zelf configureren voor gebruik met de proxy. Maak de override-map en het configuratiebestand aan:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/http-proxy.confMogelijk gemaakt door

Voeg vervolgens deze omgevingsvariabelen toe aan het bestand http-proxy.conf:

[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.company.com"Mogelijk gemaakt door

Dit zorgt ervoor dat het Docker-daemonproces zelf externe services via je proxy kan bereiken.

Docker neemt proxywijzigingen pas over nadat je de daemon hebt herstart. Voer deze commando’s uit om systemd te herladen en Docker te herstarten:

sudo systemctl daemon-reload
sudo systemctl restart dockerMogelijk gemaakt door

Het herladen van de daemon zorgt ervoor dat systemd de nieuwe serviceconfiguratie leest, terwijl de herstart van Docker de wijzigingen in daemon.json toepast.

Platformspecificaties

Docker Desktop behandelt proxyconfiguratie anders dan serverinstallaties. Op Windows en macOS gebruik je de Docker Desktop-GUI om proxy-instellingen te zetten onder Resources - Proxies. Deze instellingen configureren automatisch zowel daemon als client.

Linux-hosts die Docker Engine gebruiken, hebben de handmatige configuratie nodig zoals hierboven beschreven. Sommige distributies leveren Docker anders aan, dus controleer of je systeem dockerd direct gebruikt of via een andere servicemanager.

Je configuratie verifiëren

Test of Docker externe registries kan bereiken met een eenvoudige pull:

docker pull hello-worldMogelijk gemaakt door

Je kunt ook de effectieve configuratie van de daemon controleren:

docker system info | grep -i proxyMogelijk gemaakt door

Dit laat zien of Docker je proxy-instellingen heeft gedetecteerd en toegepast.

Als pulls nog steeds falen, kijk dan in de logs van je proxyserver om te bevestigen dat Docker verzoeken correct routeert.

Vast door netwerkproblemen? Stel Docker-poorten correct bloot en voorkom verbindingspijn.

Proxy-omgevingsvariabelen instellen

Docker-CLI-commando’s hebben een eigen proxyconfiguratie nodig die losstaat van de daemoninstellingen. Omgevingsvariabelen geven je flexibele controle over hoe Docker-clients via bedrijfsproxies verbinden.

Clientproxies sturen Docker-CLI-bewerkingen zoals docker pull, docker push en docker login aan. Wanneer je deze commando’s uitvoert, maakt de Docker-client HTTP-verzoeken naar registries en moet deze weten welke proxyserver te gebruiken. Zonder clientproxy-instellingen falen deze bewerkingen, zelfs als de daemon correct is geconfigureerd.

JSON-configuratiemethode

De netjesste aanpak gebruikt Docker’s configuratiebestand op ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}Mogelijk gemaakt door

Deze methode houdt proxy-instellingen binnen Docker’s configuratie en beïnvloedt geen andere applicaties op je systeem.

Alternatief met omgevingsvariabelen

Je kunt ook standaard proxy-omgevingsvariabelen instellen die Docker automatisch detecteert met deze commando’s:

export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.comMogelijk gemaakt door

Deze variabelen werken voor elke applicatie die proxystandaarden respecteert - niet alleen Docker.

Globale versus per-gebruikerconfiguratie

Voor systeemwijd instellen voeg je de omgevingsvariabelen toe aan /etc/environment of maak je een script in /etc/profile.d/:

# /etc/profile.d/proxy.sh
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.comMogelijk gemaakt door

Voor per-gebruikerinstellingen voeg je ze toe aan je shellprofiel (~/.bashrc, ~/.zshrc) of gebruik je de JSON-methode. Per-gebruikerinstellingen geven ontwikkelaars flexibiliteit om verschillende proxies te gebruiken of ze voor tests helemaal te omzeilen.

Beveiligingsoverwegingen

Je moet nooit gebruikersnamen en wachtwoorden hardcoden in configuratiebestanden of omgevingsvariabelen. 

Proxy-inloggegevens in platte tekst vormen beveiligingsrisico’s, zeker in gedeelde omgevingen of versiebeheersystemen.

Gebruik in plaats daarvan deze aanpakken:

• Configureer je proxyserver waar mogelijk voor IP-gebaseerde authenticatie
• Gebruik credential helpers of veilige opslagsystemen voor authenticatie
• Richt serviceaccounts in met minimale rechten voor Docker-bewerkingen

Als je toch inloggegevens moet opnemen, gebruik dan het formaat http://username:[email protected]:8080, maar bewaar deze in beveiligde bestanden met beperkte permissies.

Proxyconfiguratie tijdens builds

Docker-builds hebben proxy-instellingen nodig die expliciet via build-argumenten worden doorgegeven:

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  -t myapp .Mogelijk gemaakt door

Build-argumenten worden omgevingsvariabelen binnen de buildcontext.

Zo kunnen RUN-instructies pakketten en afhankelijkheden downloaden via je proxy. Zonder deze argumenten falen builds wanneer Dockerfiles software proberen te installeren of resources van internet willen ophalen.

Proxy-instellingen tijdens builds blijven niet bewaard in de uiteindelijke image, tenzij je ze expliciet zet met ENV-instructies in je Dockerfile.

Omgevingsvariabelen geven je de flexibiliteit om proxy-instellingen op het juiste niveau voor je workflow te regelen.

Vind je build-argumenten verwarrend? Beheers Docker build args met praktijkvoorbeelden die echt werken.

Proxy-injectie voor containers en tijdens builds

Alleen Docker-clientconfiguratie brengt je maar halverwege - je containers en builds hebben hun eigen proxy-instellingen nodig. In deze sectie laat ik je zien hoe je proxyconfiguratie injecteert tijdens runtime en buildtime.

Omgevingsvariabelen op runtime

Containers erven de proxy-instellingen van je host niet.

Je moet proxyvariabelen expliciet doorgeven wanneer je containers start. Docker biedt meerdere manieren, afhankelijk van of je alle containers of alleen specifieke wilt configureren.

JSON-configuratie is de netjesste aanpak voor consistente proxy-instellingen - zoals eerder besproken. Ter herinnering, voeg dit toe aan je ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}Mogelijk gemaakt door

Docker injecteert deze variabelen automatisch in elke container die je start. Geen extra flags nodig.

CLI-flags geven je meer controle per container:

docker run \
  --env HTTP_PROXY=http://proxy.company.com:8080 \
  --env HTTPS_PROXY=http://proxy.company.com:8080 \
  --env NO_PROXY=localhost,127.0.0.1 \
  nginxMogelijk gemaakt door

Je kunt ook een volledig omgevingsbestand meegeven:

# proxy.env
HTTP_PROXY=http://proxy.company.com:8080
HTTPS_PROXY=http://proxy.company.com:8080
NO_PROXY=localhost,127.0.0.1

docker run --env-file proxy.env nginxMogelijk gemaakt door

Bestaande containers kunnen na het starten proxyvariabelen geïnjecteerd krijgen met docker exec:

docker exec -e HTTP_PROXY=http://proxy.company.com:8080 container_name curl google.comMogelijk gemaakt door

Deze aanpak werkt voor eenmalige commando’s, maar blijft niet behouden na herstarten van de container.

Proxyconfiguratie tijdens builds

Image-builds falen in proxyomgevingen, tenzij je proxy-instellingen expliciet doorgeeft.

Build-argumenten zijn de standaardmanier om proxyvariabelen tijdens builds te injecteren:

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  --tag myapp .Mogelijk gemaakt door

Je Dockerfile moet deze argumenten declareren om ze te gebruiken:

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Use proxy for package installation
RUN apt-get update && apt-get install -y curl

# Don't persist proxy in final imageMogelijk gemaakt door

Dockerfile-declaraties laten je standaard proxywaarden instellen:

ARG HTTP_PROXY=http://proxy.company.com:8080
ARG HTTPS_PROXY=http://proxy.company.com:8080

ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY

RUN pip install requestsMogelijk gemaakt door

De instructie ENV maakt proxyvariabelen beschikbaar voor alle volgende RUN-commando’s in je build.

Wees je ervan bewust dat beperkingen in BuildKit proxyproblemen kunnen veroorzaken met nieuwere Docker-versies. BuildKit cachet buildcontexten agressief, wat soms proxywijzigingen negeert.

Je kunt BuildKit dwingen proxy-updates te herkennen:

DOCKER_BUILDKIT=1 docker build \
  --no-cache \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --tag myapp .Mogelijk gemaakt door

Of BuildKit helemaal uitschakelen voor proxygevoelige builds:

DOCKER_BUILDKIT=0 docker build --build-arg HTTP_PROXY=$HTTP_PROXY --tag myapp .Mogelijk gemaakt door

Voor multi-stage builds is consistente proxyconfiguratie in alle stages nodig:

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Build stage
FROM python:3.13 AS builder
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY requirements.txt .
RUN pip install -r requirements.txt

# Runtime stage
FROM python:3.13-slim AS runtime
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY --from=builder /usr/local/lib/python*/site-packages /usr/local/lib/python*/site-packages
RUN apt-get update && apt-get install -y curl

# Clear proxy variables for final image
ENV HTTP_PROXY=
ENV HTTPS_PROXY=
ENV NO_PROXY=Mogelijk gemaakt door

Elke stage erft build-argumenten, maar geen omgevingsvariabelen uit vorige stages. Stel proxyvariabelen expliciet in elke stage in die ze nodig heeft.

Kortom: één keer configureren, overal injecteren.

Verwarrend verschil tussen ENTRYPOINT en CMD in je proxy-geconfigureerde containers? Bekijk de complete uitleg met praktische voorbeelden.

Pakketmanagers in containers voor gebruik met een proxy configureren

Docker’s proxy-instellingen vloeien niet automatisch door naar pakketmanagers binnen je containers. Je moet elke pakketmanager apart configureren om pakketten via je bedrijfsproxy te downloaden.

Pakketmanagers zoals apt-get, yum en apk maken directe HTTP-verbindingen met pakketrepositories. In beperkte netwerkomgevingen falen deze verbindingen tenzij de pakketmanager je proxyserver kent.

Standaard omgevingsvariabelen zijn niet genoeg. De meeste pakketmanagers hebben eigen configuratiebestanden die systeemwijde proxy-instellingen overschrijven.

Ubuntu/Debian: apt-get-configuratie

Maak een proxyconfiguratiebestand aan dat apt-get leest tijdens de installatie van pakketten.

Voeg dit toe aan je Dockerfile:

FROM python:3.13

# Configure apt proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf && \
    echo 'Acquire::https::Proxy "http://proxy.company.com:8080";' >> /etc/apt/apt.conf.d/proxy.conf

RUN apt-get update && apt-get install -y curl wgetMogelijk gemaakt door

Het bestand /etc/apt/apt.conf.d/proxy.conf vertelt apt-get dat alle pakketdownloads via je proxy moeten lopen. Het bestand blijft behouden over RUN-commando’s heen in je build.

Je kunt ook proxy-uitsluitingen instellen voor interne repositories:

RUN echo 'Acquire::http::Proxy::internal.company.com "DIRECT";' >> /etc/apt/apt.conf.d/proxy.confMogelijk gemaakt door

Alpine Linux: apk-configuratie

Alpine gebruikt de pakketmanager apk, die proxy-instellingen leest uit /etc/apk/repositories en omgevingsvariabelen.

FROM python:3.13-alpine

# Configure apk proxy
ENV HTTP_PROXY=http://proxy.company.com:8080
ENV HTTPS_PROXY=http://proxy.company.com:8080

RUN apk add --no-cache curl wgetMogelijk gemaakt door

Alpine’s apk respecteert standaard HTTP-proxyomgevingsvariabelen, dus aparte configuratiebestanden zijn niet nodig. Maar je kunt er wel een maken voor meer controle:

RUN echo 'http_proxy=http://proxy.company.com:8080' > /etc/environment && \
    echo 'https_proxy=http://proxy.company.com:8080' >> /etc/environmentMogelijk gemaakt door

CentOS/RHEL: yum-configuratie

CentOS- en RHEL-systemen gebruiken yum of dnf, die proxy-instellingen lezen uit /etc/yum.conf.

FROM centos:8

# Configure yum proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/yum.conf

RUN yum update -y && yum install -y curl wgetMogelijk gemaakt door

Voor nieuwere CentOS-versies die dnf gebruiken, gebruik je het volgende:

FROM centos:stream9

# Configure dnf proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/dnf/dnf.conf

RUN dnf update -y && dnf install -y curl wgetMogelijk gemaakt door

Je kunt ook specifieke domeinen uitsluiten van proxyrouting met deze opdracht:

RUN echo 'proxy_exclude=internal.company.com,localhost' >> /etc/yum.confMogelijk gemaakt door

Proxyfunctionaliteit testen

Controleer eerst of je pakketmanager via de proxy repositories kan bereiken.

Voeg testcommando’s toe aan je Dockerfile:

FROM python:3.13

# Configure proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf

# Test package manager connectivity
RUN apt-get update && \
    apt-get install -y --dry-run curl && \
    echo "Package manager proxy test passed"

# Install actual packages
RUN apt-get install -y curl python3-pipMogelijk gemaakt door

De vlag --dry-run test pakketresolutie zonder daadwerkelijk iets te installeren. Als dit lukt, werkt je proxyconfiguratie.

Je kunt ook testen met uitgebreide uitvoer om verbindingsproblemen te debuggen:

RUN apt-get -o Debug::Acquire::http=true updateMogelijk gemaakt door

Dit laat precies zien welke URL’s apt-get probeert te bereiken en of proxyverbindingen slagen.

Voor Alpine-testen gebruik je het volgende:

RUN apk update --verbose && \
    apk add --simulate curl && \
    echo "Alpine proxy test passed"Mogelijk gemaakt door

Samengevat: configureer elke pakketmanager afzonderlijk en je builds werken achter elke proxy.

Proxygerelateerde buildartefacten opruimen? Docker prune-commando’s maken ruimte vrij en houden je systeem schoon.

Geavanceerde proxy-implementaties

Eenvoudige HTTP-proxies helpen je op weg, maar productieomgevingen hebben meer controle nodig over registrytoegang en imagecaching. Zo zet je cachingproxies en registry-mirrors op voor betere prestaties en betrouwbaarheid.

Caching proxy-registries

Steeds dezelfde basisimages pullen verspilt bandbreedte en vertraagt builds.

Cachingproxies zitten tussen je Docker-clients en externe registries zoals Docker Hub. Ze slaan vaak geraadpleegde images lokaal op, zodat volgende pulls via je interne netwerk gaan in plaats van via internet.

De populairste keuze voor ondernemingen is Harbor:

# docker-compose.yml for Harbor
version: '3.8'
services:
  harbor-core:
    image: goharbor/harbor-core:v2.8.0
    environment:
      - CORE_SECRET=your-secret-key
      - JOBSERVICE_SECRET=your-job-secret
    ports:
      - "80:8080"
    volumes:
      - ./harbor.yml:/etc/core/app.confMogelijk gemaakt door

Je kunt Harbor configureren als proxycache door harbor.yml te bewerken:

# harbor.yml
hostname: harbor.company.com
http:
  port: 80

database:
  password: harbor-db-password

data_volume: /data

proxy_cache:
  - endpoint: https://registry-1.docker.io
    username: your-dockerhub-username
    password: your-dockerhub-tokenMogelijk gemaakt door

Heb je een eenvoudiger alternatief nodig voor basiscaching, gebruik dan Docker Registry Proxy. Zo doe je dat:

docker run -d \
  --name registry-proxy \
  -p 5000:5000 \
  -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
  -v registry-cache:/var/lib/registry \
  registry:2Mogelijk gemaakt door

Wijs daarna je Docker-clients naar de cachingproxy:

{
  "registry-mirrors": ["http://harbor.company.com"]
}Mogelijk gemaakt door

Dit zijn de voordelen van cachingproxies:

• Snellere image pulls na de eerste download
• Minder internetbandbreedtegebruik
• Betere buildbetrouwbaarheid als externe registries problemen hebben
• Gecentraliseerde toegangscontrole en imagescanning

Registry-mirrors en BuildKit

Registry-mirrors laten je imagepulls omleiden naar interne of geografisch dichterbij gelegen registries.

Met configuratie van één mirror gaan alle Docker Hub-verzoeken via één mirror:

{
  "registry-mirrors": ["https://mirror.company.com"],
  "insecure-registries": ["harbor.company.com:5000"]
}Mogelijk gemaakt door

Voeg dit toe aan /etc/docker/daemon.json en herstart Docker. Alle docker pull-commando’s proberen eerst de mirror; als die onbereikbaar is, wordt teruggevallen op Docker Hub.

Meerdere mirrors bieden redundantie:

{
  "registry-mirrors": [
    "https://mirror1.company.com",
    "https://mirror2.company.com",
    "https://registry-1.docker.io"
  ]
}Mogelijk gemaakt door

Docker probeert mirrors op volgorde totdat er één slaagt.

BuildKit-mirrorinstellingen vereisen aparte configuratie omdat BuildKit sommige daemoninstellingen omzeilt:

# buildkitd.toml
debug = true

[registry."docker.io"]
  mirrors = ["mirror.company.com"]

[registry."mirror.company.com"]
  http = true
  insecure = trueMogelijk gemaakt door

Je kunt BuildKit starten met de aangepaste configuratie:

buildkitd --config=/etc/buildkit/buildkitd.tomlMogelijk gemaakt door

Of de inline mirrorconfiguratie van BuildKit gebruiken:

docker buildx create \
  --name mybuilder \
  --config /etc/buildkit/buildkitd.toml \
  --useMogelijk gemaakt door

Test tot slot je mirroropzet door een image te bouwen die van Docker Hub pullt:

FROM python:3.13-slim
RUN pip install requestsMogelijk gemaakt door

docker build --progress=plain .Mogelijk gemaakt door

De vlag --progress=plain laat zien welke registry BuildKit daadwerkelijk benadert. Je zou je mirror-URL’s in de buildoutput moeten zien.

Dat was het!

Beheer je complexe proxyopstellingen met meerdere containers? Docker Compose vereenvoudigt networking en service discovery.

Beveiliging aanscherpen

Proxyconfiguraties openen nieuwe aanvalsmogelijkheden die zorgvuldige aandacht vereisen. Zo beperk je toegang tot de Docker-socket en bescherm je proxy-inloggegevens tegen blootstelling.

Docker-socketproxy

De Docker-socket direct blootstellen is een enorm beveiligingsrisico.

De Docker-socket (/var/run/docker.sock) geeft root-toegang tot je hele hostsysteem. Elk proces dat naar deze socket kan schrijven, kan containers starten met toegang tot het hostsysteem, privileges verhogen of volledig uit containerisolatie breken.

Direct mounten van de socket is gevaarlijk:

# DON'T DO THIS
docker run -v /var/run/docker.sock:/var/run/docker.sock myappMogelijk gemaakt door

Dit patroon komt voor in Docker-in-Docker-opzetten en CI/CD-pijplijnen, maar is een beveiligingsnachtmerrie. Een gecompromitteerde container kan de hele Docker-daemon besturen.

Socketproxyservices creëren een veiliger tussenlaag. Ze filteren Docker-API-calls en beperken wat containers daadwerkelijk kunnen doen.

Gebruik de docker-socket-proxy van Tecnativa:

# docker-compose.yml
version: '3.8'
services:
  docker-proxy:
    image: tecnativa/docker-socket-proxy
    environment:
      - CONTAINERS=1
      - IMAGES=1
      - NETWORKS=1
      - VOLUMES=1
      - BUILD=0
      - COMMIT=0
      - CONFIGS=0
      - SECRETS=0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "2375:2375"Mogelijk gemaakt door

De proxy stelt alleen specifieke Docker-API-endpoints bloot. Zet omgevingsvariabelen op 1 voor toegestane operaties en 0 voor geblokkeerde.

Je applicaties verbinden met de proxy in plaats van met de ruwe socket:

docker run --env DOCKER_HOST=tcp://docker-proxy:2375 myappMogelijk gemaakt door

Volg daarnaast deze strategieën voor het hardenen van de socket:

• Draai de socketproxy op een apart netwerksegment
• Gebruik TLS-authenticatie tussen clients en de proxy
• Monitor proxylogs van de socket op verdachte API-calls
• Roteer toegangsinloggegevens voor de proxy regelmatig

Inloggegevens beheren

Proxyauthenticatie in platte-tekst-URL’s duikt overal op - in logs, proceslijsten, en dumps van omgevingen.

Embed nooit inloggegevens in proxy-URL’s:

# SECURITY RISK - credentials visible in process list
export HTTP_PROXY=http://admin:[email protected]:8080Mogelijk gemaakt door

Iedereen met toegang tot ps aux of dumps van omgevingsvariabelen kan je proxypasswoord zien. Dit omvat applicatielogs, containerinspectie en systeemmonitoringtools.

Gebruik in plaats daarvan authenticatiebestanden:

# Create credentials file with restricted permissions
echo "admin:password123" > ~/.proxy-creds
chmod 600 ~/.proxy-creds

# Configure proxy without embedded credentials
export HTTP_PROXY=http://proxy.company.com:8080Mogelijk gemaakt door

Configureer je proxyserver om inloggegevens uit het bestand te lezen of gebruik externe authenticatiesystemen.

TLS-proxies versleutelen al het proxyverkeer, inclusief authenticatiehandshakes:

# HTTPS proxy encrypts credentials in transit
export HTTPS_PROXY=https://proxy.company.com:8443Mogelijk gemaakt door

Voorzie je proxyserver van de juiste TLS-certificaten - van een CA of self-signed certificaten die je naar clients distribueert.

Authenticatie op basis van certificaten elimineert wachtwoorden volledig:

# Client certificate authentication
export HTTPS_PROXY=https://proxy.company.com:8443
curl --cert client.crt --key client.key --cacert proxy-ca.crt https://example.comMogelijk gemaakt door

De proxy valideert clientcertificaten in plaats van gebruikersnaam/wachtwoord-combinaties. Certificaten kunnen individueel worden ingetrokken bij compromittering.

Kubernetes secret management houdt proxy-inloggegevens uit containerimages:

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded
  password: cGFzc3dvcmQxMjM=  # base64 encodedMogelijk gemaakt door

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: myapp
        env:
        - name: PROXY_USER
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: username
        - name: PROXY_PASS
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: passwordMogelijk gemaakt door

Secrets blijven versleuteld in rust en worden tijdens runtime geïnjecteerd zonder in imagelagen te verschijnen.

Beperk sockettoegang en versleutel je inloggegevens - je toekomstige zelf zal je dankbaar zijn.

Overweeg je alternatieven voor Docker voor je proxyopzet? Vergelijk Docker met Podman om het juiste containerization-tool te kiezen.

Veelvoorkomende problemen oplossen

Proxyproblemen uiten zich als timeouts, verbindingsfouten en mysterieuze buildfouten die buiten je netwerk prima werken. Hier is een systematische aanpak om de meest voorkomende Docker-proxyproblemen te diagnosticeren en te fixen.

Gestructureerde diagnostische aanpak

Begin bij de basis en werk laag voor laag omhoog in de stack.

Stap 1: Verifieer proxyconnectiviteit vanaf de host

Test of je proxyserver bereikbaar is:

curl -x http://proxy.company.com:8080 https://registry-1.docker.io/v2/Mogelijk gemaakt door

Als dit faalt, zit het probleem in je proxyconfiguratie of netwerkroutering. Neem contact op met je netwerkteam voordat je Docker gaat troubleshooten.

Stap 2: Controleer proxy-instellingen van de Docker-daemon

Controleer of de daemon je proxyconfiguratie leest:

docker info | grep -i proxyMogelijk gemaakt door

Je zou je proxy-URL’s moeten zien. Als ze ontbreken, controleer /etc/docker/daemon.json en herstart de Docker-service.

Stap 3: Test Docker-clientbewerkingen

Probeer een eenvoudige image te pullen:

docker pull hello-worldMogelijk gemaakt door

Lukt dit, dan werken je clientproxy-instellingen. Falen wijst op proxyproblemen op daemon-niveau.

Stap 4: Test connectiviteit op containerniveau

Start een container en test uitgaande verbindingen:

docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  python -c "import urllib.request; print(urllib.request.urlopen('https://pypi.org').getcode())"Mogelijk gemaakt door

Dit maakt duidelijk of het probleem bij Docker-bewerkingen of bij containernetwerken ligt.

Veelvoorkomende issues en oplossingen

Issue: docker pull geeft timeouts

Je ziet deze fout wanneer Docker externe registries niet kan bereiken:

Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io: no such hostMogelijk gemaakt door

Begin met het testen van basisconnectiviteit om te isoleren waar het probleem optreedt:

# Check if DNS resolution works through proxy
nslookup registry-1.docker.io

# Test direct registry access
curl -I https://registry-1.docker.io/v2/

# Verify daemon proxy configuration
sudo journalctl -u docker.service | grep -i proxyMogelijk gemaakt door

Los dit op door DNS- en proxyconfiguratieproblemen aan te pakken:

• Voeg DNS-servers toe aan /etc/docker/daemon.json

• Configureer NO_PROXY voor interne DNS-servers

• Controleer of de proxy de HTTPS CONNECT-methode ondersteunt

Issue: Pakketinstallatie faalt tijdens builds

Pakketmanagers binnen containers kunnen repositories niet bereiken en tonen fouten zoals:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/ReleaseMogelijk gemaakt door

Test de connectiviteit van de pakketmanager direct in een tijdelijke container:

# Test package manager connectivity in a running container
docker run -it --rm python:3.13 bash
apt-get update -o Debug::Acquire::http=trueMogelijk gemaakt door

De uitgebreide uitvoer laat precies zien waar de verbinding faalt.

Los dit op door pakketmanagers te configureren voor gebruik met je proxy:

• Configureer proxy-instellingen van de pakketmanager in de Dockerfile
• Geef proxy-buildargumenten door aan Docker build
• Controleer of de proxy domeinen van pakketrepositories blokkeert

Issue: BuildKit negeert proxy-instellingen

BuildKit gaat anders om met proxies dan de legacy builder, met fouten zoals:

failed to solve: failed to fetch remote https://github.com/user/repo.gitMogelijk gemaakt door

Test of het probleem BuildKit-specifiek is door je builderconfiguratie te controleren:

# Check BuildKit configuration
docker buildx inspect

# Build with legacy builder
DOCKER_BUILDKIT=0 docker build .Mogelijk gemaakt door

Als de legacy builder werkt, heb je een BuildKit-proxyconfiguratieprobleem.

Los BuildKit-proxyproblemen op met deze aanpakken:

• Configureer BuildKit-specifieke proxy-instellingen in buildkitd.toml
• Gebruik --build-arg om proxyvariabelen expliciet door te geven
• Schakel BuildKit uit voor proxygevoelige builds

Issue: Container kan geen externe services bereiken

Je applicatie in de container kan niet verbinden met externe API’s:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='api.example.com', port=443)Mogelijk gemaakt door

Debug dit door connectiviteit binnen de container te testen:

# Test from inside the container
docker exec container_name curl -v https://api.example.com

# Check container environment variables
docker exec container_name env | grep -i proxyMogelijk gemaakt door

Dit laat zien of de proxyvariabelen aanwezig zijn en of de verbindingspoging slaagt.

Los connectiviteitsproblemen in containers op door te zorgen voor de juiste proxyconfiguratie:

• Geef proxy-omgevingsvariabelen door bij runtime
• Configureer applicatiespecifieke proxy-instellingen
• Voeg de bestemming toe aan de NO_PROXY-lijst

Loganalyse en connectiviteitstesten

Docker-daemonlogs onthullen het volledige verhaal van proxymeldingen en -fouten.

Op systemd-systemen gebruik je journalctl om Docker-servicelogs realtime te volgen:

# SystemD systems
sudo journalctl -u docker.service -fMogelijk gemaakt door

Voor systemen met traditionele logbestanden bekijk je het Docker-log direct:

# Direct log file
sudo tail -f /var/log/docker.logMogelijk gemaakt door

Let op specifieke proxygerelateerde patronen in de logs. Connection refused duidt erop dat de proxyserver niet bereikbaar is. Authenticatiefouten verschijnen als "407 Proxy Authentication Required". Timeoutfouten wijzen op problemen met netwerkroutering of overbelasting van de proxyserver.

Testen op containerniveau met curl en wget geeft gedetailleerd inzicht in proxygedrag.

Test HTTP-verbindingen via je proxy om precies te zien wat er gebeurt tijdens de handshake:

# Test HTTP proxy
docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v http://httpbin.org/ipMogelijk gemaakt door

De uitgebreide uitvoer laat DNS-resolutie, opzetten van de proxyverbinding en de daadwerkelijke HTTP-verzoekstroom zien. Je ziet regels als "Connected to proxy.company.com" gevolgd door "CONNECT httpbin.org:80" als de proxytunnel werkt.

HTTPS-verbindingen vereisen dat de proxy de CONNECT-methode ondersteunt:

# Test HTTPS proxy
docker run --rm \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v https://httpbin.org/ipMogelijk gemaakt door

Let op "CONNECT httpbin.org:443 HTTP/1.1" in de uitvoer. Zie je "Method not allowed" of soortgelijke fouten, dan ondersteunt je proxy geen HTTPS-tunneling.

Test authenticatie door inloggegevens in de proxy-URL op te nemen:

# Test with authentication
docker run --rm \
  -e HTTPS_PROXY=http://user:[email protected]:8080 \
  python:3.13-slim \
  wget -O- https://httpbin.org/ipMogelijk gemaakt door

Authenticatiefouten verschijnen als "407 Proxy Authentication Required". Bij succes gaat de request direct door naar het doel.

Debuggen op netwerkniveau met tcpdump legt de echte pakketten vast tussen Docker en je proxyserver.

Draai tcpdump om al het verkeer naar je proxy te zien:

# Capture proxy traffic
sudo tcpdump -i any host proxy.company.com and port 8080Mogelijk gemaakt door

Deze ruwe pakketcapture toont verbindingspogingen, datatransfer en beëindiging van verbindingen. Let op het opzetten van TCP-verbindingen (SYN/ACK-pakketten) gevolgd door HTTP-verkeer. Timeouts verschijnen als herhaalde SYN-pakketten zonder respons.

DNS-resolutietesten nemen een veelvoorkomende bron van proxyverwarring weg.

Veel proxyproblemen zijn eigenlijk verkapte DNS-problemen. Test DNS-resolutie binnen containers:

# Test DNS inside containers  
docker run --rm python:3.13-slim nslookup registry-1.docker.ioMogelijk gemaakt door

Als dit faalt, kan de container helemaal geen domeinnamen resolven. Probeer een publieke DNS-server om het probleem te isoleren:

# Test with custom DNS
docker run --dns 8.8.8.8 --rm python:3.13-slim nslookup registry-1.docker.ioMogelijk gemaakt door

In bedrijfsomgevingen werken DNS-servers vaak alleen van binnen het netwerk. Je proxy moet mogelijk DNS-verzoeken afhandelen naast HTTP-verkeer, of je moet containers configureren met specifieke DNS-servers die via je proxy werken.

Werk systematisch elke laag af en je vindt de oorzaak.

Op zoek naar opties die misschien anders met proxies omgaan? We hebben een gids over Docker-alternatieven zodat je in 2025 het complete landschap van containerization-tools kunt verkennen.

Conclusie

Docker-proxyconfiguratie draait niet alleen om het downloaden van images - het gaat ook om het bouwen van betrouwbare, veilige gecontaineriseerde applicaties in bedrijfsomgevingen.

Ik heb laten zien hoe je proxy-instellingen configureert op vier verschillende lagen: clientbewerkingen, daemonprocessen, containerruntime en buildtime. Elke laag heeft een specifiek doel en vereist een eigen configuratieaanpak, van JSON-bestanden en omgevingsvariabelen tot pakketmanagerinstellingen en BuildKit-configuraties. Een gelaagde proxystrategie beschermt je tegen single points of failure.

Dieper duiken in Docker, containerization en security? Bekijk onze zorgvuldig samengestelde lijst met cursussen:

• Introduction to Docker
• Intermediate Docker
• Containerization and Virtualization Concepts
• Containerization and Virtualization with Docker and Kubernetes
• DevOps Concepts
• Introduction to Kubernetes