یہ ٹھیک ہے، رہائی کے بعد Hashicorp قونصل 1.5.0 مئی 2019 کے آغاز میں، قونصل میں آپ کوبرنیٹس میں مقامی طور پر چلنے والی ایپلیکیشنز اور سروسز کی اجازت دے سکتے ہیں۔
اس ٹیوٹوریل میں ہم مرحلہ وار بنائیں گے۔ سے Poc (تصور کا ثبوت، پی او سی) اس نئی خصوصیت کو ظاہر کرتا ہے۔ آپ سے توقع کی جاتی ہے کہ آپ Kubernetes اور Hashicorp کے قونصل کے بارے میں بنیادی معلومات رکھتے ہوں۔ جب کہ آپ کسی بھی کلاؤڈ پلیٹ فارم یا آن پریمیسس ماحول کو استعمال کر سکتے ہیں، اس ٹیوٹوریل میں ہم گوگل کا کلاؤڈ پلیٹ فارم استعمال کریں گے۔
کا جائزہ لیں
اگر ہم جاتے ہیں۔ اس کی اجازت کے طریقہ کار پر قونصل کی دستاویزات، ہمیں اس کے مقصد اور استعمال کے معاملے کا ایک فوری جائزہ، نیز کچھ تکنیکی تفصیلات اور منطق کا عمومی جائزہ ملے گا۔ میں آگے بڑھنے سے پہلے کم از کم ایک بار اسے پڑھنے کی انتہائی سفارش کرتا ہوں، جیسا کہ میں اب اس سب کی وضاحت اور چبا رہا ہوں۔
خاکہ 1: قونصل کی اجازت کے طریقہ کار کا سرکاری جائزہ
یقینی طور پر، وہاں مفید معلومات موجود ہیں، لیکن اس سب کو حقیقت میں استعمال کرنے کے بارے میں کوئی گائیڈ نہیں ہے۔ لہٰذا، کسی بھی سمجھدار شخص کی طرح، آپ رہنمائی کے لیے انٹرنیٹ کا سہارا لیتے ہیں۔ اور پھر... آپ ناکام ہو جاتے ہیں۔ یہ ہوتا ہے. آئیے اسے ٹھیک کرتے ہیں۔
اس سے پہلے کہ ہم اپنا POC بنانے کے لیے آگے بڑھیں، آئیے قونصل کے اجازت کے طریقوں (ڈائیگرام 1) کے جائزہ پر واپس جائیں اور اسے Kubernetes کے تناظر میں بہتر کریں۔
فن تعمیر
اس ٹیوٹوریل میں، ہم ایک علیحدہ مشین پر ایک قونصل سرور بنائیں گے جو قونصل کلائنٹ کے انسٹال کردہ Kubernetes کلسٹر کے ساتھ بات چیت کرے گا۔ اس کے بعد ہم پوڈ میں اپنی ڈمی ایپلیکیشن بنائیں گے اور اپنے قونصل کی کلید/ویلیو اسٹور سے پڑھنے کے لیے اپنا تشکیل شدہ اجازت کا طریقہ استعمال کریں گے۔
نیچے دی گئی خاکہ اس ٹیوٹوریل میں جو فن تعمیر ہم بنا رہے ہیں اس کے ساتھ ساتھ اجازت دینے کے طریقہ کار کے پیچھے منطق کی بھی تفصیل ہے، جس کی وضاحت بعد میں کی جائے گی۔
خاکہ 2: Kubernetes اجازت کے طریقہ کار کا جائزہ
ایک فوری نوٹ: اس کے کام کرنے کے لیے قونصل سرور کو کوبرنیٹس کلسٹر سے باہر رہنے کی ضرورت نہیں ہے۔ لیکن ہاں، وہ اس طرح اور اس طرح کر سکتا ہے۔
لہذا، قونصل کا جائزہ ڈایاگرام (ڈائیگرام 1) لے کر اور اس پر Kubernetes کا اطلاق کرتے ہوئے، ہمیں اوپر دیا گیا خاکہ ملتا ہے (ڈائیگرام 2)، اور یہاں کی منطق مندرجہ ذیل ہے:
ہر پوڈ کے ساتھ ایک سروس اکاؤنٹ منسلک ہوگا جس میں ایک JWT ٹوکن ہوگا جسے Kubernetes کے ذریعہ تیار کیا گیا ہے اور جانا جاتا ہے۔ یہ ٹوکن پہلے سے طے شدہ طور پر پوڈ میں بھی داخل کیا جاتا ہے۔
پوڈ کے اندر ہماری درخواست یا سروس ہمارے قونصل کلائنٹ کو لاگ ان کمانڈ شروع کرتی ہے۔ لاگ ان درخواست میں ہمارا ٹوکن اور نام بھی شامل ہوگا۔ خاص طور پر بنایا گیا ہے۔ اجازت کا طریقہ (Kubernetes قسم)۔ یہ مرحلہ نمبر 2 قونصل ڈایاگرام (اسکیم 1) کے مرحلہ 1 سے مساوی ہے۔
ہمارا قونصل کلائنٹ پھر اس درخواست کو ہمارے قونصل سرور کو بھیجے گا۔
جادو! یہ وہ جگہ ہے جہاں قونصل سرور درخواست کی صداقت کی تصدیق کرتا ہے، درخواست کی شناخت کے بارے میں معلومات اکٹھا کرتا ہے اور اس کا موازنہ پہلے سے طے شدہ قواعد سے کرتا ہے۔ اس کی وضاحت کے لیے ذیل میں ایک اور خاکہ ہے۔ یہ مرحلہ قونصل کے جائزہ خاکہ (ڈائیگرام 3) کے مراحل 4، 5 اور 1 سے مساوی ہے۔
ہمارا قونصل سرور درخواست گزار کی شناخت کے حوالے سے ہمارے مخصوص اجازت کے طریقہ کار کے قواعد (جس کی ہم نے وضاحت کی ہے) کے مطابق اجازتوں کے ساتھ ایک قونصل ٹوکن تیار کرتا ہے۔ اس کے بعد یہ اس ٹوکن کو واپس بھیج دے گا۔ یہ قونصل ڈایاگرام (ڈائیگرام 6) کے مرحلہ 1 سے مساوی ہے۔
ہمارا قونصل کلائنٹ ٹوکن کو درخواست کرنے والی درخواست یا سروس کو بھیجتا ہے۔
ہماری درخواست یا سروس اب اس قونصل ٹوکن کو ہمارے قونصل کے ڈیٹا کے ساتھ بات چیت کرنے کے لیے استعمال کر سکتی ہے، جیسا کہ ٹوکن کے استحقاق سے طے ہوتا ہے۔
جادو نازل ہوا!
آپ میں سے ان لوگوں کے لیے جو ٹوپی میں سے صرف خرگوش سے خوش نہیں ہیں اور یہ جاننا چاہتے ہیں کہ یہ کیسے کام کرتا ہے... میں آپ کو دکھاتا ہوں کہ کتنا گہرا ہے خرگوش کا بل'.
جیسا کہ پہلے ذکر کیا گیا ہے، ہمارا "جادو" مرحلہ (شکل 2: مرحلہ 4) وہ جگہ ہے جہاں قونصل سرور درخواست کی توثیق کرتا ہے، درخواست کے بارے میں معلومات اکٹھا کرتا ہے، اور اس کا موازنہ پہلے سے طے شدہ قواعد سے کرتا ہے۔ یہ مرحلہ قونصل کے جائزہ خاکہ (ڈائیگرام 3) کے مراحل 4، 5 اور 1 سے مساوی ہے۔ ذیل میں ایک خاکہ (ڈائیگرام 3) ہے، جس کا مقصد واضح طور پر دکھانا ہے کہ اصل میں کیا ہو رہا ہے ٹوپی کے نیچے Kubernetes کی اجازت کا مخصوص طریقہ۔
خاکہ 3: جادو نازل ہوا!
نقطہ آغاز کے طور پر، ہمارا قونصل کلائنٹ لاگ ان کی درخواست ہمارے قونصل سرور کو Kubernetes اکاؤنٹ ٹوکن اور اجازت کے طریقہ کار کے مخصوص مثال کے نام کے ساتھ بھیجتا ہے جو پہلے بنایا گیا تھا۔ یہ مرحلہ پچھلے سرکٹ کی وضاحت میں مرحلہ 3 کے مساوی ہے۔
اب قونصل سرور (یا لیڈر) کو موصول شدہ ٹوکن کی صداقت کی تصدیق کرنے کی ضرورت ہے۔ لہذا، یہ Kubernetes کلسٹر سے مشورہ کرے گا (بذریعہ قونصل کلائنٹ) اور، مناسب اجازتوں کے ساتھ، ہم یہ معلوم کریں گے کہ آیا ٹوکن اصلی ہے اور اس کا تعلق کس سے ہے۔
تصدیق شدہ درخواست پھر قونصل لیڈر کو واپس کر دی جاتی ہے، اور قونصل سرور لاگ ان درخواست (اور Kubernetes قسم) سے مخصوص نام کے ساتھ اجازت کے طریقہ کار کی مثال دیکھتا ہے۔
قونصل لیڈر مخصوص اجازت کے طریقہ کار کی مثال (اگر مل جائے) کی شناخت کرتا ہے اور اس کے ساتھ منسلک پابند قوانین کے سیٹ کو پڑھتا ہے۔ پھر یہ ان اصولوں کو پڑھتا ہے اور تصدیق شدہ شناختی صفات سے ان کا موازنہ کرتا ہے۔
TA-dah! آئیے پچھلے سرکٹ کی وضاحت میں مرحلہ 5 پر چلتے ہیں۔
ایک باقاعدہ ورچوئل مشین پر قونصل سرور چلائیں۔
اب سے، میں زیادہ تر ہدایات دیتا رہوں گا کہ اس POC کو کیسے بنایا جائے، اکثر بلٹ پوائنٹس میں، مکمل جملے کی وضاحت کے بغیر۔ اس کے علاوہ، جیسا کہ پہلے بتایا گیا ہے، میں تمام انفراسٹرکچر بنانے کے لیے GCP استعمال کروں گا، لیکن آپ وہی انفراسٹرکچر کہیں اور بھی بنا سکتے ہیں۔
ورچوئل مشین شروع کریں (مثال/سرور)۔
فائر وال کے لیے ایک اصول بنائیں (AWS میں سیکیورٹی گروپ):
میں اصول اور نیٹ ورک ٹیگ دونوں کو ایک ہی مشین کا نام تفویض کرنا چاہتا ہوں، اس معاملے میں "skywiz-consul-server-poc"۔
اپنے مقامی کمپیوٹر کا IP پتہ تلاش کریں اور اسے سورس IP پتوں کی فہرست میں شامل کریں تاکہ ہم صارف انٹرفیس (UI) تک رسائی حاصل کر سکیں۔
UI کے لیے پورٹ 8500 کھولیں۔ بنائیں پر کلک کریں۔ ہم جلد ہی اس فائر وال کو دوبارہ تبدیل کر دیں گے [لنک].
مثال میں فائر وال کا اصول شامل کریں۔ قونصل سرور پر VM ڈیش بورڈ پر واپس جائیں اور نیٹ ورک ٹیگز فیلڈ میں "skywiz-consul-server-poc" شامل کریں۔ محفوظ کریں پر کلک کریں۔
ورچوئل مشین پر قونصل انسٹال کریں، یہاں چیک کریں۔ یاد رکھیں آپ کو قونصل ورژن ≥ 1.5 درکار ہے [لنک]
آئیے ایک سنگل نوڈ Consul بنائیں - کنفیگریشن مندرجہ ذیل ہے۔
groupadd --system consul
useradd -s /sbin/nologin --system -g consul consul
mkdir -p /var/lib/consul
chown -R consul:consul /var/lib/consul
chmod -R 775 /var/lib/consul
mkdir /etc/consul.d
chown -R consul:consul /etc/consul.d
قونصل کو انسٹال کرنے اور 3 نوڈس کا کلسٹر قائم کرنے کے بارے میں مزید تفصیلی گائیڈ کے لیے، دیکھیں یہاں.
مندرجہ ذیل کے طور پر /etc/consul.d/agent.json فائل بنائیں [لنک]:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d
آپ کو آؤٹ پٹ کا ایک گروپ دیکھنا چاہئے اور "... ACLs کے ذریعہ بلاک کردہ اپ ڈیٹ" کے ساتھ ختم ہونا چاہئے۔
قونصل سرور کا بیرونی IP پتہ تلاش کریں اور پورٹ 8500 پر اس IP ایڈریس کے ساتھ ایک براؤزر کھولیں۔ یقینی بنائیں کہ UI کھلتا ہے۔
کلید/قدر کا جوڑا شامل کرنے کی کوشش کریں۔ کوئی غلطی ضرور ہو گی۔ اس کی وجہ یہ ہے کہ ہم نے قونصل سرور کو ACL کے ساتھ لوڈ کیا اور تمام قواعد کو غیر فعال کر دیا۔
قونصل سرور پر اپنے شیل پر واپس جائیں اور عمل کو پس منظر میں شروع کریں یا اسے چلانے کے لیے کسی اور طریقے سے شروع کریں اور درج ذیل درج کریں:
consul acl bootstrap
"SecretID" قدر تلاش کریں اور UI پر واپس جائیں۔ ACL ٹیب میں، اس ٹوکن کی خفیہ ID درج کریں جسے آپ نے ابھی کاپی کیا ہے۔ سیکریٹ آئی ڈی کو کہیں اور کاپی کریں، ہمیں بعد میں اس کی ضرورت ہوگی۔
اب ایک کلید/قدر کا جوڑا شامل کریں۔ اس POC کے لیے، درج ذیل شامل کریں: کلید: "custom-ns/test_key"، قدر: "میں custom-ns فولڈر میں ہوں!"
ڈیمونسیٹ کے بطور قونصل کلائنٹ کے ساتھ ہماری درخواست کے لیے Kubernetes کلسٹر کا آغاز کرنا
K8s (Kubernetes) کلسٹر بنائیں۔ ہم اسے تیزی سے رسائی کے لیے سرور کے طور پر اسی زون میں بنائیں گے، اور اس لیے ہم اندرونی IP پتوں سے آسانی سے جڑنے کے لیے اسی ذیلی نیٹ کا استعمال کر سکتے ہیں۔ ہم اسے "skywiz-app-with-consul-client-poc" کہیں گے۔
ضمنی نوٹ کے طور پر، یہاں ایک اچھا ٹیوٹوریل ہے جو مجھے قونصل کنیکٹ کے ساتھ POC قونصل کلسٹر قائم کرتے وقت ملا۔
ہم توسیع شدہ اقدار کی فائل کے ساتھ Hashicorp ہیلم چارٹ بھی استعمال کریں گے۔
درج ذیل ویلیو فائل کا استعمال کریں (نوٹ میں نے سب سے زیادہ غیر فعال کر دیا ہے):
### poc-helm-consul-values.yaml
global:
enabled: false
image: "consul:latest"
# Expose the Consul UI through this LoadBalancer
ui:
enabled: false
# Allow Consul to inject the Connect proxy into Kubernetes containers
connectInject:
enabled: false
# Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect.
client:
enabled: true
join: ["<PRIVATE_IP_CONSUL_SERVER>"]
extraConfig: |
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}
# Minimal Consul configuration. Not suitable for production.
server:
enabled: false
# Sync Kubernetes and Consul services
syncCatalog:
enabled: false
ہیلم چارٹ کا اطلاق کریں:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc
جب یہ چلانے کی کوشش کرتا ہے، تو اسے قونصل سرور کے لیے اجازت کی ضرورت ہوگی، تو آئیے انہیں شامل کرتے ہیں۔
کلسٹر ڈیش بورڈ پر موجود "Pod ایڈریس رینج" کو نوٹ کریں اور ہمارے "skywiz-consul-server-poc" فائر وال اصول پر واپس جائیں۔
پوڈ کے لیے ایڈریس رینج کو IP پتوں کی فہرست میں شامل کریں اور 8301 اور 8300 کو کھولیں۔
قونصل UI پر جائیں اور چند منٹوں کے بعد آپ دیکھیں گے کہ ہمارا کلسٹر نوڈس ٹیب میں ظاہر ہوتا ہے۔
کوبرنیٹس کے ساتھ قونصل کو انٹیگریٹ کرکے اجازت دینے کا طریقہ ترتیب دینا
قونصل سرور شیل پر واپس جائیں اور وہ ٹوکن برآمد کریں جسے آپ نے پہلے محفوظ کیا تھا:
export CONSUL_HTTP_TOKEN=<SecretID>
auth طریقہ کی مثال بنانے کے لیے ہمیں اپنے Kubernetes کلسٹر سے معلومات درکار ہوں گی۔
kubernetes-میزبان
kubectl get endpoints | grep kubernetes
kubernetes-service-account-jwt
kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "- name:"
kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:
ٹوکن بیس 64 کو انکوڈ کیا گیا ہے، لہذا اپنے پسندیدہ ٹول کا استعمال کرتے ہوئے اسے ڈکرپٹ کریں [لنک]
kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:
"ca.crt" سرٹیفکیٹ لیں (بیس 64 ڈی کوڈنگ کے بعد) اور اسے "ca.crt" فائل میں لکھیں۔
اب پلیس ہولڈرز کو ان اقدار سے بدلتے ہوئے جو آپ کو ابھی موصول ہوئی ہیں، auth کا طریقہ شروع کریں۔
consul acl auth-method create
-type "kubernetes"
-name "auth-method-skywiz-consul-poc"
-description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc"
-kubernetes-host "<k8s_endpoint_retrieved earlier>"
[email protected]
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"
اس کے بعد ہمیں ایک اصول بنانے اور اسے نئے کردار کے ساتھ منسلک کرنے کی ضرورت ہے۔ اس حصے کے لیے آپ Consul UI استعمال کر سکتے ہیں، لیکن ہم کمانڈ لائن استعمال کریں گے۔
پھر کنفیگ میپ بنانے کے لیے درج ذیل بلٹ ان کمانڈ کا استعمال کریں [لنک] براہ کرم نوٹ کریں کہ ہم اپنی سروس کے نام کا حوالہ دے رہے ہیں، اگر ضروری ہو تو اسے تبدیل کریں۔
اسی ٹاپ لیول کلید کے ساتھ کئی اور کلیدی فولڈرز بنائیں (یعنی /sample_key) اور آپ کی پسند کی قیمت۔ نئے کلیدی راستوں کے لیے مناسب پالیسیاں اور کردار بنائیں۔ ہم بعد میں بائنڈنگ کریں گے۔
حسب ضرورت نام کی جگہ ٹیسٹ:
آئیے اپنا نام کی جگہ بنائیں:
kubectl create namespace custom-ns
آئیے اپنے نئے نام کی جگہ میں ایک پوڈ بنائیں۔ پوڈ کے لیے ترتیب لکھیں۔
آپ بیس 64 "ویلیو" کو ڈی کوڈ کر سکتے ہیں اور دیکھ سکتے ہیں کہ یہ UI میں custom-ns/test_key میں موجود قدر سے میل کھاتا ہے۔ اگر آپ نے اوپر اس ٹیوٹوریل میں وہی قدر استعمال کی ہے تو، آپ کی انکوڈ شدہ قدر IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi ہوگی۔
یوزر سروس اکاؤنٹ ٹیسٹ:
درج ذیل کمانڈ کا استعمال کرتے ہوئے اپنی مرضی کے مطابق سروس اکاؤنٹ بنائیں [لنک].
اجازت نہیں دی گئی. اوہ، ہم مناسب اجازتوں کے ساتھ پابند کرنے والے ایک نئے قواعد شامل کرنا بھول گئے، آئیے اب کرتے ہیں۔
اوپر پچھلے مراحل کو دہرائیں:
a) سابقہ "custom-sa/" کے لیے ایک جیسی پالیسی بنائیں۔
ب) ایک کردار بنائیں، اسے "کسٹم-سا-رول" کہیں۔
c) پالیسی کو کردار سے جوڑیں۔
ایک رول بائنڈنگ بنائیں (صرف cli/api سے ممکن ہے)۔ سلیکٹر پرچم کے مختلف معنی نوٹ کریں۔
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'
"poc-ubuntu-custom-sa" کنٹینر سے دوبارہ لاگ ان کریں۔ کامیابی!
حسب ضرورت-sa/ کلیدی راستے تک ہماری رسائی کو چیک کریں۔
آپ یہ بھی یقینی بنا سکتے ہیں کہ یہ ٹوکن "custom-ns/" میں kv تک رسائی نہیں دیتا ہے۔ "custom-sa" کو سابقہ "custom-ns" کے ساتھ تبدیل کرنے کے بعد صرف مذکورہ کمانڈ کو دہرائیں۔
اجازت نہیں دی گئی.
اوورلے مثال:
یہ بات قابل غور ہے کہ ان حقوق کے ساتھ ٹوکن میں تمام قواعد کے پابند نقشے شامل کیے جائیں گے۔
ہمارا کنٹینر "poc-ubuntu-custom-sa" پہلے سے طے شدہ نام کی جگہ میں ہے - تو آئیے اسے ایک مختلف قاعدے کے پابند کرنے کے لیے استعمال کریں۔
پچھلے اقدامات کو دہرائیں:
a) "ڈیفالٹ/" کلیدی سابقہ کے لیے ایک جیسی پالیسی بنائیں۔
ب) ایک کردار بنائیں، اسے "default-ns-role" کا نام دیں
c) پالیسی کو کردار سے جوڑیں۔
ایک اصول بائنڈنگ بنائیں (صرف cli/api سے ممکن ہے)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'
ہمارے "poc-ubuntu-custom-sa" کنٹینر پر واپس جائیں اور "default/" kv پاتھ تک رسائی حاصل کرنے کی کوشش کریں۔
اجازت نہیں دی گئی.
آپ ACL > ٹوکنز کے تحت UI میں ہر ٹوکن کے لیے مخصوص اسناد دیکھ سکتے ہیں۔ جیسا کہ آپ دیکھ سکتے ہیں، ہمارے موجودہ ٹوکن کے ساتھ صرف ایک "کسٹم-سا-رول" منسلک ہے۔ جو ٹوکن ہم فی الحال استعمال کر رہے ہیں وہ اس وقت تیار ہوا جب ہم نے لاگ ان کیا تھا اور اس وقت صرف ایک اصول کی پابندی تھی جو مماثل تھی۔ ہمیں دوبارہ لاگ ان کرنے اور نیا ٹوکن استعمال کرنے کی ضرورت ہے۔
یقینی بنائیں کہ آپ "custom-sa/" اور "default/" kv دونوں راستوں سے پڑھ سکتے ہیں۔
کامیابی!
اس کی وجہ یہ ہے کہ ہمارا "poc-ubuntu-custom-sa" "custom-sa" اور "default-ns" اصول کی پابندیوں سے میل کھاتا ہے۔
حاصل يہ ہوا
TTL ٹوکن mgmt؟
اس تحریر کے وقت، اجازت دینے کے اس طریقہ سے تیار کردہ ٹوکنز کے لیے TTL کا تعین کرنے کا کوئی مربوط طریقہ نہیں ہے۔ قونصل کی اجازت کی محفوظ آٹومیشن فراہم کرنے کا یہ ایک بہترین موقع ہوگا۔
TTL کے ساتھ دستی طور پر ٹوکن بنانے کا آپشن موجود ہے: