वीपीसी सेवा नियंत्रण - BigQuery सुरक्षा कोडलैब (कोड बनाना सीखना) I

1. परिचय

इस कोडलैब में, आपको VPC सर्विस कंट्रोल का इस्तेमाल करके, BigQuery API को सुरक्षित बनाने का तरीका बताया जाएगा. यह कोडलैब, सेवा के दायरे से सुरक्षित न की गई किसी भी एपीआई सेवा के साथ शुरू होता है. इससे सार्वजनिक डेटासेट पर क्वेरी चलाने और नतीजों को प्रोजेक्ट टेबल में सेव करने की अनुमति मिलती है. क्वेरी एक प्रोजेक्ट में चलती है और टेबल (जहां नतीजे सेव किए जाते हैं) दूसरे प्रोजेक्ट में बनाई जाती है. यह उस सेटअप की तरह काम करता है जहां डेटा को एक प्रोजेक्ट में सेव किया जा सकता है, लेकिन इसे किसी दूसरे प्रोजेक्ट का इस्तेमाल करके ऐक्सेस करना होता है.

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

• जानें कि इनग्रेस और इग्रेस के नियमों का इस्तेमाल करके, इनग्रेस और इग्रेस के उल्लंघनों को कैसे ठीक किया जाता है.
• जानें कि उल्लंघन क्यों हुआ.
• उल्लंघन ठीक करने के लिए लागू किए गए तरीके के स्कोप का विश्लेषण करें.
• ऐक्सेस लेवल का इस्तेमाल करके, वीपीसी नेटवर्क में मौजूद इंटरनल आईपी पतों से ट्रैफ़िक की अनुमति देने के विकल्प का फ़ायदा पाएं. इससे, फ़िक्स (इंग्रेस / इग्रेस नियम) के स्कोप को बदला जा सकता है.

2. संसाधन सेटअप करने और उनसे जुड़ी ज़रूरी शर्तें

शुरू करने से पहले

इस कोडलैब में, हम यह मानकर चल रहे हैं कि आपको पहले से ही इन बातों के बारे में पता है:

• BigQuery क्वेरी चलाने के बारे में बुनियादी जानकारी: BigQuery में Wikipedia के डेटासेट की क्वेरी करने का तरीका जानने के लिए, यह कोडलैब देखें
• फ़ोल्डर बनाने और उसे मैनेज करने का तरीका
• किसी फ़ोल्डर में प्रोजेक्ट बनाने या किसी मौजूदा प्रोजेक्ट को किसी फ़ोल्डर में ले जाने का तरीका
• स्कोप किए गए ऐक्सेस की नीति बनाने का तरीका
• सर्विस पेरीमीटर बनाने और उसे कॉन्फ़िगर करने का तरीका
• लॉग में सुरक्षा नीति के उल्लंघन का पता लगाने का तरीका

सेटअप

हमारा शुरुआती सेटअप इस तरह से डिज़ाइन किया गया है:

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

• Google Cloud संगठन.
• संगठन के तहत मौजूद फ़ोल्डर. इस कोडलैब के लिए, हम इसे codelab-folder कहेंगे.
• एक ही फ़ोल्डर में रखे गए दो Google Cloud प्रोजेक्ट, codelab-folder. इस कोडलैब के लिए, हम इन्हें project-1 और project-2 कहते हैं
  • अगर आपने पहले से फ़ोल्डर और प्रोजेक्ट नहीं बनाए हैं, तो Google Cloud Console में जाकर, संगठन के तहत एक फ़ोल्डर बनाएं. इसके बाद, बनाए गए फ़ोल्डर के तहत दो नए प्रोजेक्ट बनाएं.
