Een speciaal Docker-netwerk instellen voor backends achter een reverse proxy

Verbind de reverse proxy en elke HTTP-backend met één gedeeld door gebruikers gedefinieerd netwerk; houd databases op private app-netwerken.

Elke backendpoort publiceren op de NAS-host is niet nodig wanneer de proxy Compose-servicenamen kan oplossen op een door gebruikers gedefinieerde bridge. Met een patroon met twee netwerken krijgt de proxy een gecontroleerd pad naar webbackends, terwijl databases alleen bereikbaar blijven voor hun applicaties. Definieer netwerkeigenaarschap, vermijd dubbelzinnige aliassen, bepaal welke services uitgaande toegang nodig hebben en controleer of hostpoorten gesloten blijven.

Teken de beoogde bereikbaarheidstabel

Noteer elke verbinding: client naar proxy, proxy naar backend, backend naar database, backend naar externe API's en beheerder naar onderhoudseindpunten. Markeer protocol, poort, DNS-naam en of het pad de host doorkruist.

Normaal gesproken hoort alleen de reverse proxy poorten 80 en 443 te publiceren. Backends stellen hun applicatiepoort beschikbaar op het Docker-netwerk zonder een ports-toewijzing naar de host. Databases worden alleen verbonden met het app-private netwerk, tenzij een expliciet beheerpad vereist is.

Kies stabiele, unieke servicenamen of netwerkaliassen. Docker-DNS lost services op op gedeelde, door gebruikers gedefinieerde netwerken, maar generieke aliassen zoals web kunnen botsen wanneer meerdere Compose-projecten verbinding maken met hetzelfde proxynetwerk.

Maak een gedeeld proxynetwerk en een privaat app-netwerk

Maak het proxynetwerk één keer aan, markeer het in elk applicatieproject als extern en verbind de proxy plus de beoogde backend ermee. Zo blijft de netwerkidentiteit stabiel wanneer een afzonderlijk Compose-project opnieuw wordt aangemaakt.

Definieer voor elke app een afzonderlijk standaard- of benoemd privaat netwerk en verbind de backend en database ermee. De backend wordt de gecontroleerde brug tussen proxyverkeer en private status; de proxy mag geen verbinding maken met het databasenetwerk.

De documentatie over Compose-netwerkdefinities beschrijft externe netwerken en het verbinden van services in Compose. Behandel een extern netwerk als een levenscyclus die buiten de app-stack wordt beheerd: de implementatie moet controleren of het bestaat, in plaats van ervan uit te gaan dat Compose het zal aanmaken of verwijderen.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Verwijder onnodige hostpoorten en controleer uitgaand verkeer

Verwijder de publicatie van backendpoorten naar de host nadat de proxyrouting werkt. De expose-declaratie kan de containerpoort documenteren, maar is geen firewall; het netwerklidmaatschap bepaalt welke containers verbinding kunnen maken.

Gebruik internal: true alleen voor netwerken waarvan de leden daadwerkelijk geen externe route nodig hebben. Backends die identityproviders, webhooks, pakketservices of externe API's aanroepen, kunnen falen op een netwerk dat alleen intern is. Gebruik een tweede netwerk met uitgaande toegang wanneer het applicatieontwerp dat vereist.

Beveilig de Docker-socket die wordt gebruikt voor automatische proxydetectie. Een alleen-lezen bind mount beperkt onbedoelde schrijfacties, maar maakt de socket niet ongevaarlijk; een beperkte socketproxy of statische configuratie biedt een kleiner aanvalsoppervlak.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer servicedns, poortblootstelling en isolatie

Los vanuit de proxycontainer de backend-servicenaam op en vraag het health-endpoint op via de containerpoort. Controleer vanuit een niet-gerelateerde container of de naam of verbinding niet beschikbaar is, tenzij die container opzettelijk met het proxynetwerk is verbonden.

Scan de NAS-host vanaf een ander LAN-apparaat en controleer of alleen de proxypoorten openstaan. Test vervolgens TLS, doorgestuurde headers, WebSocket-upgrades, grote uploads en omleidingen van de applicatie via de openbare hostnaam. De servicekaart van de homeserver moet het proxynetwerk als onderdeel van de servicekaart van de homeserver vastleggen.

Rol terug door de vorige poorttoewijzing alleen voor diagnose te herstellen, niet als permanente verborgen afhankelijkheid. Stop als de proxy directe toegang tot de database nodig heeft, aliassen naar het verkeerde project verwijzen of het verwijderen van een hostpoort een niet-gedocumenteerde integratie verbreekt.

Veelgestelde vragen 

Is een extern Docker-netwerk automatisch veiliger?

Nee. Extern beschrijft het levenscyclusbeheer, niet de beveiliging. Elke verbonden container kan over het algemeen communiceren volgens het gedrag van de netwerkdriver en de firewall van de host.

Moeten backendservices nog steeds expose declareren?

Voor connectiviteit op een door gebruikers gedefinieerd netwerk is het optioneel, maar het kan de bedoelde containerpoort documenteren. De poort wordt er niet door naar de host gepubliceerd.

Kan het proxynetwerk als intern worden gemarkeerd?

Alleen als het proxy- en routeringsontwerp nog steeds over de vereiste inkomende en uitgaande paden beschikt. Een intern netwerk blokkeert normale externe connectiviteit voor verbonden containers en kan certificaat- of identiteitsstromen verstoren.

Waarom servicenamen gebruiken in plaats van container-IP-adressen?

Containeradressen kunnen na het opnieuw aanmaken veranderen. Docker-servicedetectie biedt een stabiele naam binnen het gedeelde netwerk, waardoor de proxyconfiguratie duurzamer wordt.

Herstel de opgeslagen basisconfiguratie, pas de goedgekeurde configuratie één keer toe, herhaal de oorspronkelijke productieachtige werklast, controleer het beloofde succes-signaal en voer daarna de gedocumenteerde terugdraaiing uit. Sluit de wijziging pas af wanneer logboeken, timing, machtigingen, capaciteit en herstelde uitvoer allemaal aan de acceptatiecriteria voldoen.