🥇হাশিকর্প কনসালের কুবারনেটস অনুমোদনের ভূমিকা

এটা ঠিক, মুক্তির পরে Hashicorp কনসাল 1.5.0 মে 2019 এর শুরুতে, কনসালে আপনি কুবারনেটে স্থানীয়ভাবে চলমান অ্যাপ্লিকেশন এবং পরিষেবাগুলি অনুমোদন করতে পারেন।

এই টিউটোরিয়ালে আমরা ধাপে ধাপে তৈরি করব POC (ধারণার প্রমাণ, PoC) এই নতুন বৈশিষ্ট্যটি প্রদর্শন করছে। আপনার কাছে Kubernetes এবং Hashicorp-এর কনসাল সম্পর্কে প্রাথমিক জ্ঞান থাকবে বলে আশা করা হচ্ছে। আপনি যেকোনো ক্লাউড প্ল্যাটফর্ম বা অন-প্রিমিসেস পরিবেশ ব্যবহার করতে পারেন, এই টিউটোরিয়ালে আমরা Google-এর ক্লাউড প্ল্যাটফর্ম ব্যবহার করব।

ওভারভিউ

আমরা যদি যাই তার অনুমোদন পদ্ধতি কনসাল ডকুমেন্টেশন, আমরা এর উদ্দেশ্য এবং ব্যবহারের ক্ষেত্রে একটি দ্রুত ওভারভিউ, সেইসাথে কিছু প্রযুক্তিগত বিবরণ এবং যুক্তির একটি সাধারণ ওভারভিউ পাব। আমি অগ্রসর হওয়ার আগে অন্তত একবার এটি পড়ার সুপারিশ করছি, কারণ আমি এখন এটি সব ব্যাখ্যা করব এবং চিবিয়ে দেব।

চিত্র 1: কনসাল অনুমোদন পদ্ধতির অফিসিয়াল ওভারভিউ

এর মধ্যে তাকান একটি নির্দিষ্ট Kubernetes অনুমোদন পদ্ধতির জন্য ডকুমেন্টেশন.

অবশ্যই, সেখানে দরকারী তথ্য আছে, কিন্তু আসলে এটি কীভাবে ব্যবহার করবেন তার কোনও নির্দেশিকা নেই৷ সুতরাং, যে কোনও বিবেকবান ব্যক্তির মতো, আপনি গাইডেন্সের জন্য ইন্টারনেট ঘেঁটেছেন। এবং তারপর... আপনি ব্যর্থ. এটা ঘটে। এর এটা ঠিক করা যাক.

আমাদের POC তৈরি করার আগে, আসুন কনসালের অনুমোদন পদ্ধতির ওভারভিউতে ফিরে যাই (ডায়াগ্রাম 1) এবং এটিকে কুবারনেটসের প্রসঙ্গে পরিমার্জন করি।

স্থাপত্য

এই টিউটোরিয়ালে, আমরা একটি পৃথক মেশিনে একটি কনসাল সার্ভার তৈরি করব যা কনসাল ক্লায়েন্ট ইনস্টল করা একটি কুবারনেটস ক্লাস্টারের সাথে যোগাযোগ করবে। তারপরে আমরা পডে আমাদের ডামি অ্যাপ্লিকেশন তৈরি করব এবং আমাদের কনসাল কী/মান স্টোর থেকে পড়ার জন্য আমাদের কনফিগার করা অনুমোদন পদ্ধতি ব্যবহার করব।

নীচের চিত্রটি এই টিউটোরিয়ালে আমরা যে আর্কিটেকচার তৈরি করছি তার বিবরণ দেয়, সেইসাথে অনুমোদন পদ্ধতির পিছনে যুক্তি, যা পরে ব্যাখ্যা করা হবে।

চিত্র 2: Kubernetes অনুমোদন পদ্ধতি ওভারভিউ

একটি দ্রুত নোট: এটি কাজ করার জন্য কনসাল সার্ভারের কুবারনেটস ক্লাস্টারের বাইরে থাকার প্রয়োজন নেই। তবে হ্যাঁ, তিনি এইভাবে এবং এটি করতে পারেন।

সুতরাং, কনসাল ওভারভিউ ডায়াগ্রাম (ডায়াগ্রাম 1) গ্রহণ করে এবং এটিতে কুবারনেটস প্রয়োগ করে, আমরা উপরের চিত্রটি পেয়েছি (ডায়াগ্রাম 2), এবং এখানে যুক্তিটি নিম্নরূপ:

প্রতিটি পডের সাথে একটি পরিষেবা অ্যাকাউন্ট সংযুক্ত থাকবে যাতে একটি JWT টোকেন জেনারেট করা হয় এবং Kubernetes দ্বারা পরিচিত হয়। এই টোকেনটিও ডিফল্টরূপে পডে ঢোকানো হয়।
পডের ভিতরে আমাদের আবেদন বা পরিষেবা আমাদের কনসাল ক্লায়েন্টের কাছে একটি লগইন কমান্ড শুরু করে। লগইন অনুরোধে আমাদের টোকেন এবং নামও অন্তর্ভুক্ত থাকবে বিশেষভাবে তৈরি অনুমোদন পদ্ধতি (Kubernetes প্রকার)। এই ধাপ #2 কনসাল ডায়াগ্রামের (স্কিম 1) ধাপ 1 এর সাথে মিলে যায়।
আমাদের কনসাল ক্লায়েন্ট তারপর এই অনুরোধটি আমাদের কনসাল সার্ভারে ফরোয়ার্ড করবে।
ম্যাজিক ! এখানেই কনসাল সার্ভার অনুরোধের সত্যতা যাচাই করে, অনুরোধের পরিচয় সম্পর্কে তথ্য সংগ্রহ করে এবং এটিকে পূর্বনির্ধারিত যেকোনো নিয়মের সাথে তুলনা করে। এটি বোঝানোর জন্য নীচে আরেকটি চিত্র দেওয়া হল। এই ধাপটি কনসাল ওভারভিউ ডায়াগ্রামের (ডায়াগ্রাম 3) ধাপ 4, 5 এবং 1 এর সাথে মিলে যায়।
আমাদের কনসাল সার্ভার অনুরোধকারীর পরিচয় সম্পর্কে আমাদের নির্দিষ্ট অনুমোদন পদ্ধতির নিয়ম (যা আমরা সংজ্ঞায়িত করেছি) অনুযায়ী অনুমতি সহ একটি কনসাল টোকেন তৈরি করে। এটি তারপর সেই টোকেনটি ফেরত পাঠাবে। এটি কনসাল ডায়াগ্রামের (ডায়াগ্রাম 6) ধাপ 1 এর সাথে মিলে যায়।
আমাদের কনসাল ক্লায়েন্ট অনুরোধ করা আবেদন বা পরিষেবাতে টোকেন ফরোয়ার্ড করে।

আমাদের আবেদন বা পরিষেবা এখন এই কনসাল টোকেন ব্যবহার করতে পারে আমাদের কনসাল ডেটার সাথে যোগাযোগ করতে, যেমন টোকেনের বিশেষাধিকার দ্বারা নির্ধারিত হয়।

জাদু প্রকাশ!

আপনাদের মধ্যে যারা টুপি থেকে শুধু একটি খরগোশ নিয়ে খুশি নন এবং এটি কীভাবে কাজ করে তা জানতে চান... আমাকে "আপনাকে দেখান কত গভীর খরগোশের গর্ত».

আগেই উল্লেখ করা হয়েছে, আমাদের "জাদু" পদক্ষেপ (চিত্র 2: ধাপ 4) হল যেখানে কনসাল সার্ভার অনুরোধটিকে প্রমাণীকরণ করে, অনুরোধ সম্পর্কে তথ্য সংগ্রহ করে এবং এটিকে পূর্বনির্ধারিত যেকোনো নিয়মের সাথে তুলনা করে। এই ধাপটি কনসাল ওভারভিউ ডায়াগ্রামের (ডায়াগ্রাম 3) ধাপ 4, 5 এবং 1 এর সাথে মিলে যায়। নীচে একটি চিত্র (ডায়াগ্রাম 3), যার উদ্দেশ্য হল স্পষ্টভাবে দেখানো যে আসলে কি ঘটছে ফণা অধীনে নির্দিষ্ট Kubernetes অনুমোদন পদ্ধতি।

চিত্র 3: জাদু প্রকাশ!

