बाइनरी पुष्टि वाले गेटिंग डिप्लॉयमेंट

1. परिचय

बाइनरी ऑथराइज़ेशन, डिप्लॉयमेंट के समय सुरक्षा से जुड़ा कंट्रोल है. यह पक्का करता है कि Google Kubernetes Engine (GKE) या Cloud Run पर सिर्फ़ भरोसेमंद कंटेनर इमेज डिप्लॉय की जाएं. बाइनरी ऑथराइज़ेशन की मदद से, डेवलपमेंट प्रोसेस के दौरान भरोसेमंद संस्थाओं से इमेज पर हस्ताक्षर करने के लिए कहा जा सकता है. इसके बाद, डिप्लॉय करते समय हस्ताक्षर की पुष्टि करने की सुविधा लागू की जा सकती है. पुष्टि करने की सुविधा लागू करके, अपने कंटेनर एनवायरमेंट पर ज़्यादा कंट्रोल पाया जा सकता है. इसके लिए, यह पक्का करें कि सिर्फ़ पुष्टि की गई इमेज को बिल्ड और रिलीज़ करने की प्रोसेस में इंटिग्रेट किया गया हो.

इस डायग्राम में, Binary Authorization/Cloud Build सेटअप में मौजूद कॉम्पोनेंट दिखाए गए हैं:

Cloud Build की बाइनरी अनुमति की पुष्टि करने वाली पाइपलाइन. **पहली इमेज.**Cloud Build पाइपलाइन, जो बाइनरी ऑथराइज़ेशन अटेस्टेशन बनाती है.

इस पाइपलाइन में:

कंटेनर इमेज बनाने के लिए कोड को सोर्स रिपॉज़िटरी में पुश किया जाता है. जैसे, Cloud Source Repositories.
कंटिन्यूअस इंटिग्रेशन (सीआई) टूल, Cloud Build कंटेनर बनाता है और उसकी जांच करता है.
यह बिल्ड, कंटेनर इमेज को Container Registry या किसी ऐसी अन्य रजिस्ट्री में पुश करता है जो आपकी बनाई गई इमेज को सेव करती है.
Cloud Key Management Service, क्रिप्टोग्राफ़िक कुंजी के जोड़े के लिए कुंजी मैनेजमेंट की सुविधा देती है. यह कंटेनर इमेज पर हस्ताक्षर करती है. इसके बाद, जनरेट हुए हस्ताक्षर को नई पुष्टि में सेव किया जाता है.
डप्लॉय करने के समय, पुष्टि करने वाला व्यक्ति, पासकोड पेयर से मिले सार्वजनिक पासकोड का इस्तेमाल करके पुष्टि करता है. बाइनरी ऑथराइज़ेशन, नीति लागू करता है. इसके लिए, कंटेनर इमेज को डिप्लॉय करने के लिए, हस्ताक्षर किए गए अटेस्टेशन की ज़रूरत होती है.

इस लैब में, डिप्लॉय किए गए आर्टफ़ैक्ट को सुरक्षित करने के लिए टूल और तकनीकों पर फ़ोकस किया जाएगा. यह लैब, आर्टफ़ैक्ट (कंटेनर) बनाने के बाद उन पर फ़ोकस करती है. हालांकि, इन्हें किसी खास एनवायरमेंट में डिप्लॉय नहीं किया गया है.

आपको क्या सीखने को मिलेगा

इमेज पर हस्ताक्षर करना
ऐडमिशन कंट्रोल की नीतियां
स्कैन की गई इमेज पर हस्ताक्षर करना
हस्ताक्षर की गई इमेज को अनुमति देना
बिना हस्ताक्षर वाली इमेज ब्लॉक की गई हैं

2. सेटअप और ज़रूरी शर्तें

अपनी स्पीड से एनवायरमेंट सेट अप करना

Google Cloud Console में साइन इन करें और नया प्रोजेक्ट बनाएं या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल करें. अगर आपके पास पहले से कोई Gmail या Google Workspace खाता नहीं है, तो आपको एक खाता बनाना होगा.

