Docker 09/18 को SSH के निर्माण और अग्रेषण का रहस्य

Dockerfile का उपयोग करना, निजी संसाधनों तक पहुंच बनाना हमेशा से मुश्किल रहा है। बस कोई अच्छा उपाय नहीं था। पर्यावरण चर का उपयोग करना या उपयोग के बाद केवल गुप्त फ़ाइलों को हटाना अच्छा नहीं है: वे छवि मेटाडेटा में बने रहते हैं। उपयोगकर्ता कभी-कभी चाल में चले गए: उन्होंने मल्टी-स्टेज असेंबली बनाई, हालांकि, अत्यधिक सावधानी बरती जानी थी ताकि अंतिम चरण में कोई गुप्त मूल्य न हों, और गुप्त फ़ाइलों को क्लिपिंग तक स्थानीय असेंबली कैश में संग्रहीत किया गया था।

डॉकर बिल्ड टीम में 18 सितंबर को कई अपडेट शामिल हैं। मुख्य विशेषता यह है कि सर्वर साइड कार्यान्वयन का एक नया संस्करण दिखाई दिया है, यह Moby BuildKit परियोजना के हिस्से के रूप में पेश किया गया है। BuildKit सर्वर एप्लिकेशन ने Dockerfile बिल्ड रहस्यों के लिए समर्थन सहित नई सुविधाओं का अधिग्रहण किया है।

राज का उपयोग करना

सबसे पहले, आपको BuildKit सर्वर साइड को सक्षम करने की आवश्यकता है। 18.09 संस्करण में BuildKit एक चयन फ़ंक्शन है जिसे DOCKER_BUILDKIT=1 पर्यावरण चर का उपयोग कर DOCKER_BUILDKIT=1 docker build करने से पहले सक्षम किया जा सकता है। अगले संस्करण में, यह BuildKit को डिफ़ॉल्ट रूप से सर्वर भाग बनाने की योजना है।

 export DOCKER_BUILDKIT=1 

बिल्ड सीक्रेट्स को लागू करना दो नई बिल्डकिट सुविधाओं पर आधारित है। उनमें से एक रजिस्ट्री में छवियों से लोड किए गए उपयोगकर्ता इंटरफ़ेस का उपयोग करने की क्षमता है; दूसरा Dockerfile के लिए RUN कमांड में बढ़ते बिंदुओं का उपयोग करने की क्षमता है। कार्यान्वयन समर्थन का उपयोग रहस्यों के समर्थन के साथ (मानक एक के बजाय), डॉकरीफाइल की पहली पंक्ति में सिंटैक्स निर्देश का उपयोग करके लिंकर छवि को परिभाषित करें - उस कंटेनर की छवि को इंगित करना जिसे आप उपयोग करना चाहते हैं। अब तक, बाहरी डॉकफाइल्स के स्थिर चैनल में रहस्य उपलब्ध नहीं हैं: आपको प्रयोगात्मक चैनल में संस्करणों में से एक की आवश्यकता होगी, उदाहरण के लिए, docker/dockerfile:experimental या docker/dockerfile/1.0.0-experimental ।

 # syntax=docker/dockerfile:1.0.0-experimental 

यदि आप, डॉकरफाइल के लेखक के रूप में जानते हैं कि डॉकफाइल में स्थापित RUN कमांड को एक गुप्त मूल्य की आवश्यकता होती है, तो इसके लिए --mount लेबल का उपयोग करें, जो यह संकेत देता है कि कमांड की जरूरत है और इसे कहां माउंट करना है। - --mount लेबल, docker run लिए --mount रूप में अल्पविराम से अलग संरचना को स्वीकार करता है।

 # syntax=docker/dockerfile:1.0.0-experimental FROM alpine RUN --mount=type=secret,id=mysite.key command-to-run 

यह लेबल इंगित करता है कि ऑपरेशन के दौरान कमांड के पास पथ /run/secrets/mysite.key साथ गुप्त फ़ाइल तक पहुंच है। रहस्य केवल माउंट लेबल के साथ टीम के लिए उपलब्ध है, और विधानसभा के अन्य हिस्सों के लिए नहीं। इस फ़ाइल में डेटा निर्दिष्ट पहचानकर्ता "mysite.key" पर आधारित गुप्त स्टोर से डाउनलोड किया गया है। डॉकर कमांड-लाइन इंटरफ़ेस वर्तमान में --secret टैग का उपयोग करके स्थानीय क्लाइंट फ़ाइलों के रहस्यों के प्रकटीकरण का समर्थन करता है।

 docker build --secret id=mysite.key,src=path/to/mysite.key . 

