इस कोडलैब (कोड बनाना सीखने के लिए ट्यूटोरियल) के बारे में जानकारी
1. परिचय
कंटेनर विश्लेषण, कंटेनर के लिए जोखिम की आशंका वाली स्कैनिंग और मेटाडेटा स्टोरेज की सुविधा देता है. स्कैनिंग सेवा, Artifact Registry और Container Registry में मौजूद इमेज की जोखिम की आशंका को स्कैन करती है. इसके बाद, इससे बने मेटाडेटा को स्टोर करती है और उसे एपीआई की मदद से इस्तेमाल करने के लिए उपलब्ध कराती है. मेटाडेटा स्टोरेज आपको अलग-अलग सोर्स से जानकारी सेव करने देता है. इनमें जोखिम की आशंकाओं का पता लगाने की सुविधा, Google Cloud की सेवाएं, और तीसरे पक्ष की सेवा देने वाली कंपनियां शामिल हैं.
जोखिम की आशंका की जांच अपने-आप या मांग पर हो सकती है:
- अपने-आप स्कैन होने की सुविधा चालू होने पर, जब भी Artifact Registry या Container Registry में नई इमेज भेजी जाती है, स्कैनिंग अपने-आप ट्रिगर हो जाती है. नए जोखिमों का पता चलने पर, जोखिम की आशंका की जानकारी लगातार अपडेट की जाती है.
- मांग पर स्कैन करने की सुविधा चालू होने पर, आपको Artifact Registry या Container Registry में मौजूद किसी स्थानीय इमेज या किसी इमेज को स्कैन करने के लिए निर्देश देना होगा. मांग पर स्कैन करने की सुविधा, कंटेनर को स्कैन करते समय आपके काम आ सकती है. उदाहरण के लिए, आपके पास डिवाइस पर बनी किसी इमेज को स्कैन करने और उसे किसी रजिस्ट्री में सेव करने से पहले, जोखिम की आशंकाओं को दूर करने का विकल्प होता है. स्कैन पूरा होने के 48 घंटे बाद तक, स्कैनिंग के नतीजे उपलब्ध होते हैं. साथ ही, स्कैन के बाद, जोखिम की आशंका से जुड़ी जानकारी अपडेट नहीं होती.
कंटेनर विश्लेषण को अपनी CI/CD पाइपलाइन के साथ जोड़कर, आप उस मेटाडेटा के आधार पर फ़ैसले ले सकते हैं. उदाहरण के लिए, डिप्लॉयमेंट की नीतियां बनाने के लिए बाइनरी ऑथराइज़ेशन का इस्तेमाल किया जा सकता है. इस नीति के तहत, सिर्फ़ भरोसेमंद रजिस्ट्री की ऐसी इमेज के डिप्लॉयमेंट की अनुमति दी जाती है जो नियमों का पालन करती हों.
आपको इनके बारे में जानकारी मिलेगी
- अपने-आप स्कैन होने की सुविधा चालू करने का तरीका
- मांग पर स्कैन करने का तरीका
- बिल्ड पाइपलाइन में स्कैनिंग को इंटिग्रेट करने का तरीका
- स्वीकार की गई इमेज पर हस्ताक्षर करने का तरीका
- इमेज ब्लॉक करने के लिए, GKE (जीकेई) एडमिशन कंट्रोलर इस्तेमाल करने का तरीका
- साइन की गई इमेज को अनुमति देने के लिए, GKE (जीकेई) को कैसे कॉन्फ़िगर करें
2. सेटअप और ज़रूरी शर्तें
अपने हिसाब से एनवायरमेंट सेटअप करें
- Google Cloud Console में साइन इन करें और नया प्रोजेक्ट बनाएं या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल करें. अगर आपके पास पहले से Gmail या Google Workspace खाता नहीं है, तो आपको नया खाता बनाना होगा.
- प्रोजेक्ट का नाम, इस प्रोजेक्ट में हिस्सा लेने वाले लोगों का डिसप्ले नेम होता है. यह एक वर्ण स्ट्रिंग है, जिसका इस्तेमाल Google API नहीं करता. इसे कभी भी अपडेट किया जा सकता है.
- प्रोजेक्ट आईडी, Google Cloud के सभी प्रोजेक्ट के लिए यूनीक होता है. साथ ही, इसे बदला नहीं जा सकता. इसे सेट करने के बाद बदला नहीं जा सकता. Cloud Console, एक यूनीक स्ट्रिंग अपने-आप जनरेट करता है; आम तौर पर, आपको उसके होने की कोई परवाह नहीं होती. ज़्यादातर कोडलैब में, आपको प्रोजेक्ट आईडी का रेफ़रंस देना होगा. आम तौर पर, इसे
PROJECT_IDके तौर पर पहचाना जाता है. अगर आपको जनरेट किया गया आईडी पसंद नहीं है, तो किसी भी क्रम में एक और आईडी जनरेट किया जा सकता है. इसके अलावा, खुद भी आज़माया जा सकता है और देखें कि वह उपलब्ध है या नहीं. इस चरण के बाद इसे बदला नहीं जा सकता और प्रोजेक्ट के कुल समय तक बना रहेगा. - आपकी जानकारी के लिए, एक तीसरी वैल्यू यानी प्रोजेक्ट नंबर है. इसका इस्तेमाल कुछ एपीआई करते हैं. दस्तावेज़ में इन तीनों वैल्यू के बारे में ज़्यादा जानें.
- इसके बाद, आपको क्लाउड संसाधनों/एपीआई का इस्तेमाल करने के लिए, Cloud Console में बिलिंग चालू करनी होगी. इस कोडलैब का इस्तेमाल करने पर, आपको ज़्यादा पैसे नहीं चुकाने होंगे. इस ट्यूटोरियल के अलावा, संसाधनों को बंद करने के लिए कि आपको बिलिंग न करनी पड़े. इसके लिए, अपने बनाए गए संसाधनों को मिटाएं या पूरा प्रोजेक्ट मिटाएं. Google Cloud के नए उपयोगकर्ता, 300 डॉलर के मुफ़्त ट्रायल वाले प्रोग्राम में हिस्सा ले सकते हैं.
Cloudshell एडिटर शुरू करें
इस लैब को Google Cloud Shell Editor के साथ इस्तेमाल करने के लिए डिज़ाइन और टेस्ट किया गया था. एडिटर को ऐक्सेस करने के लिए,
- https://console.cloud.google.com पर जाकर, अपना Google प्रोजेक्ट ऐक्सेस करें.
- सबसे ऊपर दाएं कोने में मौजूद, Cloud Shell एडिटर आइकॉन पर क्लिक करें
- आपकी विंडो के सबसे नीचे एक नया पैनल खुलेगा
एनवायरमेंट का सेटअप
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
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
इमेज बनाएं और उसे एआर (ऑगमेंटेड रिएलिटी) पर भेजें
Cloud Build का इस्तेमाल करके, अपना कंटेनर बनाएं और उसे Artifact Registry में अपने-आप पुश करें. इमेज पर मौजूद bad टैग को नोट करें. इससे आपको बाद के चरणों में इसे पहचानने में मदद मिलेगी.
gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad
इमेज की जानकारी की समीक्षा करें
बिल्ड प्रोसेस पूरी हो जाने के बाद, Artifact Registry के डैशबोर्ड में इमेज और जोखिम की आशंका से जुड़े नतीजों की समीक्षा करें.
- Cloud Console में Artifact Registry खोलें
- कॉन्टेंट देखने के लिए आर्टफ़ैक्ट-स्कैनिंग-रेपो पर क्लिक करें
- इमेज की जानकारी पर क्लिक करें
- अपनी इमेज की सबसे नई डाइजेस्ट पर क्लिक करें
- स्कैन पूरा होने के बाद, इमेज के लिए जोखिम की आशंकाओं वाले टैब पर क्लिक करें
जोखिम की आशंकाएं टैब से, आपको अभी-अभी बनाई गई इमेज के लिए, अपने-आप होने वाली स्कैनिंग के नतीजे दिखेंगे.
अपने-आप स्कैन होने की सुविधा, डिफ़ॉल्ट रूप से चालू रहती है. यह जानने के लिए Artifact Registry की सेटिंग पर जाएं कि अपने-आप स्कैन होने की सुविधा को बंद/चालू कैसे किया जा सकता है.
4. मांग पर स्कैनिंग
ऐसी कई स्थितियां हो सकती हैं जिनमें इमेज को रिपॉज़िटरी में पुश करने से पहले, आपको स्कैन करने की ज़रूरत पड़ सकती है. उदाहरण के लिए, सोर्स कंट्रोल में कोड को पुश करने से पहले, कंटेनर डेवलपर किसी इमेज को स्कैन करके गड़बड़ियों को ठीक कर सकता है. नीचे दिए गए उदाहरण में, नतीजों पर कार्रवाई करने से पहले, स्थानीय तौर पर इमेज बनाई जाएगी और उसका विश्लेषण किया जाएगा.
कोई इमेज बनाएं
इस चरण में, अपने लोकल कैश मेमोरी में इमेज बनाने के लिए, लोकल डॉकर का इस्तेमाल किया जाएगा.
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
बिल्ड में गड़बड़ी की समीक्षा करें
आपने अभी-अभी जो बिल्ड सबमिट किया है वह काम नहीं करेगा, क्योंकि इमेज में CRITICAL से जुड़ी जोखिम की आशंकाएं मौजूद हैं.
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
बिल्ड की सफलता की समीक्षा करें
आपने अभी-अभी जो बिल्ड सबमिट किया है वह सफल हो जाएगा, क्योंकि अपडेट की गई इमेज में कोई CRITICAL नहीं है.
Cloud Build इतिहास पेज पर जाकर, बिल्ड की सफलता की समीक्षा करें
स्कैन के नतीजों की समीक्षा करें
आर्टफ़ैक्ट रजिस्ट्री में अच्छी इमेज देखें
- Cloud Console में Artifact Registry खोलें
- कॉन्टेंट देखने के लिए आर्टफ़ैक्ट-स्कैनिंग-रेपो पर क्लिक करें
- इमेज की जानकारी पर क्लिक करें
- अपनी इमेज की सबसे नई डाइजेस्ट पर क्लिक करें
- इमेज के लिए जोखिम की आशंका वाले टैब पर क्लिक करें
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_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"
केएमएस कुंजी जोड़ना
नोट जोड़ने और पुष्टि किए जा सकने वाले हस्ताक्षर देने के लिए, प्रमाणित करने वाले व्यक्ति को क्रिप्टोग्राफ़िक कुंजियों की ज़रूरत होती है. इस चरण में, 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
हस्ताक्षर किया गया प्रमाणित करना
इस बिंदु पर, आपके पास वे सुविधाएं कॉन्फ़िगर की गई हैं जो आपको इमेज पर हस्ताक्षर करने के लिए चालू करती हैं. जिस कंटेनर इमेज के साथ काम किया जा रहा है उस पर हस्ताक्षर करने के लिए, पहले बनाए गए अटेस्टर का इस्तेमाल करें
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 के साथ साइन इन करना
आपने इमेज पर हस्ताक्षर करने की सुविधा चालू की है. साथ ही, आपने सैंपल इमेज पर हस्ताक्षर करने के लिए, प्रमाणित करने वाले व्यक्ति का इस्तेमाल किया है. सीआई/सीडी पाइपलाइन जैसी अपने-आप काम करने वाली प्रोसेस के दौरान, आपको प्रमाणित करने की सुविधा को लागू करना होगा.
इस सेक्शन में, 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 में 'कस्टम बिल्ड' चरण का इस्तेमाल किया जा रहा है. 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 के इतिहास पेज पर खोलें और देखें कि नए बिल्ड और बिल्ड के चरणों को पूरा किया गया है या नहीं.
8. एडमिशन कंट्रोल से जुड़ी नीतियां
बाइनरी ऑथराइज़ेशन, 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
- 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
9. GKE (जीकेई) में जोखिम की आशंकाओं को ब्लॉक करें
इस सेक्शन में, आपने अब तक जो कुछ भी सीखा है उसे Cloud Build के साथ लागू करके, इमेज को स्कैन करने के लिए सीआई/सीडी पाइपलाइन का इस्तेमाल किया जाएगा. इसके बाद, इमेज पर हस्ताक्षर करने और उसे डिप्लॉय करने से पहले, जोखिम की आशंकाओं की जांच की जाएगी. इमेज को चलाने से पहले, 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
नीति लागू करें
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 (जीकेई) को कैसे कॉन्फ़िगर करें
आने वाले समय में मिलने वाली सुविधाएं:
- Cloud Run और Google Kubernetes Engine पर इमेज डिप्लॉयमेंट को सुरक्षित करना | Cloud Build के दस्तावेज़
- क्विकस्टार्ट: GKE (जीकेई) के साथ बाइनरी ऑथराइज़ेशन नीति कॉन्फ़िगर करें | Google क्लाउड
व्यवस्थित करें
इस ट्यूटोरियल में इस्तेमाल किए गए संसाधनों के लिए, आपके Google Cloud खाते पर शुल्क न लगे. इसके लिए, उस प्रोजेक्ट को मिटा दें जिसमें संसाधन शामिल हैं या प्रोजेक्ट को बनाए रखें और अलग-अलग संसाधनों को मिटाएं.
प्रोजेक्ट मिटाया जा रहा है
बिलिंग हटाने का सबसे आसान तरीका, ट्यूटोरियल के लिए बनाए गए प्रोजेक्ट को मिटाना है.