Policy

पहचान और ऐक्सेस मैनेजमेंट (आईएएम) की नीति, जिसमें Google Cloud संसाधनों के लिए ऐक्सेस कंट्रोल तय किए जाते हैं.

Policy, bindings का कलेक्शन होता है. binding एक या उससे ज़्यादा members या प्रिंसिपल को एक role से बाइंड करता है. प्रिंसिपल, उपयोगकर्ता खाते, सेवा खाते, Google ग्रुप, और डोमेन (जैसे कि G Suite) हो सकते हैं. role, अनुमतियों की एक सूची होती है. हर role, आईएएम की पहले से तय की गई भूमिका या उपयोगकर्ता की बनाई गई कस्टम भूमिका हो सकती है.

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

JSON का उदाहरण:

    {
      "bindings": [
        {
          "role": "roles/resourcemanager.organizationAdmin",
          "members": [
            "user:mike@example.com",
            "group:admins@example.com",
            "domain:google.com",
            "serviceAccount:my-project-id@appspot.gserviceaccount.com"
          ]
        },
        {
          "role": "roles/resourcemanager.organizationViewer",
          "members": [
            "user:eve@example.com"
          ],
          "condition": {
            "title": "expirable access",
            "description": "Does not grant access after Sep 2020",
            "expression": "request.time < timestamp('2020-10-01T00:00:00.000Z')",
          }
        }
      ],
      "etag": "BwWWja0YfJA=",
      "version": 3
    }

YAML का उदाहरण:

    bindings:
    - members:
      - user:mike@example.com
      - group:admins@example.com
      - domain:google.com
      - serviceAccount:my-project-id@appspot.gserviceaccount.com
      role: roles/resourcemanager.organizationAdmin
    - members:
      - user:eve@example.com
      role: roles/resourcemanager.organizationViewer
      condition:
        title: expirable access
        description: Does not grant access after Sep 2020
        expression: request.time < timestamp('2020-10-01T00:00:00.000Z')
    etag: BwWWja0YfJA=
    version: 3

IAM और इसकी सुविधाओं के बारे में जानने के लिए, IAM का दस्तावेज़ देखें.

JSON के काेड में दिखाना 
{
  "version": integer,
  "bindings": [
    {
      object (Binding)
    }
  ],
  "etag": string
}
फ़ील्ड
version

integer

नीति का फ़ॉर्मैट बताता है.

मान्य वैल्यू 0, 1, और 3 हैं. गलत वैल्यू वाले अनुरोधों को अस्वीकार कर दिया जाता है.

शर्त के साथ भूमिकाएं असाइन करने की सुविधा पर असर डालने वाली किसी भी कार्रवाई के लिए, वर्शन 3 तय करना ज़रूरी है. यह ज़रूरी शर्त इन कार्रवाइयों पर लागू होती है:

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

अहम जानकारी: अगर IAM की शर्तों का इस्तेमाल किया जाता है, तो setIamPolicy को कॉल करते समय, आपको etag फ़ील्ड को शामिल करना होगा. अगर आपने इस फ़ील्ड को शामिल नहीं किया है, तो आईएएम आपको वर्शन 3 वाली नीति को वर्शन 1 वाली नीति से बदलने की अनुमति देता है. साथ ही, वर्शन 3 वाली नीति की सभी शर्तें मिट जाती हैं.

अगर किसी नीति में कोई शर्त शामिल नहीं है, तो उस नीति पर किए जाने वाले ऑपरेशन में, कोई भी मान्य वर्शन तय किया जा सकता है या फ़ील्ड को बिना सेट किए छोड़ा जा सकता है.

यह जानने के लिए कि किन संसाधनों में आईएएम की नीतियों में शर्तें इस्तेमाल की जा सकती हैं, आईएएम का दस्तावेज़ देखें.
bindings[]

object (Binding)

यह कुकी, role के साथ members या प्रिंसिपल की सूची को जोड़ती है. इसके अलावा, condition की जानकारी दी जा सकती है. इससे यह तय होता है कि bindings कब और कैसे लागू होंगे. हर bindings में कम से कम एक प्रिंसिपल होना चाहिए.

Policy में मौजूद bindings, ज़्यादा से ज़्यादा 1,500 प्रिंसिपल को रेफ़र कर सकता है. इनमें से ज़्यादा से ज़्यादा 250 प्रिंसिपल, Google ग्रुप हो सकते हैं. हर प्रिंसिपल को इन सीमाओं में गिना जाता है. उदाहरण के लिए, अगर bindings ने user:alice@example.com को 50 अलग-अलग भूमिकाएं दी हैं और किसी अन्य प्रिंसिपल को नहीं, तो Policy में bindings के लिए 1,450 और प्रिंसिपल जोड़े जा सकते हैं.
etag

string (bytes format)

etag का इस्तेमाल, ऑप्टिमिस्टिक कॉन्करेंसी कंट्रोल के लिए किया जाता है. इससे, किसी नीति को एक साथ अपडेट करने से रोकने में मदद मिलती है, ताकि एक अपडेट दूसरे अपडेट को न बदल दे. हमारा सुझाव है कि सिस्टम, रेस कंडीशन से बचने के लिए, नीति से जुड़े अपडेट करने के लिए, रीड-मॉडिफ़ाय-राइट साइकल में etag का इस्तेमाल करें: getIamPolicy के जवाब में etag दिखता है. सिस्टम से उम्मीद की जाती है कि वे setIamPolicy के अनुरोध में उस ईटैग को डालें, ताकि यह पक्का किया जा सके कि उनका बदलाव, नीति के उसी वर्शन पर लागू होगा.

अहम जानकारी: अगर IAM की शर्तों का इस्तेमाल किया जाता है, तो setIamPolicy को कॉल करते समय, आपको etag फ़ील्ड को शामिल करना होगा. अगर आपने इस फ़ील्ड को शामिल नहीं किया है, तो आईएएम आपको वर्शन 3 वाली नीति को वर्शन 1 वाली नीति से बदलने की अनुमति देता है. साथ ही, वर्शन 3 वाली नीति की सभी शर्तें मिट जाती हैं.

base64 कोड में बदली गई स्ट्रिंग.