დაუბრუნდით მიკროსერვისებს Istio-სთან ერთად. Მე -3 ნაწილი

Შენიშვნა. თარგმნა: პირველი ნაწილი ეს სერია მიეძღვნა ისტიოს შესაძლებლობების გაცნობას და მათ მოქმედებაში დემონსტრირებას, მეორე — კარგად მორგებული მარშრუტიზაცია და ქსელის ტრაფიკის მართვა. ახლა ჩვენ ვისაუბრებთ უსაფრთხოებაზე: მასთან დაკავშირებული ძირითადი ფუნქციების საჩვენებლად, ავტორი იყენებს Auth0 პირადობის სერვისს, მაგრამ სხვა პროვაიდერების კონფიგურაცია შესაძლებელია ანალოგიურად.

ჩვენ შევქმენით Kubernetes კლასტერი, რომელშიც განვათავსეთ Istio და მიკროსერვისის აპლიკაციის მაგალითი, Sentiment Analysis, Istio-ს შესაძლებლობების დემონსტრირებისთვის.

Istio-ს საშუალებით ჩვენ შევძელით ჩვენი სერვისების მცირე ზომის შენარჩუნება, რადგან მათ არ სჭირდებათ ისეთი ფენების დანერგვა, როგორიცაა განმეორებითი ცდები, ვადები, ამომრთველები, მიკვლევა, მონიტორინგი. გარდა ამისა, ჩვენ გამოვიყენეთ მოწინავე ტესტირებისა და განლაგების ტექნიკა: A/B ტესტირება, mirroring და canary rollouts.

ახალ მასალაში ჩვენ განვიხილავთ საბოლოო ფენებს ბიზნესის ღირებულებისკენ მიმავალ გზაზე: ავთენტიფიკაცია და ავტორიზაცია - და ისტიოში ეს ნამდვილი სიამოვნებაა!

ავთენტიფიკაცია და ავტორიზაცია ისტიოში

არასოდეს დავიჯერებდი, რომ შთაგონებული ვიქნებოდი ავტორიზაციისა და ავტორიზაციის გზით. რა შეიძლება შესთავაზოს Istio-ს ტექნოლოგიური პერსპექტივიდან, რომ ეს თემები სახალისო და, მით უმეტეს, შთამაგონებელი გახდეს თქვენთვის?

პასუხი მარტივია: Istio გადასცემს პასუხისმგებლობას ამ შესაძლებლობებზე თქვენი სერვისებიდან Envoy proxy-ზე. იმ დროისთვის, როდესაც მოთხოვნები სერვისებს მიაღწევს, ისინი უკვე დამოწმებულია და ავტორიზებულია, ასე რომ თქვენ მხოლოდ უნდა დაწეროთ ბიზნესისთვის სასარგებლო კოდი.

Კარგად ჟღერს? მოდით შევხედოთ შიგნით!

ავტორიზაცია 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

ასეთი რესურსით, პილოტი (ისტიოში საკონტროლო სიბრტყის სამი ძირითადი კომპონენტიდან ერთ-ერთი - დაახლ. თარგმანი.) აკონფიგურირებს 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

დაბრუნდით გვერდზე და გააკეთეთ მოთხოვნა - ნახავთ, რომ ის მთავრდება სტატუსით არასანქცირებული. ახლა მოდით გადავიტანოთ წინა მომხმარებლები Auth0-ით ავთენტიფიკაციისთვის.

მოთხოვნების ავტორიზაცია Auth0-ით

საბოლოო მომხმარებლის მოთხოვნების ავთენტიფიკაციისთვის, თქვენ უნდა შექმნათ API Auth0-ში, რომელიც წარმოადგენს დამოწმებულ სერვისებს (მიმოხილვები, დეტალები და რეიტინგები). API-ს შესაქმნელად გადადით Auth0 პორტალი > APIs > შექმნა API და შეავსეთ ფორმა:

აქ არის მნიშვნელოვანი ინფორმაცია იდენტიფიკატორი, რომელსაც მოგვიანებით გამოვიყენებთ სკრიპტში. მოდით ჩავწეროთ ასე:

• აუდიტორია: {YOUR_AUDIENCE}

დარჩენილი დეტალები, რომლებიც გვჭირდება, მდებარეობს განყოფილებაში Auth0 პორტალზე პროგრამები - აირჩიეთ ტესტის აპლიკაცია (შეიქმნება ავტომატურად 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 ავტორიზაციის ინსტალაცია და კონფიგურაცია

Auth0 პორტალზე გადადით გაფართოებებზე (გაგრძელება) და დააინსტალირეთ Auth0 ავტორიზაცია. ინსტალაციის შემდეგ გადადით ავტორიზაციის გაფართოებადა იქ - მოიჯარის კონფიგურაციაზე დაწკაპუნებით ზედა მარჯვენა კუთხეში და აირჩიეთ მენიუს შესაბამისი ვარიანტი (კონფიგურაცია). ჯგუფების გააქტიურება (ჯგუფები) და დააწკაპუნეთ გამოქვეყნების წესის ღილაკზე (გამოქვეყნების წესი).

ჯგუფების შექმნა

ავტორიზაციის გაფართოებაში გადადით ჯგუფები და შექმენით ჯგუფი მოდერატორები. ვინაიდან ჩვენ ყველა ავთენტიფიცირებულ მომხმარებელს განვიხილავთ როგორც ჩვეულებრივ მომხმარებლებს, არ არის საჭირო მათთვის დამატებითი ჯგუფის შექმნა.

აირჩიეთ ჯგუფი მოდერატორები, Დაჭერა წევრების დამატება, დაამატეთ თქვენი ძირითადი ანგარიში. დატოვეთ ზოგიერთი მომხმარებელი ჯგუფის გარეშე, რათა დარწმუნდეთ, რომ მათ აკრძალული აქვთ წვდომა. (ახალი მომხმარებლების შექმნა შესაძლებელია ხელით Auth0 პორტალი > მომხმარებლები > მომხმარებლის შექმნა.)

დაამატეთ ჯგუფური პრეტენზია Access Token-ს

მომხმარებლები დაემატნენ ჯგუფებს, მაგრამ ეს ინფორმაცია ასევე უნდა აისახოს წვდომის ნიშნებში. 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).

გვერდზე დაბრუნება წესები და შეამოწმეთ, რომ გაქვთ ორი წესი დაწერილი შემდეგი თანმიმდევრობით:

• ავტორიზაცია-გაგრძელება
• დაამატეთ ჯგუფური პრეტენზია

თანმიმდევრობა მნიშვნელოვანია, რადგან ჯგუფის ველი იღებს წესს ასინქრონულად ავტორიზაცია-გაგრძელება ხოლო ამის შემდეგ ემატება პრეტენზიას მეორე წესით. შედეგი არის ასეთი წვდომის ნიშანი:

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

ახლა თქვენ უნდა დააკონფიგურიროთ Envoy proxy მომხმარებლის წვდომის შესამოწმებლად, რისთვისაც ჯგუფი ამოღებულ იქნება სარჩელიდან (https://sa.io/group) დაბრუნებულ წვდომის ჟეტონში. ეს არის სტატიის შემდეგი ნაწილის თემა.

ავტორიზაციის კონფიგურაცია ისტიოში

ავტორიზაციის მუშაობისთვის, თქვენ უნდა ჩართოთ 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-Frontend და SA-WebApp სერვისებზე. განხორციელებულია შემდეგი Istio რესურსების გამოყენებით:

• სერვისის როლი — განსაზღვრავს იმ უფლებებს, რაც აქვს მომხმარებელს;
• 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 გამოიყენეთ ServiceRole გვერდის ყველა ვიზიტორზე (regular-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