একটি সূচনা বিন্দু হিসাবে, আমাদের কনসাল ক্লায়েন্ট আমাদের কনসাল সার্ভারে লগইন অনুরোধটি কুবারনেটস অ্যাকাউন্ট টোকেন এবং আগে তৈরি করা অনুমোদন পদ্ধতির নির্দিষ্ট উদাহরণের সাথে ফরোয়ার্ড করে। এই ধাপটি পূর্ববর্তী সার্কিট ব্যাখ্যায় ধাপ 3 এর সাথে মিলে যায়।
এখন কনসাল সার্ভারকে (বা নেতা) প্রাপ্ত টোকেনের সত্যতা যাচাই করতে হবে। অতএব, এটি কুবারনেটস ক্লাস্টারের সাথে পরামর্শ করবে (কনসাল ক্লায়েন্টের মাধ্যমে) এবং উপযুক্ত অনুমতি সহ, আমরা খুঁজে বের করব যে টোকেনটি আসল কিনা এবং এটি কার।
যাচাইকৃত অনুরোধটি কনসাল লিডারের কাছে ফেরত দেওয়া হয় এবং কনসাল সার্ভার লগইন অনুরোধ (এবং কুবারনেটস প্রকার) থেকে নির্দিষ্ট নাম সহ অনুমোদন পদ্ধতির উদাহরণটি সন্ধান করে।
কনসাল লিডার নির্দিষ্ট অনুমোদন পদ্ধতির উদাহরণ (যদি পাওয়া যায়) নির্ধারণ করে এবং এর সাথে সংযুক্ত বাঁধাই নিয়মের সেট পড়ে। এটি তারপর এই নিয়মগুলি পড়ে এবং যাচাইকৃত পরিচয় বৈশিষ্ট্যগুলির সাথে তাদের তুলনা করে।
টিএ-দাহ! আগের সার্কিট ব্যাখ্যার ধাপ 5 এ চলুন।

নিয়মিত ভার্চুয়াল মেশিনে কনসাল সার্ভার চালান

এখন থেকে, আমি বেশিরভাগই এই POC তৈরি করার নির্দেশনা দেব, প্রায়শই বুলেট পয়েন্টে, সম্পূর্ণ বাক্যের ব্যাখ্যা ছাড়াই। এছাড়াও, আগে উল্লেখ করা হয়েছে, আমি সমস্ত অবকাঠামো তৈরি করতে GCP ব্যবহার করব, তবে আপনি অন্য কোথাও একই অবকাঠামো তৈরি করতে পারেন।

ভার্চুয়াল মেশিন শুরু করুন (উদাহরণ/সার্ভার)।

ফায়ারওয়ালের জন্য একটি নিয়ম তৈরি করুন (AWS-এ নিরাপত্তা গোষ্ঠী):
আমি নিয়ম এবং নেটওয়ার্ক ট্যাগ উভয়ের জন্য একই মেশিনের নাম বরাদ্দ করতে চাই, এই ক্ষেত্রে "skywiz-consul-server-poc"।
আপনার স্থানীয় কম্পিউটারের আইপি ঠিকানা খুঁজুন এবং এটিকে উৎস আইপি ঠিকানার তালিকায় যোগ করুন যাতে আমরা ইউজার ইন্টারফেস (UI) অ্যাক্সেস করতে পারি।
UI এর জন্য পোর্ট 8500 খুলুন। তৈরি করুন ক্লিক করুন। আমরা শীঘ্রই আবার এই ফায়ারওয়াল পরিবর্তন করব [লিংক].
উদাহরণে একটি ফায়ারওয়াল নিয়ম যোগ করুন। কনসাল সার্ভারে ভিএম ড্যাশবোর্ডে ফিরে যান এবং নেটওয়ার্ক ট্যাগ ফিল্ডে "skywiz-consul-server-poc" যোগ করুন। Save এ ক্লিক করুন।

একটি ভার্চুয়াল মেশিনে কনসাল ইনস্টল করুন, এখানে চেক করুন। মনে রাখবেন আপনার কনসাল সংস্করণ প্রয়োজন ≥ 1.5 [লিংক]
আসুন একটি একক নোড কনসাল তৈরি করি - কনফিগারেশনটি নিম্নরূপ।

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 [লিংক]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