• ज़रूरी अनुमतियां:
  • फ़ोल्डर मैनेज करने के लिए IAM भूमिकाएं: फ़ोल्डर लेवल पर असाइन की जाती हैं
  • प्रोजेक्ट मैनेज करने के लिए IAM भूमिकाएं: प्रोजेक्ट लेवल पर असाइन की जाती हैं
  • VPC सर्विस कंट्रोल को कॉन्फ़िगर करने के लिए ज़रूरी IAM भूमिकाएं: संगठन लेवल पर असाइन की गई
  • BigQuery को मैनेज करने के लिए IAM की भूमिकाएं: प्रोजेक्ट लेवल पर असाइन की जाती हैं
  • Compute Engine इंस्टेंस को मैनेज करने के लिए IAM भूमिकाएं: प्रोजेक्ट लेवल पर असाइन की जाती हैं
• दोनों प्रोजेक्ट, project-2 और project-1 के लिए बिलिंग खाता.

इस कोडलैब के लिए, आपको पहले से तय की गई ये भूमिकाएं दी जा सकती हैं: फ़ोल्डर एडमिन और प्रोजेक्ट क्रिएटर (फ़ोल्डर लेवल पर), मालिक (प्रोजेक्ट लेवल पर), BigQuery एडमिन (प्रोजेक्ट लेवल पर), और ऐक्सेस कॉन्टेक्स्ट मैनेजर एडमिन (संगठन लेवल पर). इससे आपको इस पूरे कोडलैब के लिए ज़रूरी संसाधन सेट अप करने में मदद मिलेगी.

नियमित सर्विस पेरीमीटर बनाना

इस कोडलैब में, हम project-1 की सुरक्षा करने वाले रेगुलर सर्विस पेरीमीटर का इस्तेमाल करेंगे.

• नियमित पैरामीटर बनाएं, perimeter-1, और project-1 जोड़ें.

पेरीमीटर में, अभी किसी भी सेवा पर पाबंदी न लगाएं. हम इसे बाद में करेंगे.

Compute Engine वीएम बनाना

इस कोडलैब में, हम project-2 में मौजूद एक Compute Engine इंस्टेंस का इस्तेमाल करेंगे. यह us-central1 में मौजूद है और default नाम के डिफ़ॉल्ट वीपीसी नेटवर्क का इस्तेमाल करता है.

• सार्वजनिक इमेज से Compute Engine इंस्टेंस बनाने के लिए, दिशा-निर्देश के तौर पर दस्तावेज़ देखा जा सकता है.

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

लागत

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

BigQuery और Compute Engine इंस्टेंस का इस्तेमाल करने पर शुल्क लगता है. BigQuery के प्राइसिंग कैलकुलेटर और Compute Engine के प्राइसिंग कैलकुलेटर का इस्तेमाल करके, लागत का अनुमान लगाया जा सकता है.

3. वीपीसी सर्विस कंट्रोल की पाबंदियों के बिना BigQuery का ऐक्सेस

सार्वजनिक डेटासेट को क्वेरी करना और नतीजों को project-1 में सेव करना

1. BigQuery Studio पेज पर जाकर, यह पुष्टि करें कि आपके पास BigQuery API को ऐक्सेस करने की अनुमति है या नहीं. इसके लिए, project-2 और project-1 को ऐक्सेस करें. आपको ऐसा करने की अनुमति होनी चाहिए, क्योंकि भले ही project-1 किसी सर्विस पेरीमीटर में हो, लेकिन पेरीमीटर अभी तक किसी सेवा की सुरक्षा नहीं कर रहा है.
2. project-2 में जाकर, सार्वजनिक डेटासेट की क्वेरी चलाने के लिए, यह क्वेरी चलाएं.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

सार्वजनिक डेटासेट के लिए क्वेरी चलाने के बाद (project-2 में रहते हुए):

1. नतीजे सेव करें पर क्लिक करें और BigQuery टेबल चुनें. (नीचे दिया गया स्क्रीनशॉट देखें).
2. डेस्टिनेशन प्रोजेक्ट के तौर पर project-1 चुनें.
3. डेटासेट का नाम codelab_dataset रखें. (अगर किसी मौजूदा डेटासेट का इस्तेमाल नहीं किया जा रहा है, तो नया डेटासेट बनाएं को चुनें).
4. टेबल का नाम codelab-table रखें.
5. सेव करें पर क्लिक करें.

