सुरक्षित बिल्ड & Cloud Build, Artifact Registry, और GKE (जीकेई) के साथ डिप्लॉय करना

1. परिचय

कंटेनर विश्लेषण की सुविधा, कंटेनर के लिए कमियों का पता लगाने और मेटाडेटा को सेव करने की सुविधा देती है. स्कैनिंग सेवा, Artifact Registry और Container Registry में मौजूद इमेज को स्कैन करती है. इसके बाद, स्कैन के नतीजों से मिले मेटाडेटा को सेव करती है. साथ ही, इसे एपीआई के ज़रिए इस्तेमाल करने के लिए उपलब्ध कराती है. मेटाडेटा स्टोरेज की मदद से, अलग-अलग सोर्स से मिली जानकारी को सेव किया जा सकता है. जैसे, सुरक्षा से जुड़ी कमियों की स्कैनिंग, Google Cloud की सेवाएं, और तीसरे पक्ष के प्रोवाइडर.

जोखिम की आशंका का पता लगाने के लिए स्कैनिंग, अपने-आप या मांग पर की जा सकती है:

  • अपने-आप स्कैन होने की सुविधा चालू होने पर, Artifact Registry या Container Registry में नई इमेज पुश करने पर, स्कैनिंग अपने-आप ट्रिगर हो जाती है. नई कमज़ोरियों का पता चलने पर, कमज़ोरियों से जुड़ी जानकारी को लगातार अपडेट किया जाता है.
  • मांग पर स्कैन करने की सुविधा चालू होने पर, आपको किसी स्थानीय इमेज या Artifact Registry या Container Registry में मौजूद इमेज को स्कैन करने के लिए, एक कमांड चलानी होगी. ऑन-डिमांड स्कैनिंग की सुविधा की मदद से, कंटेनर को स्कैन करने का समय तय किया जा सकता है. उदाहरण के लिए, स्थानीय तौर पर बनाई गई इमेज को स्कैन किया जा सकता है. साथ ही, रजिस्ट्री में सेव करने से पहले, उसकी कमियों को ठीक किया जा सकता है. स्कैन पूरा होने के बाद, स्कैन के नतीजे 48 घंटे तक उपलब्ध रहते हैं. साथ ही, स्कैन के बाद सुरक्षा से जुड़ी कमज़ोरियों की जानकारी अपडेट नहीं की जाती.

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

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

  • अपने-आप स्कैन होने की सुविधा चालू करने का तरीका
  • मांग पर स्कैन करने की सुविधा का इस्तेमाल कैसे करें
  • बिल्ड पाइपलाइन में स्कैनिंग को इंटिग्रेट करने का तरीका
  • मंज़ूरी वाली इमेज पर हस्ताक्षर करने का तरीका
  • इमेज को ब्लॉक करने के लिए, GKE के ऐडमिशन कंट्रोलर इस्तेमाल करने का तरीका
  • सिर्फ़ साइन की गई और मंज़ूरी वाली इमेज को अनुमति देने के लिए, GKE को कैसे कॉन्फ़िगर करें

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

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

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

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

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

Cloud Shell Editor शुरू करना

इस लैब को Google Cloud Shell Editor के साथ इस्तेमाल करने के लिए डिज़ाइन और टेस्ट किया गया है. एडिटर को ऐक्सेस करने के लिए,

  1. https://console.cloud.google.com पर जाकर, अपने Google प्रोजेक्ट को ऐक्सेस करें.
  2. सबसे ऊपर दाएं कोने में मौजूद, Cloud Shell एडिटर आइकॉन पर क्लिक करें

8560cc8d45e8c112.png

  1. आपकी विंडो में सबसे नीचे एक नया पैनल खुलेगा

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

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

3. अपने-आप स्कैन होने की सुविधा

Artifact Registry या Container Registry में नई इमेज पुश करने पर, आर्टफ़ैक्ट स्कैनिंग अपने-आप ट्रिगर हो जाती है. नई कमज़ोरियों का पता चलने पर, कमज़ोरियों से जुड़ी जानकारी को लगातार अपडेट किया जाता है. इस सेक्शन में, आपको Artifact Registry में इमेज पुश करने और नतीजे देखने का तरीका बताया जाएगा.

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

mkdir vuln-scan && cd vuln-scan

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

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

cat > ./Dockerfile << EOF
FROM gcr.io/google-appengine/debian9@sha256:ebffcf0df9aa33f342c4e1d4c8428b784fc571cdf6fbab0b31330347ca8af97a

# System
RUN apt update && apt install python3-pip -y

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==1.1.4
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 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

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

Cloud Build का इस्तेमाल करके, अपने कंटेनर को बनाएं और उसे Artifact Registry में अपने-आप पुश करें. इमेज पर मौजूद bad टैग पर ध्यान दें. इससे आपको बाद के चरणों में इसकी पहचान करने में मदद मिलेगी.

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