আমাদের কনসাল সার্ভার শুরু করুন:

consul agent 
-server 
-ui 
-client 0.0.0.0 
-data-dir=/var/lib/consul 
-bootstrap-expect=1 
-config-dir=/etc/consul.d

আপনার একগুচ্ছ আউটপুট দেখতে হবে এবং শেষ হবে "... ACLs দ্বারা অবরুদ্ধ আপডেট।"
কনসাল সার্ভারের বাহ্যিক আইপি ঠিকানা খুঁজুন এবং পোর্ট 8500-এ এই আইপি ঠিকানা সহ একটি ব্রাউজার খুলুন। নিশ্চিত করুন যে UI খোলে।
একটি কী/মান জোড়া যোগ করার চেষ্টা করুন। একটি ভুল হতে হবে. কারণ আমরা কনসাল সার্ভার একটি ACL দিয়ে লোড করেছি এবং সমস্ত নিয়ম অক্ষম করেছি৷
কনসাল সার্ভারে আপনার শেলে ফিরে যান এবং এটি চালু করার জন্য পটভূমিতে বা অন্য কোনও উপায়ে প্রক্রিয়াটি শুরু করুন এবং নিম্নলিখিতটি লিখুন:

consul acl bootstrap

"সিক্রেটআইডি" মান খুঁজুন এবং UI এ ফিরে যান। ACL ট্যাবে, আপনি যে টোকেনটি কপি করেছেন তার গোপন ID লিখুন। অন্য কোথাও SecretID কপি করুন, আমাদের এটি পরে প্রয়োজন হবে।
এখন একটি কী/মান জোড়া যোগ করুন। এই POC-এর জন্য, নিম্নলিখিত যোগ করুন: কী: “custom-ns/test_key”, মান: “আমি কাস্টম-এনএস ফোল্ডারে আছি!”

ডেমনসেট হিসাবে কনসাল ক্লায়েন্টের সাথে আমাদের আবেদনের জন্য একটি Kubernetes ক্লাস্টার চালু করা হচ্ছে

একটি K8s (Kubernetes) ক্লাস্টার তৈরি করুন। দ্রুত অ্যাক্সেসের জন্য আমরা এটিকে সার্ভারের মতো একই জোনে তৈরি করব, এবং তাই আমরা অভ্যন্তরীণ আইপি ঠিকানাগুলির সাথে সহজেই সংযোগ করতে একই সাবনেট ব্যবহার করতে পারি। আমরা একে বলব "skywiz-app-with-consul-client-poc"।

একটি সাইড নোট হিসাবে, কনসাল কানেক্টের সাথে একটি POC কনসাল ক্লাস্টার সেট আপ করার সময় আমি এখানে একটি ভাল টিউটোরিয়াল পেয়েছি।
আমরা একটি বর্ধিত মান ফাইল সহ Hashicorp হেলম চার্ট ব্যবহার করব।
হেলম ইনস্টল এবং কনফিগার করুন। কনফিগারেশন ধাপ:

kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding 
   --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --service-account=tiller
./helm update

হেলম চার্ট: https://www.consul.io/docs/platform/k8s/helm.html
নিম্নলিখিত মান ফাইলটি ব্যবহার করুন (মনে রাখবেন আমি বেশিরভাগ অক্ষম করেছি):

### 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

যখন এটি চালানোর চেষ্টা করে, তখন কনসাল সার্ভারের জন্য অনুমতির প্রয়োজন হবে, তাই আসুন সেগুলি যোগ করি।
ক্লাস্টার ড্যাশবোর্ডে অবস্থিত "পড অ্যাড্রেস রেঞ্জ" নোট করুন এবং আমাদের "স্কাইউইজ-কনসাল-সার্ভার-পিওসি" ফায়ারওয়াল নিয়মে ফিরে যান।
আইপি ঠিকানা এবং পোর্ট 8301 এবং 8300 খোলার তালিকায় পডের ঠিকানা পরিসর যোগ করুন।

Consul UI-এ যান এবং কয়েক মিনিট পর আপনি নোড ট্যাবে আমাদের ক্লাস্টার দেখতে পাবেন।

কুবারনেটসের সাথে কনসালকে একীভূত করে একটি অনুমোদন পদ্ধতি কনফিগার করা

