חזרה לשירותי מיקרו עם Istio. חלק 3

הערה. תרגום: החלק הראשון סדרה זו הוקדשה להכיר את היכולות של איסטיו ולהדגים אותן בפעולה, שני - ניתוב מכוון וניהול תעבורת רשת. כעת נדבר על אבטחה: כדי להדגים את הפונקציות הבסיסיות הקשורות אליו, המחבר משתמש בשירות הזהות Auth0, אך ניתן להגדיר ספקים אחרים בצורה דומה.

הקמנו אשכול Kubernetes שבו פרסנו את Istio ויישום מיקרו-שירות לדוגמה, Sentiment Analysis, כדי להדגים את היכולות של Istio.

עם Istio, הצלחנו לשמור על השירותים שלנו קטנים מכיוון שהם לא צריכים ליישם שכבות כמו ניסיונות חוזרים, פסקי זמן, מפסקים, מעקב, ניטור. . בנוסף, השתמשנו בטכניקות בדיקה ופריסה מתקדמות: בדיקות A/B, שיקוף וגלגול קנרי.

בחומר החדש נעסוק ברבדים האחרונים בדרך לערך עסקי: אימות והרשאה - ובאיסטיו זה תענוג אמיתי!

אימות והרשאה באיסטיו

לעולם לא הייתי מאמין שאקבל השראה מאימות והרשאה. מה יכולה איסטיו להציע מנקודת מבט טכנולוגית כדי להפוך את הנושאים האלה למהנים, ויותר מכך, מעוררי השראה עבורך?

התשובה פשוטה: 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. יחד עם זאת, התצורה אינה מוחלת על שליחי שירות sa-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 > Create API ומלא את הטופס:

המידע החשוב כאן הוא מזהה, שבו נשתמש בהמשך התסריט. בוא נרשום את זה ככה:

• קהל: {YOUR_AUDIENCE}

שאר הפרטים שאנו צריכים נמצאים בפורטל Auth0 בקטע יישומים - בחר יישום בדיקה (נוצר אוטומטית יחד עם ה-API).

כאן נכתוב:

• תְחוּם: {YOUR_DOMAIN}
• מזהה לקוח: {YOUR_CLIENT_ID}

גלול אל יישום בדיקה לשדה טקסט כתובות URL מותרות להתקשרות חוזרת (כתובות URL פתורות להתקשרות חוזרת), בהן אנו מציינים את כתובת האתר שאליה יש לשלוח את השיחה לאחר השלמת האימות. במקרה שלנו זה:

http://{EXTERNAL_IP}/callback

ובשביל כתובות אתרים מותרות ליציאה (כתובות URL מותרות ליציאה) הוסף:

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));
}

כדי לשנות את ה-frontend לשימוש בנתוני דיירים ב-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 Authorization ונשתמש ב-Istio כדי לספק להן רמות גישה שונות.

התקנה ותצורה של Auth0 Authorization

בפורטל Auth0, עבור אל הרחבות (רחבות) והתקן Auth0 Authorization. לאחר ההתקנה, עבור אל הארכת הרשאה, ושם - לתצורת הדייר על ידי לחיצה על הפינה השמאלית העליונה ובחירה באפשרות התפריט המתאימה (תְצוּרָה). הפעל קבוצות (קבוצות) ולחץ על כפתור פרסום הכלל (כלל פרסום).

יצירת קבוצות

ב-Extension Authorization עבור אל קבוצות וליצור קבוצה מנחים. מכיוון שאנו נתייחס לכל המשתמשים המאומתים כאל משתמשים רגילים, אין צורך ליצור עבורם קבוצה נוספת.

בחר קבוצה מנחים, ללחוץ הוסף חברים, הוסף את החשבון הראשי שלך. השאר חלק מהמשתמשים ללא כל קבוצה כדי לוודא שהגישה מונעת מהם. (ניתן ליצור משתמשים חדשים באופן ידני באמצעות 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-autorization-extension
• הוסף תביעה קבוצתית

הסדר חשוב מכיוון ששדה הקבוצה מקבל את הכלל באופן אסינכרוני auth0-autorization-extension ואחרי זה מתווסף כטענה על ידי הכלל השני. התוצאה היא אסימון גישה כזה:

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

כעת עליך להגדיר את ה-proxy של 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-Frontend ו-SA-WebApp. מיושם באמצעות משאבי Istio הבאים:

• תפקיד שירות - קובע את הזכויות שיש למשתמש;
• שירות RolleBinding - קובע למי שייך תפקיד שירות זה.

למשתמשים רגילים נאפשר גישה לשירותים מסוימים (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 החל את תפקיד השירות על כל המבקרים בדף (רגיל-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 בפרויקטים אמיתיים.

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• "חזרה לשירותי מיקרו עם Istio": חלק 1 (מבוא לתכונות העיקריות), חלק 2 (ניתוב, בקרת תנועה);
• «Conduit - רשת שירות קלת משקל עבור Kubernetes";
• «מהי רשת שירות ולמה אני צריך אותה [עבור אפליקציית ענן עם מיקרו-שירותים]?".

מקור: www.habr.com