बाइनरी प्राधिकरण के साथ अपने GKE परिनियोजन को सुरक्षित करना

Google Kubernetes Engine और इसके अंतर्निहित कंटेनर मॉडल क्लाउड में होस्ट किए गए एप्लिकेशन के लिए बढ़ी हुई मापनीयता और प्रबंधनीयता प्रदान करते हैं। आपके सिस्टम की रनटाइम आवश्यकताओं के अनुसार लचीले सॉफ़्टवेयर एप्लिकेशन लॉन्च करना पहले से कहीं अधिक आसान है।

हालाँकि, यह लचीलापन नई चुनौतियों के साथ आ सकता है। ऐसे वातावरण में, यह सुनिश्चित करना मुश्किल हो सकता है कि प्रत्येक घटक आपके सर्वोत्तम प्रथाओं और मानकों के अनुसार निर्मित, परीक्षण और जारी किया गया है, और यह कि केवल अधिकृत सॉफ़्टवेयर आपके उत्पादन परिवेश में तैनात किया गया है।

बाइनरी ऑथराइजेशन (BinAuthz) एक ऐसी सेवा है जिसका उद्देश्य आपके Kubernetes Engine क्लस्टर में परिनियोजन-समय नीति प्रवर्तन को जोड़कर इनमें से कुछ चिंताओं को कम करना है। नीतियों को एक या एक से अधिक विश्वसनीय पक्षों (जिन्हें "प्रमाणक" कहा जाता है) की आवश्यकता के लिए लिखा जा सकता है ताकि किसी छवि को परिनियोजित करने से पहले उसे स्वीकृति मिल सके। मल्टी-स्टेज परिनियोजन पाइपलाइन के लिए जहां छवियां विकास से परीक्षण तक उत्पादन क्लस्टर तक प्रगति करती हैं, यह सुनिश्चित करने के लिए सत्यापनकर्ताओं का उपयोग किया जा सकता है कि सॉफ़्टवेयर के अगले चरण में जाने से पहले सभी आवश्यक प्रक्रियाएं पूरी हो गई हैं।

क्रिप्टोग्राफ़िक सार्वजनिक कुंजियों का उपयोग करके सत्यापनकर्ताओं की पहचान स्थापित और सत्यापित की जाती है, और संबंधित निजी कुंजियों का उपयोग करके सत्यापन को डिजिटल रूप से हस्ताक्षरित किया जाता है। यह सुनिश्चित करता है कि केवल विश्वसनीय पक्ष ही आपके वातावरण में सॉफ़्टवेयर के परिनियोजन को अधिकृत कर सकते हैं।

परिनियोजन के समय, बाइनरी प्राधिकरण आपके द्वारा परिभाषित नीति को यह जाँच कर लागू करता है कि कंटेनर छवि ने सभी आवश्यक बाधाओं को पार कर लिया है - जिसमें सभी आवश्यक सत्यापनकर्ताओं ने सत्यापित किया है कि छवि परिनियोजन के लिए तैयार है। यदि छवि गुजरती है, तो सेवा इसे तैनात करने की अनुमति देती है। अन्यथा, परिनियोजन अवरुद्ध है और छवि को तब तक परिनियोजित नहीं किया जा सकता जब तक कि वह अनुपालन न कर दे।

866ef6a5bf86cf5.png

आप क्या बनाएंगे

यह कोडलैब बताता है कि बाइनरी ऑथराइजेशन का उपयोग करके GKE क्लस्टर को कैसे सुरक्षित किया जाए। ऐसा करने के लिए, आप एक नीति बनाएंगे जिसका सभी परिनियोजनों के अनुरूप होना चाहिए, और इसे क्लस्टर पर लागू करना चाहिए। नीति निर्माण के भाग के रूप में, आप एक प्रमाणक बनाएंगे जो कंटेनर छवियों को सत्यापित कर सकता है, और इसका उपयोग कस्टम छवि पर हस्ताक्षर करने और चलाने के लिए कर सकता है।

इस कोडलैब का उद्देश्य बाइनरी ऑथराइजेशन के साथ कंटेनर साइनिंग कैसे काम करता है, इसका संक्षिप्त विवरण देना है। इस ज्ञान के साथ, आपको विश्वसनीय सत्यापनकर्ताओं द्वारा सुरक्षित एक सुरक्षित CI/CD पाइपलाइन बनाने में सहज महसूस करना चाहिए।

