Istio ဖြင့် microservices သို့ ပြန်သွားရန်။ အပိုင်း 3

မှတ်ချက်။ ဘာသာပြန်: ပထမဦးဆုံးအစိတျအပိုငျး ဒီစီးရီးဟာ Istio ရဲ့ စွမ်းဆောင်နိုင်ရည်တွေကို သိလာပြီး လှုပ်ရှားမှုမှာ သရုပ်ပြဖို့ လုံးလုံးလျားလျား လုပ်ဆောင်ခဲ့တာပါ၊ ဒုတိယ - ကောင်းစွာပြင်ဆင်ထားသောလမ်းကြောင်းနှင့် ကွန်ရက်အသွားအလာစီမံခန့်ခွဲမှု။ ယခုကျွန်ုပ်တို့သည်လုံခြုံရေးအကြောင်းပြောပါမည်- ၎င်းနှင့်သက်ဆိုင်သည့်အခြေခံလုပ်ဆောင်ချက်များကိုသရုပ်ပြရန် စာရေးသူသည် Auth0 အထောက်အထားဝန်ဆောင်မှုကိုအသုံးပြုသော်လည်း အခြားပံ့ပိုးပေးသူများကိုအလားတူပုံစံဖြင့် configure လုပ်နိုင်ပါသည်။

Istio ၏စွမ်းရည်များကိုပြသရန်အတွက်ကျွန်ုပ်တို့သည် Istio နှင့်ဥပမာ microservice အပလီကေးရှင်းတစ်ခု၊ Sentiment Analysis ကိုအသုံးပြုသည့် Kubernetes အစုအဝေးကိုတည်ဆောက်ထားပါသည်။

Istio ဖြင့် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများကို သေးငယ်အောင်ထားနိုင်ခဲ့ပြီး ၎င်းတို့သည် ပြန်လည်ကြိုးစားခြင်း၊ အချိန်ကုန်ခြင်း၊ Circuit Breakers၊ ခြေရာခံခြင်း၊ စောင့်ကြည့်ခြင်းစသည့် အလွှာများကို အကောင်အထည်ဖော်ရန် မလိုအပ်သောကြောင့်ဖြစ်သည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် အဆင့်မြင့်စမ်းသပ်ခြင်းနှင့် ဖြန့်ကျက်ခြင်းနည်းပညာများကို အသုံးပြုခဲ့သည်- A/B စမ်းသပ်ခြင်း၊ ပုံတူကူးခြင်းနှင့် ကိန္နရီထုတ်ခြင်းများကို အသုံးပြုပါသည်။

ပစ္စည်းအသစ်တွင်၊ လုပ်ငန်းတန်ဖိုးသို့သွားရာလမ်းကြောင်းပေါ်ရှိ နောက်ဆုံးအလွှာများကို ကိုင်တွယ်ဖြေရှင်းပါမည်- စစ်မှန်ကြောင်းအထောက်အထားနှင့် ခွင့်ပြုချက်- Istio တွင် ၎င်းသည် အမှန်တကယ် ပျော်ရွှင်မှုတစ်ခုဖြစ်သည်။

Istio ရှိ စစ်မှန်ကြောင်းအထောက်အထားနှင့် ခွင့်ပြုချက်

စစ်မှန်ကြောင်းနှင့် ခွင့်ပြုချက်ဖြင့် ကျွန်ုပ်အား လှုံ့ဆော်ခံရမည်ဟု ဘယ်သောအခါမှ ယုံမည်မဟုတ်ပါ။ ဤအကြောင်းအရာများကို ပျော်စရာကောင်းစေရန် Istio သည် နည်းပညာရှုထောင့်မှ အဘယ်အရာကို ပေးဆောင်နိုင်သနည်း။

အဖြေသည် ရိုးရှင်းသည်- Istio သည် ဤစွမ်းရည်များအတွက် သင့်ဝန်ဆောင်မှုများမှ Envoy proxy သို့ ပြောင်းလဲပေးပါသည်။ တောင်းဆိုချက်များသည် ဝန်ဆောင်မှုများရောက်ရှိချိန်တွင် ၎င်းတို့ကို စစ်မှန်ကြောင်းနှင့် တရားဝင်ခွင့်ပြုထားပြီးဖြစ်သောကြောင့် သင်လုပ်ဆောင်ရမည့်အရာမှာ စီးပွားရေးအတွက် အသုံးဝင်သောကုဒ်ကို ရေးသားခြင်းဖြစ်သည်။