কনসাল সার্ভার শেলে ফিরে যান এবং আপনার আগে সংরক্ষিত টোকেনটি রপ্তানি করুন:

export CONSUL_HTTP_TOKEN=<SecretID>

প্রমাণীকরণ পদ্ধতির একটি উদাহরণ তৈরি করতে আমাদের 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:

টোকেনটি base64 এনকোডেড, তাই আপনার প্রিয় টুল ব্যবহার করে এটি ডিক্রিপ্ট করুন [লিংক]
kubernetes-ca-cert

kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:

"ca.crt" সার্টিফিকেট নিন (বেস64 ডিকোডিং এর পরে) এবং এটি "ca.crt" ফাইলে লিখুন।
এখন আপনি এইমাত্র প্রাপ্ত মানগুলির সাথে স্থানধারকগুলিকে প্রতিস্থাপন করে প্রমাণীকরণ পদ্ধতিটি চালু করুন৷

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 ব্যবহার করতে পারেন, তবে আমরা কমান্ড লাইন ব্যবহার করব।
একটি নিয়ম লিখুন

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

নিয়ম প্রয়োগ করুন

consul acl policy create 
-name kv-custom-ns-policy 
-description "This is an example policy for kv at custom-ns/" 
-rules @kv-custom-ns-policy.hcl

আউটপুট থেকে আপনি যে নিয়মটি তৈরি করেছেন তার আইডি খুঁজুন।
একটি নতুন নিয়ম দিয়ে একটি ভূমিকা তৈরি করুন।

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id <policy_id>

এখন আমরা প্রমাণ পদ্ধতি উদাহরণের সাথে আমাদের নতুন ভূমিকা যুক্ত করব। মনে রাখবেন যে "নির্বাচনকারী" পতাকা নির্ধারণ করে যে আমাদের লগইন অনুরোধ এই ভূমিকাটি পাবে কিনা। অন্যান্য নির্বাচক বিকল্পের জন্য এখানে চেক করুন: https://www.consul.io/docs/acl/auth-methods/kubernetes.html#trusted-identity-attributes

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-ns-role' 
-selector='serviceaccount.namespace=="custom-ns"'

সবশেষে কনফিগারেশন

অ্যাক্সেস অধিকার

অ্যাক্সেস অধিকার তৈরি করুন। K8s পরিষেবা অ্যাকাউন্ট টোকেনের পরিচয় যাচাই ও শনাক্ত করার জন্য আমাদের কনসালকে অনুমতি দিতে হবে।
ফাইলটিতে নিম্নলিখিতটি লিখুন [লিংক]:

###skywiz-poc-consul-server_rbac.yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: review-tokens
 namespace: default
subjects:
- kind: ServiceAccount
 name: skywiz-app-with-consul-client-poc-consul-client
 namespace: default
roleRef:
 kind: ClusterRole
 name: system:auth-delegator
 apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: service-account-getter
 namespace: default
rules:
- apiGroups: [""]
 resources: ["serviceaccounts"]
 verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: get-service-accounts
 namespace: default
subjects:
- kind: ServiceAccount
 name: skywiz-app-with-consul-client-poc-consul-client
 namespace: default
roleRef:
 kind: ClusterRole
 name: service-account-getter
 apiGroup: rbac.authorization.k8s.io

আসুন অ্যাক্সেসের অধিকার তৈরি করি

kubectl create -f skywiz-poc-consul-server_rbac.yaml

কনসাল ক্লায়েন্টের সাথে সংযোগ করা হচ্ছে

উল্লিখিত এখানেডেমনসেটের সাথে সংযোগ করার জন্য বেশ কয়েকটি বিকল্প রয়েছে, তবে আমরা নিম্নলিখিত সহজ সমাধানে চলে যাব:
নিম্নলিখিত ফাইলটি প্রয়োগ করুন [লিংক].

### poc-consul-client-ds-svc.yaml
apiVersion: v1
kind: Service
metadata:
 name: consul-ds-client
spec:
 selector:
   app: consul
   chart: consul-helm
   component: client
   hasDNS: "true"
   release: skywiz-app-with-consul-client-poc
 ports:
 - protocol: TCP
   port: 80
   targetPort: 8500

