इस्तियो के साथ माइक्रोसर्विसेज पर वापस जाएं। भाग ---- पहला

टिप्पणी। अनुवाद।: पहले भाग यह श्रृंखला इस्तियो की क्षमताओं को जानने और उन्हें क्रियान्वित करके प्रदर्शित करने के लिए समर्पित थी, दूसरा - बारीकी से व्यवस्थित रूटिंग और नेटवर्क ट्रैफिक प्रबंधन। अब हम सुरक्षा के बारे में बात करेंगे: इससे संबंधित बुनियादी कार्यों को प्रदर्शित करने के लिए, लेखक Auth0 पहचान सेवा का उपयोग करता है, लेकिन अन्य प्रदाताओं को इसी तरह से कॉन्फ़िगर किया जा सकता है।

हमने एक कुबेरनेट्स क्लस्टर स्थापित किया है जिसमें हमने इस्तियो की क्षमताओं को प्रदर्शित करने के लिए इस्तियो और एक उदाहरण माइक्रोसर्विस एप्लिकेशन, सेंटीमेंट एनालिसिस को तैनात किया है।

इस्तियो के साथ, हम अपनी सेवाओं को छोटा रखने में सक्षम थे क्योंकि उन्हें रिट्रीज़, टाइमआउट, सर्किट ब्रेकर, ट्रेसिंग, मॉनिटरिंग जैसी परतों को लागू करने की आवश्यकता नहीं है। इसके अलावा, हमने उन्नत परीक्षण और परिनियोजन तकनीकों का उपयोग किया: ए/बी परीक्षण, मिररिंग और कैनरी रोलआउट।

नई सामग्री में, हम व्यावसायिक मूल्य के पथ पर अंतिम परतों से निपटेंगे: प्रमाणीकरण और प्राधिकरण - और इस्तियो में यह एक वास्तविक आनंद है!

इस्तियो में प्रमाणीकरण और प्राधिकरण

मुझे कभी विश्वास नहीं हुआ कि मैं प्रमाणीकरण और प्राधिकरण से प्रेरित होऊंगा। प्रौद्योगिकी के दृष्टिकोण से इस्तियो इन विषयों को मज़ेदार और इससे भी अधिक आपके लिए प्रेरणादायक बनाने के लिए क्या पेशकश कर सकता है?

उत्तर सरल है: इस्तियो इन क्षमताओं की ज़िम्मेदारी आपकी सेवाओं से हटाकर दूत प्रॉक्सी पर डाल देता है। जब तक अनुरोध सेवाओं तक पहुंचते हैं, तब तक वे पहले ही प्रमाणित और अधिकृत हो चुके होते हैं, इसलिए आपको बस व्यवसाय-उपयोगी कोड लिखना है।

सुनने में तो अच्छा लगता है? आइए अंदर देखें!

Auth0 के साथ प्रमाणीकरण

पहचान और पहुंच प्रबंधन के लिए एक सर्वर के रूप में, हम Auth0 का उपयोग करेंगे, जिसका एक परीक्षण संस्करण है, उपयोग करने में सहज है और मुझे यह पसंद है। हालाँकि, वही सिद्धांत किसी अन्य पर भी लागू किए जा सकते हैं ओपनआईडी कनेक्ट कार्यान्वयन: KeyCloak, IdentityServer और कई अन्य।

आरंभ करने के लिए, पर जाएँ Auth0 पोर्टल अपने खाते से, एक किरायेदार बनाएं (किरायेदार - "किरायेदार", अलगाव की तार्किक इकाई, अधिक जानकारी के लिए देखें प्रलेखन - लगभग। अनुवाद।) और जाएं एप्लिकेशन > डिफ़ॉल्ट ऐपचुनने डोमेन, जैसा कि नीचे स्क्रीनशॉट में दिखाया गया है:

फ़ाइल में इस डोमेन को निर्दिष्ट करें resource-manifests/istio/security/auth-policy.yaml (स्रोत कोड):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  - name: sa-feedback
  origins:
  - jwt:
      issuer: "https://{YOUR_DOMAIN}/"
      jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json"
  principalBinding: USE_ORIGIN