ကောင်းသားပဲ? အတွင်းကိုကြည့်ရအောင်။

Auth0 ဖြင့် စစ်မှန်ကြောင်းအထောက်အထားပြခြင်း။

အထောက်အထားနှင့် ရယူသုံးစွဲနိုင်မှု စီမံခန့်ခွဲမှုအတွက် ဆာဗာတစ်ခုအနေဖြင့် ကျွန်ုပ်တို့သည် အစမ်းဗားရှင်းပါရှိသော Auth0 ကို အသုံးပြုမည်ဖြစ်ပြီး၊ အသုံးပြုရန် အလိုလိုသိမြင်နိုင်ပြီး ၎င်းကို ကျွန်ုပ်နှစ်သက်ပါသည်။ သို့သော် တူညီသောမူများကို အခြားမည်သည့်အရာနှင့်မဆို အသုံးချနိုင်သည်။ OpenID Connect အကောင်အထည်ဖော်မှုများKeyCloak၊ IdentityServer နှင့် အခြားများစွာသော အခြားအရာများ။

စတင်ရန်၊ သို့ သွားပါ။ Auth0 Portal သင့်အကောင့်ဖြင့် အိမ်ငှားတစ်ဦးကို ဖန်တီးပါ။ (အိမ်ငှား - "အိမ်ငှား"၊ အသေးစိတ်အချက်အလက်များအတွက် သီးခြားခွဲထုတ်ခြင်း၏ ယုတ္တိတန်သောယူနစ်ကို ကြည့်ပါ။ စာရွက်စာတမ်း - ခန့်မှန်းခြေ ဘာသာပြန်။) သွားပြီး၊ အက်ပ်များ > မူရင်းအက်ပ်ရွေးချယ်ခြင်း ဒိုမိန်းအောက်ပါ screenshot တွင်ပြထားသည့်အတိုင်း၊

ဖိုင်တွင် ဤဒိုမိန်းကို သတ်မှတ်ပါ။ 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

အဲဒီလို အရင်းအနှီးနဲ့ Pilot ပေါ့။ (Istio ရှိ အခြေခံ Control Plane အစိတ်အပိုင်း သုံးခုအနက်မှ တစ်ခု - ခန့်မှန်းခြေ ဘာသာပြန်ပါသည်။) တောင်းဆိုချက်များကို ဝန်ဆောင်မှုများသို့ မပို့မီ အထောက်အထားစိစစ်ရန် Envoy ကို စီစဉ်သတ်မှတ်သည်- sa-web-app и sa-feedback. တစ်ချိန်တည်းတွင်၊ ဖွဲ့စည်းမှုပုံစံကို ဝန်ဆောင်မှု Envoys တွင် သက်ရောက်မှုမရှိပါ။ sa-frontendရှေ့တန်းကို အထောက်အထားမခိုင်လုံဘဲ ထွက်သွားခွင့်ပေးသည်။ မူဝါဒကိုအသုံးပြုရန်၊ အမိန့်ကိုဖွင့်ပါ-

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

စာမျက်နှာသို့ ပြန်သွားပြီး တောင်းဆိုချက်တစ်ခု ပြုလုပ်ပါ - ၎င်းသည် အခြေအနေနှင့် အဆုံးသတ်သည်ကို သင်တွေ့ရပါမည်။ 401 လုပ်ပိုင်ခွင့်မရှိပါ. ယခု Auth0 ဖြင့် စစ်မှန်ကြောင်းအထောက်အထားပြရန် frontend အသုံးပြုသူများကို ပြန်ညွှန်းလိုက်ကြပါစို့။

Auth0 ဖြင့် တောင်းဆိုချက်များကို စစ်မှန်ကြောင်းအထောက်အထားပြခြင်း။