তারপর একটি configmap তৈরি করতে নিম্নলিখিত বিল্টইন কমান্ড ব্যবহার করুন [লিংক]। দয়া করে মনে রাখবেন যে আমরা আমাদের পরিষেবার নাম উল্লেখ করছি, প্রয়োজনে এটি প্রতিস্থাপন করুন।

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
 labels:
   addonmanager.kubernetes.io/mode: EnsureExists
 name: kube-dns
 namespace: kube-system
data:
 stubDomains: |
   {"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]}
EOF

প্রমাণীকরণ পদ্ধতি পরীক্ষা করা হচ্ছে

এখন দেখা যাক অ্যাকশনে ম্যাজিক!

একই টপ-লেভেল কী দিয়ে আরও কয়েকটি কী ফোল্ডার তৈরি করুন (যেমন /sample_key) এবং আপনার পছন্দের একটি মান। নতুন মূল পথের জন্য উপযুক্ত নীতি এবং ভূমিকা তৈরি করুন। আমরা পরে বাঁধাই করব।

কাস্টম নামস্থান পরীক্ষা:

আসুন আমাদের নিজস্ব নামস্থান তৈরি করি:

kubectl create namespace custom-ns

আমাদের নতুন নামস্থানে একটি পড তৈরি করা যাক। পডের জন্য কনফিগারেশন লিখুন।

###poc-ubuntu-custom-ns.yaml
apiVersion: v1
kind: Pod
metadata:
 name: poc-ubuntu-custom-ns
 namespace: custom-ns
spec:
 containers:
 - name: poc-ubuntu-custom-ns
   image: ubuntu
   command: ["/bin/bash", "-ec", "sleep infinity"]
 restartPolicy: Never

অধীনে তৈরি করুন:

kubectl create -f poc-ubuntu-custom-ns.yaml

একবার কন্টেইনার চলমান হলে, সেখানে যান এবং কার্ল ইনস্টল করুন।

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

এখন আমরা আগে তৈরি করা অনুমোদন পদ্ধতি ব্যবহার করে কনসালের কাছে একটি লগইন অনুরোধ পাঠাব [লিংক].
আপনার পরিষেবা অ্যাকাউন্ট থেকে প্রবেশ করা টোকেন দেখতে:

cat /run/secrets/kubernetes.io/serviceaccount/token

কন্টেইনারের ভিতরে একটি ফাইলে নিম্নলিখিতটি লিখুন:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

প্রবেশ করুন!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

উপরের ধাপগুলি এক লাইনে সম্পূর্ণ করতে (যেহেতু আমরা একাধিক পরীক্ষা চালাব), আপনি নিম্নলিখিতগুলি করতে পারেন:

echo "{ 
"AuthMethod": "auth-method-skywiz-consul-poc", 
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)" 
}" 
| curl 
--request POST 
--data @- 
consul-ds-client.default.svc.cluster.local/v1/acl/login

কাজ করে! অন্তত এটা উচিত. এখন সিক্রেটআইডি নিন এবং আমাদের অ্যাক্সেস থাকা উচিত কী/মান অ্যাক্সেস করার চেষ্টা করুন।

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”

আপনি বেস64 "মান" ডিকোড করতে পারেন এবং দেখতে পারেন যে এটি UI-তে custom-ns/test_key-এর মানের সাথে মেলে। আপনি যদি এই টিউটোরিয়ালে উপরের একই মান ব্যবহার করেন তবে আপনার এনকোড করা মান হবে IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi।

ব্যবহারকারী পরিষেবা অ্যাকাউন্ট পরীক্ষা:

নিম্নলিখিত কমান্ড ব্যবহার করে একটি কাস্টম সার্ভিস অ্যাকাউন্ট তৈরি করুন [লিংক].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

পডের জন্য একটি নতুন কনফিগারেশন ফাইল তৈরি করুন। দয়া করে মনে রাখবেন যে আমি শ্রম বাঁচাতে কার্ল ইনস্টলেশন অন্তর্ভুক্ত করেছি :)

###poc-ubuntu-custom-sa.yaml
apiVersion: v1
kind: Pod
metadata:
 name: poc-ubuntu-custom-sa
 namespace: default