प्रोजेक्ट का नाम, इस प्रोजेक्ट में हिस्सा लेने वाले लोगों के लिए डिसप्ले नेम होता है. यह एक वर्ण स्ट्रिंग है, जिसका इस्तेमाल Google API नहीं करते. इसे कभी भी अपडेट किया जा सकता है.
प्रोजेक्ट आईडी, सभी Google Cloud प्रोजेक्ट के लिए यूनीक होता है. साथ ही, इसे बदला नहीं जा सकता. Cloud Console, यूनीक स्ट्रिंग अपने-आप जनरेट करता है. आम तौर पर, आपको इससे कोई फ़र्क़ नहीं पड़ता. ज़्यादातर कोडलैब में, आपको प्रोजेक्ट आईडी का रेफ़रंस देना होगा. आम तौर पर, इसे PROJECT_ID के तौर पर पहचाना जाता है. अगर आपको जनरेट किया गया आईडी पसंद नहीं है, तो कोई दूसरा रैंडम आईडी जनरेट किया जा सकता है. इसके अलावा, आपके पास अपना नाम आज़माने का विकल्प भी है. इससे आपको पता चलेगा कि वह नाम उपलब्ध है या नहीं. इस चरण के बाद, इसे बदला नहीं जा सकता. यह प्रोजेक्ट की अवधि तक बना रहेगा.
आपकी जानकारी के लिए बता दें कि एक तीसरी वैल्यू भी होती है, जिसे प्रोजेक्ट नंबर कहते हैं. इसका इस्तेमाल कुछ एपीआई करते हैं. इन तीनों वैल्यू के बारे में ज़्यादा जानने के लिए, दस्तावेज़ देखें.

इसके बाद, आपको Cloud Console में बिलिंग चालू करनी होगी, ताकि Cloud संसाधनों/एपीआई का इस्तेमाल किया जा सके. इस कोडलैब को पूरा करने में ज़्यादा खर्च नहीं आएगा. इस ट्यूटोरियल के बाद बिलिंग से बचने के लिए, बनाए गए संसाधनों को बंद किया जा सकता है. इसके लिए, बनाए गए संसाधनों को मिटाएं या पूरे प्रोजेक्ट को मिटाएं. Google Cloud के नए उपयोगकर्ताओं को, मुफ़्त में आज़माने के लिए 300 डॉलर का क्रेडिट मिलता है.

एनवायरमेंट सेटअप करना

Cloud Shell में, अपने प्रोजेक्ट का प्रोजेक्ट आईडी और प्रोजेक्ट नंबर सेट करें. इन्हें PROJECT_ID और PROJECT_ID वैरिएबल के तौर पर सेव करें.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

सेवाएं चालू करना

सभी ज़रूरी सेवाएं चालू करें:

gcloud services enable \
  cloudkms.googleapis.com \
  cloudbuild.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  artifactregistry.googleapis.com \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com \
  binaryauthorization.googleapis.com

Artifact Registry में डेटा स्टोर करने की जगह बनाना

इस लैब में, इमेज को सेव और स्कैन करने के लिए Artifact Registry का इस्तेमाल किया जाएगा. नीचे दिए गए कमांड का इस्तेमाल करके, रिपॉज़िटरी बनाएं.

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

Artifact Registry को ऐक्सेस करते समय, अपने gcloud क्रेडेंशियल का इस्तेमाल करने के लिए Docker को कॉन्फ़िगर करें.

gcloud auth configure-docker us-central1-docker.pkg.dev

वर्क डायरेक्ट्री बनाना और उसे बदलना

mkdir vuln-scan && cd vuln-scan

कोई सैंपल इमेज तय करना

यहां दिए गए कॉन्टेंट के साथ Dockerfile नाम की फ़ाइल बनाएं.

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

main.py नाम की फ़ाइल बनाएं और उसमें यह कॉन्टेंट शामिल करें

