🥇بازگشت به میکروسرویس ها با ایستیو. قسمت 3

توجه داشته باشید. ترجمه: بخش اول این مجموعه به آشنایی با قابلیت های ایستیو و نمایش آنها در عمل اختصاص داشت. دوم - تنظیم دقیق مسیریابی و مدیریت ترافیک شبکه. اکنون در مورد امنیت صحبت خواهیم کرد: برای نشان دادن عملکردهای اساسی مربوط به آن، نویسنده از سرویس هویت Auth0 استفاده می کند، اما سایر ارائه دهندگان را می توان به روشی مشابه پیکربندی کرد.

ما یک خوشه Kubernetes را راه‌اندازی کردیم که در آن Istio و یک نمونه برنامه میکروسرویس به نام Sentiment Analysis را برای نشان دادن قابلیت‌های Istio به کار بردیم.

با Istio، ما توانستیم خدمات خود را کوچک نگه داریم، زیرا آنها نیازی به پیاده‌سازی لایه‌هایی مانند تلاش مجدد، زمان‌بندی، قطع کننده مدار، ردیابی، نظارت ندارند. علاوه بر این، ما از تکنیک‌های آزمایش و استقرار پیشرفته استفاده کردیم: تست A/B، آینه‌کاری و نصب قناری.

در مطالب جدید، ما با لایه‌های نهایی در مسیر ارزش تجاری سروکار داریم: احراز هویت و مجوز - و در ایستیو این یک لذت واقعی است!

احراز هویت و مجوز در ایستیو

من هرگز باور نمی کردم که از احراز هویت و مجوز الهام بگیرم. ایستیو از منظر فناوری چه چیزی می تواند ارائه دهد تا این موضوعات را برای شما سرگرم کننده و حتی بیشتر از آن الهام بخش کند؟

پاسخ ساده است: 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

با چنین منبعی، خلبان (یکی از سه جزء اصلی Control Plane در ایستیو - تقریباً ترجمه) 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های حل شده برای پاسخ به تماس)، که در آن نشانی اینترنتی را مشخص می کنیم که پس از تکمیل احراز هویت، تماس باید در آن ارسال شود. در مورد ما این است:

http://{EXTERNAL_IP}/callback

و برای URL های خروج مجاز (URLهای مجاز برای خروج از سیستم) اضافه کنید:

http://{EXTERNAL_IP}/logout

بیایید به قسمت جلو برویم.

به روز رسانی Frontend

تغییر به شاخه auth0 مخزن [istio-mastery]. در این شاخه، کد frontend تغییر می‌کند تا کاربران را برای احراز هویت به 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

احراز هویت به ما این امکان را می دهد که بفهمیم یک کاربر چه کسی است، اما برای دانستن اینکه کاربر به چه چیزی دسترسی دارد مجوز لازم است. ایستیو ابزارهایی برای این کار نیز ارائه می دهد.

به عنوان مثال، اجازه دهید دو گروه کاربری ایجاد کنیم (نمودار زیر را ببینید):

کاربران (کاربران) - فقط با دسترسی به خدمات SA-WebApp و SA-Frontend؛
مدیران (مدیران) - با دسترسی به هر سه سرویس.

مفهوم مجوز

برای ایجاد این گروه ها از پسوند Auth0 Authorization استفاده می کنیم و از ایستیو برای ارائه سطوح مختلف دسترسی به آنها استفاده می کنیم.

نصب و پیکربندی مجوز Auth0

در پورتال Auth0، به برنامه های افزودنی بروید (گسترش دهنده ها) و نصب کنید مجوز Auth0. پس از نصب به تمدید مجوزو در آنجا - با کلیک بر روی بالا سمت راست و انتخاب گزینه منوی مناسب به پیکربندی مستاجر (پیکربندی). گروه ها را فعال کنید (گروه ها) و بر روی دکمه انتشار قانون کلیک کنید (نشر قانون).

ایجاد گروه ها

در مجوز Extension به گروه ها و یک گروه ایجاد کنید مدیران. از آنجایی که ما با همه کاربران احراز هویت شده به عنوان کاربران عادی رفتار خواهیم کرد، نیازی به ایجاد یک گروه اضافی برای آنها نیست.

یک گروه را انتخاب کنید مدیران، مطبوعات افزودن اعضا، حساب اصلی خود را اضافه کنید. برخی از کاربران را بدون هیچ گروهی رها کنید تا مطمئن شوید که دسترسی آنها ممنوع است. (کاربران جدید را می توان به صورت دستی از طریق ایجاد کرد Auth0 Portal > Users > Create User.)

ادعای گروهی را به نشانه دسترسی اضافه کنید

کاربران به گروه ها اضافه شده اند، اما این اطلاعات باید در نشانه های دسترسی نیز منعکس شود. برای مطابقت با 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 لازم است) به نشانه دسترسی اضافه می کند.

بازگشت به صفحه قوانین و بررسی کنید که دو قانون به ترتیب زیر نوشته شده باشد:

authorization-extension
افزودن ادعای گروهی

ترتیب مهم است زیرا فیلد گروه قانون را به صورت ناهمزمان دریافت می کند authorization-extension و بعد از آن به عنوان ادعا به قاعده دوم اضافه می شود. نتیجه یک نشانه دسترسی مانند زیر است:

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

اکنون باید پروکسی Envoy را برای بررسی دسترسی کاربر پیکربندی کنید، که برای آن گروه از ادعا خارج می شود (https://sa.io/group) در نشانه دسترسی برگشتی. این موضوع برای بخش بعدی مقاله است.

پیکربندی مجوز در ایستیو

برای اینکه مجوز کار کند، باید RBAC را برای ایستیو فعال کنید. برای این کار از پیکربندی زیر استفاده می کنیم:

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 برای همه بازدیدکنندگان صفحه (منظم-کاربر-خدمات-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) برای دستیابی به کنترل دقیق بر احراز هویت و مجوز دسترسی کاربر نهایی به خدمات مورد نیاز بود.

علاوه بر این، ما در خارج از خدمات فرستاده خود به این مسائل رسیدگی کرده و به موارد زیر دست یافته ایم:

کاهش مقدار کدهای عمومی که ممکن است حاوی مشکلات امنیتی و اشکال باشد.
کاهش تعداد موقعیت‌های احمقانه که در آن یک نقطه پایانی از بیرون قابل دسترسی است و فراموش کرده است که آن را گزارش کند.
حذف نیاز به به روز رسانی همه سرویس ها هر بار که نقش یا حق جدیدی اضافه می شود.
که خدمات جدید ساده، ایمن و سریع باقی می مانند.

نتیجه

ایستیو به تیم‌ها اجازه می‌دهد تا منابع خود را بر روی وظایف حیاتی کسب‌وکار بدون اضافه کردن سربار به خدمات متمرکز کنند و آنها را به وضعیت خرد برگردانند.

در این مقاله (در سه قسمت) دانش اولیه و دستورالعمل های کاربردی آماده برای شروع کار با ایستیو در پروژه های واقعی ارائه شد.

PS از مترجم

در وبلاگ ما نیز بخوانید:

"بازگشت به میکروسرویس با ایستیو": قسمت 1 (مقدمه ای بر ویژگی های اصلی), بخش 2 (مسیریابی، کنترل ترافیک);
«لوله - مش سرویس سبک وزن برای Kubernetes"؛
«سرویس مش چیست و چرا [برای یک برنامه ابری با میکروسرویس ها] به آن نیاز دارم؟'.

منبع: www.habr.com

بازگشت به میکروسرویس ها با ایستیو. قسمت 3