API Gateway और Open Policy Agent (OPA) के साथ RBAC

Bobur Umurzokov

Bobur Umurzokov

May 15, 2023

Technology

विभिन्न एक्सेस कंट्रोल मॉडल और कार्यान्वयन विधियों के साथ, बैकएंड सेवा API के लिए एक प्राधिकरण प्रणाली का निर्माण करना अभी भी चुनौतीपूर्ण हो सकता है। हालांकि, अंतिम लक्ष्य यह सुनिश्चित करना है कि सही व्यक्ति को संबंधित संसाधन तक उचित पहुंच हो। इस लेख में, हम चर्चा करेंगे कि कैसे ओपन-सोर्स API गेटवे Apache APISIX और Open Policy Agent (OPA) के साथ अपने API के लिए रोल-आधारित एक्सेस कंट्रोल (RBAC) प्राधिकरण मॉडल को सक्षम किया जाए।

सीखने के उद्देश्य

आप इस लेख में निम्नलिखित सीखेंगे:

  • RBAC क्या है और यह कैसे काम करता है?
  • OPA क्या है और यह कैसे काम करता है?
  • OPA और Apache APISIX के साथ RBAC को कैसे लागू करें?
  • OPA में पॉलिसी को कैसे परिभाषित और पंजीकृत करें।
  • अपस्ट्रीम, रूट, और OPA प्लगइन को कैसे सक्षम करें।
  • JWT टोकन पेलोड या उपभोक्ता डेटा से उपयोगकर्ता की भूमिका और अनुमति को कैसे पार्स किया जाए।

RBAC क्या है?

रोल-आधारित एक्सेस कंट्रोल (RBAC) और एट्रिब्यूट-आधारित एक्सेस कंट्रोल (ABAC) दो सामान्यतः उपयोग किए जाने वाले एक्सेस कंट्रोल मॉडल हैं जो कंप्यूटर सिस्टम में संसाधनों तक पहुंच को प्रबंधित और नियंत्रित करने के लिए उपयोग किए जाते हैं। RBAC उपयोगकर्ताओं को उनकी संगठन में भूमिका के आधार पर अनुमतियां प्रदान करता है। RBAC में, भूमिकाएं उपयोगकर्ताओं के कार्यों या जिम्मेदारियों के आधार पर परिभाषित की जाती हैं, और उन भूमिकाओं को अनुमतियां प्रदान की जाती हैं। उपयोगकर्ताओं को एक या अधिक भूमिकाओं में नियुक्त किया जाता है, और वे उन भूमिकाओं से जुड़ी अनुमतियों को प्राप्त करते हैं। API के संदर्भ में, उदाहरण के लिए, एक डेवलपर भूमिका को API संसाधन बनाने और अपडेट करने की अनुमति हो सकती है, जबकि एक एंड-यूज़र भूमिका को केवल API संसाधनों को पढ़ने या निष्पादित करने की अनुमति हो सकती है।

मूल रूप से, RBAC अनुमतियां उपयोगकर्ता की भूमिका के आधार पर प्रदान करता है, जबकि ABAC अनुमतियां उपयोगकर्ता और संसाधनों से जुड़े एट्रिब्यूट्स के आधार पर प्रदान करता है।

RBAC में, एक पॉलिसी उपयोगकर्ता की नियुक्त भूमिका, उन्हें अधिकृत कार्य, और उन संसाधनों के संयोजन से परिभाषित होती है जिन पर वे उन कार्यों को कर सकते हैं।

OPA क्या है?

OPA (Open Policy Agent) एक पॉलिसी इंजन और टूल्स का सेट है जो पूरे वितरित सिस्टम में पॉलिसी प्रवर्तन के लिए एक एकीकृत दृष्टिकोण प्रदान करता है। यह आपको एक ही स्थान से पॉलिसी को परिभाषित, प्रबंधित और लागू करने की अनुमति देता है। पॉलिसी को कोड के रूप में परिभाषित करके, OPA पॉलिसी प्रबंधन को आसान बनाता है, जिससे पॉलिसी की समीक्षा, संपादन और रोल-बैक आसान हो जाता है।

Open Policy Agent उदाहरण छवि

