گوگل کلاؤڈ سروسز اور آن پریمیسس Kubernetes انفراسٹرکچر کا استعمال کرتے ہوئے ایک ہائبرڈ کلاؤڈ پلیٹ فارم کیسے بنایا جائے

اس مضمون میں، آپ سیکھتے ہیں کہ کس طرح ایک محفوظ، توسیع پذیر ہائبرڈ کلاؤڈ پلیٹ فارم کو ڈیزائن اور بنانا ہے جو آپ کے آن پریمیسس Kubernetes انفراسٹرکچر کو گوگل کلاؤڈ پلیٹ فارم سے جوڑتا ہے۔ یہ آن پریمیسس ایپس کو کلاؤڈ سروسز (خاص طور پر GPUs) کو کمزور طویل مدتی کلیدوں، دستی اسناد کے انتظام، یا خطرناک نیٹ ورک پیٹرن کے بغیر استعمال کرنے کی اجازت دیتا ہے۔

یہ کس کے لیے ہے:

• پلیٹ فارم انجینئرز، SREs، اور سیکیورٹی پر مرکوز کلاؤڈ آرکیٹیکٹس جو آن پریمیسس اور کلاؤڈ Kubernetes اثاثوں کا مرکب چلا رہے ہیں۔

• جن ٹیموں کو آپریشنل اوور ہیڈ اور بلاسٹ ریڈیئس کو کم سے کم کرتے ہوئے GCP وسائل (خاص طور پر GPU مثالوں) تک آن پریمیسس ورک بوجھ سے قابل توسیع، قابل سماعت رسائی کی ضرورت ہے۔

آپ کو اس گائیڈ سے کیا ملے گا:

• ہائبرڈ اپروچ کے محرکات اور معاشیات (جی پی یوز کام کے بوجھ کو کلاؤڈ پر کیوں دھکیلتے ہیں)

• سروس اکاؤنٹ کیز کے عام نقصانات کے بارے میں جانیں اور جانیں کہ حقیقی دنیا کے ماحول میں ‘حادثاتی ہوا کے فرق’ کیسے ہوتے ہیں۔

• ایک عملی اینڈ ٹو اینڈ پیٹرن جو کام کے بوجھ کی شناخت فیڈریشن کا استعمال کرتا ہے تاکہ آن پریمیسس پوڈز کو ایمبیڈڈ کیز کے بغیر GCP تک قلیل مدتی، قابل سماعت رسائی فراہم کرے۔

شامل:

• تصوراتی وضاحتیں، حفاظتی فوائد اور نقصانات، اور آپریشنل بہترین طریقے۔

• ٹھوس مثالیں اور Kubernetes/Terraform نمونے آپ کو اپنے ماحول میں سیٹ اپ کو دوبارہ تیار کرنے میں مدد کرنے کے لیے (اس مضمون کے آخر میں GitHub ذخیرہ سے منسلک)

تھیوری کو پڑھنے کے بعد، GCP وسائل کی فراہمی کے لیے ہینڈ آن سیکشن کی پیروی کریں، فیڈریشن کو ترتیب دیں، CEL اور Kyverno کا استعمال کرتے ہوئے پالیسیاں نافذ کریں، اور اپنے آن پریمیسس Kubernetes کلسٹر میں محفوظ، قابل توسیع GPU رسائی کی توثیق کریں۔

میمو: Kubernetes اور Terraform نمونے اس دستاویز کے آخر میں GitHub کے ذخیروں سے منسلک ہیں۔

انڈیکس

شرائط

ان اقدامات پر عمل کرنے سے پہلے، آپ کو ضرورت ہو گی:

• Kubernetes کلسٹر اس طرح لگتا ہے: ~ نہیں GKE (آن پریمیسس، ننگی دھات، یا ورچوئل کلسٹر)

• APIs جیسے IAM، سیکورٹی ٹوکن سروس (STS)، اور ورک لوڈ آئیڈینٹیٹی کے ساتھ ایک Google Cloud پروجیکٹ فعال ہے۔

• ٹیرافارم کو انسٹال اور کنفیگر کریں۔

• Kyverno کلسٹر پر نصب

• ازگر 3 google-cloud-secret-manager اور google-cloud-aiplatform لائبریری (تصدیق کے مرحلے کے لیے۔ کوڈ گیتھب ریپوزٹری میں دستیاب ہے)

• kubectl کلسٹر تک رسائی

ہائبرڈ کلاؤڈ کیوں اہمیت رکھتا ہے۔

اگر سب کچھ ٹھیک رہا تو، ایک ہائبرڈ کلاؤڈ پلیٹ فارم آن پریمیسس اور کلاؤڈ ورک بوجھ کو ایک دوسرے سے اس طرح بات چیت کرنے کی اجازت دے گا جیسے وہ ایک ہی نیٹ ورک کا حصہ ہوں۔

ہائبرڈ کلاؤڈ سیٹ اپ چلانے کی بہت سی عملی وجوہات ہیں۔

• BigQuery پر تجزیات آف لوڈ کریں: آپ اضافی سرورز خریدے بغیر عالمی معیار کی پروسیسنگ پاور کے لیے BigQuery میں بڑے ڈیٹا سیٹس کو پائپ کر سکتے ہیں، جبکہ ڈیٹا کی خودمختاری کے لیے اپنی اینالیٹکس ایپس کو آن پریمیسس رکھتے ہوئے۔

• کلاؤڈ انٹر کنیکٹ کے ساتھ ایک متحد نیٹ ورک بنائیں: Cloud Interconnect یا Cloud VPN آپ کے آن پریمیسس ڈیٹا سینٹر کو آپ کے Google کلاؤڈ پلیٹ فارم (GCP) ورچوئل پرائیویٹ کلاؤڈ (VPC) کی توسیع بناتا ہے۔ آن پریمیسس انوائسنگ ایپس کلاؤڈ پر مبنی صارف کی خدمات کے ساتھ کم تاخیر اور عوامی انٹرنیٹ کی نمائش کے ساتھ بات چیت کرسکتی ہیں۔

