Docker Security
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
Gebruik Trickest om maklik te bou en werkvloei te outomatiseer wat deur die wêreld se mees gevorderde gemeenskapstoestelle aangedryf word. Kry Toegang Vandag:
Die Docker engine gebruik die Linux-kern se Namespaces en Cgroups om houers te isoleer, wat 'n basiese laag van sekuriteit bied. Addisionele beskerming word verskaf deur Capabilities dropping, Seccomp, en SELinux/AppArmor, wat houer-isolasie verbeter. 'n auth plugin kan verder gebruikersaksies beperk.
Die Docker engine kan plaaslik via 'n Unix-soket of op afstand met HTTP toegang verkry. Vir afstandstoegang is dit noodsaaklik om HTTPS en TLS te gebruik om vertroulikheid, integriteit en outentisering te verseker.
Die Docker engine luister standaard op die Unix-soket by unix:///var/run/docker.sock
. Op Ubuntu-stelsels word Docker se opstartopsies in /etc/default/docker
gedefinieer. Om afstandstoegang tot die Docker API en kliënt te aktiveer, stel die Docker-daemon bloot deur die volgende instellings by te voeg:
However, exposing the Docker daemon over HTTP is not recommended due to security concerns. It's advisable to secure connections using HTTPS. There are two main approaches to securing the connection:
Die kliënt verifieer die bediener se identiteit.
Beide die kliënt en bediener verifieer mekaar se identiteit.
Certificates are utilized to confirm a server's identity. For detailed examples of both methods, refer to this guide.
Container images can be stored in either private or public repositories. Docker offers several storage options for container images:
Docker Hub: 'n Publieke registrasiediens van Docker.
Docker Registry: 'n Oopbronprojek wat gebruikers toelaat om hul eie registrasie te huisves.
Docker Trusted Registry: Docker se kommersiële registrasie-aanbod, wat rolgebaseerde gebruikersverifikasie en integrasie met LDAP-gidsdienste bied.
Containers can have security vulnerabilities either because of the base image or because of the software installed on top of the base image. Docker is working on a project called Nautilus that does security scan of Containers and lists the vulnerabilities. Nautilus works by comparing the each Container image layer with vulnerability repository to identify security holes.
For more information read this.
docker scan
The docker scan
command allows you to scan existing Docker images using the image name or ID. For example, run the following command to scan the hello-world image:
Docker beeldondertekening verseker die sekuriteit en integriteit van beelde wat in houers gebruik word. Hier is 'n saamgeperste verduideliking:
Om Docker inhoudsvertroue te aktiveer, stel export DOCKER_CONTENT_TRUST=1
in. Hierdie funksie is standaard afgeskakel in Docker weergawe 1.10 en later.
Met hierdie funksie geaktiveer, kan slegs ondertekende beelde afgelaai word. Die aanvanklike beeldduw vereis die instelling van wagwoorde vir die wortel- en etiketteringssleutels, met Docker wat ook Yubikey ondersteun vir verbeterde sekuriteit. Meer besonderhede kan hier gevind word.
Pogings om 'n ongetekende beeld te trek met inhoudsvertroue geaktiveer, lei tot 'n "No trust data for latest" fout.
Vir beeldduwings na die eerste, vra Docker vir die wagwoord van die repository-sleutel om die beeld te onderteken.
Om jou private sleutels te rugsteun, gebruik die opdrag:
Wanneer jy Docker-gashere verander, is dit nodig om die wortel- en repository-sleutels te skuif om bedrywighede te handhaaf.
Gebruik Trickest om maklik te bou en werkvloei te automate wat deur die wêreld se mees gevorderde gemeenskapstools aangedryf word. Kry Toegang Vandag:
Namespaces is 'n kenmerk van die Linux-kern wat kernhulpbronne verdeel sodat een stel prosesse een stel hulpbronne sien terwyl 'n ander stel prosesse 'n verskillende stel hulpbronne sien. Die kenmerk werk deur die samelewing van die selfde namespace vir 'n stel hulpbronne en prosesse, maar daardie namespaces verwys na onderskeie hulpbronne. Hulpbronne kan in verskeie ruimtes bestaan.
Docker maak gebruik van die volgende Linux-kern Namespaces om Containere isolasie te bereik:
pid namespace
mount namespace
network namespace
ipc namespace
UTS namespace
Vir meer inligting oor die namespaces kyk na die volgende bladsy:
NamespacesDie Linux-kern kenmerk cgroups bied die vermoë om hulpbronne soos cpu, geheue, io, netwerkbandwydte onder 'n stel prosesse te beperk. Docker laat toe om Containere te skep met behulp van die cgroup kenmerk wat hulpbronbeheer vir die spesifieke Container toelaat. Hieronder is 'n Container geskep met gebruikersruimte geheue beperk tot 500m, kern geheue beperk tot 50m, cpu-aandeel tot 512, blkioweight tot 400. CPU-aandeel is 'n verhouding wat die Container se CPU-gebruik beheer. Dit het 'n standaardwaarde van 1024 en 'n reeks tussen 0 en 1024. As drie Containere dieselfde CPU-aandeel van 1024 het, kan elke Container tot 33% van die CPU neem in die geval van CPU-hulpbronkompetisie. blkio-weight is 'n verhouding wat die Container se IO beheer. Dit het 'n standaardwaarde van 500 en 'n reeks tussen 10 en 1000.
Om die cgroup van 'n houer te kry, kan jy doen:
For more information check:
CGroupsVermoëns laat finer control oor die vermoëns wat toegelaat kan word vir die root gebruiker. Docker gebruik die Linux-kern vermoënskenmerk om die operasies wat binne 'n Container gedoen kan word, te beperk ongeag die tipe gebruiker.
Wanneer 'n docker-container gedraai word, laat die proses sensitiewe vermoëns wat die proses kan gebruik om uit die isolasie te ontsnap, val. Dit probeer verseker dat die proses nie sensitiewe aksies kan uitvoer en ontsnap nie:
Linux CapabilitiesDit is 'n sekuriteitskenmerk wat Docker toelaat om die syscalls wat binne die container gebruik kan word, te beperk:
SeccompAppArmor is 'n kernverbetering om containers te beperk tot 'n beperkte stel hulpbronne met per-program profiele.:
AppArmorEtiketstelsel: SELinux ken 'n unieke etiket aan elke proses en lêersysteemobjek toe.
Beleidstoepassing: Dit handhaaf sekuriteitsbeleide wat definieer watter aksies 'n proses etiket op ander etikette binne die stelsel kan uitvoer.
Container Proses Etikette: Wanneer container enjinse container prosesse inisieer, word hulle gewoonlik 'n beperkte SELinux etiket, algemeen container_t
, toegeken.
Lêer Etikettering binne Containers: Lêers binne die container word gewoonlik as container_file_t
geëtiketteer.
Beleid Reëls: Die SELinux-beleid verseker hoofsaaklik dat prosesse met die container_t
etiket slegs kan interaksie hê (lees, skryf, uitvoer) met lêers wat as container_file_t
geëtiketteer is.
Hierdie meganisme verseker dat selfs al is 'n proses binne 'n container gecompromitteer, dit beperk is tot interaksie slegs met voorwerpe wat die ooreenstemmende etikette het, wat die potensiële skade van sulke kompromies aansienlik beperk.
SELinuxIn Docker speel 'n magtiging-plug-in 'n belangrike rol in sekuriteit deur te besluit of versoeke aan die Docker-daemon toegelaat of geblokkeer moet word. Hierdie besluit word geneem deur twee sleutelkontexte te ondersoek:
Verifikasiekonteks: Dit sluit omvattende inligting oor die gebruiker in, soos wie hulle is en hoe hulle hulself geverifieer het.
Opdragkonteks: Dit bestaan uit alle relevante data rakende die versoek wat gemaak word.
Hierdie kontekste help verseker dat slegs wettige versoeke van geverifieerde gebruikers verwerk word, wat die sekuriteit van Docker-operasies verbeter.
AuthZ& AuthN - Docker Access Authorization PluginAs jy nie behoorlik die hulpbronne wat 'n container kan gebruik, beperk nie, kan 'n gecompromitteerde container DoS die gasheer waar dit draai.
CPU DoS
Bandwidth DoS
In die volgende bladsy kan jy leer wat die --privileged
vlag impliseer:
As jy 'n houer bestuur waar 'n aanvaller daarin slaag om toegang te verkry as 'n lae voorreg gebruiker. As jy 'n verkeerd geconfigureerde suid binêre het, kan die aanvaller dit misbruik en voorregte binne die houer verhoog. Dit kan hom in staat stel om daaruit te ontsnap.
Om die houer met die no-new-privileges
opsie geaktiveer te bestuur, sal hierdie soort voorregverhoging voorkom.
For more --security-opt
options check: https://docs.docker.com/engine/reference/run/#security-configuration
Dit is van kardinale belang om te vermy om geheime direk in Docker-beelde in te sluit of om omgewing veranderlikes te gebruik, aangesien hierdie metodes jou sensitiewe inligting blootstel aan enigiemand met toegang tot die houer deur opdragte soos docker inspect
of exec
.
Docker volumes is 'n veiliger alternatief, wat aanbeveel word vir die toegang tot sensitiewe inligting. Hulle kan as 'n tydelike lêerstelsel in geheue gebruik word, wat die risiko's wat verband hou met docker inspect
en logging verminder. egter, wortelgebruikers en diegene met exec
toegang tot die houer mag steeds toegang tot die geheime hê.
Docker geheime bied 'n selfs veiliger metode vir die hantering van sensitiewe inligting. Vir voorbeelde wat geheime tydens die beeldbou fase benodig, bied BuildKit 'n doeltreffende oplossing met ondersteuning vir bou-tyd geheime, wat die bou spoed verbeter en addisionele funksies bied.
Om BuildKit te benut, kan dit op drie maniere geaktiveer word:
Deur 'n omgewing veranderlike: export DOCKER_BUILDKIT=1
Deur opdragte te prefix: DOCKER_BUILDKIT=1 docker build .
Deur dit standaard in die Docker-konfigurasie in te skakel: { "features": { "buildkit": true } }
, gevolg deur 'n Docker herstart.
BuildKit stel die gebruik van bou-tyd geheime met die --secret
opsie moontlik, wat verseker dat hierdie geheime nie in die beeldbou kas of die finale beeld ingesluit word nie, met 'n opdrag soos:
Vir geheime wat nodig is in 'n lopende houer, Docker Compose en Kubernetes bied robuuste oplossings. Docker Compose gebruik 'n secrets
sleutel in die diensdefinisie om geheime lêers te spesifiseer, soos getoon in 'n docker-compose.yml
voorbeeld:
This configuration allows for the use of secrets when starting services with Docker Compose.
In Kubernetes environments, secrets are natively supported and can be further managed with tools like Helm-Secrets. Kubernetes' Role Based Access Controls (RBAC) enhances secret management security, similar to Docker Enterprise.
gVisor is 'n toepassingskern, geskryf in Go, wat 'n substansiële gedeelte van die Linux-stelselsurface implementeer. Dit sluit 'n Open Container Initiative (OCI) runtime in genaamd runsc
wat 'n isolasiegrens tussen die toepassing en die gasheerkern bied. Die runsc
runtime integreer met Docker en Kubernetes, wat dit eenvoudig maak om sandboxed houers te laat loop.
Kata Containers is 'n oopbron-gemeenskap wat werk om 'n veilige houer runtime te bou met liggewig virtuele masjiene wat soos houers voel en presteer, maar sterker werklading-isolasie bied deur middel van hardewarevirtualisering tegnologie as 'n tweede verdedigingslaag.
Moet nie die --privileged
vlag gebruik of 'n Docker-soket binne die houer** monteer.** Die docker soket laat toe om houers te spawn, so dit is 'n maklike manier om volle beheer oor die gasheer te neem, byvoorbeeld deur 'n ander houer met die --privileged
vlag te laat loop.
Moet nie as root binne die houer loop nie. Gebruik 'n ander gebruiker en gebruikersnamespaces. Die root in die houer is dieselfde as op die gasheer tensy dit met gebruikersnamespaces herverdeel word. Dit is slegs liggies beperk deur, hoofsaaklik, Linux namespaces, vermoëns, en cgroups.
Laat alle vermoëns val (--cap-drop=all
) en stel slegs diegene wat benodig word in (--cap-add=...
). Baie werklading benodig nie enige vermoëns nie en om dit by te voeg verhoog die omvang van 'n potensiële aanval.
Gebruik die “no-new-privileges” sekuriteitsopsie om te voorkom dat prosesse meer voorregte verkry, byvoorbeeld deur suid-binaries.
Beperk hulpbronne beskikbaar aan die houer. Hulpbronlimiete kan die masjien beskerm teen ontkenning van diensaanvalle.
Gebruik amptelike docker beelde en vereis handtekeninge of bou jou eie gebaseer daarop. Moet nie terugdeure beelde erf of gebruik nie. Stoor ook root sleutels, wagwoord in 'n veilige plek. Docker het planne om sleutels met UCP te bestuur.
Herbou jou beelde gereeld om sekuriteitsopdaterings op die gasheer en beelde toe te pas.
Bestuur jou secrets verstandig sodat dit moeilik is vir die aanvaller om toegang daartoe te verkry.
As jy die docker daemon blootstel, gebruik HTTPS met kliënt- en bedienerverifikasie.
In jou Dockerfile, gee voorkeur aan COPY eerder as ADD. ADD ontleed outomaties gecomprimeerde lêers en kan lêers van URL's kopieer. COPY het nie hierdie vermoëns nie. Vermy ADD waar moontlik sodat jy nie kwesbaar is vir aanvalle deur middel van afgeleë URL's en Zip-lêers nie.
Het afsonderlike houers vir elke mikro-diens
Moet nie ssh binne die houer plaas nie, “docker exec” kan gebruik word om na die houer te ssh.
Het kleiner houer beelde
As jy binne 'n docker houer is of jy het toegang tot 'n gebruiker in die docker groep, kan jy probeer om te ontsnap en voorregte te verhoog:
Docker Breakout / Privilege EscalationAs jy toegang het tot die docker soket of toegang het tot 'n gebruiker in die docker groep maar jou aksies word beperk deur 'n docker auth plugin, kyk of jy dit kan omseil:
AuthZ& AuthN - Docker Access Authorization PluginDie hulpmiddel docker-bench-security is 'n skrif wat vir dosyne algemene beste praktyke rondom die ontplooiing van Docker-houers in produksie nagaan. Die toetse is almal geoutomatiseer, en is gebaseer op die CIS Docker Benchmark v1.3.1. Jy moet die hulpmiddel vanaf die gasheer wat docker draai of vanaf 'n houer met genoeg voorregte uitvoer. Vind uit hoe om dit in die README te loop: https://github.com/docker/docker-bench-security.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)