इमेज की जानकारी देखना

बिल्ड प्रोसेस पूरी होने के बाद, Artifact Registry के डैशबोर्ड में जाकर इमेज और कमज़ोरियों के नतीजे देखें.

  1. Cloud Console में Artifact Registry खोलें
  2. कॉन्टेंट देखने के लिए, artifact-scanning-repo पर क्लिक करें
  3. इमेज की जानकारी पर क्लिक करें
  4. अपनी इमेज के सबसे नए डाइजेस्ट पर क्लिक करें
  5. स्कैन पूरा होने के बाद, इमेज के लिए 'कमज़ोरियां' टैब पर क्लिक करें

कमज़ोरियों वाले टैब में, आपको अभी-अभी बनाई गई इमेज की अपने-आप स्कैनिंग के नतीजे दिखेंगे.

361be7b3bf293fca.png

स्कैनिंग को अपने-आप होने की सुविधा, डिफ़ॉल्ट रूप से चालू होती है. अपने-आप स्कैन होने की सुविधा को बंद या चालू करने का तरीका जानने के लिए, Artifact Registry की सेटिंग एक्सप्लोर करें.

4. On-Demand Scanning

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

इमेज बनाना

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

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

इमेज को स्कैन करें

इमेज बन जाने के बाद, उसे स्कैन करने का अनुरोध करें. स्कैन के नतीजों को मेटाडेटा सर्वर में सेव किया जाता है. मेटाडेटा सर्वर में नतीजों की जगह की जानकारी के साथ, नौकरी पूरी हो जाती है.

gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --format="value(response.scan)" > scan_id.txt

आउटपुट फ़ाइल की समीक्षा करना

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

cat scan_id.txt

स्कैन के नतीजों की पूरी जानकारी देखना

स्कैन के असल नतीजे देखने के लिए, आउटपुट फ़ाइल में दी गई रिपोर्ट की जगह पर list-vulnerabilities कमांड का इस्तेमाल करें.

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt)

आउटपुट में, इमेज में मौजूद सभी कमज़ोरियों के बारे में काफ़ी डेटा होता है.

गंभीर समस्याओं के बारे में बताना

रिपोर्ट में सेव किए गए डेटा का इस्तेमाल, लोग सीधे तौर पर बहुत कम करते हैं. आम तौर पर, नतीजों का इस्तेमाल अपने-आप काम करने वाली प्रोसेस करती है. रिपोर्ट की जानकारी पढ़ने और यह लॉग करने के लिए कि क्या कोई गंभीर जोखिम वाली कमज़ोरी मिली है, यहां दिए गए निर्देशों का इस्तेमाल करें

export SEVERITY=CRITICAL

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq ${SEVERITY}; then echo "Failed vulnerability check for ${SEVERITY} level"; else echo "No ${SEVERITY} Vulnerabilities found"; fi

इस कमांड का आउटपुट यह होगा

Failed vulnerability check for CRITICAL level

5. पाइपलाइन स्कैनिंग की सुविधा बनाना

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

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 पाइपलाइन बनाना

नीचे दी गई कमांड, आपकी डायरेक्ट्री में 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']

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

सीआई पाइपलाइन चलाना

प्रोसेसिंग के लिए बिल्ड सबमिट करें, ताकि यह पुष्टि की जा सके कि गंभीर जोखिम वाली कमज़ोरी का पता चलने पर बिल्ड काम नहीं करता है.

gcloud builds submit

बिल्ड की समीक्षा नहीं हो सकी

आपने अभी जो बिल्ड सबमिट किया है वह फ़ेल हो जाएगा, क्योंकि इमेज में गंभीर कमियां हैं.

Cloud Build का इतिहास पेज पर जाकर, बिल्ड फ़ेल होने की वजह देखें

कमज़ोरी को ठीक करना

Dockerfile को अपडेट करें, ताकि ऐसी बेस इमेज का इस्तेमाल किया जा सके जिसमें गंभीर जोखिम वाली कमियां न हों.

Debian 10 इमेज का इस्तेमाल करने के लिए, 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

अच्छी इमेज के साथ सीआई प्रोसेस चलाएं

बिल्ड को प्रोसेस करने के लिए सबमिट करें, ताकि यह पुष्टि की जा सके कि गंभीर जोखिम वाली कोई भी कमज़ोरी न मिलने पर, बिल्ड पूरा हो जाएगा.

gcloud builds submit

बिल्ड की सफलता की समीक्षा करना

आपने अभी जो बिल्ड सबमिट किया है वह पास हो जाएगा, क्योंकि अपडेट की गई इमेज में कोई भी गंभीर जोखिम नहीं है.

