इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

1. परिचय

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

यहां दिया गया डायग्राम, बाइनरी अनुमति देने/Cloud Build के सेटअप में कॉम्पोनेंट को दिखाता है:

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

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

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

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

आपको इनके बारे में जानकारी मिलेगी

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

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

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

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

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

इसके बाद, आपको क्लाउड संसाधनों/एपीआई का इस्तेमाल करने के लिए, Cloud Console में बिलिंग चालू करनी होगी. इस कोडलैब का इस्तेमाल करने पर, आपको ज़्यादा पैसे नहीं चुकाने होंगे. इस ट्यूटोरियल के अलावा, संसाधनों को बंद करने के लिए कि आपको बिलिंग न करनी पड़े. इसके लिए, अपने बनाए गए संसाधनों को मिटाएं या पूरा प्रोजेक्ट मिटाएं. 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 क्रेडेंशियल का इस्तेमाल करने के लिए डॉकर को कॉन्फ़िगर करें.

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. इमेज साइनिंग

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

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

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

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

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

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

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

बाइनरी Authorization 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_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 प्रमाणित करने वाला टूल अपने-आप बना देता है. इसलिए ऊपर दिया गया निर्देश, दो अटेस्टर vulnz-attestor और built-by-cloud-build दिखाता है. इमेज बनने के बाद, Cloud Build अपने-आप उन पर हस्ताक्षर करता है और उनकी पुष्टि करता है.

आईएएम की भूमिका जोड़ना

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

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"

केएमएस कुंजी जोड़ना

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

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

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

हस्ताक्षर किया गया प्रमाणित करना

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

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

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 की एक सुविधा है. इसकी मदद से, कंटेनर इमेज को चलाने से पहले नियमों की पुष्टि की जा सकती है. पुष्टि करने की प्रोसेस, इमेज को चलाने के हर अनुरोध पर लागू होती है. यह काम किसी भरोसेमंद सीआई/सीडी पाइपलाइन से हो सकता है या मैन्युअल तरीके से किसी इमेज को डिप्लॉय करने की कोशिश करने वाले उपयोगकर्ता के आधार पर किया जा सकता है. इस सुविधा की मदद से, सीआई/सीडी पाइपलाइन की जांच के मुकाबले, रनटाइम एनवायरमेंट को ज़्यादा असरदार तरीके से सुरक्षित किया जा सकता है.

इस सुविधा को समझने के लिए, आपको डिफ़ॉल्ट 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 लाइन शामिल है. इसमें बताया गया है कि इस नियम का पालन न करने वाले सभी पॉड को क्लस्टर पर चलने से ब्लॉक किया जाना चाहिए.

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

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

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. स्कैन की गई इमेज पर हस्ताक्षर करना

आपने इमेज पर हस्ताक्षर करने की सुविधा चालू की है. साथ ही, आपने सैंपल इमेज पर हस्ताक्षर करने के लिए, प्रमाणित करने वाले व्यक्ति का इस्तेमाल किया है. सीआई/सीडी पाइपलाइन जैसी अपने-आप काम करने वाली प्रोसेस के दौरान, आपको प्रमाणित करने की सुविधा को लागू करना होगा.

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

भूमिकाएं

Cloud Build के सेवा खाते में, बाइनरी अनुमति देने वाले प्रमाणित करने वाले व्यूअर की भूमिका जोड़ें:

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

Cloud Build सेवा खाते (केएमएस पर आधारित साइनिंग) में, क्लाउड केएमएस क्रिप्टोग्राफ़िक साइनर/वैरिफ़ायर की भूमिका जोड़ें:

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 में 'कस्टम बिल्ड' चरण का इस्तेमाल किया जा रहा है. 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 (जीकेई) को अपडेट करना होगा, ताकि वह इमेज को चलाने से पहले, जोखिम की आशंका वाली जांच से मिली इमेज के हस्ताक्षर की पुष्टि कर सके. इसके लिए, वह बाइनरी ऑथराइज़ेशन का इस्तेमाल करेगा.

प्रमाणित करने की ज़रूरत के लिए, GKE (जीकेई) नीति को अपडेट करें

आपके प्रमाणित करने वाले व्यक्ति की इमेज पर हस्ताक्षर करना ज़रूरी है. ऐसा करने के लिए, आपकी GKE बिन अनुमति की नीति में 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