ត្រឡប់ទៅ សេវាមីក្រូ ជាមួយ Istio ។ ផ្នែកទី 3

ចំណាំ។ បកប្រែ: ផ្នែកដំបូង ស៊េរីនេះត្រូវបានឧទ្ទិសដល់ការស្គាល់សមត្ថភាពរបស់ Istio និងបង្ហាញពួកគេនៅក្នុងសកម្មភាព ទីពីរ - ការកំណត់ផ្លូវ និងការគ្រប់គ្រងចរាចរណ៍បណ្តាញដែលបានកែសម្រួលយ៉ាងល្អិតល្អន់។ ឥឡូវនេះយើងនឹងនិយាយអំពីសុវត្ថិភាព៖ ដើម្បីបង្ហាញពីមុខងារជាមូលដ្ឋានដែលទាក់ទងនឹងវា អ្នកនិពន្ធប្រើប្រាស់សេវាកម្មអត្តសញ្ញាណ Auth0 ប៉ុន្តែអ្នកផ្តល់សេវាផ្សេងទៀតអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមរបៀបស្រដៀងគ្នានេះ។

យើងបង្កើតចង្កោម Kubernetes ដែលយើងបានដាក់ពង្រាយ Istio និងឧទាហរណ៍កម្មវិធី microservice ការវិភាគអារម្មណ៍ ដើម្បីបង្ហាញពីសមត្ថភាពរបស់ Istio ។

ជាមួយនឹង Istio យើងអាចរក្សាសេវាកម្មរបស់យើងឱ្យនៅតូច ដោយសារពួកគេមិនចាំបាច់អនុវត្តស្រទាប់ដូចជា ការព្យាយាមឡើងវិញ ការអស់ពេល ការបំបែកសៀគ្វី ការតាមដាន ការត្រួតពិនិត្យ។ លើសពីនេះ យើងបានប្រើបច្ចេកទេសសាកល្បង និងការដាក់ឱ្យប្រើប្រាស់កម្រិតខ្ពស់៖ ការធ្វើតេស្ត A/B ការឆ្លុះកញ្ចក់ និងការបើកដំណើរការ Canary ។

នៅក្នុងសម្ភារៈថ្មី យើងនឹងដោះស្រាយជាមួយនឹងស្រទាប់ចុងក្រោយនៅលើផ្លូវទៅកាន់តម្លៃអាជីវកម្ម៖ ការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាត - ហើយនៅក្នុង Istio វាពិតជារីករាយណាស់!

ការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាតនៅក្នុង Istio

ខ្ញុំមិនដែលជឿថាខ្ញុំនឹងត្រូវបានបំផុសគំនិតដោយការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាត។ តើ Istio អាចផ្តល់អ្វីខ្លះពីទស្សនៈបច្ចេកវិទ្យា ដើម្បីធ្វើឱ្យប្រធានបទទាំងនេះមានភាពសប្បាយរីករាយ ហើយលើសពីនេះទៅទៀត ការបំផុសគំនិតសម្រាប់អ្នក?

ចម្លើយគឺសាមញ្ញ៖ Istio ផ្លាស់ប្តូរការទទួលខុសត្រូវចំពោះសមត្ថភាពទាំងនេះពីសេវាកម្មរបស់អ្នកទៅប្រូកស៊ី Envoy ។ នៅពេលដែលសំណើឈានដល់សេវាកម្ម ពួកគេត្រូវបានផ្ទៀងផ្ទាត់ និងអនុញ្ញាតរួចហើយ ដូច្នេះអ្វីដែលអ្នកត្រូវធ្វើគឺសរសេរកូដដែលមានប្រយោជន៍សម្រាប់អាជីវកម្ម។

ពិតជា​ល្អ​ណាស់? តោះមើលខាងក្នុង!

ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវជាមួយ 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

ជាមួយនឹងធនធានបែបនេះ Pilot (ធាតុផ្សំមួយនៃយន្តហោះបញ្ជាមូលដ្ឋានទាំងបីនៅក្នុង Istio - ប្រហែល។ បកប្រែ។ ) កំណត់រចនាសម្ព័ន្ធបេសកជនដើម្បីផ្ទៀងផ្ទាត់សំណើ មុនពេលបញ្ជូនពួកគេទៅកាន់សេវាកម្ម៖ sa-web-app и sa-feedback. ក្នុងពេលជាមួយគ្នានេះ ការកំណត់រចនាសម្ព័ន្ធមិនត្រូវបានអនុវត្តចំពោះសេវា Envoys ទេ។ sa-frontendអនុញ្ញាតឱ្យយើងចាកចេញពី frontend ដោយគ្មានការផ្ទៀងផ្ទាត់។ ដើម្បីអនុវត្តគោលការណ៍ សូមដំណើរការពាក្យបញ្ជា៖

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

