بیرته د اسټیو سره مایکرو خدماتو ته. دریمه برخه

نوټ. ژباړه: لومړۍ برخه دا لړۍ د اسټیو وړتیاو پیژندلو او په عمل کې د دوی ښودلو لپاره وقف شوې وه، دوهم - په سمه توګه تنظیم شوی روټینګ او د شبکې ترافیک مدیریت. اوس موږ به د امنیت په اړه وغږیږو: د دې پورې اړوند لومړني دندې ښودلو لپاره ، لیکوال د Auth0 پیژندنې خدمت کاروي ، مګر نور چمتو کونکي په ورته ډول تنظیم کیدی شي.

موږ د Kubernetes کلستر جوړ کړ په کوم کې چې موږ Istio ځای په ځای کړی او د مایکرو سرویس غوښتنلیک مثال، د احساس تحلیل، د اسټیو وړتیاوې ښودلو لپاره.

د اسټیو سره ، موږ وکولی شو خپل خدمات کوچني وساتو ځکه چې دوی اړتیا نلري د پرتونو پلي کولو ته اړتیا ولري لکه د بیاکتنې ، وخت پای ، سرکټ ماتونکي ، تعقیب ، نظارت. برسېره پردې، موږ د ازموینې او پلي کولو پرمختللي تخنیکونه کارولي: د A/B ازموینه، عکس العمل او کانري رول آوټ.

په نوي موادو کې، موږ به د سوداګرۍ ارزښت ته په لاره کې د وروستیو پرتونو سره معامله وکړو: تصدیق او واک - او په اسټیو کې دا ریښتینې خوښي ده!

په اسټیو کې تصدیق او اختیار

ما هیڅکله باور نه درلود چې زه به د تصدیق او اختیار څخه الهام اخلم. اسټیو د ټیکنالوژۍ له لید څخه څه وړاندیز کولی شي ترڅو دا موضوعات ساتیري کړي ، او حتی نور هم تاسو ته الهام درکړي؟

ځواب ساده دی: Istio د دې وړتیاوو مسؤلیت ستاسو د خدماتو څخه د سفیر پراکسي ته لیږدوي. کله چې غوښتنې خدماتو ته ورسیږي، دوی لا دمخه تصدیق شوي او مجاز شوي، نو ټول هغه څه چې تاسو یې باید وکړئ د سوداګرۍ ګټور کوډ ولیکئ.

ډیر ښه؟ راځئ چې دننه وګورو!

د Auth0 سره تصدیق

د پیژندنې او لاسرسي مدیریت لپاره د سرور په توګه ، موږ به Auth0 وکاروو ، کوم چې د آزموینې نسخه لري ، د کارولو لپاره هوښیار دی او زه یې په ساده ډول خوښوم. په هرصورت، ورته اصول په بل هر ډول پلي کیدی شي د OpenID Connect تطبیقات: KeyCloak، IdentityServer او ډیری نور.

لومړی، لاړ شه Auth0 پورټل د خپل حساب سره، کرایه دار جوړ کړئ ( کرایه دار - "اجاره دار"، د انزوا منطقي واحد، د نورو جزیاتو لپاره وګورئ اسناد - نږدې ژباړه.) او لاړ شه غوښتنلیکونه> ډیفالټ اپلیکیشنغوره کول Domain، لکه څنګه چې لاندې سکرین شاټ کې ښودل شوي:

دا ډومین په فایل کې مشخص کړئ 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

پاڼې ته راستانه شئ او غوښتنه وکړئ - تاسو به وګورئ چې دا د وضعیت سره پای ته رسیږي 401 غیر مجاز. اوس راځئ چې د فرنټ انډ کارونکي د Auth0 سره تصدیق کولو لپاره لارښود کړو.

د Auth0 سره د غوښتنې تصدیق کول

د پای کارونکي غوښتنې تصدیق کولو لپاره ، تاسو اړتیا لرئ په Auth0 کې یو API رامینځته کړئ چې د تصدیق شوي خدماتو استازیتوب وکړي (بیاکتنې ، توضیحات ، او درجه بندي). د API جوړولو لپاره، لاړ شئ Auth0 Portal > APIs > API جوړ کړئ او فورمه ډکه کړئ:

مهم معلومات دلته دي په ګوته کړي، کوم چې موږ به وروسته په سکریپټ کې وکاروو. راځئ چې دا په لاندې ډول ولیکئ:

• شفاهي: {YOUR_AUDIENCE}

پاتې توضیحات چې موږ ورته اړتیا لرو په برخه کې د Auth0 پورټل کې موقعیت لري غوښتنلیکونه - انتخاب کړئ د ازموینې غوښتنلیک (په اتوماتيک ډول د API سره جوړ شوی).