OPA एक घोषणात्मक भाषा प्रदान करता है जिसे Rego कहा जाता है, जो आपको अपने स्टैक में पॉलिसी बनाने और लागू करने की अनुमति देता है। जब आप OPA से पॉलिसी निर्णय का अनुरोध करते हैं, तो यह .rego फ़ाइल में प्रदान किए गए नियमों और डेटा का उपयोग करके क्वेरी का मूल्यांकन करता है और एक प्रतिक्रिया उत्पन्न करता है। क्वेरी परिणाम तब आपको पॉलिसी निर्णय के रूप में वापस भेजा जाता है। OPA सभी पॉलिसी और डेटा को अपने इन-मेमोरी कैश में संग्रहीत करता है। परिणामस्वरूप, OPA तेजी से परिणाम लौटाता है। यहां एक सरल OPA Rego फ़ाइल का उदाहरण दिया गया है:

package example

default allow = false

allow {
    input.method == "GET"
    input.path =="/api/resource"
    input.user.role == "admin"
}

इस उदाहरण में, हमारे पास "example" नामक एक पैकेज है जो "allow" नामक एक नियम को परिभाषित करता है। "allow" नियम निर्दिष्ट करता है कि अनुरोध की अनुमति है यदि इनपुट विधि "GET" है, अनुरोधित पथ /api/resource है, और उपयोगकर्ता की भूमिका "admin" है। यदि ये शर्तें पूरी होती हैं, तो "allow" नियम "true" के रूप में मूल्यांकित होगा, जिससे अनुरोध आगे बढ़ सकता है।

RBAC के लिए OPA और API गेटवे का उपयोग क्यों करें?

API गेटवे API और API उपभोक्ताओं को कॉन्फ़िगर और प्रबंधित करने के लिए एक केंद्रीकृत स्थान प्रदान करता है। इसे केंद्रीकृत प्रमाणीकरण गेटवे के रूप में उपयोग किया जा सकता है, जिससे प्रत्येक व्यक्तिगत सेवा को स्वयं प्रमाणीकरण तर्क को लागू करने से बचा जा सकता है। दूसरी ओर, OPA एक प्राधिकरण परत जोड़ता है और कोड से पॉलिसी को अलग करके प्राधिकरण के लिए एक अलग लाभ प्रदान करता है। इस संयोजन के साथ, आप एक भूमिका के लिए API संसाधन की अनुमतियां जोड़ सकते हैं। उपयोगकर्ता एक या अधिक उपयोगकर्ता भूमिकाओं से जुड़े हो सकते हैं। प्रत्येक उपयोगकर्ता भूमिका RBAC संसाधनों (URI पथों द्वारा परिभाषित) पर अनुमतियों (GET, PUT, DELETE) का एक सेट परिभाषित करती है। अगले भाग में, आइए इन दोनों का उपयोग करके RBAC को कैसे प्राप्त किया जाए, यह सीखें।

Apache APISIX API गेटवे के साथ Open Policy Agent

OPA और Apache APISIX के साथ RBAC को कैसे लागू करें

Apache APISIX में, आप रूट्स और प्लगइन्स को कॉन्फ़िगर करके अपने API के व्यवहार को परिभाषित कर सकते हैं। आप APISIX opa प्लगइन का उपयोग करके RBAC पॉलिसी को लागू कर सकते हैं, जो अनुरोधों को OPA को निर्णय लेने के लिए अग्रेषित करता है। फिर OPA उपयोगकर्ताओं की भूमिकाओं और अनुमतियों के आधार पर वास्तविक समय में प्राधिकरण निर्णय लेता है।

मान लें कि हमारे पास Conference API है जहां आप इवेंट सत्र, विषय और वक्ता जानकारी को पुनः प्राप्त/संपादित कर सकते हैं। एक वक्ता केवल अपने स्वयं के सत्र और विषयों को पढ़ सकता है, जबकि एडमिन अधिक सत्र और विषय जोड़/संपादित कर सकता है। या प्रतिभागी वक्ता के सत्र के बारे में अपनी प्रतिक्रिया /speaker/speakerId/session/feedback पर POST अनुरोध के माध्यम से छोड़ सकते हैं और वक्ता केवल उसी URI के GET विधि का अनुरोध करके देख सकता है। नीचे दिया गया चित्र पूरे परिदृश्य को दर्शाता है:

Apache APISIX के साथ Open Policy Agent

  1. API उपभोक्ता API गेटवे पर एक रूट का अनुरोध करता है, जिसमें उसका क्रेडेंशियल जैसे कि प्राधिकरण हेडर में JWT टोकन होता है।
  2. API गेटवे उपभोक्ता डेटा को JWT हेडर के साथ OPA इंजन को भेजता है।
  3. OPA मूल्यांकन करता है कि उपभोक्ता के पास संसाधन तक पहुंच का अधिकार है या नहीं, जिसके लिए हम .rego फ़ाइल में निर्दिष्ट पॉलिसी (भूमिकाएं और अनुमतियां) का उपयोग करते हैं।
  4. यदि OPA निर्णय अनुमति देता है, तो अनुरोध को अपस्ट्रीम Conference सेवा को अग्रेषित किया जाएगा।