ត្រលប់ទៅទំព័រហើយធ្វើសំណើ - អ្នកនឹងឃើញថាវាបញ្ចប់ដោយស្ថានភាព 401 គ្មានការអនុញ្ញាត. ឥឡូវ​នេះ​សូម​ប្ដូរ​ទិស​អ្នក​ប្រើ frontend ដើម្បី​ផ្ទៀងផ្ទាត់​ជាមួយ Auth0។

ការផ្ទៀងផ្ទាត់សំណើជាមួយ Auth0

ដើម្បីផ្ទៀងផ្ទាត់សំណើរបស់អ្នកប្រើប្រាស់ចុងក្រោយ អ្នកត្រូវបង្កើត API ក្នុង Auth0 ដែលនឹងតំណាងឱ្យសេវាកម្មដែលបានផ្ទៀងផ្ទាត់ (ការពិនិត្យ ព័ត៌មានលម្អិត និងការវាយតម្លៃ)។ ដើម្បីបង្កើត API សូមចូលទៅកាន់ Auth0 Portal > APIs > បង្កើត API ហើយបំពេញទម្រង់បែបបទ៖

ព័ត៌មានសំខាន់នៅទីនេះគឺ អ្នកកំណត់អត្តសញ្ញាណ។ដែលយើងនឹងប្រើនៅពេលក្រោយនៅក្នុងស្គ្រីប។ ចូរយើងសរសេរវាដូចនេះ៖

• ទស្សនិកជន៖ {YOUR_AUDIENCE}

ព័ត៌មានលម្អិតដែលនៅសល់ដែលយើងត្រូវការមានទីតាំងនៅលើវិបផតថល Auth0 នៅក្នុងផ្នែក ការកម្មវិធី - ជ្រើសរើស កម្មវិធីសាកល្បង (បង្កើតដោយស្វ័យប្រវត្តិរួមជាមួយ API) ។

នៅទីនេះយើងនឹងសរសេរ៖

• ដែន៖ {YOUR_DOMAIN}
• លេខសម្គាល់អតិថិជន៖ {YOUR_CLIENT_ID}

រមូរទៅ កម្មវិធីសាកល្បង ទៅវាលអត្ថបទ URLs ហៅត្រឡប់មកវិញដែលបានអនុញ្ញាត (បានដោះស្រាយ URLs សម្រាប់ការហៅត្រឡប់មកវិញ) ដែលក្នុងនោះយើងបញ្ជាក់ URL ដែលការហៅគួរតែត្រូវបានផ្ញើបន្ទាប់ពីការផ្ទៀងផ្ទាត់ត្រូវបានបញ្ចប់។ ក្នុងករណីរបស់យើងវាគឺ៖

http://{EXTERNAL_IP}/callback

និងសម្រាប់ អនុញ្ញាត URL ចេញ (អនុញ្ញាត URLs សម្រាប់ការចេញ) បន្ថែម៖

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 របស់អ្នកនៅក្នុងពាក្យបញ្ជាខាងក្រោម នៅពេលបង្កើត និងដាក់ពង្រាយការផ្លាស់ប្តូរដែលបានធ្វើ៖

$ 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

នៅក្នុងវិបផតថល Auth0 សូមចូលទៅកាន់ផ្នែកបន្ថែម (ផ្នែក​បន្ថែម) និងដំឡើង ការអនុញ្ញាត 0. បន្ទាប់ពីការដំឡើងសូមចូលទៅកាន់ ការបន្ថែមការអនុញ្ញាតហើយនៅទីនោះ - ទៅការកំណត់រចនាសម្ព័ន្ធរបស់អ្នកជួលដោយចុចលើកំពូលខាងស្តាំ ហើយជ្រើសរើសជម្រើសម៉ឺនុយដែលសមរម្យ (ការកំណត់​រចនាសម្ព័ន្ធ). ធ្វើឱ្យក្រុមសកម្ម (ក្រុម) ហើយចុចលើប៊ូតុង បោះពុម្ពច្បាប់ (ច្បាប់ផ្សព្វផ្សាយ).

ការបង្កើតក្រុម