cat > ./main.py << EOF
import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

इमेज को एआर में बनाना और पुश करना

Cloud Build का इस्तेमाल करके, अपने कंटेनर को बनाएं और उसे Artifact Registry में अपने-आप पुश करें.

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

3. इमेज पर हस्ताक्षर करना

प्रमाणित करने वाला व्यक्ति कौन होता है

प्रमाणित करने वाला

यह व्यक्ति/प्रोसेस, सिस्टम के भरोसेमंद होने की चेन में एक लिंक के लिए ज़िम्मेदार है.
उनके पास क्रिप्टोग्राफ़िक कुंजी होती है. अगर कोई इमेज उनकी मंज़ूरी की प्रोसेस को पूरा करती है, तो वे उस पर हस्ताक्षर करते हैं.
नीति बनाने वाला व्यक्ति, नीति को सामान्य तौर पर तय करता है. वहीं, पुष्टि करने वाले व्यक्ति की ज़िम्मेदारी होती है कि वह नीति के किसी पहलू को लागू करे.
यह कोई असली व्यक्ति हो सकता है, जैसे कि क्वालिटी कंट्रोल टेस्टर या मैनेजर. यह सीआई सिस्टम में कोई बॉट भी हो सकता है.
सिस्टम की सुरक्षा, उनकी विश्वसनीयता पर निर्भर करती है. इसलिए, यह ज़रूरी है कि उनकी निजी कुंजियों को सुरक्षित रखा जाए.

इनमें से हर भूमिका को कोई व्यक्ति या आपके संगठन के लोगों की टीम निभा सकती है. प्रोडक्शन एनवायरमेंट में, इन भूमिकाओं को अलग-अलग Google Cloud Platform (GCP) प्रोजेक्ट से मैनेज किया जाता है. साथ ही, संसाधनों का ऐक्सेस इनके बीच सीमित तौर पर शेयर किया जाता है. इसके लिए, Cloud IAM का इस्तेमाल किया जाता है.

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

उदाहरण के लिए, हार्टब्लीड की कमज़ोरी को ट्रैक करने के लिए, कोई नोट बनाया जा सकता है. इसके बाद, सुरक्षा से जुड़ी सेवाएं देने वाली कंपनियां, स्कैनर बनाएंगी. इन स्कैनर का इस्तेमाल, कंटेनर इमेज में मौजूद कमज़ोरियों का पता लगाने के लिए किया जाएगा. साथ ही, हर उस कंटेनर से जुड़ा एक इंस्टेंस बनाया जाएगा जिससे समझौता किया गया है.

कंटेनर एनालिसिस को, सामान्य मेटाडेटा एपीआई के तौर पर डिज़ाइन किया गया था. साथ ही, इसका इस्तेमाल कमियों को ट्रैक करने के लिए किया जाता था. बाइनरी ऑथराइज़ेशन, कंटेनर इमेज के साथ हस्ताक्षर जोड़ने के लिए कंटेनर विश्लेषण का इस्तेमाल करता है. कंटेनर के विश्लेषण से जुड़े नोट का इस्तेमाल, एक ही पुष्टि करने वाले व्यक्ति या कंपनी को दिखाने के लिए किया जाता है. साथ ही, पुष्टि करने वाले व्यक्ति या कंपनी ने जिस कंटेनर को मंज़ूरी दी है उसके लिए, Occurrences बनाए जाते हैं और उन्हें उससे जोड़ा जाता है.

Binary Authorization API में "attestors" और "attestations" के कॉन्सेप्ट का इस्तेमाल किया जाता है. हालांकि, इन्हें Container Analysis API में, इनसे मिलते-जुलते नोट और ऑकरेंस का इस्तेमाल करके लागू किया जाता है.

अटेस्ट करने वाले का नोट बनाना