• کلاؤڈ اسٹوریج کے ساتھ لاگت سے موثر اسکیل ایبلٹی: آپ لاگز، بیک اپس، اور تاریخی ڈیٹا کو ذخیرہ کرنے کے لیے اپنی مقامی ایپس کے لیے کلاؤڈ اسٹوریج کو بیک اینڈ کے طور پر استعمال کر سکتے ہیں، اور صرف اس چیز کی ادائیگی کر سکتے ہیں جو آپ استعمال کرتے ہیں۔

• پب/سب کے ذریعے ایونٹ پر مبنی ہم آہنگی: اگر آن پریمیسس میں کوئی مسئلہ پیش آتا ہے، تو کلاؤڈ پب/سب کے ذریعے پیغامات کلاؤڈ سروس کو فوری طور پر جواب دینے کی اجازت دیتے ہیں، دستی پولنگ کی ضرورت کو ختم کرتے ہوئے۔

ہائبرڈ کی اقتصادیات: GPUs نے سب کچھ بدل دیا۔

اس سے پہلے کہ ہم تکنیکی مسائل پر غور کریں، یہ سمجھنا مددگار ہے کہ ہائبرڈ کلاؤڈ پہلے سے کہیں زیادہ کیوں اہم ہے۔

زیادہ تر کاروباروں کی طرح، آپ کی تنظیم نے آن پریمیسس ڈیٹا سینٹر میں اہم سرمایہ کاری کی ہے۔ میں نے ایک سرور خریدا۔ ریک بھرا ہوا ہے۔ نیٹ ورک کے بنیادی ڈھانچے کی ادائیگی کی جاتی ہے۔ ایک اور کام کا بوجھ چلانے کی معمولی لاگت بنیادی طور پر صفر ہے۔

پھر AI لہر آئی۔

اچانک، ہر ٹیم کو گرافکس پروسیسنگ یونٹ (GPU) کی ضرورت تھی۔ صرف ایک یا دو نہیں بلکہ درجنوں A100s تربیت کے لیے، انفرنس اینڈ پوائنٹس کا ایک سیٹ، اور ایک ویکٹر ڈیٹا بیس جس کا ماڈل کے قریب ہونا ضروری ہے۔ GPU ناکافی ہے۔ آن پریمیسس GPU ہارڈویئر کے لیڈ ٹائم مہینوں تک بڑھ سکتے ہیں۔ آپ کا کلاؤڈ فراہم کنندہ اسے منٹوں میں استعمال کرنا شروع کر سکتا ہے۔

ایک فن تعمیر جو حقیقت میں معاشی معنی رکھتا ہے یہ ہوگا:

• آن پریمیسس ڈیٹا سینٹرز کمپیوٹنگ کی زیادہ مقدار کو سنبھالتے ہیں۔ – ویب سرورز، کاروباری منطق، ڈیٹا بیس، بیچ پروسیسنگ۔ یہ کموڈٹی کمپیوٹنگ ہے جو پہلے ہی اپنے لیے ادائیگی کر چکی ہے۔

• بادل اس بات کا خیال رکھتا ہے کہ کیا کمی ہے۔ — GPU- ایکسلریٹڈ انفرنس، ماڈل ٹریننگ، اور AI/ML اینڈ پوائنٹس۔ فی درخواست ادائیگی کریں، ضرورت کے مطابق پیمانہ کریں، اور ہارڈ ویئر کے لیے کبھی بھی چھ ماہ کا انتظار نہ کریں۔

بادل مکمل منتقلی کا ہدف نہیں ہے۔ یہ فعالیت کی ایک توسیع ہے جسے آسانی سے آن پریمیسس نہیں بنایا جا سکتا۔

تاہم، یہ آن پریمیسس کام کے بوجھ کو کلاؤڈ سروسز کے لیے مستند ہونا چاہیے۔ آپ کے ڈیٹا سینٹر سے Vertex AI اینڈ پوائنٹ پر ہر API کال، GPU پر مبنی انفرنس سروس کو ہر درخواست، اور ماڈل آرٹفیکٹس کے لیے کلاؤڈ اسٹوریج کو لکھنے والے ہر ایک کے لیے اسناد کی ضرورت ہوتی ہے۔ یہ وہ مسئلہ ہے جس کو اس مضمون میں حل کیا گیا ہے۔

سروس اکاؤنٹ کی چابیاں پیمانے پر کیوں ناکام ہوتی ہیں؟

یہاں ایک ایسا منظر ہے جو ہر روز ہزاروں کاروباروں کے ساتھ ہوتا ہے۔

آپ کی ڈیولپمنٹ ٹیم کو Google Cloud Storage پر لکھنے کے لیے ایک آن پریمیسس ایپلی کیشن کی ضرورت ہے۔ "واضح” حل کیا ہے؟ ایک GCP سروس اکاؤنٹ کی کلید بنائیں، اسے بیس 64 انکوڈ کریں، اسے Kubernetes سیکرٹ میں اسٹور کریں، اور اسے پوڈ پر لگائیں۔

apiVersion: v1
kind: Secret
metadata:
  name: gcp-credentials
type: Opaque
data:
  key.json: eyJ0eXBlIjoic2VydmljZV9hY2NvdW50IiwicHJvamVjdF9pZCI6…

یہ کام کرتا ہے۔ اس سے سنگین مسائل بھی پیدا ہوتے ہیں۔

• یہ کبھی ختم نہیں ہوتا۔ وہ کلید اس وقت تک اچھی ہے جب تک کہ کوئی اسے تبدیل کرنا یاد نہ رکھے (جو وہ نہیں کرتے) یا جب تک یہ خراب نہ ہو جائے (جو وہ کریں گے)۔

• یہ آسانی سے لیک ہو سکتا ہے۔ اس نام کی جگہ تک پڑھنے کی رسائی رکھنے والا کوئی بھی اسے چلا سکتا ہے۔ kubectl get secret -o yaml مستقل GCP رسائی دستیاب ہے۔

• اصل کام کے بوجھ کے لیے کوئی آڈٹ ٹریل نہیں ہے۔ GCP دیکھتا ہے کہ "اس بالٹی تک سروس-اکاؤنٹ-xyz کے ذریعے رسائی حاصل کی گئی تھی” کے بجائے "پوڈ فرنٹ اینڈ-abc-123 نام کی جگہ پروڈکشن”۔