क्या आप करेंगे Lea आर.एन.

  • GKE क्लस्टर पर बाइनरी प्राधिकरण कैसे सक्षम करें
  • बाइनरी प्राधिकरण नीति को कैसे परिभाषित करें
  • एक अनुप्रमाणक कैसे बनाएं और इसे नीति के साथ कैसे संबद्ध करें
  • एक छवि पर एक प्रमाणक के रूप में हस्ताक्षर कैसे करें

आपको किस चीज़ की ज़रूरत पड़ेगी

चूंकि बाइनरी प्राधिकरण आपके बुनियादी ढांचे की सुरक्षा से संबंधित है, इसलिए इसे आम तौर पर अलग-अलग जिम्मेदारियों वाले कई लोगों द्वारा इंटरैक्ट किया जाएगा। इस कोडलैब में, आप उन सभी के रूप में अभिनय करेंगे। आरंभ करने से पहले, आपके द्वारा निभाई जाने वाली विभिन्न भूमिकाओं की व्याख्या करना महत्वपूर्ण है:

4426da76922fea23.png नियोक्ता :

  • यह व्यक्ति/प्रक्रिया क्लस्टर पर कोड चलाने के लिए जिम्मेदार है।
  • वे विशेष रूप से इस बात से चिंतित नहीं हैं कि सुरक्षा गारंटी कैसे लागू की जाती है, यह किसी और का काम है।
  • एक सॉफ्टवेयर इंजीनियर या एक स्वचालित पाइपलाइन हो सकता है।

5b1748abb8d8b699.png नीति निर्माता:

  • यह व्यक्ति संगठन की बड़ी तस्वीर सुरक्षा नीतियों के लिए जिम्मेदार है।
  • उनका काम नियमों की एक चेकलिस्ट बनाना है जिसे कंटेनर चलाने से पहले पारित किया जाना चाहिए।
  • वे विश्वास की श्रृंखला के प्रभारी हैं, जिसमें यह भी शामिल है कि किसी छवि को सुरक्षित माने जाने से पहले उसे किस पर हस्ताक्षर करना होगा।
  • वे आवश्यक रूप से नियमों के अनुरूप होने के तकनीकी विवरण से संबंधित नहीं हैं। वे शायद यह भी नहीं जानते होंगे कि एक कंटेनर में सॉफ्टवेयर क्या करता है। वे सिर्फ इस बारे में जानते हैं कि विश्वास स्थापित करने से पहले क्या करने की आवश्यकता है।

dca98cc118cd9139.png प्रमाणक

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

इनमें से प्रत्येक भूमिका आपके संगठन में एक व्यक्ति या लोगों की एक टीम का प्रतिनिधित्व कर सकती है। उत्पादन के माहौल में, इन भूमिकाओं को अलग-अलग Google क्लाउड प्लेटफ़ॉर्म (GCP) प्रोजेक्ट द्वारा प्रबंधित किया जाएगा, और क्लाउड IAM का उपयोग करके सीमित तरीके से संसाधनों तक पहुंच उनके बीच साझा की जाएगी।

a37eb2ed54b9c2eb.png

एक नियोक्ता के रूप में:

पर्यावरण की स्थापना

यह कोडलैब Google क्लाउड शेल का उपयोग करके आपके वेब ब्राउज़र के माध्यम से पूरा किया जा सकता है। नया सत्र खोलने के लिए निम्न लिंक पर क्लिक करें:

Google क्लाउड शेल खोलें

अपना प्रोजेक्ट सेट करना

हमारा पहला कदम उसGCP प्रोजेक्ट को सेट करना है जिसके तहत आप कोडलैब चलाना चाहते हैं। आप निम्न आदेश के साथ अपने खाते के अंतर्गत परियोजनाओं की एक सूची पा सकते हैं:

gcloud projects list

जब आप जानते हैं कि आप किस प्रोजेक्ट का उपयोग करना चाहते हैं, तो इसे एक पर्यावरण चर में सेट करें ताकि आप इसे बाकी कोडलैब के लिए उपयोग कर सकें:

PROJECT_ID=<YOUR_CHOSEN_PROJECT_ID>
gcloud config set project $PROJECT_ID