अगले, हम APISIX को इंस्टॉल और कॉन्फ़िगर करते हैं और OPA में पॉलिसी को परिभाषित करते हैं।

पूर्वापेक्षाएँ

  • Docker का उपयोग कंटेनराइज्ड etcd और APISIX को इंस्टॉल करने के लिए किया जाता है।
  • curl का उपयोग APISIX Admin API को अनुरोध भेजने के लिए किया जाता है। आप API के साथ इंटरैक्ट करने के लिए Postman जैसे टूल्स का भी उपयोग कर सकते हैं।

चरण 1: Apache APISIX इंस्टॉल करें

APISIX को निम्नलिखित क्विकस्टार्ट स्क्रिप्ट के साथ आसानी से इंस्टॉल और शुरू किया जा सकता है:

curl -sL https://run.api7.ai/apisix/quickstart | sh

चरण 2: बैकएंड सेवा (अपस्ट्रीम) को कॉन्फ़िगर करें

Conference API के लिए अनुरोधों को बैकएंड सेवा तक रूट करने के लिए, आपको Apache APISIX में Admin API के माध्यम से एक अपस्ट्रीम सर्वर जोड़ना होगा।

curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -X PUT -d '
{
   "name":"Conferences API upstream",
   "desc":"Register Conferences API as the upstream",
   "type":"roundrobin",
   "scheme":"https",
   "nodes":{
      "conferenceapi.azurewebsites.net:443":1
   }
}'

चरण 3: एक API उपभोक्ता बनाएं

अगले, हम Apache APISIX में उपयोगकर्ता नाम jack के साथ एक उपभोक्ता (एक नया वक्ता) बनाते हैं। यह उपभोक्ता के लिए jwt-auth प्लगइन को निर्दिष्ट कुंजी और सीक्रेट के साथ सेट करता है। यह उपभोक्ता को JSON Web Token (JWT) का उपयोग करके प्रमाणीकरण करने की अनुमति देगा।

curl http://127.0.0.1:9180/apisix/admin/consumers -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "jwt-auth": {
            "key": "user-key",
            "secret": "my-secret-key"
        }
    }
}'

चरण 4: JWT टोकन जनरेट करने के लिए एक सार्वजनिक एंडपॉइंट बनाएं

आपको एक नया रूट सेट करने की भी आवश्यकता है जो public-api प्लगइन का उपयोग करके टोकन को जनरेट और साइन करता है। इस परिदृश्य में, API गेटवे एक आइडेंटिटी प्रोवाइडर सर्वर के रूप में कार्य करता है, जो हमारे उपभोक्ता jack की कुंजी के साथ टोकन बनाता और सत्यापित करता है। आइडेंटिटी प्रोवाइडर Google, Okta,  Keycloak, और Ory Hydra जैसे किसी अन्य तृतीय-पक्ष सेवा भी हो सकती है।

curl http://127.0.0.1:9180/apisix/admin/routes/jas -X PUT -d '
{
    "uri": "/apisix/plugin/jwt/sign",
    "plugins": {
        "public-api": {}
    }
}'

चरण 5: API उपभोक्ता के लिए एक नया JWT टोकन प्राप्त करें

अब हम API गेटवे से हमारे वक्ता Jack के लिए एक नया टोकन प्राप्त कर सकते हैं। निम्नलिखित curl कमांड Jack के क्रेडेंशियल्स के साथ एक नया टोकन जनरेट करता है और पेलोड में भूमिका और अनुमति को असाइन करता है।

curl -G --data-urlencode 'payload={"role":"speaker","permission":"read"}' http://127.0.0.1:9080/apisix/plugin/jwt/sign?key=user-key -i

उपरोक्त कमांड चलाने के बाद, आपको एक टोकन प्रतिक्रिया के रूप में प्राप्त होगा। इस टोकन को कहीं सहेजें, बाद में हम इस टोकन का उपयोग करके अपने नए API गेटवे एंडपॉइंट तक पहुंचेंगे।

चरण 6: एक नया प्लगइन कॉन्फ़िग बनाएं

इस चरण में APISIX के 3 प्लगइन्स, proxy-rewrite, jwt-auth और opa प्लगइन्स को कॉन्फ़िगर करना शामिल है।