जैसा कि ऊपर वर्णित है, रहस्य डिफ़ॉल्ट रूप से /run/secrets में सेट होते हैं, हालांकि, आप "लक्ष्य" कुंजी का उपयोग करके किसी भी पथ को निर्दिष्ट कर सकते हैं। यदि "लक्ष्य" निर्दिष्ट है, लेकिन "आईडी" नहीं है, तो डिफ़ॉल्ट रूप से "आईडी" गंतव्य पथ का आधार नाम बन जाता है।

एक रहस्य तक सीमित होना आवश्यक नहीं है। आप विभिन्न पहचानकर्ताओं को इंगित करते हुए, उनमें से किसी भी संख्या का उपयोग कर सकते हैं।

यदि डॉकरफाइल के लेखक इंगित करते हैं कि आरयूएन निर्देश गुप्त का उपयोग कर सकता है, और असेंबली को लागू करने वाला उपयोगकर्ता इसे प्रदान नहीं करता है, तो रहस्य को अनदेखा किया जाता है और निर्दिष्ट पथ पर कोई फ़ाइल स्थापित नहीं की जाती है। यदि यह स्थिति अवांछनीय है, तो "आवश्यक" कुंजी का उपयोग करें: यह इंगित करेगा कि मान के बिना असेंबली विफल हो जाएगी।

 # syntax=docker/dockerfile:1.0.0-experimental FROM alpine RUN --mount=type=secret,id=mysite.key,required <command-to-run> 

कार्यान्वयन

अंतिम फ़ाइल या अंतिम कमांड में लीक को रोकने के लिए गुप्त फ़ाइल स्वचालित रूप से केवल एक अलग tmpfs फाइल सिस्टम में स्थापित है, और ताकि यह स्थानीय बिल्ड कैश में संग्रहीत न हो।

गुप्त मान भी बिल्ड कैश गणना से बाहर रखा गया है ताकि मेटाडेटा कैश का उपयोग नहीं किया जा सके।

SSH

सबसे अधिक बार, वे संभवतः एसएसएच प्रोटोकॉल के माध्यम से निजी रिपॉजिटरी तक पहुंचने का प्रयास करते हैं। हां, आप विधानसभा के लिए SSH निजी कुंजी को प्रकट करने के लिए गुप्त तत्वों का उपयोग कर सकते हैं, लेकिन एक बेहतर समाधान है। SSH प्रोटोकॉल सार्वजनिक कुंजी क्रिप्टोग्राफ़ी का उपयोग करता है, और इस डिज़ाइन के लिए धन्यवाद, आपको अपनी निजी कुंजी को किसी के सामने प्रकट करने की आवश्यकता नहीं है। उदाहरण के लिए, यदि आप SSH के साथ कई कंप्यूटरों का उपयोग करते हैं, तो आपको अपनी कुंजी स्थानांतरित करने की आवश्यकता नहीं है - बस ssh-A प्रोटोकॉल के माध्यम से एक कनेक्शन प्रदान करें।

हमने --ssh docker build में एक समान सुविधा जोड़ी है, जहाँ आप - --ssh एजेंट के मौजूदा कनेक्शन या लिंकर की कुंजी को निर्देशित करने के लिए --ssh लेबल का उपयोग कर सकते हैं। प्रमुख जानकारी प्रसारित करने के बजाय, डोकर लिंकर को बस यह बताता है कि यह उपलब्ध है। यदि लिंकर को एसएसएच के माध्यम से दूरस्थ सर्वर तक पहुंचने की आवश्यकता है, तो वह क्लाइंट से संपर्क करेगा और कनेक्शन के लिए आवश्यक विशिष्ट अनुरोध की पुष्टि के लिए पूछेगा। कुंजी स्वयं क्लाइंट प्रोग्राम को नहीं छोड़ती है, और उस प्रोग्राम को पूरा करने के बाद जिसे एक्सेस की आवश्यकता होती है, दूरस्थ कनेक्शन को फिर से कनेक्ट करने के लिए लिंकर से कोई डेटा नहीं रहता है।

SSH प्रोटोकॉल के माध्यम से फाइल ट्रांसफर तक पहुंच केवल Dockerfile में कमांड को दी जाती है जो सीधे type=ssh ब्लॉक को निर्दिष्ट करके SSH तक पहुंच का अनुरोध करता है। अन्य आदेशों में उपलब्ध SSH एजेंट का डेटा नहीं है।