• یہ بہت زیادہ پھیلتا ہے۔ 50 ٹیمیں × 3 ماحول × 4 GCP پروجیکٹس = 600 چابیاں ٹریک کرنے اور گھومنے کے لیے، امید ہے کہ کبھی بھی گٹ کے لیے پابند نہیں ہوں گے۔

سیکورٹی ٹیمیں یہ جانتی ہیں۔ یہی وجہ ہے کہ بہت سی تنظیموں نے کارروائی کا واحد معقول طریقہ اختیار کیا ہے۔ یہ سروس اکاؤنٹ کلیدی جنریشن کو مکمل طور پر غیر فعال کر دیتا ہے۔

حادثاتی فضائی خلا کیسے ہوتا ہے۔

کلیدی نسل کو غیر فعال کرنے سے آپ کے ہائبرڈ کلاؤڈ پلیٹ فارم کا مسئلہ حل نہیں ہوتا ہے۔ یہ صرف کسی اور کا مسئلہ بن جاتا ہے۔ کہ کوئی عام طور پر پلیٹ فارم ٹیم ہے جو جیرا کے ٹکٹ کو گھور رہی ہے جو کہتی ہے "آن پریمیسس، P1، بلاکنگ ریلیز سے GCP تک رسائی نہیں ہے۔”

نتائج کیا ہیں؟ آپ کا "ہائبرڈ کلاؤڈ پلیٹ فارم” بالکل بھی ہائبرڈ نہیں ہے۔ یہ دو منقطع نظام ہیں۔

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

ورک لوڈ آئیڈینٹی فیڈریشن خلا کو کیسے پُر کرتی ہے۔

ہر Kubernetes کلسٹر پہلے سے ہی ہر Pod پر خفیہ طور پر دستخط شدہ ID ٹوکن جاری کرتا ہے۔ اور گوگل کلاؤڈ کے پاس ایسی خدمات ہیں جو خاص طور پر ان ٹوکنز پر بھروسہ کرنے کے لیے بنائی گئی ہیں۔

یہ ہے ورک لوڈ آئیڈینٹی الائنس — OpenID Connect (OIDC) کے ساتھ مل کر، یہ وہ گمشدہ ٹکڑا ہے جو ہائبرڈ پلیٹ فارم کو واقعی کام کرتا ہے۔

اس سروس کا نام فیڈریشن کے لفظ کی وجہ سے رکھا گیا ہے۔ اس کا مطلب ہے کہ GCP آپ کی شناخت کو محفوظ نہیں کرتا ہے۔ اس کا مطلب یہ ہے کہ آپ کسی دوسرے سسٹم کی طرف سے جاری کردہ شناخت پر بھروسہ کرنے سے اتفاق کرتے ہیں جب تک کہ اس کی خفیہ طور پر تصدیق کی جا سکے۔ یہ سب درج ذیل ترتیب میں انتہائی مربوط مراحل میں کام کرتا ہے:

1. Pods جی سی پی میں ایس ٹی ایس کے اختتامی نقطہ پر Kubernetes کی طرف سے جاری کردہ JWT کی خدمت کرتے ہیں۔

2. STS کلسٹر میں عوامی JWKS کے خلاف دستخط کی تصدیق کرتا ہے۔

3. STS کام بوجھ شناختی پول (ٹارگٹ، جاری کنندہ، CEL شرائط) کے قواعد کے خلاف JWT کے دعووں کی تصدیق کرتا ہے۔

4. STS ایک قلیل المدت گوگل ایکسیس ٹوکن (عام طور پر 1 گھنٹہ) لوٹاتا ہے جسے پوڈ API کال کرنے کے لیے استعمال کرتا ہے۔

یہ بات بھی قابل ذکر ہے کہ Workload Identity Federation صرف Kubernetes تک محدود نہیں ہے۔ AWS IAM، Azure AD، GitHub Actions OIDC، اور کسی بھی OIDC سے مطابقت رکھنے والے شناخت فراہم کنندہ کے ساتھ کام کرتا ہے۔

Kubernetes ID کیسے کام کرتی ہے۔

سروس اکاؤنٹ والے تمام پوڈز خود بخود JSON ویب ٹوکن (JWT) کو ماؤنٹ کرتے ہیں۔ /run/secrets/kubernetes.io/serviceaccount/token. یہ صرف ایک مبہم داغ نہیں ہے، یہ ایک دستخط شدہ شناخت ہے۔

{
  "iss": "https://kubernetes.default.svc.cluster.local",
  "sub": "system:serviceaccount:production:backend-api",
  "aud": ["https://iam.googleapis.com/..."],
  "kubernetes.io": {
    "namespace": "production",
    "serviceaccount": {
      "name": "backend-api"
    }
  },
  "exp": 1735689600
}

JWT میں، دعوے ٹوکن پے لوڈ کے اندر صرف کلیدی قدر کے جوڑے ہیں۔ ہر دعویٰ ایک دعویٰ ہے جو جاری کنندہ کسی موضوع کے بارے میں کرتا ہے۔ اس کو ایک حقیقت کے طور پر سوچیں کہ ٹوکن کا دعویٰ ہے اور اس پر خفیہ طور پر دستخط کیے گئے ہیں تاکہ تصدیق کنندہ اس پر بھروسہ کر سکے۔

کلیدی بصیرت: یہ ٹوکن JSON Web Key Set (JWKS) سیٹ کے طور پر تیار کیا گیا ہے اور JSON Web Key Set (JWKS) کے اختتامی نقطہ کے ذریعے ظاہر ہونے والے کلسٹر کی عوامی کلید کے ساتھ کسی بھی شخص سے اس کی تصدیق کی جا سکتی ہے۔

kubectl get --raw /openid/v1/jwks

گوگل کلاؤڈ کی سیکیورٹی ٹوکن سروس (STS) ان ٹوکنز کی تصدیق کر سکتی ہے۔ چابیاں کا تبادلہ نہیں ہوتا ہے۔ راز محفوظ نہیں ہیں۔ یہ صرف شناخت کا ایک خفیہ کردہ ثبوت ہے۔

اپنے گوگل کلاؤڈ پلیٹ فارم کے وسائل کیسے تیار کریں۔