project-2 से क्वेरी चलाने के बाद, सार्वजनिक डेटासेट का डेटा project-1 में सेव कर दिया गया है.

क्वेरी डेटासेट को project-2 से project-1 में सेव किया गया

project-2 BigQuery Studio में रहते हुए, यहां दी गई क्वेरी चलाएं. इससे आपको इन जगहों से डेटा चुनने में मदद मिलेगी:

• प्रोजेक्ट: project-1
• डेटासेट: codelab_dataset
• टेबल: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

क्वेरी को सही तरीके से चलना चाहिए, क्योंकि न तो project-2 और न ही project-1 को BigQuery का इस्तेमाल करने से रोका गया है. BigQuery को किसी भी जगह से ऐक्सेस किया जा सकता है. इसके लिए, उपयोगकर्ता के पास IAM की ज़रूरी अनुमतियां होनी चाहिए.

इस डायग्राम में, यह प्रोसेस दिखाई गई है कि जब कोई प्रिंसिपल, BigQuery डेटासेट के लिए क्वेरी करता है, तब क्या होता है. हर BigQuery क्वेरी से एक BigQuery जॉब शुरू होता है. इसके बाद, यह जॉब असल कार्रवाई करता है. इस उदाहरण में, यह कार्रवाई डेटा वापस पाना है. Compute Engine इंस्टेंस और इंटरनेट से मुख्य ऐक्सेस दिखाया गया है. साथ ही, सार्वजनिक डेटासेट और किसी दूसरे Google Cloud प्रोजेक्ट से क्वेरी की गई है. डेटा (GetData) को क्वेरी करने की प्रोसेस पूरी हो गई है. इसे वीपीसी सर्विस कंट्रोल ने ब्लॉक नहीं किया है.

4. सोर्स डेटासेट प्रोजेक्ट में BigQuery API को सुरक्षित करना

पेरीमीटर perimeter-1 के कॉन्फ़िगरेशन में बदलाव करें. साथ ही, सुरक्षित किए गए संसाधन project-1 के साथ-साथ BigQuery API सेवा को भी सीमित करें.

सिर्फ़ पुष्टि किए गए ऐप्लिकेशन डाउनलोड किए जा सकें

पिछले चरण की तरह, project-2 से BigQuery Studio में यह क्वेरी चलाएं:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

वीपीसी सर्विस कंट्रोल RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER का उल्लंघन होगा

उल्लंघन का ऑडिट लॉग, project-1 में दिखेगा. ऐसा इसलिए, क्योंकि उल्लंघन इसी जगह पर हुआ था. लॉग को, देखे गए vpcServiceControlsUniqueId के हिसाब से फ़िल्टर किया जा सकता है (VPC_SC_DENIAL_UNIQUE_ID को देखे गए यूनीक आईडी से बदलें).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

उल्लंघन egressViolations है. इसमें ये शामिल हैं:

• principalEmail: [क्वेरी चलाने वाला उपयोगकर्ता खाता]
• callerIp: [The IP address of the user agent running the query]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. BigQuery जॉब बनाने के लिए उल्लंघन ठीक करना

BigQuery के काम करने के तरीके की वजह से, वीपीसी सर्विस कंट्रोल के उल्लंघन में bigquery.jobs.create को टारगेट अनुमति के तौर पर सेट किया गया है. BigQuery डेटा को मैनेज करने के लिए, Google Cloud Console या bq कमांड-लाइन टूल का इस्तेमाल करने पर, BigQuery जॉब बनाता है. इनका इस्तेमाल, ज़रूरी कार्रवाइयां पूरी करने के लिए किया जाता है. इस बीच, पहला इवेंट BigQuery जॉब बनाना है.

