ກັບໄປຫາບໍລິການຈຸລະພາກກັບ Istio. ພາກທີ 3

ຫມາຍ​ເຫດ​. ແປ.: ສ່ວນ ທຳ ອິດ ຊຸດນີ້ໄດ້ຖືກອຸທິດເພື່ອຮູ້ຈັກຄວາມສາມາດຂອງ Istio ແລະສະແດງໃຫ້ເຫັນພວກເຂົາໃນການປະຕິບັດ, ຄັ້ງທີສອງ — ການ​ຄຸ້ມ​ຄອງ​ເສັ້ນ​ທາງ​ແລະ​ການ​ຈະ​ລາ​ຈອນ​ເຄືອ​ຂ່າຍ​ປັບ​ລະ​ອຽດ​. ໃນປັດຈຸບັນພວກເຮົາຈະສົນທະນາກ່ຽວກັບຄວາມປອດໄພ: ເພື່ອສະແດງໃຫ້ເຫັນເຖິງຫນ້າທີ່ພື້ນຖານທີ່ກ່ຽວຂ້ອງກັບມັນ, ຜູ້ຂຽນໄດ້ໃຊ້ບໍລິການຕົວຕົນ Auth0, ແຕ່ຜູ້ໃຫ້ບໍລິການອື່ນໆສາມາດຕັ້ງຄ່າໄດ້ໃນລັກສະນະທີ່ຄ້າຍຄືກັນ.

ພວກເຮົາຕັ້ງກຸ່ມ Kubernetes ທີ່ພວກເຮົາໄດ້ນຳໃຊ້ Istio ແລະແອັບພລິເຄຊັນບໍລິການຈຸລະພາກຕົວຢ່າງ, ການວິເຄາະຄວາມຮູ້ສຶກ, ເພື່ອສະແດງຄວາມສາມາດຂອງ Istio.

ດ້ວຍ Istio, ພວກ​ເຮົາ​ສາ​ມາດ​ຮັກ​ສາ​ການ​ບໍ​ລິ​ການ​ຂອງ​ພວກ​ເຮົາ​ຂະ​ຫນາດ​ນ້ອຍ​ເນື່ອງ​ຈາກ​ວ່າ​ພວກ​ເຂົາ​ເຈົ້າ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ປະ​ຕິ​ບັດ​ຊັ້ນ​ຕ່າງໆ​ເຊັ່ນ Retryes, Timeouts, Circuit Breakers, Tracing, Monitoring. ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ໃຊ້ເຕັກນິກການທົດສອບ ແລະການນຳໃຊ້ແບບພິເສດ: ການທົດສອບ A/B, ການສະທ້ອນແສງ ແລະ ມ້ວນ canary.

ໃນວັດສະດຸໃຫມ່, ພວກເຮົາຈະຈັດການກັບຂັ້ນຕອນສຸດທ້າຍໃນເສັ້ນທາງໄປສູ່ມູນຄ່າທຸລະກິດ: ການຮັບຮອງແລະການອະນຸຍາດ - ແລະໃນ Istio ມັນເປັນຄວາມສຸກທີ່ແທ້ຈິງ!

ການກວດສອບແລະການອະນຸຍາດໃນ Istio

ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ເຄີຍ​ຈະ​ເຊື່ອ​ວ່າ​ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ໄດ້​ຮັບ​ການ​ດົນ​ໃຈ​ໂດຍ​ການ​ກວດ​ສອບ​ແລະ​ການ​ອະ​ນຸ​ຍາດ​. Istio ສາມາດສະເຫນີຫຍັງຈາກທັດສະນະເຕັກໂນໂລຢີເພື່ອເຮັດໃຫ້ຫົວຂໍ້ເຫຼົ່ານີ້ມ່ວນແລະ, ຫຼາຍກວ່ານັ້ນ, ເປັນແຮງບັນດານໃຈສໍາລັບທ່ານ?