کام کا بوجھ شناختی پول ایک اعتماد کی حد ہے، یہ ایک اعلان ہے کہ "ہم بیرونی ذرائع سے شناخت قبول کرتے ہیں۔” OIDC فراہم کنندہ کنفیگر کرتا ہے کہ اس شناخت کی تصدیق کیسے کی جاتی ہے۔

resource "google_iam_workload_identity_pool" "pool" {
  workload_identity_pool_id = "hybrid-platform-pool"
  project                   = "my-project"
}

resource "google_iam_workload_identity_pool_provider" "k8s_provider" {
  project                            = "my-project"
  workload_identity_pool_id          = google_iam_workload_identity_pool.pool.workload_identity_pool_id
  workload_identity_pool_provider_id = "on-prem-cluster"

  attribute_mapping = {
    "google.subject"      = "assertion.sub"
    "attribute.namespace" = "assertion['kubernetes.io']['namespace']"
  }

  attribute_condition = "attribute.namespace in [\"production\", \"staging\"]"

  oidc {
    issuer_uri = "https://kubernetes.default.svc.cluster.local"
    jwks_json  = file("jwks.json")  # Your cluster's public keys
  }
}

یہاں دو باتیں قابل غور ہیں:

1. attribute_mapping Kubernetes JWT سے دعوے نکالتا ہے اور انہیں GCP پراپرٹیز کے طور پر دستیاب کرتا ہے۔ ` دعوے کا استعمال کرتے ہوئے[‘kubernetes.io’][‘namespace’]`، نام کی جگہیں رسائی کنٹرول میں استعمال کے لیے نکالی جاتی ہیں۔

2. attribute_condition یہ وہ جگہ ہے جہاں سیکیورٹی پالیسی زندگی میں آتی ہے۔ اس بارے میں مزید تفصیلات کے لیے اگلا حصہ دیکھیں۔

عمدہ رسائی کنٹرول کے لیے CEL کا استعمال کیسے کریں۔

کہ attribute_condition فیلڈ کامن ایکسپریشن لینگویج (CEL) استعمال کرتی ہے۔ یہ واحد پالیسی لائن درجنوں شناخت اور رسائی کے انتظام (IAM) بائنڈنگ کو بدل سکتی ہے۔

attribute.namespace in ["production", "staging"]

اس حالت میں، فورڈ kube-system نام کی جگہ گوگل کلاؤڈ پر بالکل بھی تصدیق نہیں کر سکتی۔ ٹوکن ایکسچینج کو مسترد کر دیا جاتا ہے اس سے پہلے کہ میں IAM سے رابطہ کر سکوں۔

یہ زیادہ وسیع ہو سکتا ہے۔

// Only production namespace, and only specific service accounts
attribute.namespace == "production" &&
  attribute.service_account in ["payment-processor", "order-service"]

// Allow staging, but only during business hours
attribute.namespace == "staging" &&
  request.time.getHours("America/New_York") >= 9 &&
  request.time.getHours("America/New_York") < 17

یہ گہرائی میں دفاع ہے. کوئی ایک بدمعاش سروس اکاؤنٹ بناتا ہے یا kubectl GCP تک رسائی کی توثیق نہیں کی جا سکتی جب تک کہ وہ CEL کے معیار کو پاس نہ کرے۔ ڈیولپرز سے اس کی پالیسیوں پر عمل کرنے کی توقع کرنے کے بجائے، Google کے بنیادی ڈھانچے کے ذریعے حفاظتی حدود کو نافذ کیا جاتا ہے۔

Kyverno کا استعمال کرتے ہوئے خود بخود اسناد کیسے لگائیں۔

ورکنگ شناختی اتحاد کا ہونا صرف آدھی جنگ ہے۔ صارفین اور ڈویلپرز کو OIDC، STS، یا اسناد کنفیگریشن فائلوں کو سمجھنے کی ضرورت نہیں ہے۔ انہیں ایپ کو تعینات کرنے اور اسے کام کرنے کی ضرورت ہے۔

اس سے پہلے کہ ہم آٹومیشن پر پہنچیں، یہ توقف کے قابل ہے۔ اسناد کی ترتیب کی فائل دراصل - کیونکہ نام تھوڑا گمراہ کن ہے۔

کریڈینشل کنفیگریشن فائلز (جسے "بیرونی اکاؤنٹ کنفیگریشن" یا "ADC کنفیگریشن" بھی کہا جاتا ہے) چھوٹی JSON دستاویزات ہیں جو گوگل کی کلائنٹ لائبریریوں کو معلومات فراہم کرتی ہیں۔ حاصل کرنے کے لئے کس طرح رن ٹائم پر اسناد۔ کہ ~ نہیں یہ اپنے آپ میں ایک سند ہے۔ آپ اصل فائل اس مضمون میں بعد میں دیکھ سکتے ہیں۔ اس میں کوئی راز نہیں ہے۔ میٹا ڈیٹا: پوڈ کے فائل سسٹم کا راستہ جہاں کام کا بوجھ شناختی پول کا ہدف، STS ٹوکن ایکسچینج اینڈ پوائنٹ، سورس ٹوکن کی قسم، اور اصل (قلیل المدت) Kubernetes ServiceAccount ٹوکن واقع ہے۔

اس کا موازنہ اپنی موجودہ سروس اکاؤنٹ کلید سے کریں۔

	سروس اکاؤنٹ کی کلید (key.json)	اسناد ترتیب دیں (credential-configuration.json)
فائل میں کیا ہے؟	RSA نجی کلید ہے۔ ہے اسناد	بیرونی ٹوکن ایکسچینج کی ہدایات
خفیہ ڈیٹا کی زندگی	ہمیشہ کے لیے جب تک دستی طور پر گھمایا نہ جائے۔	ماخذ ٹوکن خود بخود گھمائے جاتے ہیں (~1 گھنٹہ TTL)۔
اگر آپ کی فائلیں لیک ہو جاتی ہیں۔	GCP سروس اکاؤنٹس تک طویل مدتی رسائی	بذات خود بیکار ہے۔ ایک ٹوکن کی طرف اشارہ کرتا ہے جسے صرف پوڈ پڑھ سکتے ہیں۔
شناخت ماڈل	براہ راست GCP سروس اکاؤنٹ کی نقالی کریں۔	بیرونی شناختوں کو STS کے ذریعے GCP میں ضم کریں۔
وہ شخص جو گردش کو سنبھالتا ہے۔	انسان (یا کوئی نہیں)	Kubernetes API سرور شفاف طریقے سے

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

