Istio संग microservices मा फर्कनुहोस्। भाग 3

नोट। अनुवाद।: पहिलो भाग यो श्रृंखला Istio को क्षमताहरू जान्न र तिनीहरूलाई कार्यमा प्रदर्शन गर्न समर्पित थियो, दोस्रो - राम्रोसँग ट्युन गरिएको मार्ग र नेटवर्क ट्राफिक व्यवस्थापन। अब हामी सुरक्षाको बारेमा कुरा गर्नेछौं: यससँग सम्बन्धित आधारभूत कार्यहरू प्रदर्शन गर्न, लेखकले Auth0 पहिचान सेवा प्रयोग गर्दछ, तर अन्य प्रदायकहरू समान रूपमा कन्फिगर गर्न सकिन्छ।

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

Istio को साथ, हामीले हाम्रा सेवाहरूलाई सानो राख्न सक्षम भयौं किनभने तिनीहरूले पुन: प्रयासहरू, टाइमआउटहरू, सर्किट ब्रेकरहरू, ट्रेसिङ, निगरानी जस्ता तहहरू लागू गर्न आवश्यक पर्दैन। थप रूपमा, हामीले उन्नत परीक्षण र तैनाती प्रविधिहरू प्रयोग गर्यौं: A/B परीक्षण, मिररिङ र क्यानरी रोलआउटहरू।

नयाँ सामग्रीमा, हामी व्यापार मूल्यको मार्गमा अन्तिम तहहरूसँग व्यवहार गर्नेछौं: प्रमाणीकरण र प्राधिकरण - र Istio मा यो एक वास्तविक आनन्द हो!

Istio मा प्रमाणीकरण र प्राधिकरण

म प्रमाणीकरण र प्राधिकरण द्वारा प्रेरित हुनेछु भनेर मैले कहिल्यै विश्वास गर्दिन। Istio ले यी विषयहरूलाई रमाइलो बनाउनको लागि टेक्नोलोजी दृष्टिकोणबाट के प्रस्ताव गर्न सक्छ, र अझ बढी, तपाईंलाई प्रेरित गर्न?

जवाफ सरल छ: Istio ले यी क्षमताहरूको लागि तपाईंको सेवाहरूबाट राजदूत प्रोक्सीमा जिम्मेवारी सार्छ। अनुरोधहरू सेवाहरूमा पुग्दा, तिनीहरू पहिले नै प्रमाणीकरण र अधिकृत भइसकेका छन्, त्यसैले तपाईंले गर्नु पर्ने भनेको व्यवसाय-उपयोगी कोड लेख्नु हो।

राम्रो लाग्छ? भित्र हेरौं!

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

यस्तो स्रोत संग, पायलट (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 पोर्टल > APIs > API सिर्जना गर्नुहोस् र फारम भर्नुहोस्:

महत्त्वपूर्ण जानकारी यहाँ छ पहिचानकर्ता, जुन हामी पछि स्क्रिप्टमा प्रयोग गर्नेछौं। यसलाई यसरी लेखौं:

• दर्शक: {YOUR_AUDIENCE}

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

यहाँ हामी लेख्नेछौं:

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

मा स्क्रोल गर्नुहोस् परीक्षण आवेदन पाठ क्षेत्रमा अनुमति दिइएको कलब्याक URL हरू (कलब्याकको लागि समाधान गरिएको URLs), जसमा हामीले प्रमाणीकरण पूरा भएपछि कल पठाइने URL निर्दिष्ट गर्छौं। हाम्रो मामला मा यो छ:

http://{EXTERNAL_IP}/callback

र को लागी अनुमति दिइएको लगआउट URL हरू (लग आउटको लागि अनुमति दिइएको URL हरू) थप्नुहोस्:

http://{EXTERNAL_IP}/logout

अगाडि बढौं।

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

शाखामा स्विच गर्नुहोस् auth0 REPOSITORIA [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;
• २ - हामी हाम्रा सेवाहरूको सूची सूचीबद्ध गर्छौं।

निम्न आदेशको साथ कन्फिगरेसन लागू गरौं:

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

सबै सेवाहरूलाई अब भूमिका-आधारित पहुँच नियन्त्रण आवश्यक छ। अर्को शब्दमा, सबै सेवाहरूमा पहुँच निषेधित छ र प्रतिक्रियाको परिणाम हुनेछ RBAC: access denied। अब अधिकृत प्रयोगकर्ताहरूलाई पहुँच अनुमति दिनुहोस्।

नियमित प्रयोगकर्ताहरूको लागि पहुँच कन्फिगरेसन

सबै प्रयोगकर्ताहरूसँग SA-Frontend र SA-WebApp सेवाहरूमा पहुँच हुनुपर्छ। निम्न Istio स्रोतहरू प्रयोग गरी कार्यान्वयन गरियो:

• सेवा भूमिका - प्रयोगकर्तासँग भएका अधिकारहरू निर्धारण गर्दछ;
• ServiceRoleBinding - यो सेवारोल कसको हो भनेर निर्धारण गर्दछ।

साधारण प्रयोगकर्ताहरूको लागि हामी निश्चित सेवाहरूमा पहुँच अनुमति दिनेछौं (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

दूतहरूमा क्यासिङको कारणले, प्राधिकरण नियमहरू लागू हुन केही मिनेट लाग्न सक्छ। त्यसपछि तपाइँ प्रयोगकर्ताहरू र मध्यस्थकर्ताहरूको पहुँचको विभिन्न स्तरहरू छन् भनेर सुनिश्चित गर्न सक्नुहुन्छ।

यस भागमा निष्कर्ष

गम्भीरताका साथ, के तपाईंले प्रमाणीकरण र प्राधिकरणको लागि सरल, सहज, स्केलेबल र सुरक्षित दृष्टिकोण देख्नुभएको छ?

केवल तीन Istio स्रोतहरू (RbacConfig, ServiceRole, र ServiceRoleBinding) लाई सेवाहरूमा अन्तिम प्रयोगकर्ता पहुँचको प्रमाणीकरण र प्राधिकरणमा राम्रो नियन्त्रण प्राप्त गर्न आवश्यक थियो।

यसका अतिरिक्त, हामीले हाम्रा दूत सेवाहरूबाट यी समस्याहरूको ख्याल राखेका छौं, प्राप्त गर्न:

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

निष्कर्षमा

Istio ले टोलीहरूलाई सेवाहरूमा ओभरहेड थपे बिना, तिनीहरूलाई माइक्रो स्थितिमा फर्काएर व्यापार-महत्वपूर्ण कार्यहरूमा आफ्ना स्रोतहरू केन्द्रित गर्न अनुमति दिन्छ।

लेख (तीन भागहरूमा) ले वास्तविक परियोजनाहरूमा Istio को साथ सुरू गर्न आधारभूत ज्ञान र तयार व्यावहारिक निर्देशनहरू प्रदान गरेको छ।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• "इस्टिओको साथ माइक्रोसर्भिसेसहरूमा फर्कनुहोस्": भाग १ (मुख्य विशेषताहरूको परिचय), भाग २ (मार्ग, ट्राफिक नियन्त्रण);
• «कन्ड्युट - Kubernetes को लागि हल्का सेवा जाल»;
• «सेवा जाल के हो र मलाई किन चाहिन्छ [माइक्रोसर्भिसेसको साथ क्लाउड अनुप्रयोगको लागि]?"।

स्रोत: www.habr.com