ऐसे संसाधन के साथ, पायलट (इस्तियो में तीन बुनियादी नियंत्रण विमान घटकों में से एक - लगभग अनुवाद।) सेवाओं को अग्रेषित करने से पहले अनुरोधों को प्रमाणित करने के लिए दूत को कॉन्फ़िगर करता है: sa-web-app и sa-feedback. उसी समय, कॉन्फ़िगरेशन सेवा दूतों पर लागू नहीं होता है sa-frontend, जो हमें फ्रंटएंड को अप्रमाणित छोड़ने की अनुमति देता है। नीति लागू करने के लिए, आदेश चलाएँ:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created

पृष्ठ पर लौटें और अनुरोध करें - आप देखेंगे कि यह स्थिति के साथ समाप्त होता है 401 अनधिकृत. आइए अब फ्रंटएंड उपयोगकर्ताओं को Auth0 से प्रमाणित करने के लिए पुनर्निर्देशित करें।

Auth0 के साथ अनुरोधों को प्रमाणित करना

अंतिम उपयोगकर्ता अनुरोधों को प्रमाणित करने के लिए, आपको Auth0 में एक एपीआई बनाने की आवश्यकता है जो प्रमाणित सेवाओं (समीक्षा, विवरण और रेटिंग) का प्रतिनिधित्व करेगी। एपीआई बनाने के लिए, पर जाएँ Auth0 पोर्टल > एपीआई > एपीआई बनाएं और फॉर्म भरें:

यहाँ महत्वपूर्ण जानकारी है पहचानकर्ता, जिसे हम बाद में स्क्रिप्ट में उपयोग करेंगे। आइए इसे इस तरह लिखें:

• दर्शक: {आपके_दर्शक}

हमें आवश्यक शेष विवरण अनुभाग में Auth0 पोर्टल पर स्थित हैं अनुप्रयोगों - चुनते हैं परीक्षण आवेदन (एपीआई के साथ स्वचालित रूप से बनाया गया)।

यहां हम लिखेंगे:

• डोमेन: {आपका डोमेन}
• ग्राहक ID: {YOUR_CLIENT_ID}

तक स्क्रॉल करें परीक्षण आवेदन पाठ फ़ील्ड के लिए अनुमत कॉलबैक यूआरएल (कॉलबैक के लिए हल किए गए यूआरएल), जिसमें हम उस यूआरएल को निर्दिष्ट करते हैं जहां प्रमाणीकरण पूरा होने के बाद कॉल भेजा जाना चाहिए। हमारे मामले में यह है:

http://{EXTERNAL_IP}/callback

और के लिए अनुमत लॉगआउट यूआरएल (लॉग आउट करने के लिए अनुमत URL) जोड़ें:

http://{EXTERNAL_IP}/logout

चलिए फ्रंटएंड पर चलते हैं।

फ्रंटएंड अद्यतन

शाखा में स्विच करें auth0 रिपोजिटरी [istio-mastery]. इस शाखा में, प्रमाणीकरण के लिए उपयोगकर्ताओं को Auth0 पर पुनर्निर्देशित करने और अन्य सेवाओं के अनुरोधों में JWT टोकन का उपयोग करने के लिए फ्रंटएंड कोड को बदल दिया जाता है। उत्तरार्द्ध को निम्नानुसार कार्यान्वित किया गया है (ऐप.जेएस):

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}