Cloud Build का इतिहास पेज पर जाकर, बिल्ड के पूरा होने की स्थिति देखें

स्कैन के नतीजों की समीक्षा करना

Artifact Registry में अच्छी इमेज की समीक्षा करना

  1. Cloud Console में Artifact Registry खोलें
  2. कॉन्टेंट देखने के लिए, artifact-scanning-repo पर क्लिक करें
  3. इमेज की जानकारी पर क्लिक करें
  4. अपनी इमेज के सबसे नए डाइजेस्ट पर क्लिक करें
  5. इमेज के लिए, 'कमज़ोरियां' टैब पर क्लिक करें

6. हस्ताक्षर की इमेज

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

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

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

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

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

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

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

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}

7. Cloud Build की मदद से साइन करना

आपने इमेज साइन करने की सुविधा चालू की हो और आपने खुद ही 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 की भूमिका जोड़ें (केएमएस पर आधारित हस्ताक्षर):

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 में कस्टम बिल्ड स्टेप का इस्तेमाल किया जाएगा. 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 की उस पाइपलाइन में पुष्टि करने का चरण जोड़ना होगा जिसे आपने पहले बनाया था.

  1. जो नया चरण जोड़ा जा रहा है उसकी समीक्षा करें.

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

#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'
  1. अपडेट किए गए पूरे पाइपलाइन की जानकारी वाली cloudbuild.yaml फ़ाइल से, अपनी 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 का इतिहास पेज खोलें. इसके बाद, सबसे हाल के बिल्ड और बिल्ड के चरणों के सही तरीके से लागू होने की समीक्षा करें.

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

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

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

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

  1. मौजूदा नीति की समीक्षा करना
gcloud container binauthz policy export
  1. ध्यान दें कि उल्लंघन ठीक करने का तरीका (एनफ़ोर्समेंट) ALWAYS_ALLOW पर सेट है

evaluationMode: ALWAYS_ALLOW

  1. यह पुष्टि करने के लिए कि कुछ भी डिप्लॉय किया जा सकता है, सैंपल डिप्लॉय करें
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
  1. पुष्टि करें कि डिप्लॉयमेंट काम कर रहा है
kubectl get pods

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

161db370d99ffb13.png

  1. डिप्लॉयमेंट मिटाएं
kubectl delete pod hello-server

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

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

  1. मौजूदा नीति को ऐसी फ़ाइल में एक्सपोर्ट करना जिसमें बदलाव किया जा सके
gcloud container binauthz policy export  > policy.yaml
  1. नीति बदलें

टेक्स्ट एडिटर में, 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
  1. टर्मिनल खोलें और नई नीति लागू करें. इसके बाद, बदलाव लागू होने के लिए कुछ सेकंड इंतज़ार करें
gcloud container binauthz policy import policy.yaml
  1. वर्कलोड डिप्लॉय करने की कोशिश करें
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
  1. डिप्लॉयमेंट के दौरान यह मैसेज दिखता है
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

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

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

  1. नीति बदलें

टेक्स्ट एडिटर में, 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
  1. नीति को वापस लागू करना
gcloud container binauthz policy import policy.yaml

9. GKE में जोखिम की आशंकाओं को ब्लॉक करना

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

d5c41bb89e22fd61.png

पुष्टि करने की सुविधा को ज़रूरी बनाने के लिए, 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

नीति लागू करना

gcloud beta container binauthz policy import binauth_policy.yaml

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

यहां दिए गए निर्देश का इस्तेमाल करके, पहले बनाए गए ऐप्लिकेशन के लिए डिप्लॉयमेंट डिस्क्रिप्टर बनाएं. यहां इस्तेमाल की गई इमेज, वह इमेज है जिसे आपने पहले बनाया था. इसमें गंभीर कमज़ोरियां हैं और इसमें हस्ताक्षर किया गया अटेस्टेशन शामिल नहीं है.

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

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

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

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

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

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

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

10. बधाई हो!

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

हमने इन विषयों पर बात की:

  • अपने-आप स्कैन होने की सुविधा चालू करने का तरीका
  • मांग पर स्कैन करने की सुविधा का इस्तेमाल कैसे करें
  • बिल्ड पाइपलाइन में स्कैनिंग को इंटिग्रेट करने का तरीका
  • मंज़ूरी वाली इमेज पर हस्ताक्षर करने का तरीका
  • इमेज को ब्लॉक करने के लिए, GKE के ऐडमिशन कंट्रोलर इस्तेमाल करने का तरीका
  • सिर्फ़ साइन की गई और मंज़ूरी वाली इमेज को अनुमति देने के लिए, GKE को कैसे कॉन्फ़िगर करें

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

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

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

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

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