Επιστροφή στις microservices με το Istio. Μέρος 3

Σημείωση. μετάφρ.: Το πρώτο μέρος αυτή η σειρά ήταν αφιερωμένη στο να γνωρίσουμε τις δυνατότητες του Istio και να τις επιδείξουμε στην πράξη, δεύτερος — λεπτομερώς συντονισμένη δρομολόγηση και διαχείριση κυκλοφορίας δικτύου. Τώρα θα μιλήσουμε για την ασφάλεια: για να επιδείξει τις βασικές λειτουργίες που σχετίζονται με αυτήν, ο συγγραφέας χρησιμοποιεί την υπηρεσία ταυτότητας Auth0, αλλά άλλοι πάροχοι μπορούν να ρυθμιστούν με παρόμοιο τρόπο.

Δημιουργήσαμε ένα σύμπλεγμα Kubernetes στο οποίο αναπτύξαμε το Istio και ένα παράδειγμα εφαρμογής μικροϋπηρεσιών, το Sentiment Analysis, για να δείξουμε τις δυνατότητες του Istio.

Με το Istio, καταφέραμε να διατηρήσουμε τις υπηρεσίες μας μικρές, επειδή δεν χρειάζεται να εφαρμόσουν επίπεδα όπως Επαναλήψεις, Χρονικά όρια, Διακοπτές κυκλώματος, Ανίχνευση, Παρακολούθηση. . Επιπλέον, χρησιμοποιήσαμε προηγμένες τεχνικές δοκιμών και ανάπτυξης: δοκιμές A/B, mirroring και rollouts καναρινιών.

Στο νέο υλικό, θα ασχοληθούμε με τα τελικά επίπεδα στην πορεία προς την επιχειρηματική αξία: έλεγχος ταυτότητας και εξουσιοδότηση - και στο Ίστιο είναι πραγματική απόλαυση!

Έλεγχος ταυτότητας και εξουσιοδότηση στο Ίστιο

Ποτέ δεν θα πίστευα ότι θα εμπνευστώ από τον έλεγχο ταυτότητας και την εξουσιοδότηση. Τι μπορεί να προσφέρει το Istio από τεχνολογική άποψη για να κάνει αυτά τα θέματα διασκεδαστικά και, ακόμη περισσότερο, εμπνευσμένα για εσάς;

Η απάντηση είναι απλή: Το Istio μεταθέτει την ευθύνη για αυτές τις δυνατότητες από τις υπηρεσίες σας στον πληρεξούσιο Envoy. Μέχρι να φτάσουν τα αιτήματα στις υπηρεσίες, έχουν ήδη επαληθευτεί και εξουσιοδοτηθεί, οπότε το μόνο που έχετε να κάνετε είναι να γράψετε κωδικό χρήσιμο για τις επιχειρήσεις.

Ακούγεται καλό? Ας ρίξουμε μια ματιά στο εσωτερικό!

Έλεγχος ταυτότητας με 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

Με έναν τέτοιο πόρο, Pilot (ένα από τα τρία βασικά στοιχεία του επιπέδου ελέγχου στο Ίστιο - περίπου μετάφρ.) διαμορφώνει το Envoy για έλεγχο ταυτότητας αιτημάτων πριν τα προωθήσει στις υπηρεσίες: 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 Μη εξουσιοδοτημένη. Τώρα ας ανακατευθύνουμε τους χρήστες διεπαφής για έλεγχο ταυτότητας με το Auth0.

Έλεγχος ταυτότητας αιτημάτων με Auth0

Για τον έλεγχο ταυτότητας αιτημάτων τελικού χρήστη, πρέπει να δημιουργήσετε ένα API στο Auth0 που θα αντιπροσωπεύει τις υπηρεσίες ελέγχου ταυτότητας (κριτικές, λεπτομέρειες και αξιολογήσεις). Για να δημιουργήσετε ένα API, μεταβείτε στο Auth0 Portal > APIs > Δημιουργία API και συμπληρώστε τη φόρμα:

Οι σημαντικές πληροφορίες είναι εδώ Αναγνωριστικό, το οποίο θα χρησιμοποιήσουμε αργότερα στο σενάριο. Ας το γράψουμε ως εξής:

• ακροατήριο: {YOUR_AUDIENCE}

Οι υπόλοιπες λεπτομέρειες που χρειαζόμαστε βρίσκονται στην Πύλη Auth0 στην ενότητα Εφαρμογές — επιλέξτε Εφαρμογή δοκιμής (δημιουργείται αυτόματα μαζί με το API).