curl "http://127.0.0.1:9180/apisix/admin/plugin_configs/1" -X PUT -d '
{
   "plugins":{
      "jwt-auth":{
      },
      "proxy-rewrite":{
         "host":"conferenceapi.azurewebsites.net"
      }
   }
}'
  • proxy-rewrite प्लगइन को conferenceapi.azurewebsites.net होस्ट पर अनुरोधों को प्रॉक्सी करने के लिए कॉन्फ़िगर किया गया है।
  • OPA प्रमाणीकरण प्लगइन को OPA पॉलिसी इंजन का उपयोग करने के लिए कॉन्फ़िगर किया गया है जो http://localhost:8181/v1/data/rbacExample पर चल रहा है। साथ ही, APISIX सभी उपभोक्ता-संबंधित जानकारी OPA को भेजता है। हम इस पॉलिसी .rego फ़ाइल को Opa कॉन्फ़िगरेशन सेक्शन में जोड़ेंगे।

चरण 7: Conference सत्रों के लिए एक रूट बनाएं

अंतिम चरण Conferences API वक्ता सत्रों के लिए एक नया रूट बनाना है:

curl "http://127.0.0.1:9180/apisix/admin/routes/1" -X PUT -d '
{
    "name":"Conferences API speaker sessions route",
    "desc":"Create a new route in APISIX for the Conferences API speaker sessions",
    "methods": ["GET", "POST"],
    "uris": ["/speaker/*/topics","/speaker/*/sessions"],
    "upstream_id":"1",
    "plugin_config_id":1
}'

पेलोड में रूट के बारे में जानकारी होती है, जैसे इसका नाम, विवरण, विधियां, URIs, अपस्ट्रीम ID, और प्लगइन कॉन्फ़िगरेशन ID। इस मामले में, रूट को GET और POST अनुरोधों को दो अलग-अलग URIs, /speaker/topics और /speaker/sessions के लिए हैंडल करने के लिए कॉन्फ़िगर किया गया है। "upstream_id" फ़ील्ड इस रूट के लिए आने वाले अनुरोधों को हैंडल करने वाले अपस्ट्रीम सेवा की ID निर्दिष्ट करता है, जबकि "plugin_config_id" फ़ील्ड इस रूट के लिए उपयोग की जाने वाली प्लगइन कॉन्फ़िगरेशन की ID निर्दिष्ट करता है।

चरण 8: OPA के बिना सेटअप का परीक्षण करें

अब तक, हमने APISIX को Conference API एंडपॉइंट्स पर आने वाले अनुरोधों को निर्देशित करने के लिए सभी आवश्यक कॉन्फ़िगरेशन सेट कर दिया है, केवल अधिकृत API उपभोक्ताओं को अनुमति देते हुए। अब, हर बार जब एक API उपभोक्ता एक एंडपॉइंट तक पहुंचना चाहता है, तो उसे Conference बैकएंड सेवा से डेटा प्राप्त करने के लिए एक JWT टोकन प्रदान करना होगा। आप एंडपॉइंट और डोमेन एड्रेस को हिट करके इसकी पुष्टि कर सकते हैं, जिसे हम अब अनुरोध कर रहे हैं, यह हमारा कस्टम API गेटवे है, न कि वास्तविक Conference सेवा:

curl -i http://127.0.0.1:9080/speaker/1/topics -H 'Authorization: {API_CONSUMER_TOKEN}'

चरण 9: OPA सेवा चलाएं

अन्य दो चरण हैं, हम Docker का उपयोग करके OPA सेवा चलाते हैं और इसकी API का उपयोग करके हमारी पॉलिसी परिभाषा अपलोड करते हैं, जिसका उपयोग आने वाले अनुरोधों के लिए प्राधिकरण पॉलिसी का मूल्यांकन करने के लिए किया जा सकता है।

docker run -d --network=apisix-quickstart-net --name opa -p 8181:8181 openpolicyagent/opa:latest run -s