अटेस्ट करने वाले की जानकारी, सिर्फ़ एक छोटा सा डेटा होता है. यह उस हस्ताक्षर के टाइप के लिए लेबल के तौर पर काम करता है जिसे लागू किया जा रहा है. उदाहरण के लिए, एक नोट में सुरक्षा से जुड़ी कमियों की जांच के बारे में बताया जा सकता है, जबकि दूसरे नोट का इस्तेमाल QA साइन ऑफ़ के लिए किया जा सकता है. साइन करने की प्रोसेस के दौरान, इस नोट का इस्तेमाल किया जाएगा.

नोट बनाना

cat > ./vulnz_note.json << EOM
{
  "attestation": {
    "hint": {
      "human_readable_name": "Container Vulnerabilities attestation authority"
    }
  }
}
EOM

नोट सेव करना

NOTE_ID=vulnz_note

curl -vvv -X POST \
    -H "Content-Type: application/json"  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @./vulnz_note.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}"

आपका नोट अब कंटेनर विश्लेषण एपीआई में सेव हो गया है.

Attestor बनाना

अटेस्टर्स का इस्तेमाल, इमेज पर हस्ताक्षर करने की प्रोसेस को पूरा करने के लिए किया जाता है. ये बाद में पुष्टि करने के लिए, नोट की एक कॉपी को इमेज से अटैच करेंगे. पुष्टि करने वाले व्यक्ति का इस्तेमाल करने के लिए, आपको नोट को Binary Authorization के साथ भी रजिस्टर करना होगा:

अटेस्ट करने वाला व्यक्ति बनाएं

ATTESTOR_ID=vulnz-attestor

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

पुष्टि करने वाले की पुष्टि करना

gcloud container binauthz attestors list

ध्यान दें कि आखिरी लाइन में NUM_PUBLIC_KEYS: 0 लिखा है. इसका मतलब है कि आपको बाद के चरण में कुंजियां देनी होंगी

यह भी ध्यान दें कि इमेज जनरेट करने वाली कोई बिल्ड प्रोसेस चलाने पर, Cloud Build आपके प्रोजेक्ट में built-by-cloud-build attestor अपने-आप बना देता है. इसलिए, ऊपर दी गई कमांड से पुष्टि करने वाले दो लोग, vulnz-attestor और built-by-cloud-build दिखते हैं. इमेज बन जाने के बाद, Cloud Build उनके लिए अपने-आप हस्ताक्षर करता है और पुष्टि करने वाले दस्तावेज़ बनाता है.

IAM रोल जोड़ना

बाइनरी ऑथराइज़ेशन सेवा खाते को, अटेस्टेशन नोट देखने के अधिकार की ज़रूरत होगी. नीचे दिए गए एपीआई कॉल का इस्तेमाल करके ऐक्सेस दें

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}"  --format="value(projectNumber)")

BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"


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 कुंजी जोड़ना

इस अटेस्टेशन सेवा का इस्तेमाल करने से पहले, आपकी संस्था को एक क्रिप्टोग्राफ़िक कुंजी जोड़ी बनानी होगी. इसका इस्तेमाल कंटेनर इमेज पर हस्ताक्षर करने के लिए किया जा सकता है. ऐसा Google Cloud Key Management Service (KMS) की मदद से किया जा सकता है.

नई कुंजी के बारे में बताने के लिए, सबसे पहले कुछ एनवायरमेंट वैरिएबल जोड़ें

KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1

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

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 Cloud Console के 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

हस्ताक्षर किया गया अटेस्टेशन बनाना

इस समय, आपके पास इमेज पर हस्ताक्षर करने की सुविधा कॉन्फ़िगर करने का विकल्प होता है. आपने जिस कंटेनर इमेज पर काम किया है उसे साइन करने के लिए, पहले से बनाए गए Attestor का इस्तेमाल करें.