एक कार्यशील निर्देशिका बनाना

इस कोडलैब के दौरान, आप कुछ कॉन्फ़िगरेशन फ़ाइलें बना रहे होंगे। आप काम करने के लिए एक नई निर्देशिका बनाना चाह सकते हैं:

mkdir binauthz-codelab ; cd binauthz-codelab

एपीआई को सक्षम करना

बाइनरी प्राधिकरण का उपयोग करने से पहले, आपको अपने GCP प्रोजेक्ट पर प्रासंगिक API को सक्षम करना होगा:

//enable GKE to create and manage your cluster
gcloud services enable container.googleapis.com
//enable BinAuthz to manage a policy on the cluster
gcloud services enable binaryauthorization.googleapis.com
//enable KMS to manage cryptographic signing keys
gcloud services enable cloudkms.googleapis.com

वैकल्पिक रूप से, आप Google क्लाउड प्लेटफ़ॉर्म API लाइब्रेरी के माध्यम से अपने प्रोजेक्ट के लिए API सक्षम कर सकते हैं।

एक क्लस्टर स्थापित करना

इसके बाद, Kubernetes Engine के माध्यम से अपनेप्रोजेक्ट के लिए Kubernetes क्लस्टर सेट करें। निम्न आदेश बाइनरी प्राधिकरण सक्षम के साथ us-central1-a ज़ोन में "बिनाउथज़-कोडलैब" नामक एक नया क्लस्टर बनाएगा:

gcloud beta container clusters create \
    --enable-binauthz \
    --zone us-central1-a \
    binauthz-codelab

एक बार आपका क्लस्टर बन जाने के बाद, इसे अपने स्थानीय वातावरण में जोड़ें ताकि आप kubectl का उपयोग करके स्थानीय रूप से इसके साथ बातचीत कर kubectl :

gcloud container clusters get-credentials binauthz-codelab --zone us-central1-a

एक पॉड चल रहा है

अब, नए क्लस्टर में एक कंटेनर जोड़ें। निम्न आदेश एक साधारण Dockerfile बनाएगा जिसका आप उपयोग कर सकते हैं:

०४बीसीई४१९३०

यह कंटेनर "tail -f /dev/null" कमांड चलाने के अलावा कुछ नहीं करेगा, जिससे यह हमेशा के लिए प्रतीक्षा करेगा। यह विशेष रूप से उपयोगी कंटेनर नहीं है, लेकिन यह आपको अपने क्लस्टर की सुरक्षा का परीक्षण करने की अनुमति देगा।

कंटेनर बनाएं और उसे Google कंटेनर रजिस्ट्री (GCR) में धकेलें:

#set the GCR path you will use to host the container image
CONTAINER_PATH=us.gcr.io/${PROJECT_ID}/hello-world

#build container
docker build -t $CONTAINER_PATH ./

#push to GCR
gcloud auth configure-docker --quiet
docker push $CONTAINER_PATH

अब आप कंटेनर रजिस्ट्री वेब इंटरफ़ेस में नए बनाए गए कंटेनर को देखने में सक्षम होंगे।

8d95f439df5fedb2.png

अब, अपने क्लस्टर पर कंटेनर चलाएँ:

kubectl create deployment hello-world --image=$CONTAINER_PATH

यदि सब कुछ ठीक रहा, तो आपका कंटेनर चुपचाप चलना चाहिए।

आप चल रहे पॉड्स को सूचीबद्ध करके इसे सत्यापित कर सकते हैं:

kubectl get pods

a1724f9d39373710.png

नीति निर्माता के रूप में:

नीति जोड़ना Add

अब आपके पास एक क्लस्टर सेट अप है और अपना कोड चला रहा है। अब, क्लस्टर को पॉलिसी के साथ सुरक्षित करें।

नीति फ़ाइल बनाने के लिए पहला कदम है:

cat > ./policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: ALWAYS_DENY
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
EOM