ConfigMap میں اس فائل کا ہونا آدھا حل ہے۔ یہ کام کے بوجھ کے پوڈ میں ختم ہونا چاہئے جسے اصل میں GCP خدمات تک رسائی کی ضرورت ہے۔ یہ وہ جگہ ہے جہاں Kyverno کھیل میں آتا ہے۔ ایک واحد کلسٹر پالیسی آپ کی پوڈ کی ضرورت کی ہر چیز کو خود بخود انجیکشن دیتی ہے۔

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: workload-identity-federation
spec:
  rules:
    - name: inject-gcp-credentials
      match:
        any:
          - resources:
              kinds:
                - Deployment
              selector:
                matchLabels:
                  workload-identity-federation: "enabled"
      mutate:
        patchStrategicMerge:
          spec:
            template:
              spec:
                volumes:
                  - name: workload-identity-credential-configuration
                    configMap:
                      name: workload-identity-federation-config
                containers:
                  - (name): "*"
                    volumeMounts:
                      - name: workload-identity-credential-configuration
                        mountPath: /etc/workload-identity
                        readOnly: true
                    env:
                      - name: GOOGLE_APPLICATION_CREDENTIALS
                        value: "/etc/workload-identity/credential-configuration.json"

مندرجہ بالا کلسٹر پالیسی تین چیزیں کرتی ہے:

1. تعیناتی کرتے وقت، کنٹینر کے اندر کنفیگ میپ کو ماؤنٹ کریں۔ /etc/workload-identity.

2. نامی ایک ماحولیاتی متغیر انجیکشن GOOGLE_APPLICATION_CREDENTIALS یہ اسناد کنفیگریشن فائل کے مطلق راستے کی طرف اشارہ کرتا ہے۔

ایک ڈویلپر کے نقطہ نظر سے، یہ مکمل انضمام ہے۔

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    workload-identity-federation: "enabled" # That's it.
spec:
  # ... normal deployment spec

اسناد کی کنفیگریشن فائل (Terraform کی طرف سے ConfigMap کے طور پر تیار کی گئی) گوگل کلائنٹ لائبریری کو بتاتی ہے کہ ٹوکن کا تبادلہ کیسے کیا جائے۔

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "credential_source": {
    "file": "/run/secrets/kubernetes.io/serviceaccount/token"
  }
}

یہ JSON فائل گوگل کے ورک لوڈ آئیڈینٹی فیڈریشن کے لیے صارف کی اسناد کو ترتیب دیتی ہے۔ Kubernetes ServiceAccount ٹوکن (اس پر واقع ہے: /run/secrets/kubernetes.io/serviceaccount/token) گوگل کلاؤڈ تک رسائی کے ٹوکنز کے لیے، ورک لوڈ شناختی پول کے ذریعے کنفیگر کردہ بیرونی شناخت فراہم کنندہ کا استعمال کریں۔ یہ GCP سے باہر چلنے والے کام کے بوجھ کو اجازت دیتا ہے، جیسے کہ آن پریمیسس Kubernetes کلسٹرز، طویل المدت سروس اکاؤنٹ کیز کو منظم کیے بغیر GCP سروسز کی تصدیق کر سکتے ہیں۔

تمام Google Cloud SDKs اور کلائنٹ لائبریریاں اس فارمیٹ کو سمجھتی ہیں۔ Python، Go، Java، اور Node.js سبھی کام کرتے ہیں۔

وفاقی شناختوں کو IAM کی اجازت کیسے دی جائے۔

ایک سروس اکاؤنٹ ٹوکن (جسے فیڈریشن کی شناخت بھی کہا جاتا ہے) STS سروس کے ذریعہ قابل اعتماد وسائل تک رسائی کی اجازت درکار ہوتی ہے۔ IAM رول کو شناختی پول پراپرٹی سے منسلک کریں۔

resource "google_project_iam_member" "secret_access" {
  for_each = toset(["production", "staging"])
  project  = "my-project"
  role     = "roles/secretmanager.secretAccessor"
  member   = "principalSet://iam.googleapis.com/projects/\({PROJECT_NUMBER}/locations/global/workloadIdentityPools/\){POOL_ID}/attribute.namespace/${each.value}"
}

یہ خفیہ مینیجر کو تمام تصدیق شدہ پوڈز تک رسائی فراہم کرتا ہے۔ production یا staging نام کی جگہ۔ کہ principalSet نحو انتساب کے ملاپ کی اجازت دیتا ہے۔ آپ اسے مخصوص سروس اکاؤنٹس تک بھی محدود کر سکتے ہیں۔

member = "principal://iam.googleapis.com/.../subject/system:serviceaccount:production:payment-processor"

اپنی ترتیبات کو کیسے چیک کریں۔

آپ ایک سادہ Python اسکرپٹ کا استعمال کرتے ہوئے اپنے سیٹ اپ کی تصدیق کر سکتے ہیں جس میں سیکرٹ مینیجر کے راز درج ہیں۔ یہ آن پریمیسس کلسٹر میں پوڈ کے اندر چلتا ہے۔

# list_secrets.py - running on-prem, accessing GCP Secret Manager
from google.cloud import secretmanager

def list_secrets(project_id: str):
    """
    List all secrets in a GCP project.

    No credentials are passed explicitly. The google-cloud-secret-manager
    library automatically:
    1. Reads GOOGLE_APPLICATION_CREDENTIALS env var (set by Kyverno)
    2. Loads the credential configuration JSON
    3. Reads the K8s ServiceAccount token from /run/secrets/...
    4. Exchanges it for a GCP access token via STS
    5. Uses that token to call the Secret Manager API
    """
    client = secretmanager.SecretManagerServiceClient()
    parent = f"projects/{project_id}"

    print(f"Secrets in {project_id}:")
    print("-" * 40)

    for secret in client.list_secrets(request={"parent": parent}):
        secret_name = secret.name.split("/")[-1]
        print(f"  - {secret_name}")

    print("-" * 40)
    print("Authentication: Workload Identity Federation")
    print("Credentials: None stored, token exchanged at runtime")

