ഇസ്തിയോയ്‌ക്കൊപ്പം മൈക്രോസർവീസുകളിലേക്ക് മടങ്ങുക. ഭാഗം 3

കുറിപ്പ്. വിവർത്തനം.: ആദ്യ ഭാഗം ഈ സീരീസ് ഇസ്തിയോയുടെ കഴിവുകൾ അറിയുന്നതിനും അവ പ്രവർത്തനത്തിൽ പ്രകടിപ്പിക്കുന്നതിനുമായി നീക്കിവച്ചിരിക്കുന്നു, രണ്ടാമത്തേത് - നന്നായി ട്യൂൺ ചെയ്ത റൂട്ടിംഗും നെറ്റ്‌വർക്ക് ട്രാഫിക് മാനേജുമെന്റും. ഇപ്പോൾ നമ്മൾ സുരക്ഷയെക്കുറിച്ച് സംസാരിക്കും: അതുമായി ബന്ധപ്പെട്ട അടിസ്ഥാന പ്രവർത്തനങ്ങൾ പ്രദർശിപ്പിക്കുന്നതിന്, രചയിതാവ് Auth0 ഐഡന്റിറ്റി സേവനം ഉപയോഗിക്കുന്നു, എന്നാൽ മറ്റ് ദാതാക്കളെ സമാനമായ രീതിയിൽ ക്രമീകരിക്കാൻ കഴിയും.

ഞങ്ങൾ ഒരു കുബെർനെറ്റസ് ക്ലസ്റ്ററും ഇസ്തിയോയുടെ കഴിവുകൾ പ്രകടിപ്പിക്കുന്നതിനായി ഒരു ഉദാഹരണ മൈക്രോസർവീസ് ആപ്ലിക്കേഷനായ സെന്റിമെന്റ് അനാലിസിസും വിന്യസിച്ചു.

Retries, Timeouts, Circuit Breakers, Tracing, Monitoring തുടങ്ങിയ ലെയറുകൾ നടപ്പിലാക്കേണ്ട ആവശ്യമില്ലാത്തതിനാൽ 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

അത്തരമൊരു റിസോഴ്സ് ഉപയോഗിച്ച്, പൈലറ്റ് (ഇസ്റ്റിയോയിലെ മൂന്ന് അടിസ്ഥാന കൺട്രോൾ പ്ലെയിൻ ഘടകങ്ങളിൽ ഒന്ന് - ഏകദേശം. വിവർത്തനം.) അഭ്യർത്ഥനകൾ സേവനങ്ങളിലേക്ക് കൈമാറുന്നതിന് മുമ്പ് ആധികാരികമാക്കുന്നതിന് ദൂതനെ കോൺഫിഗർ ചെയ്യുന്നു: sa-web-app и sa-feedback. അതേ സമയം, കോൺഫിഗറേഷൻ സേവന ദൂതന്മാർക്ക് ബാധകമല്ല sa-frontend, ആധികാരികതയില്ലാത്ത മുൻഭാഗം വിടാൻ ഞങ്ങളെ അനുവദിക്കുന്നു. നയം പ്രയോഗിക്കുന്നതിന്, കമാൻഡ് പ്രവർത്തിപ്പിക്കുക:

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

പേജിലേക്ക് മടങ്ങി ഒരു അഭ്യർത്ഥന നടത്തുക - അത് സ്റ്റാറ്റസോടെ അവസാനിക്കുന്നത് നിങ്ങൾ കാണും XXX അംഗീകാരമില്ലാത്തതാണ്. Auth0 ഉപയോഗിച്ച് ആധികാരികമാക്കാൻ ഇനി ഫ്രണ്ട്‌എൻഡ് ഉപയോക്താക്കളെ റീഡയറക്‌ട് ചെയ്യാം.

Auth0 ഉപയോഗിച്ച് അഭ്യർത്ഥനകൾ പ്രാമാണീകരിക്കുന്നു