अटेस्टेशन में क्रिप्टोग्राफ़िक सिग्नेचर शामिल होना चाहिए. इससे यह पता चलता है कि अटेस्ट करने वाले व्यक्ति ने किसी कंटेनर इमेज की पुष्टि कर ली है और वह आपके क्लस्टर पर सुरक्षित तरीके से चल सकती है. किस कंटेनर इमेज की पुष्टि करनी है, यह तय करने के लिए आपको उसका डाइजेस्ट तय करना होगा.

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

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}

4. ऐडमिशन कंट्रोल की नीतियां

बाइनरी ऑथराइज़ेशन, GKE और Cloud Run में उपलब्ध एक सुविधा है. इसकी मदद से, कंटेनर इमेज को चलाने की अनुमति देने से पहले नियमों की पुष्टि की जा सकती है. पुष्टि की प्रोसेस, इमेज को चलाने के लिए किए गए हर अनुरोध पर लागू होती है. भले ही, यह अनुरोध किसी भरोसेमंद CI/CD पाइपलाइन से किया गया हो या किसी उपयोगकर्ता ने मैन्युअल तरीके से इमेज को डिप्लॉय करने की कोशिश की हो. इस सुविधा की मदद से, सिर्फ़ सीआई/सीडी पाइपलाइन की जांचों की तुलना में, अपने रनटाइम एनवायरमेंट को ज़्यादा असरदार तरीके से सुरक्षित किया जा सकता है.

इस सुविधा को समझने के लिए, आपको GKE की डिफ़ॉल्ट नीति में बदलाव करना होगा, ताकि अनुमति देने से जुड़ा सख्त नियम लागू किया जा सके.

GKE क्लस्टर बनाना

बाइनरी ऑथराइज़ेशन की सुविधा चालू करके GKE क्लस्टर बनाएं:

gcloud beta container clusters create binauthz \
    --zone us-central1-a  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Cloud Build को इस क्लस्टर पर डिप्लॉय करने की अनुमति दें:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/container.developer"

सभी को अनुमति देने वाली नीति

सबसे पहले, डिफ़ॉल्ट नीति की स्थिति और किसी भी इमेज को डिप्लॉय करने की आपकी क्षमता की पुष्टि करें

मौजूदा नीति की समीक्षा करना

gcloud container binauthz policy export

ध्यान दें कि उल्लंघन ठीक करने का तरीका (एनफ़ोर्समेंट) ALWAYS_ALLOW पर सेट है

evaluationMode: ALWAYS_ALLOW

यह पुष्टि करने के लिए कि कुछ भी डिप्लॉय किया जा सकता है, सैंपल डिप्लॉय करें

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

पुष्टि करें कि डिप्लॉयमेंट काम कर रहा है

kubectl get pods

आपको यह आउटपुट दिखेगा

डिप्लॉयमेंट मिटाएं

kubectl delete pod hello-server

सभी नीतियों को अस्वीकार करने की नीति

अब नीति को अपडेट करके, सभी इमेज को अनुमति न दें.

मौजूदा नीति को ऐसी फ़ाइल में एक्सपोर्ट करें जिसमें बदलाव किया जा सकता है

gcloud container binauthz policy export  > policy.yaml

नीति बदलें

टेक्स्ट एडिटर में, evaluationMode को ALWAYS_ALLOW से बदलकर ALWAYS_DENY करें.

edit policy.yaml

नीति की YAML फ़ाइल इस तरह दिखनी चाहिए:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

यह नीति काफ़ी आसान है. globalPolicyEvaluationMode लाइन से पता चलता है कि यह नीति, Google की तय की गई ग्लोबल नीति को बढ़ाती है. इससे सभी आधिकारिक GKE कंटेनर डिफ़ॉल्ट रूप से चल पाते हैं. इसके अलावा, नीति में defaultAdmissionRule का एलान किया गया है. इसमें बताया गया है कि अन्य सभी पॉड अस्वीकार कर दिए जाएंगे. एडमिशन रूल में enforcementMode लाइन शामिल होती है. इससे पता चलता है कि इस नियम का पालन न करने वाले सभी पॉड को क्लस्टर पर चलने से रोक दिया जाना चाहिए.

