Cloud Run पर सुरक्षित रूप से डिप्लॉय करना

1. खास जानकारी

आपको सुरक्षा को बेहतर बनाने के लिए, किसी सेवा को Cloud Run पर डिप्लॉय करने के डिफ़ॉल्ट चरणों में बदलाव करना होगा. इसके बाद, आपको डिप्लॉय किए गए ऐप्लिकेशन को सुरक्षित तरीके से ऐक्सेस करने का तरीका पता चलेगा. ऐप्लिकेशन एक "पार्टनर रजिस्ट्रेशन सेवा" हो Cymbal Eagles ऐप्लिकेशन का इस्तेमाल कर रही थी. इस ऐप्लिकेशन का इस्तेमाल ऐसी कंपनियां करती हैं जो खाने के ऑर्डर को प्रोसेस करने के लिए, Cymbal Eagles के साथ काम करती हैं.

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

Cloud Run पर किसी ऐप्लिकेशन को डिप्लॉय करने के बुनियादी डिफ़ॉल्ट चरणों में कुछ छोटे-छोटे बदलाव करके, ऐप्लिकेशन की सुरक्षा को बेहतर बनाया जा सकता है. आपको डिप्लॉय किए गए ऐप्लिकेशन और उसके डिप्लॉयमेंट के निर्देशों का पालन करना होगा. साथ ही, डिप्लॉय किए गए ऐप्लिकेशन की सुरक्षा को बेहतर बनाने के लिए, डिप्लॉयमेंट के चरणों में बदलाव करना होगा.

इसके बाद, आपको ऐप्लिकेशन के ऐक्सेस की अनुमति देने और अनुमति पाने का अनुरोध करने का तरीका बताया जाएगा..

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

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

Cloud Shell चालू करें

  1. Cloud Console में, Cloud Shell चालू करें 853e55310c205094.png पर क्लिक करें.

55efc1aaa7a4d3ad.png

अगर आपने Cloud Shell का इस्तेमाल पहले कभी नहीं किया है, तो आपको इसके बारे में जानकारी देने वाली एक इंटरमीडिएट स्क्रीन (पेज के फ़ोल्ड के नीचे) दिखेगी. अगर ऐसा है, तो जारी रखें पर क्लिक करें (यह आपको फिर कभी नहीं दिखेगा). एक बार इस्तेमाल होने वाली स्क्रीन कुछ इस तरह दिखती है:

9c92662c6a846a5c.png

प्रावधान करने और Cloud Shell से कनेक्ट होने में कुछ ही समय लगेगा.

9f0e51b578fecce5.png

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

Cloud Shell से कनेक्ट करने के बाद, आपको दिखेगा कि आपकी पुष्टि पहले ही हो चुकी है. साथ ही, यह प्रोजेक्ट पहले से ही आपके प्रोजेक्ट आईडी पर सेट है.

  1. यह पुष्टि करने के लिए Cloud Shell में नीचे दिया गया कमांड चलाएं कि आपकी पुष्टि हो गई है:
gcloud auth list

