इस्टियो के साथ वापस माइक्रोसोर्विस के लिए। भाग 3

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

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

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



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

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

मुझे कभी भी विश्वास नहीं होता था कि मैं प्रमाणीकरण और प्राधिकरण से प्रेरित होगा। इन विषयों को रोमांचक बनाने के लिए और इससे भी ज्यादा प्रेरणा देने के लिए इस्तियो क्या तकनीकी पेशकश कर सकता है?

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

अच्छा लगता है? चलो अंदर देखो!

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

हम Auth0 को पहचान और अभिगम प्रबंधन के लिए एक सर्वर के रूप में उपयोग करेंगे, जिसका एक परीक्षण संस्करण है, जो उपयोग करने के लिए सहज है और मुझे यह पसंद है। हालाँकि, समान सिद्धांत किसी भी अन्य OpenID कनेक्ट कार्यान्वयन पर लागू किया जा सकता है: 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 के Envoys पर लागू नहीं होता है, जिससे हमें फ्रंटएंड को अनधिकृत रूप से छोड़ने की अनुमति मिलती है। नीति लागू करने के लिए, कमांड निष्पादित करें:

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

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

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

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



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

• श्रोता : {Your_AUDIENCE}

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

यहाँ हम लिखते हैं:

• डोमेन : {your_DOMAIN}
• ग्राहक आईडी : {Your_CLIENT_ID}

ऑल्टेड कॉलबैक URLs टेक्स्ट बॉक्स ( कॉलबैक के लिए अनुमत URL) के लिए टेस्ट एप्लिकेशन में स्क्रॉल करें, जिसमें हम उस URL को इंगित करते हैं जहां प्रमाणीकरण पूरा होने के बाद कॉल को भेजा जाना चाहिए। हमारे मामले में, यह है:

 http://{EXTERNAL_IP}/callback 

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

 http://{EXTERNAL_IP}/logout 

चलो आगे की ओर बढ़ते हैं।

सीमांत अद्यतन

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

 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)); } 

sa-frontend/src/services/Auth.js में किरायेदार के डेटा का उपयोग करने के लिए दृश्यपटल को परिवर्तित करने के लिए, 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 स्थिति कोड प्राप्त होगा, जो इंगित करता है कि अनुरोध अधिकृत नहीं है।

चलो अगला कदम उठाते हैं - अनुरोधों को अधिकृत करते हैं।

प्रमाण के साथ प्राधिकरण ०

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

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

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

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

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

Auth0 प्राधिकरण की स्थापना और विन्यास

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

समूह निर्माण

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

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

टोकन तक पहुंचने के लिए समूह दावा जोड़ें

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

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



नीचे दिए गए कोड को कॉपी करें और इसे नए ऐड ग्रुप क्लेम नियम ( namespacedGroup.js ) के रूप में सहेजें।

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

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

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

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

यह आदेश महत्वपूर्ण है क्योंकि समूह फ़ील्ड एसिंक्रोनस रूप से ऑरल-ऑथोराइज़ेशन-एक्सटेंशन नियम को प्राप्त करता है और फिर दूसरे नियम द्वारा दावे के रूप में जोड़ा जाता है। परिणाम एक पहुंच टोकन है:

 { "https://sa.io/group": "Moderators", "iss": "https://sentiment-analysis.eu.auth0.com/", "sub": "google-oauth2|196405271625531691872" // [  ] } 

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

इस्टियो प्राधिकरण विन्यास

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

 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 - Inclusion क्षेत्र में सूचीबद्ध सेवाओं और नामस्थानों के लिए केवल आरबीएसी सक्षम करें;
• 2 - हमारी सेवाओं की सूची को सूचीबद्ध करें।

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

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

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

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

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

• ServiceRole - उन अधिकारों को परिभाषित करता है जो उपयोगकर्ता के पास है;
• ServiceRoleBinding - यह निर्धारित करता है कि यह 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 माध्यम regular-user-binding पृष्ठ पर सभी आगंतुकों के लिए एक ServiceRole लागू करें ( नियमित-उपयोगकर्ता-सेवा-भूमिका-बाध्यकारी-सत्यम ):

 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 जिसका मान मॉडरेटर्स ( mod- सेवा-भूमिका-बाइंडिंग .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 

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

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

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

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

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

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

निष्कर्ष

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

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

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

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

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