Docker-ի 2375 պորտը բաց է․ ինչպես փակել առանց հեռավար կառավարումը կորցնելու

Եթե Docker daemon-ը լսում է 2375 պորտով առանց TLS-ի, անհրաժեշտ հեռավար կառավարումը նախ տեղափոխեք SSH կամ փոխադարձ TLS կապի, ապա անջատեք հին TCP ունկնդրումը։ Docker-ի հեռավար հասանելիության կարգավորումը 2375-ը նշում է որպես առանց TLS-ի, իսկ 2376-ը՝ TLS-ով կապի լռելյայն պորտ։ SSH-ն հարմար է Docker CLI-ով սերվերը կառավարելու համար, իսկ փոխադարձ TLS-ը՝ անմիջական API կապ պահանջող ինտեգրման։

Անցման հերթականությունը կարևոր է. պարզեք՝ որ ծրագրերն են օգտվում հին հասցեից, ժամանակավորապես սահմանափակեք դրա ցանցային հասանելիությունը, գործարկեք պաշտպանված փոխարինումը և միայն հաջող փորձարկումից հետո հեռացրեք TCP կարգավորումը։ Docker-ի անվտանգության փաստաթուղթը պահանջում է ցանցով բացված API-ն պաշտպանել HTTPS-ով և վկայականներով ու խորհուրդ է տալիս այն հասանելի դարձնել միայն վստահելի ցանցից կամ VPN-ից։ Daemon-ի կառավարումը կարող է բարձր արտոնություններ տալ հոսթի նկատմամբ, ուստի միայն firewall-ի կանոնը բավարար պաշտպանություն չէ։

Գտեք ունկնդրումը և դրա կարգավորումը

Linux սերվերի վրա sudo ss -lntp | grep ':2375' հրամանով տեսեք՝ որ գործընթացն է լսում պորտով և որ հասցեին է կապված։ Բոլոր միջերեսներին կամ արտաքին հասցեին կապված ունկնդրումը հնարավոր է հասանելի լինի ցանցից՝ կախված firewall-ի կանոններից։ Տեղային հասցեն նույնպես արժե հեռացնել, եթե դրա կարիքը չկա. նույն հոսթի ծրագրերը կարող են դիմել տեղային API-ին։

Այնուհետև ստուգեք sudo systemctl cat docker.service հրամանի արդյունքը և /etc/docker/daemon.json ֆայլը։ Փնտրեք dockerd-ի -H tcp:// պարամետր կամ hosts ցանկի TCP գրառում։ Միաժամանակ systemd-ի գործարկման պարամետրերում և daemon.json-ում ունկնդրման հասցեներ սահմանելը կարող է խանգարել Docker-ի գործարկմանը, ուստի փոխեք ձեր տեղակայման մեջ կիրառվող կարգավորումը։ Փոփոխությունից առաջ գրանցեք նաև տեղային Unix socket-ի հասցեն, որպեսզի այն պատահմամբ չհեռացնեք։

Գտեք հին հասցեից օգտվող ավտոմատացումները, տեղակայման գործիքները և ադմինիստրատորների Docker CLI կարգավորումները։ Ստուգեք նրանց DOCKER_HOST արժեքներն ու Docker context-ները. միայն սերվերի կարգավորումը փոխելը կարող է խափանել հաճախորդներին, որոնք շարունակում են դիմել հին պորտին։ Եթե սերվերը կառավարում եք հեռվից, պահպանեք գործող SSH սեանսը և վերականգնման հասանելիությունը մինչև daemon-ի վերագործարկումն ու նոր կապի ստուգումը։

Ընտրեք հեռավար մուտքի անհրաժեշտ ձևը

Docker daemon-ի socket-ի պաշտպանության ուղեցույցը նկարագրում է և՛ SSH context-ը, և՛ սերվերի ու հաճախորդի վկայականներով TLS կապը։ Ընտրությունը որոշեք ըստ այն բանի, թե ով և ինչպես պետք է դիմի daemon-ին.

1. Եթե հեռավար մուտք պետք չէ, հեռացրեք TCP ունկնդրումը և պահպանեք տեղային Unix socket-ը։ Այդ դեպքում daemon API-ի համար ցանցային պորտ անհրաժեշտ չէ։
2. Եթե ադմինիստրատորը Docker CLI-ով կառավարում է սերվերը, օգտագործեք SSH։ CLI-ի հարցումները SSH-ով հասնում են հեռավար սերվերի Docker socket-ին, և առանձին TCP API պորտ բացելու կարիք չկա։
3. Եթե արտաքին համակարգերին անհրաժեշտ է անմիջական API կապ, կարգավորեք փոխադարձ TLS։ Daemon-ը պետք է ստուգի հաճախորդի վկայականը, հաճախորդը՝ սերվերինը, իսկ firewall-ը պետք է սահմանափակի, թե որ հասցեներից է այդ կապը հնարավոր։

CLI կառավարումը տեղափոխեք SSH

Նախ համոզվեք, որ նախատեսված SSH օգտատերը սերվերի վրա իրավունք ունի դիմելու Docker socket-ին։ Այդ իրավունքը տվեք միայն վստահելի հաշիվներին. SSH-ով միանալը չի նվազեցնում daemon-ին հասանելիություն ունեցող հաշվի արտոնությունները։ Հաճախորդի համակարգում ստեղծեք context, օրինակ՝ docker context create secure-remote --docker host=ssh://[email protected] հրամանով։ user-ը և host.example-ը փոխարինեք ձեր իրական օգտատիրոջով ու հասցեով։