इस डायग्राम में दिखाया गया है कि जब कोई प्रिंसिपल, project-1 में मौजूद किसी डेटासेट के लिए project-2 से क्वेरी चलाता है, तब क्या होता है. क्वेरी चलाने वाले प्रोजेक्ट (project-2) में मौजूद डेटासेट प्रोजेक्ट (project-1) से, BigQuery जॉब बनाने का ऑपरेशन पूरा नहीं हो सका. ऐसा इसलिए हुआ, क्योंकि वीपीसी सर्विस कंट्रोल के इग्रेस डेटा ट्रैफ़िक से जुड़े नियम का उल्लंघन हुआ है. इसकी वजह यह है कि सर्विस पेरीमीटर perimeter-1, BigQuery API को सुरक्षित रखता है. पेरीमीटर लागू होने के बाद, project-1 से पेरीमीटर के बाहर या पेरीमीटर के बाहर से सुरक्षित प्रोजेक्ट के लिए, BigQuery API का कोई अनुरोध शुरू नहीं किया जा सकता. हालांकि, ऐसा तब किया जा सकता है, जब सर्विस पेरीमीटर कॉन्फ़िगरेशन से इसकी अनुमति मिली हो.

डेटा बाहर भेजने से जुड़े उल्लंघन को ठीक करने के लिए, डेटा बाहर भेजने से जुड़ा एक नियम बनाया जा सकता है. यह नियम इन पर आधारित होता है:

• सोर्स (FROM): यानी कि उपयोगकर्ता का ईमेल पता और कॉन्टेक्स्ट (जैसे: कॉलर का आईपी पता, डिवाइस की स्थिति, जगह की जानकारी वगैरह)
• डेस्टिनेशन (TO): यानी कि टारगेट रिसॉर्स, सेवा, और तरीका या अनुमति.

डेटा बाहर भेजने से जुड़े उल्लंघन को ठीक करने के लिए, डेटा बाहर भेजने का ऐसा नियम बनाएं जो BigQuery सेवा और bigquery.jobs.create तरीके/ अनुमति पर, क्वेरी चलाने वाले उपयोगकर्ता खाते ([e-mail]) को targetResource (project-2) की ओर ट्रैफ़िक भेजने की अनुमति देता हो.

कॉन्फ़िगर किए गए इग्रेस नियम के मुताबिक, यह होना चाहिए:

• FROM | Identities: सिर्फ़ तय की गई आइडेंटिटी [e-mail] को पेरीमीटर बाउंड्री पार करने की अनुमति होनी चाहिए.
• TO | projects: बताई गई पहचान, पेरीमीटर की सीमाओं को सिर्फ़ तब पार कर सकती है, जब डेस्टिनेशन, बताया गया प्रोजेक्ट project-2 हो.
• TO | सेवाएं: बताई गई पहचान, पेरीमीटर के बाहर ट्रैफ़िक शुरू कर सकती है. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब एपीआई कॉल बताई गई सेवा और तरीके के लिए हो. इसके अलावा, अगर वे सर्विस पेरीमीटर में सुरक्षित की गई किसी दूसरी सेवा का इस्तेमाल करने की कोशिश करते हैं, तो कार्रवाई को ब्लॉक कर दिया जाएगा. ऐसा इसलिए, क्योंकि अन्य सेवाओं को अनुमति नहीं है.

समस्या हल करने की जांच करना: ईग्रेस नियम

ईग्रैस नियम लागू होने के बाद, उसी क्वेरी को चलाएं.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

इस बार, NO_MATCHING_ACCESS_LEVEL के इनग्रेस से जुड़े उल्लंघन का पता चलेगा. उल्लंघन का नया मामला, टारगेट प्रोजेक्ट और तरीके के हिसाब से पहले मामले से अलग है.

वीपीसी सर्विस कंट्रोल से जुड़े किसी एक उल्लंघन को ठीक करने का मतलब यह नहीं है कि अन्य उल्लंघन नहीं होंगे. अगर कॉन्टेक्स्ट अलग है, तो पहले से कॉन्फ़िगर की गई नीति के हिसाब से एपीआई कॉल करने पर, अलग उल्लंघन होगा.

