Docker brez roota: varnejši daemon lahko upočasni omrežje

Dockerjev način rootless nastavite tako, da uporabniku zagotovite podrejene UID in GID, namestite njegov daemon ter preverite, da odjemalec uporablja kontekst »rootless«. Po Dockerjevih navodilih za namestitev daemon in vsebniki tečejo v uporabniškem imenskem prostoru brez korenskih pravic; za preslikavo identitet sta potrebna programa newuidmap in newgidmap.

Pred selitvijo storitve preverite še pisanje v priklopljene mape, objavo vrat in omrežno prepustnost. Rootless omrežje lahko zaradi uporabniškega sklada zmanjša pretok, zato uspešen zagon vsebnika sam po sebi ne pove, kako bo storitev delovala pri običajni obremenitvi.

Pripravite podrejene identitete

Prijavite se kot uporabnik, ki bo poganjal Docker. Z ukazoma »command -v newuidmap« in »command -v newgidmap« preverite, ali sta programa nameščena; na številnih distribucijah ju vsebuje paket uidmap. Če manjkata, mora paket namestiti skrbnik oziroma uporabnik s pravico do upravljanja sistemskih paketov.

V datotekah /etc/subuid in /etc/subgid nato poiščite vnos za isti račun. Vsaka naj mu dodeli vsaj 65.536 podrejenih identitet. Zapis »uporabnik:231072:65536« je zgolj primer oblike vnosa: vsebuje ime, začetek razpona in njegovo dolžino. Razponov ne prepisujte iz primera; če vnosa manjkata, naj skrbnik dodeli ustrezna, neprekrivajoča se razpona. Ta priprava gostitelja lahko zahteva skrbniške pravice, čeprav bo daemon pozneje tekel brez njih.

Namestite daemon in preverite kontekst

1. V običajni prijavni seji ciljnega uporabnika zaženite »dockerd-rootless-setuptool.sh install«. Če ukaza ni, preverite namestitev paketa docker-ce-rootless-extras. Namestitveno orodje ob neizpolnjenih predpogojih izpiše napotke.
2. Stanje uporabniške storitve preverite z »systemctl --user status docker« in jo po potrebi zaženite z »systemctl --user start docker«. Za samodejni zagon omogočite še »systemctl --user enable docker«; skrbnik lahko z »loginctl enable-linger uporabnik« omogoči delovanje uporabniške storitve tudi brez aktivne prijave.
3. Zaženite »docker context use rootless« in »docker info«. Preverite, da odjemalec kaže kontekst »rootless«, strežniški del izpisa pa oznako »rootless« med varnostnimi možnostmi. Če je nastavljena spremenljivka DOCKER_HOST, preverite, na katero vtičnico usmerja ukaze.

Uporabite pravo prijavno sejo, ne zgolj prehoda z »sudo su«: v takšni seji uporabniško vodilo systemd lahko manjka in »systemctl --user« odpove. Če sistemski Dockerjev daemon med poskusom ostane vključen, namestitveno orodje zahteva možnost »--force«. Oba daemona nato obravnavajte ločeno: pred vsakim preizkusom potrdite kontekst in se izognite hkratni objavi istih gostiteljskih vrat.

Preizkusite preslikavo UID in pisanje v mapo

Za osnovni pregled zaženite »docker run --rm alpine id« in »docker run --rm alpine cat /proc/self/uid_map«. Prvi ukaz pokaže identiteto procesa v vsebniku, drugi njeno preslikavo. Nato v začasni mapi, v katero ciljni uporabnik sme pisati, zaženite »docker run --rm -v "$PWD":/mnt alpine touch /mnt/rootless-probe«. Na gostitelju z »stat -c '%u:%g' rootless-probe« preverite lastnika nastale datoteke.