Այնուհետև գործարկեք docker context use secure-remote և docker info։ Արդյունքում պետք է ստանաք հեռավար daemon-ի տվյալները, ոչ թե տեղային սերվերի։ Եթե առանձին context պետք չէ, տվյալ սեանսում կարող եք օգտագործել DOCKER_HOST=ssh://[email protected] հասցեն։ Context-ների միջև վերադառնալու համար կիրառեք docker context use default. ավտոմատացման համար նախապես ընտրեք այն եղանակը, որով տվյալ գործիքը սահմանում է իր Docker հասցեն։

Հաջող SSH փորձարկումից հետո հեռացրեք TCP հասցեն daemon-ի կիրառվող կարգավորումից՝ պահպանելով տեղային Unix socket-ը։ systemd-ի override-ը փոխելու դեպքում գործարկեք sudo systemctl daemon-reload, ապա sudo systemctl restart docker.service։ daemon.json-ը փոխելուց հետո նույնպես վերագործարկեք ծառայությունը։ Եթե daemon-ը չի մեկնարկում, ստուգեք ծառայության կարգավորումն ու գրանցամատյանը և վերականգնման հասանելիությամբ ուղղեք սխալը՝ մինչև գործող SSH սեանսը փակելը։

Ուղղակի API կապի համար կարգավորեք փոխադարձ TLS

Եթե ինտեգրումը պետք է անմիջապես դիմի TCP API-ին, պատրաստեք վստահելի CA, սերվերի բանալին ու վկայականը, ինչպես նաև լիազորված հաճախորդների բանալիներն ու վկայականները։ Սերվերի վկայականի subjectAltName դաշտում ներառեք այն DNS անունը կամ IP հասցեն, որով հաճախորդը միանալու է. սերվերի վկայականը նախատեսեք serverAuth-ի, հաճախորդինը՝ clientAuth-ի համար։ CA-ի մասնավոր բանալին պահեք առանձին, իսկ հաճախորդի բանալիների հասանելիությունը սահմանափակեք, քանի որ դրանց տիրապետողը կարող է կառավարել daemon-ը։

Daemon-ի կարգավորման մեջ միացրեք --tlsverify և սահմանեք --tlscacert, --tlscert ու --tlskey ֆայլերը։ TCP ունկնդրումը կապեք վստահելի ցանցային հասցեի 2376 պորտին՝ օգտագործելով կարգավորման ձեր գործող եղանակը։ Միայն --tls պարամետրը բավարար չէ. այդ ռեժիմը կարող է գաղտնագրել կապը՝ առանց հաճախորդի վկայականը ստուգելու։ Մի թողեք հին չպաշտպանված TCP հասցեն զուգահեռ աշխատել։

Հաճախորդի կողմից փորձեք docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://host.example:2376 version հրամանը՝ տեղադրելով ձեր իրական հասցեն ու ֆայլերի ուղիները։ Այնուհետև նույն վկայականներով կատարեք ինտեգրման իրական API գործողությունը։ Այս երկրորդ փորձը ցույց է տալիս, որ աշխատում է ոչ միայն TLS կապը, այլև ինտեգրման համար անհրաժեշտ հրամանը։

Սահմանափակեք ցանցը և հաստատեք արդյունքը

Firewall-ում փակեք հին չպաշտպանված պորտը արտաքին աղբյուրների համար։ SSH ընտրելու դեպքում թույլատրեք կառավարման համար անհրաժեշտ SSH մուտքը վստահելի հասցեներից։ TLS ընտրելու դեպքում API պորտը հասանելի դարձրեք միայն հայտնի հաճախորդների հասցեներին կամ VPN-ի ներսում։ Ցանցային սահմանափակումը լրացնում է նույնականացումը. վստահելի ցանցի ներսում գտնվող ծրագրերն էլ չպետք է կարողանան անանուն կառավարել daemon-ը։

Վերագործարկումից հետո սերվերի վրա կրկին գործարկեք sudo ss -lntp | grep ':2375' և համոզվեք, որ Docker daemon-ը հին պորտով այլևս չի լսում։ Հին հասցեին հասանելիություն ունեցած առանձին համակարգից ստուգեք, որ TCP կապը չի հաստատվում։ Դրանից հետո հաստատեք, որ SSH context-ով docker info կամ TLS վկայականներով docker version դեռ աշխատում է։ Եթե ընտրել եք փոխադարձ TLS, փորձեք նաև միանալ առանց հաճախորդի վկայականի. այդ կապը չպետք է API հասանելիություն տա։ Վերջում վերագործարկեք հին հասցեից օգտված ավտոմատացումները և ստուգեք նրանց իրական գործողությունը։

Կարդացեք նաև:

• Google Authenticator-ը նոր հեռախոս տեղափոխեք՝ առանց մուտքերը կորցնելու
• Docker Cloud Sandboxes-ը գործակալին ամպ է տանում՝ նոութբուքը կարող է քնել
• Չորս տարվա բաժնեմասը մեկ տարում չի վաստակվում․ ինչպես է աշխատում cliff-ը