if __name__ == "__main__":
    list_secrets("my-project-id")

اسے لیبل والے پوڈ کے اندر چلائیں۔

$ kubectl exec -it my-app-xyz -- python list_secrets.py

Secrets in my-project-id:
----------------------------------------
  - database-password
  - api-key-stripe
  - oauth-client-secret
  - ml-model-api-key
----------------------------------------
Authentication: Workload Identity Federation
Credentials: None stored, token exchanged at runtime

سروس اکاؤنٹ کی کلید غائب ہے۔ کوئی حفاظتی راز نصب نہیں ہیں۔ ایک Kubernetes ServiceAccount ٹوکن جو رن ٹائم پر GCP اسناد کے لیے تبدیل کیا جاتا ہے۔

یہی طرز تمام GCP سروسز پر لاگو ہوتا ہے، بشمول سیکرٹ مینیجر، کلاؤڈ اسٹوریج، BigQuery، Pub/Sub، اور Vertex AI۔

آن پریمیسس ایپس کو کلاؤڈ GPUs سے کیسے جوڑیں۔

عام بہاؤ کے بارے میں سوچو۔ فراڈ کا پتہ لگانے کے لیے آن پریمیسس تکمیلی خدمات کو Vertex AI اینڈ پوائنٹ کو کال کرنا چاہیے۔ یہ ماڈل گوگل کلاؤڈ میں GPUs پر چلتا ہے۔ A100 مہینوں میں نہیں بلکہ منٹوں میں چل سکتا ہے۔ آپ کی درخواست کی منطق آن پریمیسس رہتی ہے (آپ نے پہلے ہی اس کے کمپیوٹ اخراجات کی ادائیگی کر دی ہے)۔

ایک بار جب IAM بائنڈنگ نافذ ہو جائے تو، اجازت شدہ نام کی جگہ میں کوئی بھی پوڈ Vertex AI کو کال کر سکتا ہے۔

# fraud_detector.py - running on-prem, calling cloud GPUs
from google.cloud import aiplatform

def check_fraud(transaction: dict) -> float:
    """
    Call a Vertex AI endpoint for fraud detection.

    The model runs on A100 GPUs in Google Cloud.
    This code runs on-prem in the datacenter.

    Authentication is automatic:
    1. Kyverno injected GOOGLE_APPLICATION_CREDENTIALS
    2. The aiplatform SDK reads the credential config
    3. K8s SA token is exchanged for GCP token via STS
    4. Request is authenticated to Vertex AI
    """
    endpoint = aiplatform.Endpoint(
        endpoint_name="projects/my-project/locations/us-central1/endpoints/fraud-model"
    )
    prediction = endpoint.predict(instances=[transaction])
    return prediction.predictions[0]["fraud_score"]


def generate_embeddings(texts: list[str]) -> list[list[float]]:
    """
    Generate text embeddings using a cloud-hosted model.

    Embedding models are GPU-intensive. Running them on-prem
    would require dedicated hardware. In the cloud, you pay per request.
    """
    from vertexai.language_models import TextEmbeddingModel

    model = TextEmbeddingModel.from_pretrained("text-embedding-004")
    embeddings = model.get_embeddings(texts)
    return [e.values for e in embeddings]

ڈویلپرز توثیق کے بارے میں بالکل نہیں سوچتے ہیں۔ آپ کی تعیناتی میں ایک لیبل شامل کرنا آپ کے آن پریمیسس پوڈز کو کال کرنے کی اجازت دیتا ہے:

• Vertex AI اینڈ پوائنٹ کلاؤڈ GPUs پر ML تخمینہ کے لیے

• کلاؤڈ اسٹوریج ماڈل نمونے اور تربیتی ڈیٹا کے لیے

• BigQuery فیچر اسٹوریج اور تجزیہ کے لیے

• شائع کریں/سبسکرائب کریں۔ ماحول کے درمیان واقعات کی سلسلہ بندی کے لیے

• خفیہ مینیجر API کیز اور کنفیگریشن کے لیے

یہ ایک ہائبرڈ پلیٹ فارم ہے جو حسب منشا کام کرتا ہے۔

CEL شرائط کے ساتھ GPU رسائی کو کیسے بڑھایا جائے۔

CEL حالات خاص طور پر طاقتور ہو جاتے ہیں جب آپ GPU کی رسائی کو مخصوص نام کی جگہوں تک محدود کرنا چاہتے ہیں۔ مثال کے طور پر، صرف ML سے متعلقہ نام کی جگہوں کو Vertex AI تک رسائی کی اجازت دینا:

attribute.namespace in ["ml-inference", "ml-training", "data-science"] &&
  attribute.service_account.startsWith("ml-")

آپ ہر نام کی جگہ کے لیے مختلف رسائی کی سطحیں بھی دے سکتے ہیں۔

# ML inference namespace gets prediction access
resource "google_project_iam_member" "ml_inference" {
  project = "my-project"
  role    = "roles/aiplatform.user"
  member  = "principalSet://iam.googleapis.com/.../attribute.namespace/ml-inference"
}

# Data science namespace gets full Vertex AI access (for experimentation)
resource "google_project_iam_member" "data_science" {
  project = "my-project"
  role    = "roles/aiplatform.admin"
  member  = "principalSet://iam.googleapis.com/.../attribute.namespace/data-science"
}

آن پریمیسس ایپلیکیشن ٹیموں کو GCP IAM کے بارے میں جاننے یا اس کی پرواہ کرنے کی ضرورت نہیں ہے۔ بس صحیح نام کی جگہ پر تعینات کریں، ایک لیبل شامل کریں، اور پلیٹ فارم باقی چیزوں کا خیال رکھتا ہے۔

حفاظتی خصوصیات کا موازنہ

ذیل میں تصدیق کے دو طریقوں کا ایک ساتھ بہ پہلو موازنہ ہے۔