Εδώ θα γράψουμε:

• Domain: {YOUR_DOMAIN}
• Ταυτότητα πελάτη: {YOUR_CLIENT_ID}

Κάντε κύλιση στο Εφαρμογή δοκιμής στο πεδίο κειμένου Επιτρεπόμενες διευθύνσεις URL επιστροφής κλήσης (επιλυμένες διευθύνσεις URL για την επιστροφή κλήσης), στις οποίες καθορίζουμε τη διεύθυνση URL όπου θα πρέπει να σταλεί η κλήση μετά την ολοκλήρωση του ελέγχου ταυτότητας. Στην περίπτωσή μας είναι:

http://{EXTERNAL_IP}/callback

Και για Επιτρεπόμενες διευθύνσεις URL αποσύνδεσης (επιτρεπόμενες διευθύνσεις URL για αποσύνδεση) προσθέστε:

http://{EXTERNAL_IP}/logout

Ας προχωρήσουμε στο frontend.

Ενημέρωση Frontend

Μετάβαση σε υποκατάστημα auth0 αποθήκη [istio-mastery]. Σε αυτόν τον κλάδο, ο κώδικας διεπαφής αλλάζει για να ανακατευθύνει τους χρήστες στο Auth0 για έλεγχο ταυτότητας και να χρησιμοποιεί το διακριτικό JWT σε αιτήματα προς άλλες υπηρεσίες. Το τελευταίο υλοποιείται ως εξής (Εφαρμογές):

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 Portal > Χρήστες > Δημιουργία χρήστη.)

Προσθήκη ομαδικής αξίωσης στο Access Token

Οι χρήστες έχουν προστεθεί σε ομάδες, αλλά αυτές οι πληροφορίες πρέπει επίσης να αντικατοπτρίζονται στα διακριτικά πρόσβασης. Για να συμμορφωθεί με το OpenID Connect και ταυτόχρονα να επιστρέψει τις ομάδες που χρειαζόμαστε, το διακριτικό θα πρέπει να προσθέσει το δικό του προσαρμοσμένη αξίωση. Εφαρμόζεται μέσω κανόνων Auth0.

Για να δημιουργήσετε έναν κανόνα, μεταβείτε στο Auth0 Portal to Κανόνες που, Πατήστε Δημιουργία κανόνα και επιλέξτε έναν κενό κανόνα από τα πρότυπα.

Αντιγράψτε τον παρακάτω κώδικα και αποθηκεύστε τον ως νέο κανόνα Προσθήκη ομαδικής αξίωσης (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) στο επιστρεφόμενο διακριτικό πρόσβασης. Αυτό είναι το θέμα για την επόμενη ενότητα του άρθρου.

Διαμόρφωση εξουσιοδότησης στο Ίστιο

Για να λειτουργήσει η εξουσιοδότηση, πρέπει να ενεργοποιήσετε το 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.

Για τους απλούς χρήστες θα επιτρέψουμε την πρόσβαση σε ορισμένες υπηρεσίες (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"

Σημαίνει "όλοι οι χρήστες" ότι οι χρήστες χωρίς έλεγχο ταυτότητας θα έχουν επίσης πρόσβαση στην εφαρμογή Web SA; Όχι, η πολιτική θα ελέγχει την εγκυρότητα του διακριτικού 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 επιτρέπει στις ομάδες να εστιάζουν τους πόρους τους σε κρίσιμες για την επιχείρηση εργασίες χωρίς να προσθέτουν γενικά έξοδα στις υπηρεσίες, επαναφέροντάς τες σε micro status.

Το άρθρο (σε τρία μέρη) παρείχε βασικές γνώσεις και έτοιμες πρακτικές οδηγίες για να ξεκινήσετε με το Istio σε πραγματικά έργα.

ΥΓ από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

• "Επιστροφή στις μικροϋπηρεσίες με Istio": μέρος 1 (εισαγωγή στα κύρια χαρακτηριστικά), μέρος 2 (δρομολόγηση, έλεγχος κυκλοφορίας);
• «Αγωγός - ελαφρύ πλέγμα εξυπηρέτησης για Kubernetes"?
• «Τι είναι το service mesh και γιατί το χρειάζομαι [για μια εφαρμογή cloud με microservices];».

Πηγή: www.habr.com