नया उल्लंघन, इनग्रेस का उल्लंघन है.

• principalEmail: [क्वेरी चलाने वाला उपयोगकर्ता खाता]
• callerIp: [The IP address of the user agent running the query]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

bigquery.tables.getData तरीके के उल्लंघन की वजह, BigQuery जॉब की ओर से शुरू किया गया एपीआई कॉल है. यह कॉल, BigQuery टेबल से डेटा पाने की कोशिश कर रहा है.

यह समझना ज़रूरी है कि कोई एपीआई सेवा कैसे काम करती है, ताकि संभावित उल्लंघनों का अनुमान लगाया जा सके.

6. BigQuery टेबल का डेटा पाने के लिए उल्लंघन ठीक करना

इनग्रेस नियम, इनग्रेस के उल्लंघन को ठीक करता है. साथ ही, यह भी तय करता है कि किसे सेवा के पेरीमीटर की सीमा को पार करने की अनुमति है. इसके अलावा, यह भी तय करता है कि किस कॉन्टेक्स्ट में ऐक्सेस की अनुमति है. जैसे, सोर्स/ टारगेट प्रोजेक्ट और वे एपीआई तरीके जिन्हें वे ऐक्सेस कर सकते हैं.

इनग्रेस के उल्लंघन को इनग्रेस के नियम से ठीक किया जाता है. इसे इनके साथ कॉन्फ़िगर किया जाता है:

• सोर्स (FROM): यानी कि उपयोगकर्ता का ईमेल पता और कॉन्टेक्स्ट (जैसे: कॉल करने वाले का आईपी पता, डिवाइस की स्थिति, जगह की जानकारी वगैरह)
• डेस्टिनेशन (TO): यानी कि टारगेट रिसॉर्स, सेवा, और तरीका या अनुमति.

इनग्रेस नियम के तहत, तय किए गए उपयोगकर्ता को तय की गई सेवा और तरीके से project-1 पर ट्रैफ़िक भेजने की अनुमति होगी.

कॉन्फ़िगर किए गए इनग्रेस नियम के मुताबिक, यह होना चाहिए:

• FROM | Identities: सिर्फ़ तय की गई आइडेंटिटी [e-mail] को पेरीमीटर बाउंड्री पार करने की अनुमति होनी चाहिए.
• TO | projects: बताई गई पहचान, पेरीमीटर की सीमाओं को सिर्फ़ तब पार कर सकती है, जब डेस्टिनेशन, बताया गया प्रोजेक्ट project-1 हो.
• TO | सेवाएं: बताई गई पहचान, पेरीमीटर के अंदर सिर्फ़ तब ट्रैफ़िक शुरू कर सकती है, जब एपीआई कॉल BigQuery API के लिए हो और बताई गई bigquery.tables.getData विधि का इस्तेमाल किया गया हो.

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

हमने project-1 में BigQuery API के इस्तेमाल पर पाबंदी लगा दी है, ताकि इसका इस्तेमाल सिर्फ़ [e-mail] कर सके, न कि [e-mail].

इस डायग्राम में दिखाया गया है कि दो अलग-अलग प्रिंसिपल, एक ही डेटासेट को क्वेरी करने की कोशिश कैसे करते हैं. वीपीसी सर्विस कंट्रोल, [e-mail] (नीले रंग की डॉटेड लाइनें) को ऐक्सेस करने की अनुमति नहीं देते. ऐसा इसलिए, क्योंकि सर्विस पेरीमीटर कॉन्फ़िगरेशन के तहत, उन्हें project-1 से या project-1 की ओर BigQuery ऑपरेशन चलाने की अनुमति नहीं है. [e-mail] (हरी सॉलिड लाइन) को ऐक्सेस मिल गया है, क्योंकि वीपीसी सर्विस कंट्रोल कॉन्फ़िगरेशन के तहत, उन्हें project-1 से और project-1 की ओर ऑपरेशन करने की अनुमति है.