នៅក្នុងផ្នែកបន្ថែមការអនុញ្ញាត សូមចូលទៅកាន់ ក្រុម និងបង្កើតក្រុម អ្នកសម្របសម្រួល. ដោយសារយើងនឹងចាត់ទុកអ្នកប្រើប្រាស់ដែលបានផ្ទៀងផ្ទាត់ទាំងអស់ជាអ្នកប្រើប្រាស់ធម្មតា នោះមិនចាំបាច់បង្កើតក្រុមបន្ថែមសម្រាប់ពួកគេទេ។

ជ្រើសរើសក្រុម អ្នកសម្របសម្រួល, ចុច​លើ បន្ថែមសមាជិកបន្ថែមគណនីចម្បងរបស់អ្នក។ ទុកឱ្យអ្នកប្រើប្រាស់មួយចំនួនដោយគ្មានក្រុមណាមួយ ដើម្បីប្រាកដថាពួកគេត្រូវបានបដិសេធការចូលប្រើប្រាស់។ (អ្នកប្រើប្រាស់ថ្មីអាចត្រូវបានបង្កើតដោយដៃតាមរយៈ វិបផតថល Auth0 > អ្នកប្រើប្រាស់ > បង្កើតអ្នកប្រើប្រាស់.)

បន្ថែម​ការ​ទាមទារ​ក្រុម​ទៅ​កាន់​សញ្ញា​សម្ងាត់​ចូល​ប្រើប្រាស់

អ្នក​ប្រើ​ត្រូវ​បាន​បន្ថែម​ទៅ​ក្នុង​ក្រុម ប៉ុន្តែ​ព័ត៌មាន​នេះ​ក៏​ត្រូវ​តែ​ត្រូវ​បាន​បង្ហាញ​នៅ​ក្នុង​សញ្ញា​សម្ងាត់​ចូល​ដំណើរ​ការ។ ដើម្បីអនុលោមតាម 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);
}

ការកត់សម្គាល់៖ កូដនេះយកក្រុមអ្នកប្រើប្រាស់ដំបូងដែលបានកំណត់ក្នុងផ្នែកបន្ថែមការអនុញ្ញាត ហើយបន្ថែមវាទៅក្នុងសញ្ញាសម្ងាត់ចូលប្រើជាការទាមទារផ្ទាល់ខ្លួន (ក្រោមឈ្មោះរបស់វា តាមតម្រូវការដោយ Auth0)។

ត្រឡប់ទៅ ទំព័រ ក្បួន ហើយពិនិត្យមើលថាអ្នកមានច្បាប់ពីរដែលសរសេរតាមលំដាប់ដូចខាងក្រោមៈ

• auth0-authorization-extension
• បន្ថែមការទាមទារក្រុម

លំដាប់​គឺ​សំខាន់​ព្រោះ​វាល​ក្រុម​ទទួល​ក្បួន​ដោយ​អសមកាល auth0-authorization-extension ហើយបន្ទាប់ពីនោះវាត្រូវបានបន្ថែមជាការទាមទារដោយច្បាប់ទីពីរ។ លទ្ធផលគឺជាសញ្ញាសម្ងាត់ចូលដំណើរការដូចនេះ៖

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

ឥឡូវអ្នកត្រូវកំណត់រចនាសម្ព័ន្ធប្រូកស៊ី Envoy ដើម្បីពិនិត្យមើលការចូលប្រើរបស់អ្នកប្រើប្រាស់ ដែលក្រុមនឹងត្រូវបានទាញចេញពីការទាមទារ (https://sa.io/group) នៅក្នុងនិមិត្តសញ្ញាចូលប្រើត្រឡប់មកវិញ។ នេះគឺជាប្រធានបទសម្រាប់ផ្នែកបន្ទាប់នៃអត្ថបទ។

ការកំណត់រចនាសម្ព័ន្ធការអនុញ្ញាតនៅក្នុង Istio

សម្រាប់ការអនុញ្ញាតឱ្យដំណើរការ អ្នកត្រូវតែបើក RBAC សម្រាប់ Istio។ ដើម្បីធ្វើដូចនេះយើងនឹងប្រើការកំណត់ដូចខាងក្រោមៈ

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-Fronten និង 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 អនុវត្ត ServiceRole ដល់អ្នកទស្សនាទំព័រទាំងអស់ (normal-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 (ផ្លូវ, ការត្រួតពិនិត្យចរាចរណ៍);
• «បំពង់ - សំណាញ់សេវាទម្ងន់ស្រាលសម្រាប់ Kubernetes»
• «តើអ្វីទៅជាសេវាសំណាញ់ ហើយហេតុអ្វីបានជាខ្ញុំត្រូវការ [សម្រាប់កម្មវិធីពពកជាមួយមីក្រូសឺវីស]?"។

ប្រភព: www.habr.com