🥇 اسٹیو کے ساتھ مائیکرو سروسز پر واپس جائیں۔ حصہ 3

نوٹ. ترجمہ: پہلا حصہ یہ سلسلہ اسٹیو کی صلاحیتوں کو جاننے اور انہیں عملی طور پر ظاہر کرنے کے لیے وقف کیا گیا تھا، دوسرا - باریک ٹیونڈ روٹنگ اور نیٹ ورک ٹریفک مینجمنٹ۔ اب ہم سیکورٹی کے بارے میں بات کریں گے: اس سے متعلق بنیادی افعال کو ظاہر کرنے کے لیے، مصنف Auth0 شناختی سروس کا استعمال کرتا ہے، لیکن دوسرے فراہم کنندگان کو بھی اسی طرح ترتیب دیا جا سکتا ہے۔

ہم نے ایک Kubernetes کلسٹر قائم کیا جس میں Istio کی صلاحیتوں کو ظاہر کرنے کے لیے ہم نے Istio اور ایک مثال مائیکرو سروس ایپلیکیشن، Sentiment Analysis، کو تعینات کیا۔

Istio کے ساتھ، ہم اپنی خدمات کو چھوٹا رکھنے میں کامیاب رہے کیونکہ انہیں دوبارہ کوششیں، ٹائم آؤٹ، سرکٹ بریکر، ٹریسنگ، مانیٹرنگ جیسی پرتوں کو لاگو کرنے کی ضرورت نہیں ہے۔ اس کے علاوہ، ہم نے جانچ اور تعیناتی کی جدید تکنیکوں کا استعمال کیا: A/B ٹیسٹنگ، عکس بندی اور کینری رول آؤٹ۔

نئے مواد میں، ہم کاروباری قدر کے راستے پر آخری تہوں سے نمٹیں گے: تصدیق اور اجازت - اور Istio میں یہ ایک حقیقی خوشی کی بات ہے!

Istio میں تصدیق اور اجازت

میں نے کبھی یقین نہیں کیا تھا کہ میں تصدیق اور اجازت سے متاثر ہوں گا۔ Istio ان موضوعات کو پرلطف بنانے کے لیے ٹیکنالوجی کے نقطہ نظر سے کیا پیش کر سکتا ہے اور اس سے بھی زیادہ، آپ کے لیے متاثر کن؟

جواب آسان ہے: Istio ان صلاحیتوں کی ذمہ داری آپ کی خدمات سے ایلچی پراکسی کو منتقل کرتا ہے۔ جب تک درخواستیں خدمات تک پہنچتی ہیں، وہ پہلے ہی تصدیق شدہ اور مجاز ہو چکی ہوتی ہیں، لہذا آپ کو بس کاروبار کے لیے مفید کوڈ لکھنا ہے۔

اچھا لگتا ہے؟ آئیے اندر ایک نظر ڈالیں!

Auth0 کے ساتھ تصدیق

شناخت اور رسائی کے انتظام کے لیے سرور کے طور پر، ہم Auth0 استعمال کریں گے، جس کا آزمائشی ورژن ہے، استعمال کرنے کے لیے بدیہی ہے اور مجھے یہ پسند ہے۔ تاہم، ایک ہی اصول کسی دوسرے پر لاگو کیا جا سکتا ہے اوپن آئی ڈی کنیکٹ کے نفاذ: 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

اس طرح کے وسائل کے ساتھ، پائلٹ (Istio میں کنٹرول پلین کے تین بنیادی اجزاء میں سے ایک - تقریباً ترجمہ) درخواستوں کو خدمات پر بھیجنے سے پہلے ان کی تصدیق کے لیے ایلچی کو ترتیب دیتا ہے: 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 کے ساتھ درخواستوں کی تصدیق کرنا

اختتامی صارف کی درخواستوں کی توثیق کرنے کے لیے، آپ کو Auth0 میں ایک API بنانا ہوگا جو تصدیق شدہ خدمات (جائزے، تفصیلات اور درجہ بندی) کی نمائندگی کرے گا۔ API بنانے کے لیے، پر جائیں۔ Auth0 پورٹل> APIs> API بنائیں اور فارم پُر کریں:

اہم معلومات یہاں ہے۔ شناختی، جسے ہم بعد میں اسکرپٹ میں استعمال کریں گے۔ آئیے اسے اس طرح لکھتے ہیں:

شائقین: {YOUR_AUDIENCE}

ہمیں درکار باقی تفصیلات سیکشن میں موجود Auth0 پورٹل پر موجود ہیں۔ درخواستیں --.منتخب کرنا ٹیسٹ کی درخواست (API کے ساتھ خود بخود بنایا گیا)۔

یہاں ہم لکھیں گے:

ڈومین: {YOUR_DOMAIN}
کلائنٹ کی شناخت: {YOUR_CLIENT_ID}

تک سکرول کریں۔ ٹیسٹ کی درخواست ٹیکسٹ فیلڈ میں اجازت یافتہ کال بیک URLs (کال بیک کے لیے حل شدہ یو آر ایل)، جس میں ہم یو آر ایل کی وضاحت کرتے ہیں جہاں تصدیق مکمل ہونے کے بعد کال بھیجی جانی چاہیے۔ ہمارے معاملے میں یہ ہے:

http://{EXTERNAL_IP}/callback

اور کے لئے لاگ آؤٹ URLs کی اجازت ہے۔ (لاگ آؤٹ کرنے کے لیے اجازت یافتہ یو آر ایل) شامل کریں:

http://{EXTERNAL_IP}/logout

آئیے فرنٹ اینڈ کی طرف چلتے ہیں۔

فرنٹ اینڈ اپ ڈیٹ

برانچ پر جائیں۔ auth0 REPOZITORIA [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 کے ساتھ اجازت

توثیق ہمیں یہ سمجھنے کی اجازت دیتی ہے کہ صارف کون ہے، لیکن یہ جاننے کے لیے اجازت درکار ہوتی ہے کہ انہیں کس چیز تک رسائی حاصل ہے۔ اسٹیو اس کے لیے بھی ٹولز پیش کرتا ہے۔

مثال کے طور پر، آئیے دو صارف گروپ بنائیں (نیچے خاکہ دیکھیں):

صارفین (صارفین) - صرف SA-WebApp اور SA-Frontend سروسز تک رسائی کے ساتھ؛
ناظمین (ماڈریٹرز) - تینوں خدمات تک رسائی کے ساتھ۔

اجازت کا تصور

ان گروپس کو بنانے کے لیے، ہم Auth0 Authorization کی توسیع کا استعمال کریں گے اور Istio کا استعمال کریں گے تاکہ انہیں مختلف سطحوں تک رسائی فراہم کی جا سکے۔

Auth0 اتھارٹی کی انسٹالیشن اور کنفیگریشن

Auth0 پورٹل میں، ایکسٹینشن پر جائیں (ملانے) اور انسٹال کریں۔ Auth0 کی اجازت. تنصیب کے بعد، پر جائیں اجازت کی توسیع، اور وہاں - اوپر دائیں طرف کلک کرکے اور مناسب مینو آپشن کو منتخب کرکے کرایہ دار کی ترتیب تک (تشکیل). گروپس کو فعال کریں۔ (گروپ) اور پبلش رول بٹن پر کلک کریں۔ (اصول شائع کریں).

گروپس بنائیں

اتھارٹی ایکسٹینشن میں جائیں۔ گروپس اور ایک گروپ بنائیں منتظمین. چونکہ ہم تمام مستند صارفین کو باقاعدہ استعمال کرنے والوں کے طور پر پیش کریں گے، اس لیے ان کے لیے کوئی اضافی گروپ بنانے کی ضرورت نہیں ہے۔

ایک گروپ کا انتخاب کریں۔ منتظمین،دبائیں۔ ممبران شامل کریں، اپنا مرکزی اکاؤنٹ شامل کریں۔ کچھ صارفین کو بغیر کسی گروپ کے چھوڑ دیں تاکہ یہ یقینی بنایا جا سکے کہ ان تک رسائی سے انکار کر دیا گیا ہے۔ (نئے صارفین کو دستی طور پر بنایا جا سکتا ہے۔ Auth0 پورٹل> صارفین> صارف بنائیں.)

ٹوکن تک رسائی میں گروپ کلیم شامل کریں۔

صارفین کو گروپس میں شامل کیا گیا ہے، لیکن یہ معلومات رسائی ٹوکن میں بھی ظاہر ہونی چاہیے۔ 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 کی ضرورت ہے)۔

صفحہ پر واپس جائیں۔ قواعد اور چیک کریں کہ آپ کے پاس دو اصول درج ذیل ترتیب میں لکھے گئے ہیں:

auth0-authorization-extension
گروپ کلیم شامل کریں۔

آرڈر اہم ہے کیونکہ گروپ فیلڈ کو قاعدہ متضاد طور پر موصول ہوتا ہے۔ auth0-authorization-extension اور اس کے بعد دوسرے قاعدے کے ذریعہ دعوی کے طور پر شامل کیا جاتا ہے۔ نتیجہ اس طرح ایک رسائی ٹوکن ہے:

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

اب آپ کو صارف کی رسائی چیک کرنے کے لیے ایلچی پراکسی کو کنفیگر کرنے کی ضرورت ہے، جس کے لیے گروپ کو دعوے سے نکال دیا جائے گا (https://sa.io/group) واپس کردہ رسائی ٹوکن میں۔ یہ مضمون کے اگلے حصے کا موضوع ہے۔

Istio میں اجازت کی ترتیب

کام کرنے کی اجازت کے لیے، آپ کو Istio کے لیے 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 وسائل کا استعمال کرتے ہوئے لاگو کیا گیا:

سروس رول - صارف کے حقوق کا تعین کرتا ہے۔
سروس رول بائنڈنگ - یہ تعین کرتا ہے کہ یہ سروس رول کس کا ہے۔

عام صارفین کے لیے ہم کچھ خدمات تک رسائی کی اجازت دیں گے (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 کا اطلاق کریں (ریگولر-یوزر-سروس-رول-بائنڈنگ.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

ہمارے بلاگ پر بھی پڑھیں:

"استیو کے ساتھ مائیکرو سروسز پر واپس جائیں": حصہ 1 (اہم خصوصیات کا تعارف), حصہ 2 (روٹنگ، ٹریفک کنٹرول);
«نالی - Kubernetes کے لیے ہلکا پھلکا سروس میش؛ "
«سروس میش کیا ہے اور مجھے اس کی ضرورت کیوں ہے [مائیکرو سروسز کے ساتھ کلاؤڈ ایپلیکیشن کے لیے]؟'.

ماخذ: www.habr.com

Istio کے ساتھ مائیکرو سروسز پر واپس جائیں۔ حصہ 3