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

1. परिचय

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

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

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

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

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

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

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

सेटअप

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

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

• 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. VPC सर्विस कंट्रोल की पाबंदियों के बिना BigQuery का ऐक्सेस

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

1. BigQuery Studio पेज पर जाकर, project-2 और project-1 को ऐक्सेस करें. इससे यह पुष्टि की जा सकेगी कि आपके पास BigQuery API को ऐक्सेस करने की अनुमति है या नहीं. आपको ऐसा करने की अनुमति होनी चाहिए, क्योंकि भले ही 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: [क्वेरी चलाने वाले उपयोगकर्ता एजेंट का आईपी पता]

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

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

BigQuery के काम करने के तरीके की वजह से, VPC सर्विस कंट्रोल के उल्लंघन में टारगेट की गई अनुमति 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 सेवा पर क्वेरी चलाने वाले उपयोगकर्ता खाते ([e-mail]) को, targetResource (project-2) की ओर ट्रैफ़िक भेजने की अनुमति दे. साथ ही, bigquery.jobs.create तरीके/ अनुमति का इस्तेमाल करने की अनुमति दे.

कॉन्फ़िगर किए गए इग्रेस नियम के मुताबिक, यह उम्मीद की जाती है कि:

• 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: [क्वेरी चलाने वाले उपयोगकर्ता एजेंट का आईपी पता]

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 हो.

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

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

इस डायग्राम में दिखाया गया है कि दो अलग-अलग प्रिंसिपल, एक ही डेटासेट को क्वेरी करने की कोशिश कैसे करते हैं. वीपीसी सर्विस कंट्रोल, [e-mail] (नीली डॉट वाली लाइनें) को ऐक्सेस करने की अनुमति नहीं देते. ऐसा इसलिए, क्योंकि सर्विस पेरीमीटर कॉन्फ़िगरेशन के तहत, उन्हें project-1 से या project-1 की ओर BigQuery ऑपरेशन चलाने की अनुमति नहीं है. [e-mail] (हरी सॉलिड लाइन) को ऐक्सेस करने की अनुमति है, क्योंकि VPC सर्विस कंट्रोल कॉन्फ़िगरेशन के तहत, उन्हें 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 क्वेरी तब तक नहीं चलेगी, जब तक उसे वीपीसी नेटवर्क default में मौजूद क्लाइंट से प्रोजेक्ट project-2 के लिए नहीं चलाया जाता. इस व्यवहार की पुष्टि करने के लिए, 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 के डिफ़ॉल्ट सेवा खाते के तौर पर काम करते समय, वीएम (हरी लाइनें) से ऐक्सेस करने की अनुमति होती है. ऐक्सेस की अनुमति इसलिए दी गई है, क्योंकि सर्विस पेरीमीटर को कॉन्फ़िगर किया गया है. इससे, सुरक्षित किए गए संसाधनों को इंटरनल आईपी पते से ऐक्सेस करने की अनुमति मिलती है.

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

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

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

9. बधाई हो!

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

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

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

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

लाइसेंस

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