അന്തിമ ഉപയോക്തൃ അഭ്യർത്ഥനകൾ ആധികാരികമാക്കാൻ, നിങ്ങൾ ആധികാരിക സേവനങ്ങളെ (അവലോകനങ്ങൾ, വിശദാംശങ്ങൾ, റേറ്റിംഗുകൾ) പ്രതിനിധീകരിക്കുന്ന ഒരു API Auth0-ൽ സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഒരു 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 റിപ്പോസിറ്റോറിയ [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-ലേക്ക് റീഡയറക്‌ടുചെയ്യും, അവിടെ നിങ്ങൾ ലോഗിൻ ചെയ്യേണ്ടതുണ്ട് (അല്ലെങ്കിൽ രജിസ്റ്റർ ചെയ്യുക), അതിനുശേഷം ഇതിനകം ആധികാരികമായ അഭ്യർത്ഥനകൾ നടത്തുന്ന പേജിലേക്ക് നിങ്ങളെ തിരികെ അയയ്‌ക്കും. ലേഖനത്തിന്റെ ആദ്യ ഭാഗങ്ങളിൽ പറഞ്ഞിരിക്കുന്ന കമാൻഡുകൾ curl ഉപയോഗിച്ച് പരീക്ഷിച്ചാൽ, നിങ്ങൾക്ക് കോഡ് ലഭിക്കും 401 സ്റ്റാറ്റസ് കോഡ്, അഭ്യർത്ഥനയ്ക്ക് അംഗീകാരമില്ലെന്ന് സൂചന നൽകുന്നു.

നമുക്ക് അടുത്ത ഘട്ടം എടുക്കാം - അഭ്യർത്ഥനകൾ അംഗീകരിക്കുക.

Auth0 ഉപയോഗിച്ചുള്ള അംഗീകാരം

ഒരു ഉപയോക്താവ് ആരാണെന്ന് മനസ്സിലാക്കാൻ പ്രാമാണീകരണം ഞങ്ങളെ അനുവദിക്കുന്നു, എന്നാൽ അവർക്ക് ആക്സസ് എന്താണെന്ന് അറിയാൻ അംഗീകാരം ആവശ്യമാണ്. ഇതിനുള്ള ടൂളുകളും ഇസ്തിയോ വാഗ്ദാനം ചെയ്യുന്നു.

ഉദാഹരണമായി, നമുക്ക് രണ്ട് ഉപയോക്തൃ ഗ്രൂപ്പുകൾ സൃഷ്ടിക്കാം (ചുവടെയുള്ള ഡയഗ്രം കാണുക):

• ഉപയോക്താക്കൾ (ഉപയോക്താക്കൾ) - SA-WebApp, SA-Frontend സേവനങ്ങളിലേക്ക് മാത്രം ആക്‌സസ്സ്;
• മോഡറേറ്റർമാർ (മോഡറേറ്റർമാർ) - മൂന്ന് സേവനങ്ങളിലേക്കും പ്രവേശനം.

അംഗീകാര ആശയം

ഈ ഗ്രൂപ്പുകൾ സൃഷ്‌ടിക്കുന്നതിന്, ഞങ്ങൾ Auth0 ഓതറൈസേഷൻ വിപുലീകരണം ഉപയോഗിക്കുകയും അവർക്ക് വിവിധ തലത്തിലുള്ള ആക്‌സസ് നൽകുന്നതിന് ഇസ്തിയോ ഉപയോഗിക്കുകയും ചെയ്യും.

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-authorization-extension
• ഗ്രൂപ്പ് ക്ലെയിം ചേർക്കുക

ഗ്രൂപ്പ് ഫീൽഡിന് റൂൾ അസമന്വിതമായി ലഭിക്കുന്നതിനാൽ ഓർഡർ പ്രധാനമാണ് auth0-authorization-extension അതിനു ശേഷം അത് രണ്ടാമത്തെ നിയമം വഴി ഒരു ക്ലെയിം ആയി ചേർക്കുന്നു. ഫലം ഇതുപോലുള്ള ഒരു ആക്സസ് ടോക്കൺ ആണ്:

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

ഇപ്പോൾ നിങ്ങൾ ഉപയോക്തൃ ആക്‌സസ് പരിശോധിക്കാൻ എൻവോയ് പ്രോക്‌സി കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്, അതിനായി ഗ്രൂപ്പിനെ ക്ലെയിമിൽ നിന്ന് പിൻവലിക്കും (https://sa.io/group) തിരിച്ചെത്തിയ ആക്സസ് ടോക്കണിൽ. ലേഖനത്തിന്റെ അടുത്ത ഭാഗത്തിനുള്ള വിഷയം ഇതാണ്.

ഇസ്തിയോയിലെ ഓതറൈസേഷൻ കോൺഫിഗറേഷൻ

പ്രവർത്തിക്കാനുള്ള അംഗീകാരത്തിനായി, നിങ്ങൾ ഇസ്റ്റിയോയ്‌ക്കായി 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 സേവനങ്ങളിലേക്ക് ആക്സസ് ഉണ്ടായിരിക്കണം. ഇനിപ്പറയുന്ന ഇസ്റ്റിയോ ഉറവിടങ്ങൾ ഉപയോഗിച്ച് നടപ്പിലാക്കി:

• സർവീസ് റോൾ - ഉപയോക്താവിന് ഉള്ള അവകാശങ്ങൾ നിർണ്ണയിക്കുന്നു;
• സർവീസ് റോൾ ബൈൻഡിംഗ് - ഈ സർവീസ് റോൾ ആരുടേതാണെന്ന് നിർണ്ണയിക്കുന്നു.

സാധാരണ ഉപയോക്താക്കൾക്ക് ഞങ്ങൾ ചില സേവനങ്ങളിലേക്ക് ആക്സസ് അനുവദിക്കും (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