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

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

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

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

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

Cloud Shell चालू करें

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

55efc1aaa7a4d3ad.png

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

9c92662c6a846a5c.png

Cloud Shell को प्रोवाइड करने और उससे कनेक्ट होने में सिर्फ़ कुछ मिनट लगेंगे.

9f0e51b578fecce5.png

इस वर्चुअल मशीन में, डेवलपमेंट के लिए ज़रूरी सभी टूल लोड होते हैं. यह 5 जीबी की होम डायरेक्ट्री उपलब्ध कराती है और 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. gcloud कमांड को आपके प्रोजेक्ट के बारे में पता है या नहीं, इसकी पुष्टि करने के लिए Cloud Shell में यह कमांड चलाएं:
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 सेवा एपीआई को चालू करें, जो आपके ऐप्लिकेशन को चलाएगा. साथ ही, Firestore API को चालू करें, जो NoSQL डेटा स्टोरेज उपलब्ध कराएगा. इसके अलावा, Cloud Build API को चालू करें, जिसका इस्तेमाल डिप्लॉयमेंट कमांड के लिए किया जाएगा. साथ ही, आर्टफ़ैक्ट रजिस्ट्री को चालू करें, जिसका इस्तेमाल ऐप्लिकेशन कंटेनर को बिल्ड करते समय किया जाएगा:
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 देखें, जिसमें इस ऐप्लिकेशन को डिप्लॉय करने के लिए ज़रूरी चरणों के बारे में बताया गया है. इनमें से कुछ चरणों में, सुरक्षा से जुड़े ऐसे फ़ैसले शामिल हो सकते हैं जिन पर आपको विचार करना पड़े. डिप्लॉय किए गए ऐप्लिकेशन की सुरक्षा को बेहतर बनाने के लिए, आपको इनमें से कुछ विकल्पों में बदलाव करना होगा. इनके बारे में यहां बताया गया है:

तीसरा चरण - npm install चलाना

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

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

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

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

छठा से लेकर ग्यारहवां चरण - सही तरीके से काम करने की पुष्टि करने के लिए, सैंपल वेब अनुरोध करना

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

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

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

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

सेवा खाता बनाना और उसे Firestore/Datastore का ज़रूरी ऐक्सेस देना

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 फ़ाइल में बदलाव करके, पुष्टि किए बिना ऐक्सेस करने की अनुमति न दें(–no-allow-unauthenticated). साथ ही, डिप्लॉय किए गए ऐप्लिकेशन के लिए नया सेवा खाता(–service-account) तय करें. 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

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

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

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

Authorization: Bearer identity-token

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

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

Google Cloud CLI टूल, पुष्टि किए गए डिफ़ॉल्ट उपयोगकर्ता के लिए टोकन दे सकता है. अपने खाते के लिए आइडेंटिटी टोकन पाने और उसे 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":[]}

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

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

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

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

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

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

जोड़े गए Authorization हेडर के साथ अनुरोध करने के लिए, 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 Eats के अन्य कोडलैब एक्सप्लोर करें:

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

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

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

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