جائیداد	سروس اکاؤنٹ کی کلید	ورک لوڈ آئیڈینٹی الائنس
کریڈینشل لائف ٹائم	جب تک دستی طور پر تبدیل نہ کیا جائے (عام طور پر کئی سال)	مختصر مدت (GCP ٹوکن کے لیے 1 گھنٹہ)
پھیلنے کا خطرہ	ہائی - جامد چابیاں کہیں بھی کاپی کی جا سکتی ہیں۔	کم — ٹوکن کی میعاد تیزی سے ختم ہو جاتی ہے۔
آڈٹ ٹریل	صرف سروس اکاؤنٹ کا نام	نام کی جگہ + سروس اکاؤنٹ کا نام
کلیدی انتظام اوور ہیڈ	بڑے پیمانے پر 600+ چابیاں	انتظام کرنے کے لیے کوئی چابیاں نہیں ہیں۔
سیکیورٹی پالیسی کا نفاذ	دستی/ٹرسٹ پر مبنی	CEL کے ذریعے GCP انفراسٹرکچر کے ذریعے نافذ کیا گیا۔
ڈویلپر کا تجربہ	چابیاں کاپی کریں، راز بنائیں، حجم بڑھائیں۔	اپنی تعیناتی میں 1 لیبل شامل کریں۔

ٹوکن کی قلیل مدتی نوعیت پر زور دینے کے قابل ہے۔ یہاں تک کہ بدترین صورت حال میں جہاں ٹوکن لیک ہو جائیں، ٹوکن ختم ہو جائیں گے۔ Kubernetes ServiceAccount ٹوکنز کی زندگی بھر کی ترتیب ہوتی ہے، اور STS کے ذریعے جاری کردہ GCP رسائی ٹوکن ایک گھنٹے کے لیے درست ہوتے ہیں۔ دوسری طرف، سروس اکاؤنٹ کی چابیاں اس وقت تک درست رہتی ہیں جب تک کہ کوئی واضح طور پر ان کی جگہ نہ لے لے (عام طور پر کئی سال)۔

کوڈ لے آؤٹ کے طور پر بنیادی ڈھانچہ مکمل کریں۔

GCP اور Kubernetes دونوں وسائل کو منظم کرنے کے لیے پورے حل کو Terraform میں کوڈ کیا گیا ہے۔

workload-identity-federation/
├── providers.tf      # Google + Kubernetes providers
├── locals.tf         # Configuration (namespaces, project ID, etc.)
├── gcp.tf            # Identity pool, provider, IAM bindings
└── kubernetes.tf     # ConfigMap with credential configuration

اکیلا terraform apply:

1. GCP میں کام کا بوجھ شناختی پول بنائیں

2. اپنے کلسٹر میں JWKS کا استعمال کرتے ہوئے OIDC فراہم کنندہ کو ترتیب دیں۔

3. اجازت شدہ نام کی جگہوں کے لیے IAM بائنڈنگ ترتیب دینا

4. اپنی اسناد کی ترتیب کے ساتھ ہر نام کی جگہ کے لیے ایک کنفیگ میپ بنائیں۔

Kyverno کی پالیسیوں کے ساتھ مل کر، آپ کو مکمل طور پر خودکار پائپ لائن ملتی ہے۔

New namespace added to allowed list
        │
        ▼
Terraform creates ConfigMap in that namespace
        │
        ▼
Developer deploys with label
        │
        ▼
Kyverno injects credentials automatically
        │
        ▼
Pod authenticates to GCP via OIDC
        │
        ▼
Application accesses GCP services

کوئی ٹکٹ نہیں ہے۔ کوئی بڑی درخواستیں نہیں ہیں۔ انتظام کرنے کے لئے کوئی راز نہیں ہیں.

vCluster کا استعمال کرتے ہوئے تصور کا ثبوت کیسے چلائیں۔

اگر آپ اسے GKE کے باہر عمل میں دیکھنا چاہتے ہیں، تو آپ vCluster کا استعمال کرتے ہوئے ایک ڈیمو ترتیب دے سکتے ہیں، ایک ورچوئل Kubernetes کلسٹر جو دوسرے Kubernetes کلسٹر کے اندر چل رہا ہے۔ اس سے ثابت ہوتا ہے کہ حل تمام کلسٹرز پر کام کرتا ہے۔ آپ Vind کا استعمال کرتے ہوئے Docker میں vCluster ترتیب دے سکتے ہیں۔

# vcluster.yaml
experimental:
  docker:
    nodes:
      - name: worker-1
      - name: worker-2
deploy:
  cni:
    flannel:
      enabled: true
controlPlane:
  distro:
    k8s:
      version: "v1.35.0"