7. इंटरनल आईपी पते के आधार पर, सेवा के दायरे में आने वाले ट्रैफ़िक को सीमित करें

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

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

इंटरनल आईपी पते के लिए ऐक्सेस की शर्त के साथ ऐक्सेस लेवल बनाना

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

1. Access Context Manager पेज पर, ऐक्सेस लेवल बनाएं को चुनें.
2. 'नया ऐक्सेस लेवल' पैनल में जाकर:
   1. टाइटल दें: इसके लिए, codelab-al का इस्तेमाल किया जा सकता है.
   2. 'शर्तें' सेक्शन में जाकर, आईपी सबनेटवर्क पर क्लिक करें.
   3. प्राइवेट आईपी टैब चुनें. इसके बाद, वीपीसी नेटवर्क चुनें पर क्लिक करें.
   4. VPC नेटवर्क जोड़ें पैनल में जाकर, default नेटवर्क को ब्राउज़ करके ढूंढा जा सकता है. इसके अलावा, //compute.googleapis.com/projects/project-2/global/networks/default फ़ॉर्मैट में नेटवर्क का पूरा नाम मैन्युअल तरीके से भी डाला जा सकता है.
   5. वीपीसी नेटवर्क जोड़ें पर क्लिक करें.
   6. आईपी सबनेट चुनें पर क्लिक करें.
   7. वह इलाका चुनें जहां वीएम इंस्टेंस मौजूद है. इस कोडलैब के लिए, यह us-central1 है.
   8. सेव करें पर क्लिक करें.

हमने एक ऐक्सेस लेवल बनाया है, जिसे अब तक किसी भी पेरीमीटर या इनग्रेस/एग्रेस नीति पर लागू नहीं किया गया है.

इनग्रेस नियम में ऐक्सेस लेवल जोड़ना

यह पक्का करने के लिए कि इनग्रेस नियम के तहत अनुमति पाने वाले उपयोगकर्ता की पुष्टि ऐक्सेस लेवल के हिसाब से भी की गई है, इनग्रेस नियम में ऐक्सेस लेवल को कॉन्फ़िगर करना ज़रूरी है. क्वेरी डेटा का ऐक्सेस देने वाला इनग्रेस नियम perimeter-1 में है. ऐक्सेस लेवल codelab-al के तौर पर सोर्स तय करने के लिए, इनग्रेस नियम में बदलाव करें.

नए कॉन्फ़िगरेशन की टेस्टिंग

इनग्रेस नियम में ऐक्सेस लेवल जोड़ने के बाद, वही BigQuery क्वेरी तब तक नहीं चलेगी, जब तक उसे प्रोजेक्ट project-2 के वीपीसी नेटवर्क default में मौजूद क्लाइंट से नहीं चलाया जाता. इस व्यवहार की पुष्टि करने के लिए, Google Cloud Console से क्वेरी चलाएं. इस दौरान, एंडपॉइंट डिवाइस इंटरनेट से कनेक्ट होना चाहिए. क्वेरी पूरी नहीं होगी. साथ ही, इनग्रेस के उल्लंघन के बारे में बताया जाएगा.

डिफ़ॉल्ट रूप से:

• Compute Engine इंस्टेंस के ऐक्सेस स्कोप की डिफ़ॉल्ट वैल्यू डिफ़ॉल्ट ऐक्सेस होती है. इससे BigQuery API को ऐक्सेस नहीं किया जा सकता.
• Compute Engine इंस्टेंस से Compute Engine का डिफ़ॉल्ट सेवा खाता जुड़ा होगा. इस दौरान, वीएम से चलने वाले सभी कमांड, इस सेवा खाते के तौर पर चलेंगे. यह खाता [e-mail] फ़ॉर्मैट में होना चाहिए.
  वीएम से जुड़े ऐक्सेस स्कोप और सेवा खाते, दोनों को बदला जा सकता है.