Auth0 में टैनेंट डेटा का उपयोग करने के लिए फ्रंटएंड को बदलने के लिए, खोलें sa-frontend/src/services/Auth.js और इसमें वे मान बदलें जो हमने ऊपर लिखे हैं (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

आवेदन तैयार है. किए गए परिवर्तनों को बनाते और तैनात करते समय नीचे दिए गए आदेशों में अपनी डॉकर आईडी निर्दिष्ट करें:

$ docker build -f sa-frontend/Dockerfile 
 -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 
 sa-frontend

$ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

$ kubectl set image deployment/sa-frontend 
 sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

ऐप आज़माएं! आपको Auth0 पर पुनः निर्देशित किया जाएगा, जहां आपको लॉग इन (या रजिस्टर) करना होगा, जिसके बाद आपको उस पृष्ठ पर वापस भेज दिया जाएगा जहां से पहले से ही प्रमाणित अनुरोध किए जाएंगे। यदि आप लेख के पहले भागों में उल्लिखित कमांड को कर्ल के साथ आज़माते हैं, तो आपको कोड मिलेगा 401 स्थिति कोड, यह संकेत देते हुए कि अनुरोध अधिकृत नहीं है।

आइए अगला कदम उठाएं - अनुरोधों को अधिकृत करें।

Auth0 के साथ प्राधिकरण

प्रमाणीकरण हमें यह समझने की अनुमति देता है कि उपयोगकर्ता कौन है, लेकिन यह जानने के लिए प्राधिकरण की आवश्यकता है कि उनकी पहुंच किस तक है। इस्तियो इसके लिए उपकरण भी प्रदान करता है।

उदाहरण के तौर पर, आइए दो उपयोगकर्ता समूह बनाएं (नीचे चित्र देखें):

• सदस्य (उपयोगकर्ता) - केवल SA-WebApp और SA-फ्रंटेंड सेवाओं तक पहुंच के साथ;
• मध्यस्थ (मॉडरेटर) - तीनों सेवाओं तक पहुंच के साथ।

प्राधिकरण अवधारणा

इन समूहों को बनाने के लिए, हम Auth0 प्राधिकरण एक्सटेंशन का उपयोग करेंगे और उन्हें विभिन्न स्तरों तक पहुंच प्रदान करने के लिए इस्तियो का उपयोग करेंगे।

Auth0 प्राधिकरण की स्थापना और कॉन्फ़िगरेशन

Auth0 पोर्टल में, एक्सटेंशन पर जाएं (एक्सटेंशन) और इंस्टॉल करें Auth0 प्राधिकरण. इंस्टालेशन के बाद यहां जाएं प्राधिकरण विस्तार, और वहां - ऊपर दाईं ओर क्लिक करके और उचित मेनू विकल्प का चयन करके किरायेदार के कॉन्फ़िगरेशन पर जाएं (कॉन्फ़िगरेशन). समूहों को सक्रिय करें (समूह) और पब्लिश रूल बटन पर क्लिक करें (नियम प्रकाशित करें).

समूह बनाएं

प्राधिकरण एक्सटेंशन में जाएं समूह और एक ग्रुप बनाएं मध्यस्थ. चूँकि हम सभी प्रमाणित उपयोगकर्ताओं को नियमित उपयोगकर्ता मानेंगे, इसलिए उनके लिए कोई अतिरिक्त समूह बनाने की आवश्यकता नहीं है।

एक समूह चुनें मध्यस्थ, प्रेस सदस्य जोड़ें, अपना मुख्य खाता जोड़ें। यह सुनिश्चित करने के लिए कि उन्हें पहुंच से वंचित किया गया है, कुछ उपयोगकर्ताओं को बिना किसी समूह के छोड़ दें। (नए उपयोगकर्ता मैन्युअल रूप से बनाए जा सकते हैं Auth0 पोर्टल > उपयोगकर्ता > उपयोगकर्ता बनाएं.)

एक्सेस टोकन में समूह दावा जोड़ें

उपयोगकर्ताओं को समूहों में जोड़ा गया है, लेकिन यह जानकारी एक्सेस टोकन में भी दिखाई देनी चाहिए। ओपनआईडी कनेक्ट का अनुपालन करने के लिए और साथ ही हमें जिन समूहों की आवश्यकता है उन्हें वापस करने के लिए, टोकन को अपना खुद का जोड़ना होगा कस्टम दावा. Auth0 नियमों के माध्यम से कार्यान्वित किया गया।

नियम बनाने के लिए, Auth0 पोर्टल पर जाएँ नियम, प्रेस नियम बनाएं और टेम्प्लेट से एक खाली नियम चुनें।

नीचे दिए गए कोड को कॉपी करें और इसे नए नियम के रूप में सहेजें समूह दावा जोड़ें (नेमस्पेस्डग्रुप.जेएस):

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}