यह नीति अपेक्षाकृत सरल है। GlobalPolicyEvaluationMode लाइन घोषित करती है कि यह नीति Google द्वारा परिभाषित वैश्विक नीति का विस्तार करती है। यह सभी आधिकारिक GKE कंटेनरों को डिफ़ॉल्ट रूप से चलने देता है। इसके अतिरिक्त, नीति एक डिफ़ॉल्ट प्रवेश नियम की घोषणा करती है जिसमें कहा गया है कि अन्य सभी पॉड को अस्वीकार कर दिया जाएगा । प्रवेश नियम में एक प्रवर्तन मोड लाइन शामिल है, जिसमें कहा गया है कि सभी पॉड जो इस नियम के अनुरूप नहीं हैं, उन्हें क्लस्टर पर चलने से रोक दिया जाना चाहिए।

अधिक जटिल नीतियों के निर्माण के निर्देशों के लिए, बाइनरी प्राधिकरण दस्तावेज़ीकरण देखें

सीई424657बीसीई1501एफ.पीएनजी

अब, आप पॉलिसी को अपने प्रोजेक्ट पर लागू कर सकते हैं:

gcloud container binauthz policy import policy.yaml

वैकल्पिक रूप से, नीति को Google क्लाउड कंसोल UI के माध्यम से भी सेट किया जा सकता है।

एक नियोक्ता के रूप में:

नीति का परीक्षण

आपकी नई नीति को किसी भी कस्टम कंटेनर छवियों को क्लस्टर पर परिनियोजित होने से रोकना चाहिए। आप अपने पॉड को हटाकर और इसे फिर से चलाने का प्रयास करके इसे सत्यापित कर सकते हैं:

kubectl delete deployment --all
kubectl delete event --all
kubectl create deployment hello-world --image=$CONTAINER_PATH

यदि आप पॉड्स के लिए क्लस्टर की जाँच करते हैं, तो आपको ध्यान देना चाहिए कि इस बार कोई पॉड नहीं चल रहा है:

kubectl get pods

पॉड्स को गायब होते देखने के लिए आपको दूसरी बार कमांड चलाने की आवश्यकता हो सकती है। Kubectl ने नीति के विरुद्ध पॉड की जाँच की, पाया कि यह नियमों के अनुरूप नहीं है, और इसे अस्वीकार कर दिया।

आप अस्वीकृति को कुबेक्टल ईवेंट के रूप में सूचीबद्ध देख सकते हैं:

kubectl get event --template \
  '{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}{{.message}}{{"\n"}}{{end}}'

d57096ad40933ded.png

बाइनरी ऑथराइजेशन में अटेस्टर्स को क्लाउड कंटेनर एनालिसिस एपीआई के शीर्ष पर लागू किया जाता है , इसलिए यह वर्णन करना महत्वपूर्ण है कि आगे बढ़ने से पहले यह कैसे काम करता है। कंटेनर विश्लेषण API को आपको विशिष्ट कंटेनर छवियों के साथ मेटाडेटा संबद्ध करने की अनुमति देने के लिए डिज़ाइन किया गया था।

उदाहरण के तौर पर, हार्टब्लिड भेद्यता को ट्रैक करने के लिए एक नोट बनाया जा सकता है। सुरक्षा विक्रेता तब भेद्यता के लिए कंटेनर छवियों का परीक्षण करने के लिए स्कैनर बनाएंगे, और प्रत्येक समझौता किए गए कंटेनर से जुड़े एक घटना का निर्माण करेंगे।

208aa5ebc53ff2b3.png

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

बाइनरी प्राधिकरण एपीआई "सत्यापनकर्ता" और "सत्यापन" की अवधारणाओं का उपयोग करता है, लेकिन इन्हें कंटेनर विश्लेषण एपीआई में संबंधित नोट्स और घटनाओं का उपयोग करके कार्यान्वित किया जाता है।

63a701bd0057ea17.png

वर्तमान में, क्लस्टर उन सभी छवियों पर कैच-ऑल रिजेक्शन करेगा जो आधिकारिक रिपॉजिटरी में नहीं हैं। आपका अगला कदम एक अनुप्रमाणक बनाना है, ताकि आप चुनिंदा रूप से विश्वसनीय कंटेनरों को अनुमति दे सकें।

एक प्रमाणक के रूप में:

एक कंटेनर विश्लेषण नोट बनाना

36f8f5ade32507f7.png

अपने नोट के लिए आवश्यक डेटा वाली JSON फ़ाइल बनाकर प्रारंभ करें। यह आदेश एक JSON फ़ाइल बनाएगा जिसमें आपका नोट स्थानीय रूप से होगा:

cat > ./create_note_request.json << EOM
{
  "attestation": {
    "hint": {
      "human_readable_name": "This note represents an attestation authority"
    }
  }
}
EOM

अब, कंटेनर विश्लेषण API का उपयोग करके अपने प्रोजेक्ट के लिए नोट सबमिट करें:

NOTE_ID=my-attestor-note

curl -vvv -X POST \
    -H "Content-Type: application/json"  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @./create_note_request.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

आप यह सत्यापित कर सकते हैं कि नोट को वापस लाकर सहेजा गया था:

curl -vvv  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

बाइनरी प्राधिकरण में एक प्रमाणक बनाना

af0267ab7f7757f9.png

आपका नोट अब कंटेनर विश्लेषण API में सहेजा गया है। अपने अनुप्रमाणक का उपयोग करने के लिए, आपको नोट को बाइनरी प्राधिकरण के साथ पंजीकृत करना होगा:

ATTESTOR_ID=my-binauthz-attestor

gcloud container binauthz attestors create $ATTESTOR_ID \
    --attestation-authority-note=$NOTE_ID \
    --attestation-authority-note-project=${PROJECT_ID}

सब कुछ अपेक्षित रूप से काम करने के लिए सत्यापित करने के लिए, पंजीकृत अधिकारियों की सूची का प्रिंट आउट लें:

gcloud container binauthz attestors list

9ef5aba66d1b06d3.png

आपको अपने नए अनुप्रमाणक को Google क्लाउड कंसोल UI के माध्यम से भी देखने में सक्षम होना चाहिए।

IAM भूमिका जोड़ना

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

बाइनरी प्राधिकरण में अनुमतियां स्वचालित रूप से जेनरेट किए गए सेवा खाते के माध्यम से नियंत्रित की जाती हैं

सबसे पहले, सेवा खाते का ईमेल पता ढूंढें:

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}"  --format="value(projectNumber)")
BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

अब, कंटेनर विश्लेषण IAM JSON अनुरोध बनाने के लिए इसका उपयोग करें:

cat > ./iam_request.json << EOM
{
  'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${BINAUTHZ_SA_EMAIL}'
        ]
      }
    ]
  }
}
EOM

आवश्यक IAM भूमिका प्रदान करने के लिए एक कर्ल अनुरोध करें:

curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @./iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

KMS कुंजी जोड़ना

1e3af7c177f7a311.png

इससे पहले कि आप इस अनुप्रमाणक का उपयोग कर सकें, आपके प्राधिकरण को एक क्रिप्टोग्राफ़िक कुंजी जोड़ी बनाने की आवश्यकता है जिसका उपयोग कंटेनर छवियों पर हस्ताक्षर करने के लिए किया जा सकता है। यह Google क्लाउड कुंजी प्रबंधन सेवा (KMS) के माध्यम से किया जा सकता है।

सबसे पहले, नई कुंजी का वर्णन करने के लिए कुछ पर्यावरण चर जोड़ें

००२३९३२१६०

चाबियों का एक सेट रखने के लिए एक कीरिंग बनाएं

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

अनुप्रमाणक के लिए एक नया असममित हस्ताक्षर कुंजी युग्म बनाएं

gcloud kms keys create "${KEY_NAME}" \
    --keyring="${KEYRING}" --location="${KEY_LOCATION}" \
    --purpose asymmetric-signing  --default-algorithm="ec-sign-p256-sha256"

आपको अपनी कुंजी Google क्लाउड कंसोल के KMS पृष्ठ पर दिखाई देनी चाहिए। अब, gcloud binauthz कमांड के माध्यम से कुंजी को अपने अधिकार से संबद्ध करें:

gcloud beta container binauthz attestors public-keys add  \
    --attestor="${ATTESTOR_ID}"  \
    --keyversion-project="${PROJECT_ID}"  \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

यदि आप अधिकारियों की सूची फिर से प्रिंट करते हैं, तो अब आपको एक पंजीकृत कुंजी दिखाई देगी:

gcloud container binauthz attestors list

c5ad61fbf14f1885.png