यह भी SSH के एक और पहलू पर ध्यान देने योग्य है - TOFU सुरक्षा मॉडल का उपयोग। पहली बार SSH सर्वर से कनेक्ट होने पर, यह अज्ञात होस्ट के बारे में जानकारी का अनुरोध करेगा, क्योंकि इसके पास इस सर्वर के लिए स्थानीय रूप से एक सार्वजनिक कुंजी उपलब्ध नहीं है और तदनुसार, यह सत्यापित नहीं कर सकता है कि दूरस्थ पार्टी द्वारा प्रदान की गई सार्वजनिक कुंजी इस पते के लिए मान्य है या नहीं।

डॉकरफाइल के साथ संयोजन करते समय, इस अनुरोध की शुद्धता को सत्यापित नहीं किया जा सकता है, और तदनुसार, एसएसएच का उपयोग करने की कोशिश कर रहे कंटेनर में सर्वर की सार्वजनिक कुंजी पहले से मौजूद होनी चाहिए। इस सार्वजनिक कुंजी को प्राप्त करने के कई तरीके हैं। उदाहरण के लिए, आधार छवि इसे प्रदान करेगी, या आप इसे बिल्ड संदर्भ से कॉपी करेंगे। यदि आप एक सरल समाधान चाहते हैं, तो ssh–keyscan प्रोग्राम को विधानसभा के हिस्से के रूप में ssh–keyscan - यह मेजबान की वर्तमान सार्वजनिक कुंजी को लोड करेगा।

Dockerfile में RUN कमांड तक SSH की पहुंच का अनुरोध करने के लिए, आपको "ssh" प्रकार का एक ब्लॉक निर्दिष्ट करना होगा। फिर, प्रक्रिया के दौरान, एसएसएच एजेंट को केवल-पढ़ने के लिए एक सॉकेट स्थापित किया जाएगा। यह SSH_AUTH_SOCK परिवेश चर भी सेट करेगा ताकि SSH प्रोटोकॉल का उपयोग करने वाले प्रोग्राम स्वचालित रूप से इस सॉकेट का उपयोग करें।

 # syntax=docker/dockerfile:experimental FROM alpine # install ssh client and git RUN apk add --no-cache openssh-client git # download public key for github.com RUN mkdir -p -m 0600 ~/.ssh && ssh-keyscan github.com >> ~/.ssh/known_hosts # clone our private repository RUN --mount=type=ssh git clone git@github.com:myorg/myproject.git myproject 

डॉकर क्लाइंट पक्ष पर, इस विधानसभा के लिए SSH अग्रेषण की अनुमति देने के लिए --ssh लेबल --ssh उपयोग करें।

 docker build --ssh default . 

लेबल स्थानीय एसएसएच एजेंट या निजी कुंजी के सॉकेट स्थान को निर्धारित करने वाले प्रमुख मूल्यों की एक जोड़ी को स्वीकार करता है। यदि आप मान default=$SSH_AUTH_SOCK का उपयोग करना चाहते हैं, तो आप सॉकेट पथ को खाली छोड़ सकते हैं।

डॉकरफाइल ब्लॉक में, आप एक ही असेंबली में विभिन्न सर्वरों को अलग करने के लिए आईडी कुंजी का उपयोग कर सकते हैं। उदाहरण के लिए, डॉकफेराइल में विभिन्न रिपॉजिटरी तक पहुंच विभिन्न तैनाती कुंजियों के साथ प्राप्त की जा सकती है। इस स्थिति में, डॉकरफाइल में आप उपयोग करेंगे:

 … RUN --mount=type=ssh,id=projecta git clone projecta … RUN --mount=type=ssh,id=projectb git clone projectb … 

और --ssh projecta=./projecta.pem --ssh projectb=./projectb.pem build --ssh projecta=./projecta.pem --ssh projectb=./projectb.pem साथ क्लाइंट डेटा का विस्तार करें। ध्यान दें कि यदि आप वास्तविक कुंजी निर्दिष्ट करते हैं, तो भी केवल एजेंट कनेक्शन लिंकर को भेजा जाता है, न कि इन निजी कुंजी की वास्तविक सामग्री।

इसके साथ, डॉक 18.09 में निर्माण रहस्यों की नई सुविधाओं की समीक्षा पूरी हो गई है। मुझे उम्मीद है कि नई सुविधाएँ परियोजनाओं में डॉकफाइल की क्षमताओं का अधिक उपयोग करने में मदद करेंगी और असेंबली लाइन के लिए उच्च स्तर की सुरक्षा प्रदान करेंगी।