[root@localhost #] vcluster create hybrid --driver docker -f vcluster.yaml
[root@localhost #] kubectl get nodes
hybrid-control-plane   Ready    control-plane   14d   v1.34.0   192.168.107.2           Debian GNU/Linux 12 (bookworm)   7.0.5-orbstack-00330-ge3df4e19b0a0-dirty   containerd://2.1.3
hybrid-worker          Ready              14d   v1.34.0   192.168.107.3           Debian GNU/Linux 12 (bookworm)   7.0.5-orbstack-00330-ge3df4e19b0a0-dirty   containerd://2.1.3
hybrid-worker2         Ready              14d   v1.34.0   192.168.107.4           Debian GNU/Linux 12 (bookworm)   7.0.5-orbstack-00330-ge3df4e19b0a0-dirty   containerd://2.1.3

vCluster کے اندر ایک سادہ ٹیسٹ تعیناتی تعینات کریں۔

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gcp-test
  labels:
    workload-identity-federation: "enabled"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gcp-test
  template:
    metadata:
      labels:
        app: gcp-test
    spec:
      containers:
        - name: test
          image: google/cloud-sdk:slim
          command: ["sleep", "infinity"]

اسے پوڈ میں چلائیں اور درج ذیل کو چیک کریں:

$ kubectl exec -it gcp-test-xxx -- bash

# Inside the pod:
\( gcloud auth login --cred-file=\)GOOGLE_APPLICATION_CREDENTIALS
Authenticated with external account credentials for: [principal://iam.googleapis.com/...]

$ gcloud secrets list --project=my-project
NAME                 CREATED
database-password    2024-01-15T10:30:00Z
api-key              2024-01-14T09:15:00Z

کوئی چابی نہیں ہے۔ کوئی حفاظتی راز نصب نہیں ہیں۔ شناختی فیڈریشن ڈیزائن کے مطابق کام کرتی ہے۔

عام مسائل اور حل

ایئر گیپڈ کلسٹرز کے لیے JWKS دریافت کو کیسے ہینڈل کریں۔

اگر آپ کے کلسٹر کا OIDC دریافت اختتامی نقطہ عوامی طور پر قابل رسائی نہیں ہے (زیادہ تر آن پریم کلسٹرز نہیں ہیں)، آپ کو لازمی طور پر JWKS کو برآمد کرنا اور اسے GCP پر اپ لوڈ کرنا چاہیے۔

kubectl get --raw /openid/v1/jwks > jwks.json

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

جاری کنندہ URL کی مماثلتوں کو کیسے حل کریں۔

کہ iss Kubernetes ٹوکن کے دعوے آپ کے OIDC فراہم کنندہ میں کنفیگر کردہ جاری کنندہ URL سے بالکل مماثل ہونے چاہئیں۔ اندرونی DNS استعمال کرنے والے کلسٹرز کے لیے:

issuer_uri = "https://kubernetes.default.svc.cluster.local"

اس URL تک GCP سے پہنچنے کی ضرورت نہیں ہے۔ JWKS فائل توثیق کی کلید فراہم کرتی ہے۔ تاہم، یہ بالکل وہی ہونا چاہیے جو ٹوکن میں ہے۔

ٹوکن ایکسچینج کی ناکامیوں کو کیسے ڈیبگ کریں۔

اگر توثیق ناکام ہو جاتی ہے تو غلطی کا پیغام پیچیدہ ہو سکتا ہے۔ عام وجوہات اور حل:

غلطی	ممکنہ وجہ	ٹھیک کریں
invalid_grant	جاری کنندہ کا URL مماثل ہے۔	چیک کریں iss جو کچھ ترتیب دیا گیا ہے اس کے لیے JWT سے چارج کریں۔ issuer_uri
audience mismatch	غلط audience اسناد کی ترتیب میں	Terraform کے ذریعے کریڈینشل کنفیگریشن JSON کو دوبارہ تخلیق کریں۔
CEL condition failed	نام کی جگہیں وائٹ لسٹ میں نہیں ہیں۔	نام کی جگہ شامل کریں۔ attribute_condition اور دوبارہ اپلائی کریں۔
JWKS validation failed	دستخط کرنے والی کلید کو گھمایا گیا ہے۔	JWKS کو دوبارہ برآمد کریں اور Terraform کنفیگریشن کو اپ ڈیٹ کریں۔

نتیجہ

اس ترتیب کو لاگو کرنے کے بعد، آن پریمیسس ورک بوجھ GCP سے بالکل اسی طرح تصدیق کرتے ہیں جیسے GKE ورک بوجھ، بغیر کسی طویل مدتی سند کے۔ سیکیورٹی ٹیم خوش ہے (آڈٹ کی کوئی کلید نہیں ہے)، ڈویلپر خوش ہیں (صرف لیبل شامل کریں)، اور پلیٹ فارم ٹیم خوش ہے (مزید اسناد کے انتظام کے ٹکٹ نہیں)۔

یہاں ہم نے اس ٹیوٹوریل میں کیا کیا ہے:

1. میں سمجھتا ہوں کہ سروس اکاؤنٹ کی کلیدیں پیمانے پر کیوں ناکام ہوتی ہیں اور اس سے سیکیورٹی کے خطرات لاحق ہوتے ہیں۔

2. اپنے کلسٹر میں ٹوکن جاری کرنے والے پر بھروسہ کرنے کے لیے، آپ نے GCP میں ایک ورک بوجھ شناختی پول اور OIDC فراہم کنندہ بنایا ہے۔

3. CEL شرائط کا استعمال کرتے ہوئے دانے دار نام کی جگہ کی سطح تک رسائی کی پالیسیاں نافذ کریں۔

4. Kyverno ClusterPolicy کا استعمال کرتے ہوئے پوڈز میں خودکار طور پر اسناد داخل کریں۔

5. IAM کے کردار کو ایک متحد شناختی وصف سے جوڑیں - کہیں بھی دیرپا کلید نہیں۔

6. آن پریمیسس پوڈ سے GCP APIs (سیکرٹ مینیجر، ورٹیکس AI) کو کال کرکے سیٹ اپ کی تصدیق کی۔

7. vCluster کا استعمال کرتے ہوئے، ہم نے یہ ظاہر کیا کہ ہمارا حل کسی بھی Kubernetes کلسٹر پر کام کرتا ہے۔

یہاں استعمال ہونے والی ٹیکنالوجی نئی نہیں ہے۔ OIDC ورژن 1.20 سے Kubernetes میں شامل ہے۔ ورک لوڈ آئیڈینٹی الائنس GCP میں کئی سالوں سے ہیں۔ Kyverno اور Terraform بالغ ٹولز ہیں۔ یہ ٹیوٹوریل ایک اختتام سے آخر تک حل فراہم کرتا ہے جسے ڈویلپر کم سے کم کوشش کے ساتھ اپنا سکتے ہیں۔

اگر آپ کی تنظیم کو غیر فعال کر دیا گیا ہے یا اسے سروس اکاؤنٹ کیز کو غیر فعال کرنے کی ضرورت ہے، تو یہ آگے کا راستہ ہے۔ آن پریمیسس اور کلاؤڈ کلسٹر آخر میں ایک دوسرے کے ساتھ محفوظ طریقے سے اسکیل کر سکتے ہیں جیسا کہ ارادہ ہے۔

مکمل نفاذ ایک Terraform ماڈیول کے طور پر فراہم کیا گیا ہے جس میں Kyverno پالیسیاں ہیں۔ github.com/shkatara/hybrid-platform-gcp-workload-identity-federation

اگر آپ کو یہ کارآمد لگتا ہے، تو آپ https://www.linkedin.com/in/shubhamkatara/، https://www.youtube.com/@kubesimplify، https://www.linkedin.com/company/kubesimplify/ پر میری پیروی کر سکتے ہیں۔