कमांड आउटपुट

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`
  1. Cloud Shell में यह कमांड चलाएं, ताकि यह पुष्टि की जा सके कि gcloud के लिए कमांड को आपके प्रोजेक्ट के बारे में जानकारी है:
gcloud config list project

कमांड आउटपुट

[core]
project = <PROJECT_ID>

अगर ऐसा नहीं है, तो आप इसे इस निर्देश की मदद से सेट कर सकते हैं:

gcloud config set project <PROJECT_ID>

कमांड आउटपुट

Updated property [core/project].

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

इस लैब के लिए, Cloud Shell की कमांड लाइन में कमांड चलाए जाएंगे. आम तौर पर, निर्देशों को कॉपी करके उन्हें बिना किसी बदलाव के चिपकाया जा सकता है. हालांकि, कुछ मामलों में आपको प्लेसहोल्डर वैल्यू को सही करने के लिए, उनमें बदलाव करना होगा.

  1. बाद के निर्देशों में इस्तेमाल करने के लिए, प्रोजेक्ट आईडी पर एनवायरमेंट वैरिएबल सेट करें:
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export SERVICE_NAME=partner-registration-service
  1. आपके ऐप्लिकेशन को चलाने वाले Cloud Run Service API को चालू करें. इसमें NoSQL डेटा स्टोरेज देने वाला Firestore API, डिप्लॉयमेंट कमांड के लिए इस्तेमाल किया जाने वाला Cloud Build API, और उस Artifact Registry को चालू करना होगा जिसका इस्तेमाल ऐप्लिकेशन कंटेनर को बनाए जाने के दौरान किया जाएगा:
gcloud services enable \
  run.googleapis.com \
  firestore.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com
  1. नेटिव मोड में Firestore डेटाबेस शुरू करें. यह निर्देश App Engine API का इस्तेमाल करता है, इसलिए पहले उसे चालू किया जाना चाहिए.

निर्देश में App Engine के लिए एक क्षेत्र तय किया जाना चाहिए, जिसका हम इस्तेमाल नहीं करेंगे, लेकिन उसे ऐतिहासिक वजहों से और डेटाबेस के लिए एक क्षेत्र बनाना होगा. हम App Engine के लिए us-central और डेटाबेस के लिए nam5 का इस्तेमाल करेंगे. nam5 अमेरिका के एक से ज़्यादा इलाकों में मौजूद है. एक से ज़्यादा इलाकों वाले डेटा सोर्स से, डेटाबेस की उपलब्धता और उसके लंबे समय तक काम करने की संभावना बढ़ जाती है.

gcloud services enable appengine.googleapis.com

gcloud app create --region=us-central
gcloud firestore databases create --region=nam5
  1. सैंपल ऐप्लिकेशन रिपॉज़िटरी का क्लोन बनाएं और डायरेक्ट्री पर जाएं
git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git

cd cymbal-eats/partner-registration-service

3. README की समीक्षा करें

एडिटर खोलें और ऐप्लिकेशन में मौजूद फ़ाइलें देखें. README.md देखें. इसमें इस ऐप्लिकेशन को डिप्लॉय करने का तरीका बताया गया है. इनमें से कुछ चरणों पर विचार करने के लिए, सीधे तौर पर या साफ़ तौर पर सुरक्षा से जुड़े फ़ैसले लिए जा सकते हैं. डिप्लॉय किए गए अपने ऐप्लिकेशन की सुरक्षा को बेहतर बनाने के लिए, आपको इनमें से कुछ विकल्प बदलने होंगे. इसके बारे में यहां बताया गया है:

चरण 3 - npm install चलाएं

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

चौथा और पांचवां चरण - deploy.sh में बदलाव करें और चलाएं

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

  1. अप्रमाणित ऐक्सेस की अनुमति न दें. एक्सप्लोरेशन के दौरान चीज़ों को आज़माने की अनुमति देना आसान हो सकता है. हालांकि, इस वेब सेवा का इस्तेमाल कमर्शियल पार्टनर करते हैं और इसके लिए हमेशा अपने उपयोगकर्ताओं की पुष्टि करनी चाहिए.
  2. तय करें कि ऐप्लिकेशन को किसी ऐसे सेवा खाते का इस्तेमाल करना चाहिए जो सिर्फ़ ज़रूरी खास अधिकारों के साथ बनाया गया हो. इस खाते का इस्तेमाल करने के लिए, किसी ऐसे सेवा खाते का इस्तेमाल करना ज़रूरी नहीं है जिसके पास ज़रूरत से ज़्यादा एपीआई और संसाधन का ऐक्सेस हो. इसे कम से कम अधिकारों का सिद्धांत कहा जाता है और यह ऐप्लिकेशन की सुरक्षा का एक बुनियादी सिद्धांत है.

चरण 6 से 11 - सही व्यवहार की पुष्टि करने के लिए सैंपल वेब अनुरोध बनाएं

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

4. सेवा को सुरक्षित रूप से डिप्लॉय करें

deploy.sh स्क्रिप्ट में ज़रूरत के मुताबिक, दो बदलावों की पहचान की गई: बिना पुष्टि वाले ऐक्सेस की अनुमति नहीं है और बहुत कम खास अधिकारों वाले सेवा खाते का इस्तेमाल किया जा रहा है.

आपको सबसे पहले एक नया सेवा खाता बनाना होगा. इसके बाद, उस सेवा खाते का रेफ़रंस देने और बिना पुष्टि किए ऐक्सेस न देने के लिए, deploy.sh स्क्रिप्ट में बदलाव करना होगा. इसके बाद, बदली गई डिप्लॉय स्क्रिप्ट चलाने से पहले, बदली गई स्क्रिप्ट चलाकर सेवा को डिप्लॉय करना होगा..

एक सेवा खाता बनाएं और उसे Firestore/डेटास्टोर का ज़रूरी ऐक्सेस दें

gcloud iam service-accounts create partner-sa

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:partner-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role=roles/datastore.user

deploy.sh में बदलाव करें

deploy.sh फ़ाइल में बदलाव करके, बिना पुष्टि वाले ऐक्सेस को अनुमति न दें(–बिना पुष्टि वाला ऐक्सेस नहीं) और डिप्लॉय किए गए ऐप्लिकेशन के लिए नया सेवा खाता(–सेवा-खाता) तय करें. GOOGLE_PROJECT_ID को सही करके अपने प्रोजेक्ट का आईडी बनाएं.

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

gcloud run deploy $SERVICE_NAME \
  --source . \
  --platform managed \
  --region ${REGION} \
  --no-allow-unauthenticated \
  --project=$PROJECT_ID \
  --service-account=partner-sa@${PROJECT_ID}.iam.gserviceaccount.com

सेवा को डिप्लॉय करें

कमांड लाइन से, deploy.sh स्क्रिप्ट चलाएं:

./deploy.sh

डिप्लॉयमेंट पूरा होने के बाद, कमांड आउटपुट की आखिरी लाइन में नए ऐप्लिकेशन की सेवा का यूआरएल दिखेगा. यूआरएल को किसी एनवायरमेंट वैरिएबल में सेव करें:

export SERVICE_URL=<URL from last line of command output>

अब curl टूल का इस्तेमाल करके, ऐप्लिकेशन से कोई ऑर्डर फ़ेच करने की कोशिश करें:

curl -i -X GET $SERVICE_URL/partners

curl निर्देश के लिए -i फ़्लैग इसे आउटपुट में रिस्पॉन्स हेडर शामिल करने के बारे में बताता है. आउटपुट की पहली लाइन यह होनी चाहिए:

HTTP/2 403

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

5. पुष्टि किए गए अनुरोध करें

डिप्लॉय किए गए ऐप्लिकेशन को, वेब अनुरोध करके शुरू किया जाता है. Cloud Run के लिए इनकी पुष्टि करना ज़रूरी है. वेब अनुरोधों की पुष्टि, फ़ॉर्म में Authorization हेडर शामिल करके की जाती है:

Authorization: Bearer identity-token

आइडेंटिटी-टोकन, एक छोटा शब्द होता है. यह क्रिप्टोग्राफ़िक तरीके से हस्ताक्षर किया गया और कोड में बदला गया ऐसा स्ट्रिंग होता है जिसे पुष्टि करने वाली किसी भरोसेमंद कंपनी की ओर से जारी किया जाता है. इस मामले में, Google की ओर से जारी किया गया एक ऐसा मान्य पहचान टोकन ज़रूरी है जिसकी समयसीमा खत्म न हुई हो.

अपने उपयोगकर्ता खाते के तौर पर अनुरोध करना

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

export ID_TOKEN=$(gcloud auth print-identity-token)

डिफ़ॉल्ट रूप से, Google की ओर से जारी किए गए आइडेंटिटी टोकन एक घंटे के लिए मान्य होते हैं. पहले अस्वीकार किए गए अनुरोध को करने के लिए, नीचे दिया गया curl कमांड चलाएं, क्योंकि उसे अनुमति नहीं दी गई थी. इस निर्देश में ज़रूरी हेडर शामिल होगा:

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

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

{"status":"success","data":[]}

अभी तक कोई पार्टनर नहीं है.

दो curl निर्देशों की मदद से, डायरेक्ट्री में JSON के सैंपल डेटा का इस्तेमाल करके, पार्टनर को रजिस्टर करें:

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner.json" \
  $SERVICE_URL/partner

और

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner2.json" \
  $SERVICE_URL/partner

रजिस्टर किए गए सभी पार्टनर को देखने के लिए, जीईटी से जुड़ा पिछला अनुरोध अभी दोहराएं:

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

आपको JSON डेटा में काफ़ी ज़्यादा कॉन्टेंट दिखेगा. इसमें, रजिस्टर किए गए दोनों पार्टनर के बारे में जानकारी मिलेगी.

बिना अनुमति वाले खाते के तौर पर अनुरोध करना

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

पिछले अनुरोध में इस्तेमाल किए गए डिफ़ॉल्ट खाते को अनुमति दी गई थी, क्योंकि इस खाते से प्रोजेक्ट बनाया गया था. साथ ही, डिफ़ॉल्ट रूप से इसी खाते ने खाते में किसी भी Cloud Run ऐप्लिकेशन शुरू करने की अनुमति दी थी. ज़रूरत पड़ने पर वह अनुमति वापस ली जा सकती है, जो प्रोडक्शन ऐप्लिकेशन में ज़रूरी होती है. इसके बजाय, अब आपको एक नया सेवा खाता बनाना होगा, जिसमें कोई खास अधिकार या भूमिकाएं असाइन नहीं की गई होंगी. इसके बाद, डिप्लॉय किए गए ऐप्लिकेशन को ऐक्सेस करने के लिए इसका इस्तेमाल करें.

  1. tester नाम का सेवा खाता बनाएं.
gcloud iam service-accounts create tester
  1. आपको इस नए खाते के लिए आइडेंटिटी टोकन की तरह ही, अपने डिफ़ॉल्ट खाते के लिए पहचान टोकन मिलेगा. हालांकि, इसके लिए आपके डिफ़ॉल्ट खाते को, सेवा खातों के नाम पर काम करने की अनुमति होनी चाहिए. अपने खाते को यह अनुमति दें.
export USER_EMAIL=$(gcloud config list account --format "value(core.account)")

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="user:$USER_EMAIL" \
  --role=roles/iam.serviceAccountTokenCreator
  1. अब TEST_पहचान के एनवायरमेंट वैरिएबल में इस नए खाते के लिए पहचान टोकन सेव करने के लिए, नीचे दिया गया निर्देश चलाएं. अगर निर्देश में गड़बड़ी का मैसेज दिखता है, तो एक या दो मिनट इंतज़ार करें और फिर से कोशिश करें.
export TEST_TOKEN=$( \
  gcloud auth print-identity-token \
    --impersonate-service-account \
    "tester@$PROJECT_ID.iam.gserviceaccount.com" \
)
  1. पहले की तरह ही पुष्टि किया गया वेब अनुरोध करें, लेकिन इस पहचान टोकन का इस्तेमाल करें:
curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

कमांड आउटपुट फिर से HTTP/2 403 से शुरू होगा, क्योंकि अनुरोध की पुष्टि की गई है, लेकिन उसे अनुमति नहीं दी गई है. नए सेवा खाते से इस ऐप्लिकेशन को शुरू करने की अनुमति नहीं है.

किसी खाते को अनुमति देना

किसी उपयोगकर्ता या सेवा खाते के लिए अनुरोध करने के लिए, उसके पास Cloud Run सेवा पर Cloud Run Invoker की भूमिका होनी चाहिए. टेस्टर सेवा खाते को यह निर्देश दें:

export REGION=us-central1
gcloud run services add-iam-policy-binding ${SERVICE_NAME} \
  --member="serviceAccount:tester@$PROJECT_ID.iam.gserviceaccount.com" \
  --role=roles/run.invoker \
  --region=${REGION}

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

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

कमांड आउटपुट अब HTTP/1.1 200 OK से शुरू होता है और आख़िरी लाइन में JSON रिस्पॉन्स होता है. इस अनुरोध को Cloud Run ने स्वीकार किया और ऐप्लिकेशन ने इसे प्रोसेस किया.

6. पुष्टि करने वाले प्रोग्राम बनाम उपयोगकर्ताओं की पुष्टि करना

आपने अब तक पुष्टि के लिए जो अनुरोध किए हैं उनमें अब curl कमांड-लाइन टूल का इस्तेमाल किया गया है. इसके बजाय, कुछ अन्य टूल और प्रोग्रामिंग भाषाओं का इस्तेमाल किया जा सकता है. हालांकि, सादे वेब पेजों वाले वेब ब्राउज़र का इस्तेमाल करके, पुष्टि किए गए Cloud Run अनुरोध नहीं किए जा सकते. अगर कोई उपयोगकर्ता किसी लिंक पर क्लिक करता है या वेब पेज पर फ़ॉर्म सबमिट करने के लिए किसी बटन पर क्लिक करता है, तो ब्राउज़र पुष्टि किए गए अनुरोधों के लिए Cloud Run के लिए ज़रूरी Authorization हेडर नहीं जोड़ेगा.

Cloud Run के पहले से मौजूद पुष्टि करने के तरीके को प्रोग्राम के लिए बनाया गया है, न कि असली उपयोगकर्ता.

ध्यान दें:

Cloud Run उपयोगकर्ताओं के लिए उपलब्ध वेब ऐप्लिकेशन को होस्ट कर सकती है, लेकिन इस तरह के ऐप्लिकेशन को Cloud Run सेट करना होगा, ताकि उपयोगकर्ताओं की ओर से पुष्टि न किए गए अनुरोधों को अनुमति दी जा सके वेब ब्राउज़र पर. अगर ऐप्लिकेशन के लिए उपयोगकर्ता की पुष्टि करना ज़रूरी हो, तो ऐप्लिकेशन को Cloud Run के लिए कहने के बजाय इसे हैंडल करना होगा. ऐप्लिकेशन ऐसा उसी तरह कर सकता है जिस तरह Cloud Run के बाहर के वेब ऐप्लिकेशन करते हैं. इस प्रोसेस को करने का तरीका, इस कोडलैब के दायरे से बाहर है.

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

Python प्रोग्राम से पुष्टि किए गए अनुरोध

कोई प्रोग्राम, स्टैंडर्ड एचटीटीपी वेब अनुरोधों का इस्तेमाल करके, सुरक्षित Cloud Run ऐप्लिकेशन के लिए पुष्टि किए गए अनुरोध कर सकता है. हालांकि, अनुरोध में एक Authorization हेडर शामिल होता है. इन प्रोग्राम के लिए सिर्फ़ एक नई चुनौती यह है कि उसे हेडर में एक मान्य और मौजूदा पहचान टोकन मिल सके. इस टोकन की पुष्टि, Cloud Run करेगी. इसके लिए, Google Cloud Identity and Access Management (IAM) का इस्तेमाल किया जाएगा. इसलिए, टोकन को IAM से मान्यता पा चुकी किसी संस्था से जारी और हस्ताक्षर किया जाना चाहिए. ऐसी क्लाइंट लाइब्रेरी कई भाषाओं में उपलब्ध हैं जिनका इस्तेमाल प्रोग्राम, इस तरह के टोकन को जारी करने का अनुरोध करने के लिए कर सकते हैं. इस उदाहरण में, Python google.auth क्लाइंट लाइब्रेरी का इस्तेमाल किया जाएगा. आम तौर पर वेब अनुरोध करने के लिए, कई Python लाइब्रेरी मौजूद हैं; इस उदाहरण में, लोकप्रिय requests मॉड्यूल का इस्तेमाल किया गया है.

पहला चरण दो क्लाइंट लाइब्रेरी इंस्टॉल करना है:

pip install google-auth
pip install requests

डिफ़ॉल्ट उपयोगकर्ता के लिए, पहचान टोकन का अनुरोध करने के लिए Python कोड यह है:

credentials, _ = google.auth.default()
credentials.refresh(google.auth.transport.requests.Request())
identity_token = credentials.id_token

अगर अपने कंप्यूटर पर Cloud Shell जैसे कमांड शेल या स्टैंडर्ड टर्मिनल शेल का इस्तेमाल किया जा रहा है, तो उस शेल के अंदर पुष्टि करने वाले उपयोगकर्ता को डिफ़ॉल्ट उपयोगकर्ता माना जाता है. Cloud Shell में यह वही उपयोगकर्ता होता है जिसने Google में लॉग इन किया होता है. अन्य मामलों में, यह gcloud auth login या अन्य gcloud कमांड से पुष्टि किए गए उपयोगकर्ता होता है. अगर उपयोगकर्ता ने कभी लॉग इन नहीं किया है, तो कोई भी डिफ़ॉल्ट उपयोगकर्ता नहीं होगा और यह कोड काम नहीं करेगा.

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

जोड़े गए ऑथराइज़ेशन हेडर के साथ अनुरोध करने के लिए, Python कोड यह है:

auth_header = {"Authorization": "Bearer " + identity_token}
response = requests.get(url, headers=auth_header)

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

cat > ./print_partners.py << EOF
def print_partners():
    import google.auth
    import google.auth.transport.requests
    import requests

    credentials, _ = google.auth.default()
    credentials.refresh(google.auth.transport.requests.Request())
    identity_token = credentials.id_token

    auth_header = {"Authorization": "Bearer " + identity_token}
    response = requests.get("${SERVICE_URL}/partners", headers=auth_header)

    parsed_response = response.json()
    partners = parsed_response["data"]

    for partner in partners:
        print(f"{partner['partnerId']}: {partner['name']}")


print_partners()
EOF

आप इस प्रोग्राम को शेल कमांड से चलाएंगे. आपको पहले डिफ़ॉल्ट उपयोगकर्ता के तौर पर अपनी पुष्टि करनी होगी. इसके बाद ही, प्रोग्राम उन क्रेडेंशियल का इस्तेमाल कर पाएगा. नीचे दिया गया gcloud auth कमांड चलाएं:

gcloud auth application-default login

लॉगिन पूरा करने के लिए, निर्देशों का पालन करें. फिर कमांड लाइन से प्रोग्राम चलाएं:

python print_partners.py

आउटपुट कुछ ऐसा दिखेगा:

10102: Zippy food delivery
67292: Foodful

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

7. बधाई हो!

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

आने वाले समय में मिलने वाली सुविधाएं:

Cymbal Eagles के अन्य कोडलैब एक्सप्लोर करें:

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

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

प्रोजेक्ट मिटाया जा रहा है

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