इस क्वेरी को वीपीसी नेटवर्क default से भी चलाया जा सकता है. यह project-2 में मौजूद है. इसी तरह, default वीपीसी नेटवर्क का इस्तेमाल करके project-2 में मौजूद Compute Engine इंस्टेंस से एक ही BigQuery क्वेरी को चलाने पर भी गड़बड़ी होगी. ऐसा इसलिए है, क्योंकि इनग्रेस नियम अब भी सिर्फ़ मुख्य खाते [e-mail] को अनुमति देने के लिए कॉन्फ़िगर किया गया है. हालांकि, वीएम Compute Engine के डिफ़ॉल्ट सेवा खाते का इस्तेमाल कर रहा है.

project-2 में Compute Engine इंस्टेंस से एक ही निर्देश को सही तरीके से चलाने के लिए,पक्का करें कि:

• वर्चुअल मशीन (वीएम) के पास BigQuery API का इस्तेमाल करने का ऐक्सेस स्कोप होना चाहिए. इसके लिए, वीएम के ऐक्सेस स्कोप के तौर पर सभी Cloud API का पूरा ऐक्सेस दें को चुनें.
• वर्चुअल मशीन से जुड़े सेवा खाते के पास, ये IAM अनुमतियां होनी चाहिए:
  • project-2 में BigQuery जॉब बनाना
  • project-1 में मौजूद BigQuery टेबल से BigQuery डेटा पाना
• Compute Engine के डिफ़ॉल्ट सेवा खाते को, इनग्रेस और इग्रेस के नियम के तहत अनुमति दी जानी चाहिए.

अब हमें Compute Engine के डिफ़ॉल्ट सेवा खाते को, इंग्रेस डेटा ट्रैफ़िक के नियमों में जोड़ना होगा. इससे BigQuery टेबल से डेटा पाने की अनुमति मिलेगी. साथ ही, इसे इग्रेस डेटा ट्रैफ़िक के नियमों में भी जोड़ना होगा. इससे BigQuery जॉब बनाने की अनुमति मिलेगी.

project-2 में मौजूद Compute Engine इंस्टेंस से, default वीपीसी नेटवर्क पर, यहां दी गई bq query कमांड चलाएं:

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

मौजूदा कॉन्फ़िगरेशन के साथ, BigQuery कमांड सिर्फ़ तब काम करेगी, जब:

• project-2 में डिफ़ॉल्ट वीपीसी नेटवर्क का इस्तेमाल करके, वर्चुअल मशीन पर चलता हो.
• us-central1 क्षेत्र (आईपी सबनेटवर्क) में मौजूद हो और
• सर्विस पेरीमीटर में कॉन्फ़िगर किए गए Compute Engine के डिफ़ॉल्ट सेवा खाते का इस्तेमाल करके चलाया जाता है.

अगर BigQuery कमांड क्वेरी को किसी दूसरी जगह से चलाया जाता है, तो वह काम नहीं करेगी. जैसे:

• अगर इसे project-2 में डिफ़ॉल्ट वीपीसी नेटवर्क का इस्तेमाल करके वीएम पर चलाया जाता है, लेकिन यह ऐक्सेस लेवल में जोड़े गए सबनेट से अलग इलाके में मौजूद है या
• अगर उपयोगकर्ता ने इंटरनेट पर मौजूद क्लाइंट के साथ [e-mail] को चलाया है.

इस डायग्राम में, एक ही प्रिंसिपल [e-mail] के दो अलग-अलग जगहों से शुरू किए गए ऐक्सेस के बारे में बताया गया है: इंटरनेट और Compute Engine इंस्टेंस. वीपीसी सर्विस कंट्रोल की वजह से, इंटरनेट से सीधे BigQuery को ऐक्सेस नहीं किया जा सकता (नीली डॉट वाली लाइनें). हालांकि, Compute Engine के डिफ़ॉल्ट सेवा खाते के तौर पर काम करते हुए, वीएम (हरी सॉलिड लाइनें) से BigQuery को ऐक्सेस किया जा सकता है. ऐक्सेस की अनुमति इसलिए दी गई है, क्योंकि सर्विस पेरीमीटर को कॉन्फ़िगर किया गया है. इससे, सुरक्षित किए गए संसाधनों को इंटरनल आईपी पते से ऐक्सेस करने की अनुमति मिलती है.