ຄໍາຕອບແມ່ນງ່າຍດາຍ: Istio ປ່ຽນຄວາມຮັບຜິດຊອບສໍາລັບຄວາມສາມາດເຫຼົ່ານີ້ຈາກການບໍລິການຂອງທ່ານໄປຫາຕົວແທນ Envoy. ເມື່ອການຮ້ອງຂໍໄປເຖິງການບໍລິການ, ພວກມັນໄດ້ຮັບການຢັ້ງຢືນແລະອະນຸຍາດແລ້ວ, ດັ່ງນັ້ນສິ່ງທີ່ທ່ານຕ້ອງເຮັດແມ່ນຂຽນລະຫັດທີ່ມີປະໂຫຍດທາງທຸລະກິດ.

ສຽງດີ? ລອງເບິ່ງພາຍໃນ!

ການຢືນຢັນດ້ວຍ Auth0

ໃນຖານະເປັນເຄື່ອງແມ່ຂ່າຍສໍາລັບການກໍານົດຕົວຕົນແລະການຄຸ້ມຄອງການເຂົ້າເຖິງ, ພວກເຮົາຈະນໍາໃຊ້ Auth0, ທີ່ມີສະບັບທົດລອງ, ແມ່ນ intuitive ການນໍາໃຊ້ແລະຂ້າພະເຈົ້າພຽງແຕ່ມັກມັນ. ຢ່າງໃດກໍ່ຕາມ, ຫຼັກການດຽວກັນສາມາດຖືກນໍາໃຊ້ກັບສິ່ງອື່ນໆ ການປະຕິບັດ OpenID Connect: KeyCloak, IdentityServer ແລະອື່ນໆຈໍານວນຫຼາຍ.

ເພື່ອເລີ່ມຕົ້ນ, ໄປທີ່ Auth0 Portal ດ້ວຍບັນຊີຂອງທ່ານ, ສ້າງຜູ້ເຊົ່າ (ຜູ້ເຊົ່າ - "ຜູ້ເຊົ່າ", ຫນ່ວຍງານຢ່າງມີເຫດຜົນຂອງການໂດດດ່ຽວ, ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມເບິ່ງ ເອກະສານ — ປະ​ມານ​. ແປ.) ແລະໄປ ແອັບພລິເຄຊັ່ນ > ແອັບເລີ່ມຕົ້ນເລືອກ ໂດເມນ, ດັ່ງທີ່ສະແດງຢູ່ໃນຫນ້າຈໍຂ້າງລຸ່ມນີ້:

ລະບຸໂດເມນນີ້ຢູ່ໃນໄຟລ໌ 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 - ປະມານ. ກຳນົດຄ່າ Envoys ເພື່ອກວດສອບການຮ້ອງຂໍກ່ອນທີ່ຈະສົ່ງຕໍ່ໄປຫາການບໍລິການ: 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 ແລະຕື່ມແບບຟອມ:

ຂໍ້ມູນທີ່ສໍາຄັນຢູ່ທີ່ນີ້ແມ່ນ ຕົວຊີ້ວັດ, ທີ່ພວກເຮົາຈະໃຊ້ຕໍ່ມາໃນສະຄິບ. ຂໍ​ໃຫ້​ຂຽນ​ໄວ້​ດັ່ງ​ນີ້:

• Audience: {YOUR_AUDIENCE}

ລາຍລະອຽດທີ່ຍັງເຫຼືອທີ່ພວກເຮົາຕ້ອງການແມ່ນຕັ້ງຢູ່ໃນ Auth0 Portal ໃນພາກ ຄໍາຮ້ອງສະຫມັກ - ເລືອກ ການທົດສອບຄໍາຮ້ອງສະຫມັກ (ສ້າງອັດຕະໂນມັດພ້ອມກັບ API).

ໃນທີ່ນີ້ພວກເຮົາຈະຂຽນ:

• ໂດເມນ: {YOUR_DOMAIN}
• ID ລູກຄ້າ: {YOUR_CLIENT_ID}