دلته به یې لیکو:

• Domain: {YOUR_DOMAIN}
• د پیرودونکي شناخت: {YOUR_CLIENT_ID}

ته سکرول د ازموینې غوښتنلیک د متن ساحې ته اجازه ورکړل شوي کال بیک URLs (د کال بیک لپاره حل شوي URLs) ، په کوم کې چې موږ هغه URL مشخص کوو چیرې چې زنګ باید د تصدیق بشپړیدو وروسته واستول شي. زموږ په قضیه کې دا دی:

http://{EXTERNAL_IP}/callback

او لپاره د ننوتلو اجازه ورکړل شوي URLs (د ننوتلو لپاره اجازه ورکړل شوي URLs) اضافه کړئ:

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}' // Используется для редиректа после аутентификации
}

غوښتنلیک چمتو دی. خپل د ډاکر 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 سره اجازه ورکول

تصدیق موږ ته اجازه راکوي چې پوه شو چې یو کارن څوک دی، مګر اجازه ورکول اړین دي ترڅو پوه شي چې دوی څه ته لاسرسی لري. اسټیو د دې لپاره وسیلې هم وړاندیز کوي.

د مثال په توګه، راځئ چې دوه کاروونکي ګروپونه جوړ کړو (لاندې انځور وګورئ):

• کارونکي (کارونکي) - یوازې د SA-WebApp او SA-Frontend خدماتو ته د لاسرسي سره؛
• منځلاري (منتقدین) - ټولو دریو خدماتو ته د لاسرسي سره.

د واک ورکولو مفهوم

د دې ګروپونو رامینځته کولو لپاره، موږ به د Auth0 اختیار ورکولو توسیع وکاروو او د مختلف کچې لاسرسي چمتو کولو لپاره به Istio وکاروو.

د Auth0 Authorization نصب او ترتیب کول

په 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 خدماتو ته لاسرسی ولري. د لاندې اسټیو سرچینو په کارولو سره پلي شوي:

• د خدمت رول - هغه حقونه ټاکي چې کاروونکي لري؛
• 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 د پاڼې ټولو لیدونکو ته د خدمت رول پلي کړئ (باقاعده-کاروونکي-خدمت-رول-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

په سفیرانو کې د کیچ کولو له امله، دا ممکن څو دقیقې وخت ونیسي چې د واک ورکولو مقررات پلي شي. بیا تاسو کولی شئ ډاډ ترلاسه کړئ چې کاروونکي او مدیران د لاسرسي مختلف کچې لري.

په دې برخه کې پایله

په جدي توګه که څه هم، ایا تاسو کله هم د اعتبار او واک ورکولو لپاره یو ساده، بې هڅې، د توزیع وړ او خوندي طریقه لیدلې ده؟

یوازې درې اسټیو سرچینې (RbacConfig، ServiceRole، او ServiceRoleBinding) ته اړتیا وه ترڅو د تصدیق او خدماتو ته د پای کارونکي لاسرسي واک باندې ښه کنټرول ترلاسه کړي.

برسېره پر دې، موږ دا مسلې زموږ د استازي خدماتو څخه په پام کې نیولي دي، السته راوړو:

• د عمومي کوډ مقدار کمول چې ممکن امنیتي ستونزې او کیګونه ولري؛
• د احمقانه حالتونو شمیر کمول په کوم کې چې یو پای ټکی له بهر څخه د لاسرسي وړ وګرځید او راپور ورکول یې هیر کړل؛
• هرکله چې نوی رول یا حق اضافه شي د ټولو خدماتو تازه کولو اړتیا له مینځه وړل؛
• چې نوي خدمات ساده، خوندي او چټک پاتې شي.

پایلې

اسټیو ټیمونو ته اجازه ورکوي چې خپلې سرچینې د سوداګرۍ - مهم کارونو باندې تمرکز وکړي پرته لدې چې خدماتو ته سر اضافه کړي ، کوچني حالت ته یې بیرته راولي.

مقاله (په دریو برخو کې) په اصلي پروژو کې د اسټیو سره د پیل کولو لپاره لومړني پوهه او چمتو شوي عملي لارښوونې چمتو کړې.

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

• "د اسټیو سره مایکرو خدماتو ته بیرته": لومړۍ برخه (د اصلي ځانګړتیاوو پیژندنه), دویمه برخه (روټینګ، د ترافیک کنټرول);
• «کنډیټ - د Kubernetes لپاره د لږ وزن خدمت میش»
• «د خدمت میش څه شی دی او زه ولې اړتیا لرم [د مایکرو خدماتو سره د کلاوډ غوښتنلیک لپاره]؟".

سرچینه: www.habr.com