नोट: यह कोड प्राधिकरण एक्सटेंशन में परिभाषित पहले उपयोगकर्ता समूह को लेता है और इसे कस्टम दावे के रूप में एक्सेस टोकन में जोड़ता है (इसके नामस्थान के तहत, जैसा कि Auth0 द्वारा आवश्यक है)।

पृष्ठ पर लौटें नियम और जांचें कि आपके पास निम्नलिखित क्रम में दो नियम लिखे हैं:

• auth0-प्राधिकरण-विस्तार
• समूह दावा जोड़ें

क्रम महत्वपूर्ण है क्योंकि समूह फ़ील्ड नियम को अतुल्यकालिक रूप से प्राप्त करता है auth0-प्राधिकरण-विस्तार और इसके बाद इसे दूसरे नियम के तहत दावे के तौर पर जोड़ा जाता है. परिणाम इस प्रकार एक एक्सेस टोकन है:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

अब आपको उपयोगकर्ता पहुंच की जांच करने के लिए एन्वॉय प्रॉक्सी को कॉन्फ़िगर करने की आवश्यकता है, जिसके लिए समूह को दावे से हटा दिया जाएगा (https://sa.io/group) लौटाए गए एक्सेस टोकन में। यह लेख के अगले भाग का विषय है।

इस्तियो में प्राधिकरण विन्यास

काम करने के लिए प्राधिकरण के लिए, आपको इस्तियो के लिए आरबीएसी को सक्षम करना होगा। ऐसा करने के लिए, हम निम्नलिखित कॉन्फ़िगरेशन का उपयोग करेंगे:

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'                     # 1
  inclusion:
    services:                                   # 2
    - "sa-frontend.default.svc.cluster.local"
    - "sa-web-app.default.svc.cluster.local"
    - "sa-feedback.default.svc.cluster.local" 

स्पष्टीकरण:

• 1 - केवल फ़ील्ड में सूचीबद्ध सेवाओं और नामस्थानों के लिए RBAC सक्षम करें Inclusion;
• 2 - हम अपनी सेवाओं की एक सूची सूचीबद्ध करते हैं।

आइए निम्नलिखित कमांड के साथ कॉन्फ़िगरेशन लागू करें:

$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created

सभी सेवाओं को अब भूमिका-आधारित अभिगम नियंत्रण की आवश्यकता है। दूसरे शब्दों में, सभी सेवाओं तक पहुंच निषिद्ध है और इसके परिणामस्वरूप प्रतिक्रिया होगी RBAC: access denied. आइए अब अधिकृत उपयोगकर्ताओं तक पहुंच की अनुमति दें।

नियमित उपयोगकर्ताओं के लिए एक्सेस कॉन्फ़िगरेशन

सभी उपयोगकर्ताओं के पास SA-Frontend और SA-WebApp सेवाओं तक पहुंच होनी चाहिए। निम्नलिखित इस्तियो संसाधनों का उपयोग करके कार्यान्वित किया गया:

• सेवा भूमिका — उपयोगकर्ता के पास मौजूद अधिकारों को निर्धारित करता है;
• सेवा भूमिका बाइंडिंग - यह निर्धारित करता है कि यह ServiceRole किसकी है।

सामान्य उपयोगकर्ताओं के लिए हम कुछ सेवाओं तक पहुंच की अनुमति देंगे (servicerole.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: regular-user
  namespace: default
spec:
  rules:
  - services: 
    - "sa-frontend.default.svc.cluster.local" 
    - "sa-web-app.default.svc.cluster.local"
    paths: ["*"]
    methods: ["*"]

और के माध्यम से regular-user-binding सभी पेज विज़िटरों पर ServiceRole लागू करें (नियमित-उपयोगकर्ता-सेवा-भूमिका-बाध्यकारी.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

क्या "सभी उपयोगकर्ताओं" का मतलब यह है कि अप्रमाणित उपयोगकर्ताओं को भी SA WebApp तक पहुंच प्राप्त होगी? नहीं, पॉलिसी JWT टोकन की वैधता की जाँच करेगी।

आइए कॉन्फ़िगरेशन लागू करें:

$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user created
servicerolebinding.rbac.istio.io/regular-user-binding created

मॉडरेटर के लिए एक्सेस कॉन्फ़िगरेशन

मॉडरेटर के लिए, हम सभी सेवाओं तक पहुंच सक्षम करना चाहते हैं (mod-service-role.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: mod-user
  namespace: default
spec:
  rules:
  - services: ["*"]
    paths: ["*"]
    methods: ["*"]

लेकिन हम ऐसे अधिकार केवल उन्हीं उपयोगकर्ताओं के लिए चाहते हैं जिनके एक्सेस टोकन में दावा शामिल है https://sa.io/group अर्थ सहित Moderators (mod-service-role-binding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: mod-user-binding
  namespace: default
spec:
  subjects:
  - properties:
      request.auth.claims[https://sa.io/group]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user" 

आइए कॉन्फ़िगरेशन लागू करें:

$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user created
servicerolebinding.rbac.istio.io/mod-user-binding created

दूतों में कैशिंग के कारण, प्राधिकरण नियमों को प्रभावी होने में कुछ मिनट लग सकते हैं। फिर आप यह सुनिश्चित कर सकते हैं कि उपयोगकर्ताओं और मॉडरेटर के पास पहुंच के विभिन्न स्तर हैं।

इस भाग पर निष्कर्ष

हालाँकि, क्या आपने कभी प्रमाणीकरण और प्राधिकरण के लिए एक सरल, सहज, स्केलेबल और सुरक्षित दृष्टिकोण देखा है?

सेवाओं तक अंतिम उपयोगकर्ता की पहुंच के प्रमाणीकरण और प्राधिकरण पर बढ़िया नियंत्रण प्राप्त करने के लिए केवल तीन इस्तियो संसाधनों (RbacConfig, ServiceRole, और ServiceRoleBinding) की आवश्यकता थी।

इसके अलावा, हमने अपनी दूत सेवाओं से इन मुद्दों का ध्यान रखा है और निम्नलिखित हासिल किए हैं:

• सामान्य कोड की मात्रा कम करना जिसमें सुरक्षा समस्याएँ और बग हो सकते हैं;
• उन मूर्खतापूर्ण स्थितियों की संख्या को कम करना जिनमें एक समापन बिंदु बाहर से पहुंच योग्य निकला और इसकी रिपोर्ट करना भूल गया;
• हर बार नई भूमिका या अधिकार जोड़े जाने पर सभी सेवाओं को अद्यतन करने की आवश्यकता को समाप्त करना;
• नई सेवाएँ सरल, सुरक्षित और तेज़ रहें।

उत्पादन

इस्तियो टीमों को सेवाओं में ओवरहेड जोड़े बिना, उन्हें सूक्ष्म स्थिति में वापस लाए बिना, व्यवसाय-महत्वपूर्ण कार्यों पर अपने संसाधनों को केंद्रित करने की अनुमति देता है।

लेख (तीन भागों में) ने वास्तविक परियोजनाओं में इस्तियो के साथ शुरुआत करने के लिए बुनियादी ज्ञान और तैयार व्यावहारिक निर्देश प्रदान किए।

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• "इस्टियो के साथ माइक्रोसर्विसेज पर वापस": भाग 1 (मुख्य विशेषताओं का परिचय), भाग 2 (रूटिंग, यातायात नियंत्रण);
• «कंड्यूट - कुबेरनेट्स के लिए हल्का सर्विस मेश";
• «सेवा जाल क्या है और मुझे इसकी आवश्यकता क्यों है [माइक्रोसर्विसेज के साथ क्लाउड एप्लिकेशन के लिए]?'.

स्रोत: www.habr.com