Istio सह microservices वर परत. भाग 3

नोंद. अनुवाद: पहिला भाग ही मालिका Istio च्या क्षमता जाणून घेण्यासाठी आणि कृतीत दाखवण्यासाठी समर्पित होती, दुसरा - बारीक ट्यून केलेले रूटिंग आणि नेटवर्क रहदारी व्यवस्थापन. आता आपण सुरक्षिततेबद्दल बोलू: त्याच्याशी संबंधित मूलभूत कार्ये प्रदर्शित करण्यासाठी, लेखक Auth0 ओळख सेवा वापरतो, परंतु इतर प्रदाते त्याच प्रकारे कॉन्फिगर केले जाऊ शकतात.

आम्ही Kubernetes क्लस्टर सेट केले ज्यामध्ये Istio आणि Istio च्या क्षमतांचे प्रदर्शन करण्यासाठी एक उदाहरण मायक्रोसर्व्हिस ऍप्लिकेशन, सेंटिमेंट ॲनालिसिस, तैनात केले.

Istio सह, आम्ही आमच्या सेवा लहान ठेवू शकलो कारण त्यांना पुन्हा प्रयत्न, टाइमआउट्स, सर्किट ब्रेकर्स, ट्रेसिंग, मॉनिटरिंग सारखे स्तर लागू करण्याची आवश्यकता नाही. याव्यतिरिक्त, आम्ही प्रगत चाचणी आणि उपयोजन तंत्रे वापरली: A/B चाचणी, मिररिंग आणि कॅनरी रोलआउट्स.

नवीन सामग्रीमध्ये, आम्ही व्यवसाय मूल्याच्या मार्गावरील अंतिम स्तरांवर व्यवहार करू: प्रमाणीकरण आणि अधिकृतता - आणि Istio मध्ये हा खरा आनंद आहे!

Istio मध्ये प्रमाणीकरण आणि अधिकृतता

मला कधीच विश्वास बसला नाही की मी प्रमाणीकरण आणि अधिकृततेने प्रेरित होईल. हे विषय मनोरंजक आणि त्याहूनही अधिक, तुमच्यासाठी प्रेरणादायी बनवण्यासाठी तंत्रज्ञानाच्या दृष्टीकोनातून Istio काय देऊ शकते?

उत्तर सोपे आहे: Istio या क्षमतांची जबाबदारी तुमच्या सेवांमधून दूत प्रॉक्सीकडे हलवते. सेवांपर्यंत विनंत्या पोहोचेपर्यंत, त्या आधीच प्रमाणित आणि अधिकृत केल्या गेल्या आहेत, त्यामुळे तुम्हाला फक्त व्यवसाय-उपयुक्त कोड लिहायचा आहे.

छान वाटतंय? चला आत एक नजर टाकूया!

Auth0 सह प्रमाणीकरण

ओळख आणि प्रवेश व्यवस्थापनासाठी सर्व्हर म्हणून, आम्ही Auth0 चा वापर करू, ज्याची चाचणी आवृत्ती आहे, वापरण्यास अंतर्ज्ञानी आहे आणि मला ते आवडते. तथापि, समान तत्त्वे इतर कोणत्याही लागू केले जाऊ शकतात OpenID Connect अंमलबजावणी: 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

अशा संसाधनासह, पायलट (Istio मधील तीन मूलभूत कंट्रोल प्लेन घटकांपैकी एक - अंदाजे भाषांतर.) विनंत्या सेवांना अग्रेषित करण्यापूर्वी त्यांना प्रमाणीकृत करण्यासाठी दूत कॉन्फिगर करते: 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 मध्ये एक API तयार करणे आवश्यक आहे जे प्रमाणीकृत सेवा (पुनरावलोकने, तपशील आणि रेटिंग) दर्शवेल. API तयार करण्यासाठी, वर जा Auth0 पोर्टल > API > API तयार करा आणि फॉर्म भरा:

येथे महत्वाची माहिती आहे अभिज्ञापक, ज्याचा वापर आपण नंतर स्क्रिप्टमध्ये करू. चला ते असे लिहूया:

• प्रेक्षक: {YOUR_AUDIENCE}

आम्हाला आवश्यक असलेले उर्वरित तपशील विभागातील Auth0 पोर्टलवर आहेत अनुप्रयोग - निवडा चाचणी अर्ज (API सह आपोआप तयार केलेले).