8. साफ़-सफ़ाई सेवा

जब सेवा का इस्तेमाल नहीं किया जा रहा होता है, तब वीपीसी सर्विस कंट्रोल का इस्तेमाल करने के लिए कोई शुल्क नहीं लिया जाता. हालांकि, इस लैब में इस्तेमाल किए गए सेटअप को हटाना सबसे सही तरीका है. शुल्क से बचने के लिए, वीएम इंस्टेंस और BigQuery डेटासेट या Google Cloud प्रोजेक्ट भी मिटाए जा सकते हैं. Cloud प्रोजेक्ट को मिटाने से, उस प्रोजेक्ट में इस्तेमाल किए गए सभी संसाधनों के लिए बिलिंग बंद हो जाती है.

• वीएम इंस्टेंस मिटाने के लिए, यह तरीका अपनाएं:
  • Google Cloud Console में, VM इंस्टेंस पेज पर जाएं.
  • वीएम इंस्टेंस के नाम के बाईं ओर मौजूद चेकबॉक्स को चुनें. इसके बाद, मिटाएं को चुनें. पुष्टि करने के लिए, फिर से मिटाएं पर क्लिक करें.
• सर्विस पेरीमीटर मिटाने के लिए, यह तरीका अपनाएं:
  • Google Cloud Console में, सुरक्षा को चुनें. इसके बाद, उस लेवल पर VPC सर्विस कंट्रोल को चुनें जहां ऐक्सेस पॉलिसी का दायरा तय किया गया है. इस मामले में, फ़ोल्डर लेवल पर.
  • VPC सर्विस कंट्रोल पेज पर, टेबल की उस लाइन में मौजूद मिटाएं पर क्लिक करें जिसे आपको मिटाना है.
• ऐक्सेस लेवल मिटाने के लिए, यह तरीका अपनाएं:
  • Google Cloud Console में, फ़ोल्डर के स्कोप में ऐक्सेस कॉन्टेक्स्ट मैनेजर पेज खोलें.
  • ग्रिड में, ऐक्सेस लेवल की वह लाइन ढूंढें जिसे आपको मिटाना है. इसके बाद, तीन बिंदु वाला मेन्यू चुनें. इसके बाद, मिटाएं चुनें.
• प्रोजेक्ट बंद करने के लिए, यह तरीका अपनाएं:
  • Google Cloud Console में, उस प्रोजेक्ट के IAM और एडमिन सेटिंग पेज पर जाएं जिसे आपको मिटाना है.
  • आईएएम और एडमिन सेटिंग पेज पर, बंद करें को चुनें.
  • प्रोजेक्ट आईडी डालें और शटडाउन करें को चुनें.

9. बधाई हो!

इस कोडलैब में, आपने वीपीसी सर्विस कंट्रोल पेरीमीटर बनाया, उसे लागू किया, और उससे जुड़ी समस्या को हल किया.

ज़्यादा जानें

इन स्थितियों के बारे में भी जानें:

• प्रोजेक्ट को वीपीसी सर्विस कंट्रोल से सुरक्षित किए जाने के बाद, सार्वजनिक डेटासेट पर वही क्वेरी चलाएं.
• project-1 को project-1 के जैसे ही पेरीमीटर में जोड़ें.project-2
• project-2 को उसके पेरीमीटर में जोड़ें और project-1 को मौजूदा पेरीमीटर में रखें.
• टेबल में डेटा अपडेट करने के लिए क्वेरी चलाएं, न कि सिर्फ़ डेटा वापस पाने के लिए.

लाइसेंस

इस काम के लिए, Creative Commons एट्रिब्यूशन 2.0 जेनेरिक लाइसेंस के तहत लाइसेंस मिला है.