ज़्यादा जटिल नीतियां बनाने के निर्देशों के लिए, बाइनरी ऑथराइज़ेशन का दस्तावेज़ देखें.

टर्मिनल खोलें और नई नीति लागू करें. इसके बाद, बदलाव लागू होने के लिए कुछ सेकंड इंतज़ार करें

gcloud container binauthz policy import policy.yaml

वर्कलोड डिप्लॉय करने का सैंपल आज़माएं

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

डिप्लॉयमेंट के दौरान यह मैसेज दिखता है

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

नीति को वापस बदलकर, सभी को अनुमति दें

अगले सेक्शन पर जाने से पहले, नीति में किए गए बदलावों को पहले जैसा कर लें

नीति बदलें

टेक्स्ट एडिटर में, evaluationMode को ALWAYS_DENY से बदलकर ALWAYS_ALLOW करें.

edit policy.yaml

नीति की YAML फ़ाइल इस तरह दिखनी चाहिए:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

नीति को वापस लागू करना

gcloud container binauthz policy import policy.yaml

5. स्कैन की गई इमेज पर हस्ताक्षर करना

आपने इमेज साइनिंग की सुविधा चालू की हो. साथ ही, आपने खुद ही Attestor का इस्तेमाल करके, अपनी सैंपल इमेज को साइन किया हो. आपको CI/CD पाइपलाइन जैसी अपने-आप काम करने वाली प्रोसेस के दौरान, पुष्टि करने वाले दस्तावेज़ लागू करने होंगे.

इस सेक्शन में, इमेज की पुष्टि अपने-आप करने के लिए Cloud Build को कॉन्फ़िगर किया जाएगा

भूमिकाएं

Cloud Build सेवा खाते में, Binary Authorization Attestor Viewer की भूमिका जोड़ें:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

Cloud Build सेवा खाते में, Cloud KMS CryptoKey Signer/Verifier की भूमिका जोड़ें (KMS पर आधारित हस्ताक्षर):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

Cloud Build सेवा खाते में, कंटेनर विश्लेषण के नोट अटैच करने की भूमिका जोड़ें:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

Cloud Build सेवा खाते के लिए ऐक्सेस देना

Cloud Build को, मांग पर स्कैन करने वाले एपीआई को ऐक्सेस करने के अधिकार चाहिए होंगे. इन कमांड की मदद से ऐक्सेस दें.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

कस्टम बिल्ड Cloud Build चरण तैयार करना

अटेस्टेशन की प्रोसेस को आसान बनाने के लिए, Cloud Build में कस्टम बिल्ड स्टेप का इस्तेमाल किया जाएगा. Google, कस्टम बिल्ड का यह चरण उपलब्ध कराता है. इसमें प्रोसेस को आसान बनाने के लिए हेल्पर फ़ंक्शन शामिल होते हैं. इस्तेमाल करने से पहले, कस्टम बिल्ड स्टेप के कोड को कंटेनर में बनाया जाना चाहिए और Cloud Build पर पुश किया जाना चाहिए. इसके लिए, ये कमांड चलाएं:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community

cloudbuild.yaml फ़ाइल में हस्ताक्षर करने का चरण जोड़ना

इस चरण में, आपको Cloud Build पाइपलाइन में पुष्टि करने का चरण जोड़ना होगा.

नीचे दिए गए हस्ताक्षर करने के तरीके को देखें.

सिर्फ़ समीक्षा करें. कॉपी न करें

#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

नीचे दिए गए पूरे पाइपलाइन के साथ cloudbuild.yaml फ़ाइल लिखो.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'



images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF

बिल्ड को चलाना

gcloud builds submit

Cloud Build के इतिहास में जाकर, बिल्ड की समीक्षा करें

Cloud Console में Cloud Build का इतिहास पेज खोलें. इसके बाद, सबसे हाल के बिल्ड और बिल्ड के चरणों के सही तरीके से लागू होने की समीक्षा करें.