येथे आम्ही लिहू:

• डोमेन: {YOUR_DOMAIN}
• क्लायंट आयडी: {YOUR_CLIENT_ID}

पर्यंत स्क्रोल करा चाचणी अर्ज मजकूर फील्डवर अनुमत कॉलबॅक URL (कॉलबॅकसाठी सोडवलेले URL), ज्यामध्ये प्रमाणीकरण पूर्ण झाल्यानंतर कॉल कोठे पाठवला जावा ते आम्ही URL निर्दिष्ट करतो. आमच्या बाबतीत ते आहे:

http://{EXTERNAL_IP}/callback

आणि साठी अनुमत लॉगआउट URL (लॉग आउट करण्यासाठी परवानगी दिलेल्या URL) जोडा:

http://{EXTERNAL_IP}/logout

चला फ्रंटएंड वर जाऊया.

फ्रंटएंड अपडेट

शाखेत जा auth0 REPOZITORIA [istio-mastery]. या शाखेत, वापरकर्त्यांना प्रमाणीकरणासाठी Auth0 वर पुनर्निर्देशित करण्यासाठी आणि इतर सेवांना विनंती करताना 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));
}

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 सह अधिकृतता

प्रमाणीकरण आम्हाला वापरकर्ता कोण आहे हे समजून घेण्यास अनुमती देते, परंतु त्यांना काय प्रवेश आहे हे जाणून घेण्यासाठी अधिकृतता आवश्यक आहे. Istio यासाठी देखील साधने ऑफर करते.

उदाहरण म्हणून, दोन वापरकर्ता गट तयार करू (खालील आकृती पहा):

• वापरकर्ते (वापरकर्ते) — फक्त SA-WebApp आणि SA-Frontend सेवांमध्ये प्रवेशासह;
• नियंत्रक (नियंत्रक) - तिन्ही सेवांमध्ये प्रवेशासह.

अधिकृतता संकल्पना

हे गट तयार करण्यासाठी, आम्ही Auth0 ऑथोरायझेशन एक्स्टेंशन वापरू आणि त्यांना विविध स्तरांवर प्रवेश प्रदान करण्यासाठी Istio वापरू.

Auth0 अधिकृतता स्थापित करणे आणि कॉन्फिगरेशन

Auth0 पोर्टलमध्ये, विस्तारांवर जा (विस्तार) आणि स्थापित करा Auth0 अधिकृतता. स्थापनेनंतर, वर जा अधिकृतता विस्तार, आणि तेथे - वरच्या उजवीकडे क्लिक करून आणि योग्य मेनू पर्याय निवडून भाडेकरूच्या कॉन्फिगरेशनवर जा (कॉन्फिगरेशन). गट सक्रिय करा (गट) आणि प्रकाशित नियम बटणावर क्लिक करा (नियम प्रकाशित करा).

गट तयार करणे

अधिकृतता विस्तारामध्ये जा गट आणि एक गट तयार करा नियंत्रक. आम्ही सर्व प्रमाणीकृत वापरकर्त्यांना नियमित वापरकर्ते मानणार असल्याने, त्यांच्यासाठी अतिरिक्त गट तयार करण्याची गरज नाही.

एक गट निवडा नियंत्रक, दाबा सभासद जोडा, तुमचे मुख्य खाते जोडा. काही वापरकर्त्यांना प्रवेश नाकारला गेला आहे याची खात्री करण्यासाठी कोणत्याही गटाशिवाय सोडा. (नवीन वापरकर्ते याद्वारे व्यक्तिचलितपणे तयार केले जाऊ शकतात Auth0 पोर्टल > वापरकर्ते > वापरकर्ता तयार करा.)

प्रवेश टोकनमध्ये गट हक्क जोडा

वापरकर्ते गटांमध्ये जोडले गेले आहेत, परंतु ही माहिती ऍक्सेस टोकनमध्ये देखील प्रतिबिंबित करणे आवश्यक आहे. OpenID Connect चे पालन करण्यासाठी आणि त्याच वेळी आम्हाला आवश्यक असलेले गट परत करण्यासाठी, टोकनला स्वतःचे जोडणे आवश्यक आहे सानुकूल दावा. Auth0 नियमांद्वारे लागू केले.