အသုံးပြုသူတောင်းဆိုမှုများကို စစ်မှန်ကြောင်းအထောက်အထားပြရန်၊ စစ်မှန်ကြောင်းအတည်ပြုထားသောဝန်ဆောင်မှုများ (ပြန်လည်သုံးသပ်ခြင်း၊ အသေးစိတ်နှင့် အဆင့်သတ်မှတ်ချက်များ) ကိုကိုယ်စားပြုမည့် Auth0 တွင် API တစ်ခုဖန်တီးရန် လိုအပ်ပါသည်။ API တစ်ခုဖန်တီးရန်၊ သို့သွားပါ။ Auth0 Portal > APIs > API ဖန်တီးပါ။ ဖောင်ကိုဖြည့်ပါ။

ဤနေရာတွင် အရေးကြီးသောအချက်မှာ ခွဲခြားသတ်မှတ်ဇာတ်ညွှန်းတွင် နောက်မှသုံးပါမည်။ ဒီအတိုင်းရေးကြည့်ရအောင်။

• ပရိသတ်- {YOUR_AUDIENCE}

ကျွန်ုပ်တို့လိုအပ်သော ကျန်အသေးစိတ်အချက်အလက်များမှာ ကဏ္ဍရှိ Auth0 Portal တွင် တည်ရှိနေပါသည်။ applications ကို - ရွေးချယ်ပါ။ စမ်းသပ်လျှောက်လွှာ (API နှင့်အတူ အလိုအလျောက် ဖန်တီးထားသည်)။

ဤတွင်ကျွန်ုပ်တို့ရေးပါမည်:

• ဒိုမိန်း− {YOUR_DOMAIN}
• သုံးစွဲသူ ID- {YOUR_CLIENT_ID}

သို့ ဆင်းပါ။ စမ်းသပ်လျှောက်လွှာ စာသားအကွက်သို့ ပြန်ခေါ်ရန် URL များကို ခွင့်ပြုထားသည်။ (ပြန်ခေါ်ခြင်းအတွက် ဖြေရှင်းထားသော URL များ)၊ အထောက်အထားစိစစ်ခြင်းပြီးဆုံးပြီးနောက် ခေါ်ဆိုမှုပေးပို့သင့်သည့် URL ကို သတ်မှတ်ပေးပါသည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊

http://{EXTERNAL_IP}/callback

ထိုအဘို့ ထွက်ရန် URL များကို ခွင့်ပြုထားသည်။ (ထွက်ရန်ခွင့်ပြုထားသော URL များ) ထည့်ပါ-

http://{EXTERNAL_IP}/logout

ရှေ့ဆုံးသို့ ဆက်သွားကြပါစို့။

Frontend အပ်ဒိတ်

ဌာနခွဲသို့ပြောင်းပါ။ 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 ID ကို သတ်မှတ်ပါ-

$ 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 ဖြင့် ခွင့်ပြုချက်

စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းသည် ကျွန်ုပ်တို့အား သုံးစွဲသူတစ်ဦးဖြစ်သည်ကို နားလည်နိုင်သော်လည်း ၎င်းတို့ထံဝင်ရောက်ခွင့်ရှိသည်ကို သိရှိရန် ခွင့်ပြုချက်လိုအပ်ပါသည်။ Istio သည် ၎င်းအတွက် ကိရိယာများကိုလည်း ပေးပါသည်။

ဥပမာအနေနဲ့၊ အသုံးပြုသူအုပ်စုနှစ်ခုကို ဖန်တီးကြည့်ရအောင် (အောက်က ပုံကြမ်းကိုကြည့်ပါ)။

• အသုံးပြုသူများသည် (အသုံးပြုသူများ) — SA-WebApp နှင့် SA-Frontend ဝန်ဆောင်မှုများသို့သာ ဝင်ရောက်ခွင့်၊
• ကြီးကြပ်သူများ (ထိန်းကျောင်းသူများ) - ဝန်ဆောင်မှု သုံးခုစလုံးကို အသုံးပြုနိုင်ခြင်း။

ခွင့်ပြုချက်အယူအဆ

ဤအဖွဲ့များကို ဖန်တီးရန်၊ ကျွန်ုပ်တို့သည် Auth0 ခွင့်ပြုချက်ဆိုင်ရာ တိုးချဲ့မှုကို အသုံးပြုပြီး ၎င်းတို့အား ကွဲပြားခြားနားသော ဝင်ရောက်ခွင့်အဆင့်များပေးစွမ်းရန် Istio ကို အသုံးပြုပါမည်။