यह Docker कमांड OPA इमेज के नवीनतम संस्करण के साथ एक कंटेनर चलाता है। यह मौजूदा APISIX नेटवर्क apisix-quickstart-net पर opa नाम के साथ एक नया कंटेनर बनाता है और पोर्ट 8181 को एक्सपोज़ करता है। इसलिए, APISIX सीधे [http://opa:8181](http://opa:8181) एड्रेस का उपयोग करके OPA को पॉलिसी चेक अनुरोध भेज सकता है। ध्यान दें कि OPA और APISIX को एक ही Docker नेटवर्क में चलना चाहिए।

चरण 10: पॉलिसी को परिभाषित और पंजीकृत करें

OPA साइड पर दूसरा चरण यह है कि आपको उन पॉलिसी को परिभाषित करने की आवश्यकता है जो API संसाधनों तक पहुंच को नियंत्रित करने के लिए उपयोग की जाएंगी। ये पॉलिसी पहुंच के लिए आवश्यक एट्रिब्यूट्स (कौन से उपयोगकर्ताओं के पास कौन सी भूमिकाएं हैं) और उन एट्रिब्यूट्स के आधार पर अनुमतियां (कौन सी भूमिकाओं के पास कौन सी अनुमतियां हैं) को परिभाषित करती हैं। उदाहरण के लिए, नीचे दिए गए कॉन्फ़िगरेशन में, हम OPA को यह कह रहे हैं कि user_roles टेबल की जांच करें कि jack के लिए कौन सी भूमिका है। यह जानकारी APISIX द्वारा input.consumer.username के अंदर भेजी जाती है। साथ ही, हम उपभोक्ता की अनुमति को JWT पेलोड को पढ़कर और token.payload.permission को निकालकर सत्यापित कर रहे हैं। टिप्पणियां चरणों को स्पष्ट रूप से वर्णन करती हैं।

curl -X PUT '127.0.0.1:8181/v1/policies/rbacExample' \
    -H 'Content-Type: text/plain' \
    -d 'package rbacExample

# उपयोगकर्ता भूमिकाएं असाइन करना

user_roles := {
    "jack": ["speaker"],
    "bobur":["admin"]
}

# भूमिका अनुमति असाइनमेंट
role_permissions := {
    "speaker": [{"permission": "read"}],
    "admin":   [{"permission": "read"}, {"permission": "write"}]
}

# सहायक JWT फ़ंक्शन
bearer_token := t {
 t := input.request.headers.authorization
}

# प्राधिकरण टोकन को डिकोड करके भूमिका और अनुमति प्राप्त करें
token = {"payload": payload} {
 [_, payload, _] := io.jwt.decode(bearer_token)
}

# RBAC को लागू करने वाला तर्क
default allow = false

allow {
    # उपयोगकर्ता के लिए भूमिकाओं की सूची देखें
    roles := user_roles[input.consumer.username]

    # उस सूची में प्रत्येक भूमिका के लिए
    r := roles[_]

    # भूमिका r के लिए अनुमतियों की सूची देखें
    permissions := role_permissions[r]

    # प्रत्येक अनुमति के लिए
    p := permissions[_]

    # जांचें कि r को दी गई अनुमति उपयोगकर्ता के अनुरोध से मेल खाती है
    p == {"permission": token.payload.permission}
}'

चरण 11: OPA प्लगइन के साथ मौजूदा प्लगइन कॉन्फ़िग को अपडेट करें

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

curl "http://127.0.0.1:9180/apisix/admin/plugin_configs/1" -X PATCH -d '
{
   "plugins":{
      "opa":{
         "host":"http://opa:8181",
         "policy":"rbacExample",
         "with_consumer":true
      }
   }
}'

चरण 12: OPA के साथ सेटअप का परीक्षण करें

अब हम OPA पॉलिसी के साथ किए गए सभी सेटअप का परीक्षण कर सकते हैं। यदि आप API गेटवे एंडपॉइंट तक पहुंचने के लिए समान curl कमांड चलाने का प्रयास करते हैं, तो यह पहले JWT टोकन को प्रमाणीकरण प्रक्रिया के रूप में जांचता है और उपभोक्ता और JWT टोकन डेटा को OPA को प्राधिकरण प्रक्रिया के रूप में भूमिका और अनुमति को सत्यापित करने के लिए भेजता है। किसी भी अनुरोध को JWT टोकन के बिना या अनुमति वाली भूमिकाओं के बिना अस्वीकार कर दिया जाएगा।

curl -i http://127.0.0.1:9080/speaker/1/topics -H 'Authorization: {API_CONSUMER_TOKEN}'

निष्कर्ष

इस लेख में, हमने OPA और Apache APISIX के साथ RBAC को लागू करना सीखा। हमने एक सरल कस्टम पॉलिसी तर्क को परिभाषित किया ताकि हमारे API उपभोक्ता की भूमिका और अनुमतियों के आधार पर API संसाधन तक पहुंच को अनुमति/अस्वीकार किया जा सके। साथ ही, इस ट्यूटोरियल ने प्रदर्शित किया कि हम JWT टोकन पेलोड या उपभोक्ता ऑब्जेक्ट से API उपभोक्ता-संबंधित जानकारी को पॉलिसी फ़ाइल में कैसे निकाल सकते हैं।

संबंधित संसाधन

अनुशंसित सामग्री

Tags:
RBAC
Open Policy Agent
Authentication & Authorization
API Security