नियम तयार करण्यासाठी, Auth0 पोर्टलवर जा नियम, दाबा नियम तयार करा आणि टेम्पलेट्समधून रिक्त नियम निवडा.

खालील कोड कॉपी करा आणि नवीन नियम म्हणून सेव्ह करा गट हक्क जोडा (namespacedGroup.js):

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) परत केलेल्या प्रवेश टोकनमध्ये. हा लेखाच्या पुढील भागाचा विषय आहे.

Istio मध्ये अधिकृतता कॉन्फिगरेशन

कार्य करण्यासाठी अधिकृततेसाठी, तुम्ही 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 — फील्डमध्ये सूचीबद्ध केलेल्या सेवा आणि नेमस्पेससाठीच 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 सेवांमध्ये प्रवेश असणे आवश्यक आहे. खालील Istio संसाधने वापरून अंमलबजावणी:

• सेवाभूमिका — वापरकर्त्याचे अधिकार निर्धारित करते;
• सर्व्हिसरोलबाइंडिंग — ही सर्व्हिसरोल कोणाची आहे हे ठरवते.

सामान्य वापरकर्त्यांसाठी आम्ही काही सेवांमध्ये प्रवेश करण्याची परवानगी देऊ (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 सर्व पृष्ठ अभ्यागतांना सर्व्हिसरोल लागू करा (नियमित-वापरकर्ता-सेवा-भूमिका-बाइंडिंग.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

दूतांच्या कॅशिंगमुळे, अधिकृतता नियम लागू होण्यासाठी काही मिनिटे लागू शकतात. त्यानंतर तुम्ही हे सुनिश्चित करू शकता की वापरकर्ते आणि नियंत्रकांना प्रवेशाचे वेगवेगळे स्तर आहेत.

या भागावर निष्कर्ष

गंभीरपणे तरी, प्रमाणीकरण आणि अधिकृततेसाठी तुम्ही कधी सोपा, सहज, स्केलेबल आणि सुरक्षित दृष्टीकोन पाहिला आहे का?

सेवांवरील अंतिम वापरकर्त्याच्या प्रवेशाच्या प्रमाणीकरणावर आणि अधिकृततेवर सूक्ष्म नियंत्रण मिळविण्यासाठी फक्त तीन Istio संसाधने (RbacConfig, ServiceRole, आणि ServiceRoleBinding) आवश्यक आहेत.

या व्यतिरिक्त, आम्ही आमच्या दूत सेवांमधून या समस्यांची काळजी घेतली आहे, हे साध्य केले आहे:

• जेनेरिक कोडचे प्रमाण कमी करणे ज्यामध्ये सुरक्षा समस्या आणि बग असू शकतात;
• मूर्ख परिस्थितींची संख्या कमी करणे ज्यामध्ये एक शेवटचा बिंदू बाहेरून प्रवेश करण्यायोग्य असल्याचे दिसून आले आणि त्याची तक्रार करण्यास विसरले;
• प्रत्येक वेळी नवीन भूमिका किंवा अधिकार जोडल्यावर सर्व सेवा अद्ययावत करण्याची गरज दूर करणे;
• नवीन सेवा साध्या, सुरक्षित आणि जलद राहतील.

निष्कर्ष

Istio कार्यसंघांना सेवांमध्ये ओव्हरहेड न जोडता, त्यांना सूक्ष्म स्थितीत परत न आणता त्यांची संसाधने व्यवसाय-गंभीर कार्यांवर केंद्रित करण्याची परवानगी देतो.

लेख (तीन भागांमध्ये) वास्तविक प्रकल्पांमध्ये Istio सह प्रारंभ करण्यासाठी मूलभूत ज्ञान आणि तयार व्यावहारिक सूचना प्रदान करते.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• "इस्टिओसह मायक्रो सर्व्हिसेसकडे परत जा": भाग १ (मुख्य वैशिष्ट्यांचा परिचय), भाग २ (मार्ग, वाहतूक नियंत्रण);
• «कंड्युट - कुबर्नेट्ससाठी हलकी सेवा जाळी";
• «सर्व्हिस मेश म्हणजे काय आणि मला [मायक्रोसर्व्हिसेससह क्लाउड ऍप्लिकेशनसाठी] याची आवश्यकता का आहे?».

स्त्रोत: www.habr.com