Auth0 Authorization ကို တပ်ဆင်ခြင်းနှင့် ဖွဲ့စည်းမှု

Auth0 portal တွင်၊ extensions သို့သွားပါ (extensions) နှင့် install လုပ်ပါ။ Auth0 ခွင့်ပြုချက်. တပ်ဆင်ပြီးနောက်၊ သို့သွားပါ။ ခွင့်ပြုချက် တိုးချဲ့မှုနှင့် အဲဒီမှာ - အပေါ်ညာဘက်အပေါ်ကိုနှိပ်ပြီး သင့်လျော်သောမီနူးရွေးချယ်မှုကို ရွေးချယ်ခြင်းဖြင့် အိမ်ငှား၏ဖွဲ့စည်းပုံသို့ (ပြင်ဆင်မှု). အဖွဲ့များကို အသက်သွင်းပါ။ (အုပ်စုများ) ပြီးလျှင် Publish rule ခလုတ်ကို နှိပ်ပါ။ (စည်းကမ်းထုတ်ပြန်ခြင်း).

အဖွဲ့များဖန်တီးခြင်း။

Authorization Extension မှာ သွားလိုက်ပါ။ အဖွဲ့များ နှင့်အဖွဲ့တစ်ခုဖန်တီးပါ။ မော်ဒ. ကျွန်ုပ်တို့သည် စစ်မှန်သောအသုံးပြုသူများအားလုံးကို ပုံမှန်အသုံးပြုသူများအဖြစ် ဆက်ဆံမည်ဖြစ်သောကြောင့် ၎င်းတို့အတွက် အပိုအဖွဲ့တစ်ခုကို ဖန်တီးရန် မလိုအပ်ပါ။

အဖွဲ့ကို ရွေးပါ။ မော်ဒ၊စာနယ်ဇင်း အသင်းဝင်များထည့်ပါသင်၏ပင်မအကောင့်ကိုထည့်ပါ။ ဝင်ရောက်ခွင့် ငြင်းပယ်ခံရကြောင်း သေချာစေရန် အချို့သော သုံးစွဲသူများကို မည်သည့်အဖွဲ့မှ ချန်ထားခဲ့ပါ။ (အသုံးပြုသူအသစ်များမှတဆင့် ကိုယ်တိုင်ဖန်တီးနိုင်ပါသည်။ Auth0 Portal > အသုံးပြုသူများ > အသုံးပြုသူကို ဖန်တီးပါ။.)

Access Token သို့ အုပ်စုအရေးဆိုမှုကို ထည့်ပါ။

အသုံးပြုသူများကို အဖွဲ့များသို့ ပေါင်းထည့်ထားပြီးဖြစ်သော်လည်း ဤအချက်အလက်ကို ဝင်ရောက်ခွင့်တိုကင်များတွင်လည်း ထင်ဟပ်စေရပါမည်။ OpenID Connect ကိုလိုက်နာရန်နှင့် ကျွန်ုပ်တို့လိုအပ်သောအဖွဲ့များကို တစ်ချိန်တည်းတွင်ပြန်ပေးရန်၊ တိုကင်သည် ၎င်း၏ကိုယ်ပိုင်ထည့်ရန် လိုအပ်မည်ဖြစ်သည်။ စိတ်ကြိုက်တောင်းဆိုမှု. Auth0 စည်းမျဉ်းများဖြင့် အကောင်အထည်ဖော်ခဲ့သည်။

စည်းမျဉ်းတစ်ခုဖန်တီးရန် Auth0 Portal သို့သွားပါ။ စည်းကမ်းများ၊စာနယ်ဇင်း စည်းကမ်းဖန်တီးပါ။ နမူနာပုံစံများမှ ဗလာစည်းမျဉ်းတစ်ခုကို ရွေးပါ။

အောက်ပါကုဒ်ကို ကော်ပီကူးပြီး စည်းကမ်းအသစ်အဖြစ် သိမ်းဆည်းပါ။ အုပ်စုအရေးဆိုမှုကို ထည့်ပါ။ (namespacedGroup.js):

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