Root v vsebniku je v običajni preslikavi povezan z uporabnikom gostitelja, drugi UID v vsebniku pa lahko ustreza podrejenemu UID. Zato poskus ponovite z identiteto, pod katero dejansko teče vaša aplikacija, in z mapo z enakimi dovoljenji, kot jih bo imela njena podatkovna mapa. Uspeh pri privzetem rootu v vsebniku še ne zagotavlja, da bo vanjo lahko pisal proces z drugim UID. Po preizkusu odstranite ustvarjeno datoteko.

Uskladite vrata, shrambo in omejitve virov

Najprej preizkusite neprivilegirana gostiteljska vrata, na primer z »docker run --rm -p 8080:80 nginx:alpine«, nato pa se povežite na vrata 8080. Dockerjev pregled omejitev rootless načina navaja, da gostiteljska vrata pod 1024 zahtevajo dodatno sistemsko nastavitev ali dodelitev ustrezne zmožnosti programu rootlesskit. Pri dostopu do storitve uporabite objavljena vrata: naslov IP vsebnika, ki ga pokaže »docker inspect«, je znotraj omrežnega imenskega prostora RootlessKit in praviloma ni neposredno dosegljiv z gostitelja.

Pri shrambi z »docker info« preverite dejanski gonilnik in podatkovni imenik novega daemona. Med podprtimi gonilniki so overlay2, fuse-overlayfs, btrfs in vfs, vendar je njihova uporabnost odvisna od jedra in nameščenih dodatkov. Podatkovni imenik Dockerja na NFS ni podprt. Slike in imenovani nosilci sistemskega daemona se v uporabniški daemon ne prenesejo samodejno, zato pred selitvijo pripravite ločeno pot za podatke in varnostno kopijo.

Omejitve CPU, pomnilnika in števila procesov zahtevajo cgroup v2 ter systemd. Če »docker info« kot »Cgroup Driver« kaže »none«, lahko rootless način ustrezne zastavice pri zagonu vsebnika prezre. Tudi kadar kaže »systemd«, preverite, kateri krmilniki so uporabniku dejansko dodeljeni. Če storitev potrebuje omrežje overlay ali privilegije nad viri gostitelja, njeno združljivost preverite pred prenosom podatkov.

Izmerite omrežje in pripravite povratek

Pri rootless načinu sta zmogljivost in vedenje omrežja odvisna od kombinacije omrežnega gonilnika in gonilnika vrat. Raziskovalca sta v raziskavi bypass4netns pri svoji preizkušeni konfiguraciji izmerila več kot 30-kratno prepustnost rootless vsebnikov z bypass4netns glede na rootless vsebnike brez te rešitve. To ni napoved pospeška pri običajni namestitvi Dockerja; pokaže pa, kako velik vpliv ima lahko omrežna pot. bypass4netns ni vključen kot običajna možnost RootlessKit.

Za odločitev o selitvi izmerite isto storitev na istem gostitelju s sistemskim in nato z uporabniškim daemonem. Ohranite enako sliko, velikost zahtevkov, število sočasnih povezav in oddaljenega odjemalca; ponovite meritve prepustnosti, zakasnitve in porabe CPU. Če odjemalci dostopajo prek objavljenih vrat, merite prav to pot. Preverite tudi, ali storitev potrebuje izvorni naslov odjemalca, saj ga posredovanje vrat v privzeti nastavitvi ne ohrani vedno.

Pred preklopom ohranite konfiguracijo in podatke stare storitve ter zabeležite njen kontekst, vrata in nosilce. Če preizkus pokaže težavo, ustavite rootless storitev, sprostite njena objavljena vrata in z »docker context use default« odjemalca vrnite na sistemski daemon. Staro storitev ponovno zaženite s prvotnimi podatki; sam preklop konteksta ne premakne podatkov med daemonoma.

Preberite tudi:

• Individualni naložbeni račun: 15 let brez izplačila odloča o oprostitvi
• Slovenska ali evropska znamka: napačen razred lahko izniči prihranek
• Delo od doma: dogovor ni dovolj brez obvestila in varnih pogojev