6. हस्ताक्षर की गई इमेज को अनुमति देना

इस सेक्शन में, आपको GKE को अपडेट करना होगा, ताकि वह Binary Authorization का इस्तेमाल कर सके. इससे यह पुष्टि की जा सकेगी कि इमेज में, Vulnerability scanning का सिग्नेचर है. इसके बाद ही, इमेज को चलाने की अनुमति दी जाएगी.

पुष्टि करने की सुविधा को ज़रूरी बनाने के लिए, GKE की नीति को अपडेट करना

ज़रूरी इमेज पर, आपके Attestor के हस्ताक्षर होने चाहिए. इसके लिए, अपनी GKE BinAuth नीति में clusterAdmissionRules जोड़ें

फ़िलहाल, आपके क्लस्टर में एक नियम वाली नीति लागू है: आधिकारिक रिपॉज़िटरी से कंटेनर को अनुमति दें और बाकी सभी को अस्वीकार करें.

नीचे दी गई कमांड का इस्तेमाल करके, अपडेट किए गए कॉन्फ़िगरेशन से नीति को बदलें.

COMPUTE_ZONE=us-central1-a

cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  ${COMPUTE_ZONE}.binauthz:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM

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

नई नीति को बाइनरी ऑथराइज़ेशन में अपलोड करें:

gcloud beta container binauthz policy import binauth_policy.yaml

साइन की गई इमेज को डिप्लॉय करना

अच्छी इमेज के लिए, इमेज डाइजेस्ट पाएं

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


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

Kubernetes कॉन्फ़िगरेशन में डाइजेस्ट का इस्तेमाल करना

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

ऐप्लिकेशन को GKE पर डिप्लॉय करना

kubectl apply -f deploy.yaml

कंसोल में वर्कलोड की समीक्षा करें और इमेज के डिप्लॉयमेंट की स्थिति देखें.

7. बिना हस्ताक्षर वाली इमेज ब्लॉक की गई हैं

इमेज बनाना

इस चरण में, लोकल डॉकर का इस्तेमाल करके इमेज को लोकल कैश में बनाया जाएगा.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

बिना हस्ताक्षर वाली इमेज को रेपो में पुश करें

docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

खराब इमेज के लिए इमेज डाइजेस्ट पाना

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


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

Kubernetes कॉन्फ़िगरेशन में डाइजेस्ट का इस्तेमाल करना

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

GKE पर ऐप्लिकेशन को डिप्लॉय करने की कोशिश की गई

kubectl apply -f deploy.yaml

कंसोल में वर्कलोड की समीक्षा करें और उस गड़बड़ी को नोट करें जिसमें डिप्लॉयमेंट को अस्वीकार किए जाने की बात कही गई है:

No attestations found that were valid and signed by a key trusted by the attestor

8. बधाई हो!

बधाई हो, आपने कोडलैब पूरा कर लिया है!

हमने इन विषयों के बारे में जानकारी दी है:

इमेज पर हस्ताक्षर करना
ऐडमिशन कंट्रोल की नीतियां
स्कैन की गई इमेज पर हस्ताक्षर करना
हस्ताक्षर की गई इमेज को अनुमति देना
बिना हस्ताक्षर वाली इमेज ब्लॉक की गई हैं

इसके बाद क्या होगा:

व्यवस्थित करें

इस ट्यूटोरियल में इस्तेमाल किए गए संसाधनों के लिए, अपने Google Cloud खाते से शुल्क न लिए जाने के लिए, संसाधनों वाला प्रोजेक्ट मिटाएं. इसके अलावा, प्रोजेक्ट को बनाए रखने और अलग-अलग संसाधनों को मिटाने का विकल्प भी है.

प्रोजेक्ट मिटाना

बिलिंग बंद करने का सबसे आसान तरीका यह है कि ट्यूटोरियल के लिए बनाया गया प्रोजेक्ट मिटा दें.

—

पिछली बार अपडेट किए जाने की तारीख: 21/3/23