ပွောဆို: ဤကုဒ်သည် Authorization တိုးချဲ့မှုတွင် သတ်မှတ်ထားသော ပထမဆုံးအသုံးပြုသူအုပ်စုကို ယူသွားပြီး စိတ်ကြိုက်အရေးဆိုမှုတစ်ခုအဖြစ် (Auth0 မှ လိုအပ်သည့်အတိုင်း ၎င်း၏အမည်နေရာအောက်တွင်) အသုံးပြုခွင့်တိုကင်သို့ ပေါင်းထည့်သည်။

စာမျက်နှာသို့ ပြန်သွားရန် စည်းကမ်းများ သင့်တွင် အောက်ပါအစီအစဥ်အတိုင်း ရေးထားသော စည်းမျဉ်းနှစ်ခုရှိကြောင်း စစ်ဆေးပါ။

• auth0-authorization-extension
• အုပ်စုအရေးဆိုမှုကို ထည့်ပါ။

အဖွဲ့အကွက်သည် စည်းမျဉ်းကို တပြိုင်တည်း လက်ခံရရှိသောကြောင့် အမိန့်သည် အရေးကြီးပါသည်။ auth0-authorization-extension ထို့နောက် ၎င်းကို ဒုတိယနည်းဥပဒေဖြင့် တိုင်ကြားမှုအဖြစ် ထည့်သွင်းထားသည်။ ရလဒ်သည် ဤကဲ့သို့သော ဝင်ရောက်ခွင့် တိုကင်တစ်ခုဖြစ်သည်-

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

ယခုတွင် သင်သည် အသုံးပြုသူဝင်ရောက်ခွင့်ကို စစ်ဆေးရန် Envoy proxy ကို ပြင်ဆင်သတ်မှတ်ရန် လိုအပ်ပြီး ၎င်းတို့သည် အရေးဆိုမှုမှ အုပ်စုကို ထုတ်ယူမည် (https://sa.io/group) ပြန်လည်ဝင်ရောက်ခွင့် တိုကင်တွင်။ ဤသည်မှာ ဆောင်းပါး၏ နောက်အပိုင်းအတွက် ခေါင်းစဉ်ဖြစ်သည်။

Istio ရှိ ခွင့်ပြုချက်ဖွဲ့စည်းမှု

အလုပ်လုပ်ရန်ခွင့်ပြုချက်အတွက်၊ သင်သည် Istio အတွက် RBAC ကိုဖွင့်ရပါမည်။ ဒါကိုလုပ်ဖို့၊ အောက်ပါ configuration ကိုသုံးပါမယ်။

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 — ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများစာရင်းကို စာရင်းပြုစုထားပါသည်။

အောက်ပါ command ဖြင့် configuration ကိုသုံးကြပါစို့။

$ 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 သည် မည်သူဖြစ်သည်ကို ဆုံးဖြတ်သည်။

သာမာန်အသုံးပြုသူများအတွက် ကျွန်ုပ်တို့သည် အချို့သောဝန်ဆောင်မှုများသို့ ဝင်ရောက်ခွင့်ပြုပါမည် (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 ကို စာမျက်နှာလာရောက်ကြည့်ရှုသူအားလုံးအတွက် အသုံးပြုပါ (ပုံမှန်-user-service-role-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 နှင့် စတင်ရန်အတွက် အဆင်သင့်လုပ်ထားသည့် လက်တွေ့လမ်းညွှန်ချက်များကို ပေးထားသည်။

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• "Istio ဖြင့် အသေးစားဝန်ဆောင်မှုများသို့ ပြန်သွားရန်"- အပိုင်း 1 (အဓိကအင်္ဂါရပ်များမိတ်ဆက်), အပိုင်း 2 (လမ်းကြောင်း၊ ယာဉ်ထိန်း);
• «Conduit - Kubernetes အတွက် ပေါ့ပါးသော ဝန်ဆောင်မှုကွက်";
• «ဝန်ဆောင်မှု mesh ဆိုတာ ဘာလဲ၊ [မိုက်ခရိုဝန်ဆောင်မှုများပါသော cloud application တစ်ခုအတွက်] ဘာကြောင့် လိုအပ်တာလဲ။"။

source: www.habr.com