ध्यान दें कि प्रत्येक प्राधिकरण के लिए कई कुंजियाँ पंजीकृत की जा सकती हैं। यह उपयोगी हो सकता है यदि प्राधिकरण लोगों की एक टीम का प्रतिनिधित्व करता है। उदाहरण के लिए, QA टीम में कोई भी QA अनुप्रमाणक के रूप में कार्य कर सकता है, और अपनी व्यक्तिगत निजी कुंजी के साथ हस्ताक्षर कर सकता है।

एक प्रमाणक के रूप में:

अब जब आपके पास अपना अधिकार स्थापित हो गया है और जाने के लिए तैयार है, तो आप इसका उपयोग उस कंटेनर छवि पर हस्ताक्षर करने के लिए कर सकते हैं जिसे आपने पहले बनाया था।

एक हस्ताक्षरित सत्यापन बनाना

858d7e6feeb6f159.png

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

DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
    --format='get(image_summary.digest)')

अब, आप अपना सत्यापन बनाने के लिए gcloud का उपयोग कर सकते हैं। कमांड केवल उस कुंजी का विवरण लेता है जिसे आप हस्ताक्षर करने के लिए उपयोग करना चाहते हैं, और विशिष्ट कंटेनर छवि जिसे आप स्वीकृत करना चाहते हैं

gcloud beta container binauthz attestations sign-and-create  \
    --artifact-url="${CONTAINER_PATH}@${DIGEST}" \
    --attestor="${ATTESTOR_ID}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${PROJECT_ID}" \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

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

gcloud container binauthz attestations list \
   --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

अब, जब आप उस कंटेनर छवि को चलाने का प्रयास करते हैं, तो बाइनरी प्राधिकरण यह निर्धारित करने में सक्षम होगा कि इसे सत्यापनकर्ता द्वारा हस्ताक्षरित और सत्यापित किया गया था और इसे चलाना सुरक्षित है

अब जब आपने अपनी छवि को एक अनुप्रमाणक द्वारा सुरक्षित रूप से सत्यापित कर लिया है, तो चलिए इसे क्लस्टर पर चलाते हैं।

नीति निर्माता के रूप में:

नीति को अद्यतन करना

वर्तमान में, आपका क्लस्टर एक नियम के साथ एक नीति चला रहा है: आधिकारिक रिपॉजिटरी से कंटेनरों को अनुमति दें, और अन्य सभी को अस्वीकार करें।

अनुप्रमाणक द्वारा सत्यापित किसी भी चित्र को अनुमति देने के लिए इसे बदलें:

cat << EOF > updated_policy.yaml
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
      - projects/${PROJECT_ID}/attestors/${ATTESTOR_ID}
EOF

अब आपके पास डिस्क पर एक नई फ़ाइल होनी चाहिए, जिसे update_policy.yaml कहा जाता है। अब, सभी छवियों को अस्वीकार करने वाले डिफ़ॉल्ट नियम के बजाय, यह पहले सत्यापन के लिए आपके सत्यापनकर्ता की जांच करता है।

822240fc0b02408e.png

नई नीति को बाइनरी प्राधिकरण में अपलोड करें:

gcloud container binauthz policy import updated_policy.yaml

एक नियोक्ता के रूप में:

सत्यापित छवि चलाना

आगे आप हस्ताक्षरित छवि चलाएंगे और सत्यापित करेंगे कि पॉड निम्न आदेश के साथ चल रहा है:

kubectl create deployment hello-world-signed --image="${CONTAINER_PATH}@${DIGEST}"

अब जांचें कि आपका पॉड चल रहा है या नहीं:

kubectl get pods

आपको देखना चाहिए कि आपके पॉड ने नीति को पारित कर दिया है और क्लस्टर पर चल रहा है।

बधाई हो! अब आप नीति में अधिक जटिल नियम जोड़कर अपने क्लस्टर के लिए विशिष्ट सुरक्षा गारंटी दे सकते हैं।

क्लस्टर हटाएं:

gcloud container clusters delete binauthz-codelab --zone us-central1-a

कंटेनर छवि हटाएं:

gcloud container images delete $CONTAINER_PATH@$DIGEST --force-delete-tags

प्रमाणक हटाएं:

gcloud container binauthz attestors delete my-binauthz-attestor

कंटेनर विश्लेषण संसाधन हटाएं:

curl -vvv -X DELETE  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"