ເລື່ອນໄປຫາ ການທົດສອບຄໍາຮ້ອງສະຫມັກ ໄປທີ່ຊ່ອງຂໍ້ຄວາມ ອະນຸຍາດໃຫ້ເອີ້ນຄືນ URLs (ແກ້ໄຂ URLs ສໍາລັບການໂທຄືນ), ໃນທີ່ພວກເຮົາກໍານົດ URL ທີ່ການໂທຄວນຈະຖືກສົ່ງຫຼັງຈາກການກວດສອບສໍາເລັດ. ໃນກໍລະນີຂອງພວກເຮົາມັນແມ່ນ:

http://{EXTERNAL_IP}/callback

ແລະ ສຳ ລັບ URL ອອກຈາກລະບົບທີ່ໄດ້ຮັບອະນຸຍາດ (ອະນຸຍາດໃຫ້ URLs ອອກຈາກລະບົບ) ເພີ່ມ:

http://{EXTERNAL_IP}/logout

ຂໍໃຫ້ກ້າວໄປສູ່ເສັ້ນທາງຫນ້າ.

ອັບເດດ Frontend

ປ່ຽນເປັນສາຂາ auth0 ຄັງເກັບມ້ຽນ [istio-mastery]. ໃນສາຂານີ້, ລະຫັດ frontend ຖືກປ່ຽນເພື່ອປ່ຽນເສັ້ນທາງຜູ້ໃຊ້ໄປຫາ Auth0 ສໍາລັບການພິສູດຢືນຢັນແລະນໍາໃຊ້ JWT token ໃນການຮ້ອງຂໍກັບການບໍລິການອື່ນໆ. ສຸດທ້າຍແມ່ນປະຕິບັດດັ່ງຕໍ່ໄປນີ້ (.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

ໃນປະຕູ Auth0, ໄປທີ່ສ່ວນຂະຫຍາຍ (ການ​ຂະ​ຫຍາຍ) ແລະ​ຕິດ​ຕັ້ງ​ Auth0 ການ​ອະ​ນຸ​ຍາດ​. ຫຼັງຈາກການຕິດຕັ້ງ, ໄປທີ່ ການຂະຫຍາຍການອະນຸຍາດ, ແລະຢູ່ທີ່ນັ້ນ - ກັບການຕັ້ງຄ່າຂອງຜູ້ເຊົ່າໂດຍການຄລິກໃສ່ຂວາເທິງແລະເລືອກຕົວເລືອກເມນູທີ່ເຫມາະສົມ. (ການຕັ້ງຄ່າ). ເປີດໃຊ້ກຸ່ມ (ກຸ່ມ) ແລະ​ໃຫ້​ຄລິກ​ໃສ່​ປຸ່ມ​ກົດ​ລະ​ບຽບ​ການ​ເຜີຍ​ແຜ່​ (ກົດ​ລະ​ບຽບ​ການ​ເຜີຍ​ແຜ່​).

ສ້າງກຸ່ມ

ໃນ​ການ​ຂະ​ຫຍາຍ​ການ​ອະ​ນຸ​ຍາດ​ໄປ​ທີ່ Groups ແລະສ້າງກຸ່ມ Moderators. ເນື່ອງຈາກພວກເຮົາຈະປະຕິບັດຕໍ່ຜູ້ໃຊ້ທີ່ມີຄວາມຖືກຕ້ອງທັງຫມົດເປັນຜູ້ໃຊ້ປົກກະຕິ, ມັນບໍ່ຈໍາເປັນຕ້ອງສ້າງກຸ່ມເພີ່ມເຕີມສໍາລັບພວກເຂົາ.

ເລືອກກຸ່ມ Moderators, ກົດປຸ່ມ ເພີ່ມສະມາຊິກ, ເພີ່ມບັນຊີຕົ້ນຕໍຂອງທ່ານ. ປ່ອຍໃຫ້ຜູ້ໃຊ້ບາງຄົນໂດຍບໍ່ມີກຸ່ມເພື່ອໃຫ້ແນ່ໃຈວ່າພວກເຂົາຖືກປະຕິເສດການເຂົ້າເຖິງ. (ຜູ້ໃຊ້ໃຫມ່ສາມາດສ້າງດ້ວຍຕົນເອງໂດຍຜ່ານ Auth0 Portal > ຜູ້ໃຊ້ > ສ້າງຜູ້ໃຊ້.)

ເພີ່ມການຮຽກຮ້ອງກຸ່ມເພື່ອເຂົ້າເຖິງ Token

ຜູ້​ໃຊ້​ໄດ້​ຖືກ​ເພີ່ມ​ເຂົ້າ​ໄປ​ໃນ​ກຸ່ມ​, ແຕ່​ຂໍ້​ມູນ​ນີ້​ຍັງ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ສະ​ທ້ອນ​ໃຫ້​ເຫັນ​ໃນ tokens ການ​ເຂົ້າ​ເຖິງ​. ເພື່ອປະຕິບັດຕາມ OpenID Connect ແລະໃນເວລາດຽວກັນສົ່ງຄືນກຸ່ມທີ່ພວກເຮົາຕ້ອງການ, token ຈະຕ້ອງເພີ່ມຂອງມັນເອງ. ການຮຽກຮ້ອງແບບກຳນົດເອງ. ປະຕິບັດຜ່ານກົດລະບຽບ Auth0.

ເພື່ອສ້າງກົດລະບຽບ, ໄປທີ່ Auth0 Portal to ກົດລະບຽບ, ກົດປຸ່ມ ສ້າງກົດລະບຽບ ແລະເລືອກກົດລະບຽບຫວ່າງເປົ່າຈາກແມ່ແບບ.

ຄັດລອກລະຫັດຂ້າງລຸ່ມນີ້ແລະບັນທຶກມັນເປັນກົດລະບຽບໃຫມ່ ເພີ່ມການຮຽກຮ້ອງກຸ່ມ (namespacedGroup.js):

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

Примечание: ລະຫັດນີ້ເອົາກຸ່ມຜູ້ໃຊ້ທໍາອິດທີ່ກໍານົດຢູ່ໃນການຂະຫຍາຍການອະນຸຍາດແລະເພີ່ມມັນໃສ່ token ການເຂົ້າເຖິງເປັນການຮຽກຮ້ອງແບບກໍານົດເອງ (ພາຍໃຕ້ namespace ຂອງມັນ, ຕາມຄວາມຕ້ອງການຂອງ Auth0).

ກັບໄປທີ່ໜ້າ ກົດລະບຽບ ແລະກວດເບິ່ງວ່າທ່ານມີສອງກົດລະບຽບຂຽນຢູ່ໃນຄໍາສັ່ງຕໍ່ໄປນີ້:

• auth0-authorization-extension
• ເພີ່ມການຮຽກຮ້ອງກຸ່ມ

ຄໍາສັ່ງແມ່ນສໍາຄັນເພາະວ່າພາກສະຫນາມຂອງກຸ່ມໄດ້ຮັບກົດລະບຽບ asynchronously auth0-authorization-extension ແລະຫຼັງຈາກນັ້ນມັນຖືກເພີ່ມເປັນການຮຽກຮ້ອງໂດຍກົດລະບຽບທີສອງ. ຜົນໄດ້ຮັບແມ່ນ token ການເຂົ້າເຖິງເຊັ່ນນີ້:

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

ຕອນນີ້ທ່ານຕ້ອງການປັບຄ່າຕົວແທນ Envoy ເພື່ອກວດສອບການເຂົ້າເຖິງຂອງຜູ້ໃຊ້, ເຊິ່ງກຸ່ມຈະຖືກດຶງອອກຈາກການຮຽກຮ້ອງ (https://sa.io/group) ໃນ token ການເຂົ້າເຖິງກັບຄືນ. ນີ້ແມ່ນຫົວຂໍ້ສໍາລັບພາກຕໍ່ໄປຂອງບົດຄວາມ.

ການຕັ້ງຄ່າການອະນຸຍາດໃນ 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 ພຽງແຕ່ສໍາລັບການບໍລິການແລະ namespaces ທີ່ລະບຸໄວ້ໃນພາກສະຫນາມ 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. ປະຕິບັດໂດຍໃຊ້ຊັບພະຍາກອນ 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 ກັບຜູ້ເຂົ້າຊົມໜ້າທັງໝົດ (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 token.

ໃຫ້ໃຊ້ການຕັ້ງຄ່າ:

$ 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: ["*"]

ແຕ່ພວກເຮົາຕ້ອງການສິດທິດັ່ງກ່າວສໍາລັບຜູ້ໃຊ້ທີ່ token ການເຂົ້າເຖິງມີການຮຽກຮ້ອງ 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) ເທົ່ານັ້ນທີ່ຕ້ອງການເພື່ອບັນລຸການຄວບຄຸມທີ່ລະອຽດອ່ອນກ່ຽວກັບການພິສູດຢືນຢັນແລະການອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສຸດທ້າຍເຂົ້າເຖິງການບໍລິການ.

ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ດູແລບັນຫາເຫຼົ່ານີ້ອອກຈາກການບໍລິການທູດຂອງພວກເຮົາ, ບັນລຸໄດ້:

• ການຫຼຸດຜ່ອນຈໍານວນລະຫັດທົ່ວໄປທີ່ອາດຈະມີບັນຫາຄວາມປອດໄພແລະຂໍ້ບົກພ່ອງ;
• ການຫຼຸດຜ່ອນຈໍານວນຂອງສະຖານະການ stupid ໃນຫນຶ່ງ endpoint ຫັນອອກເພື່ອໃຫ້ສາມາດເຂົ້າເຖິງໄດ້ຈາກພາຍນອກແລະລືມທີ່ຈະລາຍງານມັນ;
• ການລົບລ້າງຄວາມຕ້ອງການທີ່ຈະປັບປຸງການບໍລິການທັງຫມົດທຸກຄັ້ງທີ່ມີການເພີ່ມບົດບາດຫຼືສິດໃຫມ່;
• ວ່າການບໍລິການໃຫມ່ຍັງຄົງງ່າຍດາຍ, ປອດໄພແລະໄວ.

ສະຫລຸບ

Istio ອະນຸຍາດໃຫ້ທີມງານສຸມໃສ່ຊັບພະຍາກອນຂອງເຂົາເຈົ້າກ່ຽວກັບວຽກງານທີ່ສໍາຄັນຂອງທຸລະກິດໂດຍບໍ່ມີການເພີ່ມຄ່າໃຊ້ຈ່າຍໃນການບໍລິການ, ໃຫ້ເຂົາເຈົ້າກັບຄືນສູ່ສະຖານະພາບຈຸນລະພາກ.

ບົດຄວາມ (ໃນສາມສ່ວນ) ໄດ້ໃຫ້ຄວາມຮູ້ພື້ນຖານແລະຄໍາແນະນໍາພາກປະຕິບັດທີ່ກຽມພ້ອມສໍາລັບການເລີ່ມຕົ້ນກັບ Istio ໃນໂຄງການທີ່ແທ້ຈິງ.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• "ກັບຄືນໄປບ່ອນບໍລິການຈຸລະພາກກັບ Istio": ພາກ​ທີ 1 (ການ​ນໍາ​ສະ​ເຫນີ​ກ່ຽວ​ກັບ​ລັກ​ສະ​ນະ​ຕົ້ນ​ຕໍ​), ພາກ​ທີ 2 (ເສັ້ນ​ທາງ​, ການ​ຄວບ​ຄຸມ​ຈະ​ລາ​ຈອນ​);
• «Conduit - ຕາຫນ່າງການບໍລິການທີ່ມີນ້ໍາຫນັກເບົາສໍາລັບ Kubernetes"
• «ຕາໜ່າງບໍລິການແມ່ນຫຍັງ ແລະເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງການມັນ [ສຳລັບແອັບພລິເຄຊັນຄລາວກັບບໍລິການຈຸລະພາກ]?".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com