spec:
 serviceAccountName: custom-sa
 containers:
 - name: poc-ubuntu-custom-sa
   image: ubuntu
   command: ["/bin/bash","-ec"]
   args: ["apt-get update && apt-get install curl -y; sleep infinity"]
 restartPolicy: Never

এর পরে, পাত্রের ভিতরে একটি শেল চালান।

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

প্রবেশ করুন!

echo "{ 
"AuthMethod": "auth-method-skywiz-consul-poc", 
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)" 
}" 
| curl 
--request POST 
--data @- 
consul-ds-client.default.svc.cluster.local/v1/acl/login

অনুমতি অস্বীকার করা হয়েছে। ওহ, আমরা উপযুক্ত অনুমতির সাথে বাধ্যতামূলক একটি নতুন নিয়ম যোগ করতে ভুলে গেছি, এখন এটি করা যাক।

উপরের পূর্ববর্তী পদক্ষেপগুলি পুনরাবৃত্তি করুন:
ক) "কাস্টম-সা/" উপসর্গের জন্য একটি অভিন্ন নীতি তৈরি করুন।
খ) একটি ভূমিকা তৈরি করুন, এটিকে "কাস্টম-সা-ভূমিকা" বলুন
গ) ভূমিকার সাথে নীতি সংযুক্ত করুন।

একটি নিয়ম-বাইন্ডিং তৈরি করুন (কেবল 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" কন্টেইনার থেকে আবার লগইন করুন। সফলতার !
কাস্টম-সা/ কী পাথে আমাদের অ্যাক্সেস দেখুন।

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”

এছাড়াও আপনি নিশ্চিত করতে পারেন যে এই টোকেনটি "custom-ns/"-এ kv-এ অ্যাক্সেস দেয় না। "কাস্টম-সা" উপসর্গ "কাস্টম-এনএস" দিয়ে প্রতিস্থাপন করার পরে উপরের কমান্ডটি পুনরাবৃত্তি করুন।
অনুমতি অস্বীকার করা হয়েছে।

ওভারলে উদাহরণ:

এটি লক্ষণীয় যে সমস্ত নিয়ম-বান্ধব ম্যাপিং এই অধিকারগুলির সাথে টোকেনে যোগ করা হবে।
আমাদের কন্টেইনার "poc-ubuntu-custom-sa" ডিফল্ট নেমস্পেসে রয়েছে - তাই আসুন এটি একটি ভিন্ন নিয়ম-বান্ধনের জন্য ব্যবহার করি।
পূর্ববর্তী পদক্ষেপগুলি পুনরাবৃত্তি করুন:
ক) “ডিফল্ট/” কী উপসর্গের জন্য একটি অভিন্ন নীতি তৈরি করুন।
খ) একটি ভূমিকা তৈরি করুন, এটিকে "ডিফল্ট-এনএস-রোল" নাম দিন
গ) ভূমিকার সাথে নীতি সংযুক্ত করুন।
একটি নিয়ম-বাইন্ডিং তৈরি করুন (কেবল 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 দিয়ে ম্যানুয়ালি একটি টোকেন তৈরি করার বিকল্প রয়েছে:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
মেয়াদ শেষ হওয়ার সময় - যে সময়ে এই টোকেনটি প্রত্যাহার করা হবে। (ঐচ্ছিক; কনসাল 1.5.0 এ যোগ করা হয়েছে)
শুধুমাত্র ম্যানুয়াল তৈরি/আপডেটের জন্য বিদ্যমান https://www.consul.io/api/acl/tokens.html#expirationtime

আশা করি অদূর ভবিষ্যতে আমরা কীভাবে টোকেন তৈরি হয় তা নিয়ন্ত্রণ করতে সক্ষম হব (নিয়ম বা অনুমোদন পদ্ধতি অনুসারে) এবং TTL যোগ করতে পারব।

ততক্ষণ পর্যন্ত, আপনার যুক্তিতে একটি লগআউট এন্ডপয়েন্ট ব্যবহার করার পরামর্শ দেওয়া হচ্ছে।

এছাড়াও আমাদের ব্লগে অন্যান্য নিবন্ধ পড়ুন:

উত্স: www.habr.com

Hashicorp কনসাল এর Kubernetes অনুমোদনের ভূমিকা