🥇 Hashicorp Consul को Kubernetes प्राधिकरणको परिचय

त्यो सहि हो, रिलिज पछि हाशिकोर्प कन्सुल १.५.० मे 2019 को सुरुमा, कन्सुलमा तपाईंले कुबेरनेटमा स्थानीय रूपमा चलिरहेका अनुप्रयोगहरू र सेवाहरूलाई अधिकृत गर्न सक्नुहुन्छ।

यस ट्यूटोरियलमा हामी चरणबद्ध रूपमा सिर्जना गर्नेछौं POC (प्रुफ अफ कन्सेप्ट, PoC) यो नयाँ सुविधाको प्रदर्शन गर्दै। तपाईंसँग Kubernetes र Hashicorp को कन्सुलको आधारभूत ज्ञान हुने अपेक्षा गरिएको छ। तपाईंले कुनै पनि क्लाउड प्लेटफर्म वा अन-प्रिमाइसेस वातावरण प्रयोग गर्न सक्नुहुन्छ, यस ट्यूटोरियलमा हामी Google को क्लाउड प्लेटफर्म प्रयोग गर्नेछौं।

सिंहावलोकन

यदि हामी जान्छौं यसको प्राधिकरण विधि मा कन्सुल कागजात, हामी यसको उद्देश्य र प्रयोग केसको द्रुत सिंहावलोकन, साथै केही प्राविधिक विवरणहरू र तर्कको सामान्य सिंहावलोकन प्राप्त गर्नेछौं। म यसलाई अगाडि बढ्नु अघि कम्तिमा एक पटक पढ्न सिफारिस गर्दछु, किनकि म अब यो सबैलाई व्याख्या र चपाउनेछु।

रेखाचित्र १: कन्सुल प्राधिकरण विधिको आधिकारिक सिंहावलोकन

भित्र हेरौं एक विशिष्ट Kubernetes प्राधिकरण विधि को लागी दस्तावेज.

अवश्य, त्यहाँ उपयोगी जानकारी छ, तर वास्तवमा यो सबै कसरी प्रयोग गर्ने भन्ने बारे कुनै गाइड छैन। त्यसोभए, कुनै पनि समझदार व्यक्तिले जस्तै, तपाइँ मार्गदर्शनको लागि इन्टरनेटको खोजी गर्नुहुन्छ। र त्यसपछि ... तपाईं असफल। यस्तो हुन्छ। यसलाई ठीक गरौं।

हामी हाम्रो POC सिर्जना गर्न अगाडि बढ्नु अघि, कन्सुलको प्राधिकरण विधिहरू (चित्र १) को सिंहावलोकनमा फर्कौं र कुबर्नेट्सको सन्दर्भमा यसलाई परिष्कृत गरौं।

वास्तुकला

यस ट्यूटोरियलमा, हामी कन्सुलर क्लाइन्ट स्थापना भएको कुबेरनेट क्लस्टरसँग कुराकानी गर्ने छुट्टै मेसिनमा कन्सुल सर्भर सिर्जना गर्नेछौं। त्यसपछि हामी पोडमा हाम्रो डमी अनुप्रयोग सिर्जना गर्नेछौं र हाम्रो कन्सुल कुञ्जी/मूल्य स्टोरबाट पढ्नको लागि कन्फिगर गरिएको प्राधिकरण विधि प्रयोग गर्नेछौं।

तलको रेखाचित्रले हामीले यस ट्यूटोरियलमा सिर्जना गर्ने वास्तुकलाको विवरण दिन्छ, साथै प्राधिकरण विधिको पछाडिको तर्क, जुन पछि व्याख्या गरिनेछ।

रेखाचित्र २: कुबर्नेट्स प्राधिकरण विधि सिंहावलोकन

द्रुत नोट: कन्सुल सर्भरले यो काम गर्नको लागि कुबेरनेट क्लस्टर बाहिर बस्नु पर्दैन। तर हो, उसले यो तरिका र त्यो गर्न सक्छ।

त्यसोभए, कन्सुल सिंहावलोकन रेखाचित्र (चित्र १) लिएर यसमा कुबेरनेटहरू लागू गर्दै, हामीले माथिको रेखाचित्र (चित्र २) पाउँछौं, र यहाँ तर्क निम्नानुसार छ:

प्रत्येक पोडमा एक सेवा खाता संलग्न हुनेछ जसमा एक JWT टोकन उत्पन्न हुन्छ र Kubernetes द्वारा ज्ञात हुन्छ। यो टोकन पनि पूर्वनिर्धारित रूपमा पोडमा सम्मिलित हुन्छ।
हाम्रो एप्लिकेसन वा पोड भित्रको सेवाले हाम्रो कन्सुल क्लाइन्टलाई लगइन आदेश सुरु गर्छ। लगइन अनुरोधमा हाम्रो टोकन र नाम पनि समावेश हुनेछ विशेष रूपमा सिर्जना गरिएको प्राधिकरण विधि (Kubernetes प्रकार)। यो चरण #2 कन्सुल रेखाचित्र (योजना 1) को चरण 1 सँग मेल खान्छ।
हाम्रो कन्सुल ग्राहकले यस अनुरोधलाई हाम्रो कन्सुल सर्भरमा फर्वार्ड गर्नेछ।
जादू! यो जहाँ कन्सुल सर्भरले अनुरोधको प्रामाणिकता प्रमाणित गर्दछ, अनुरोधको पहिचानको बारेमा जानकारी सङ्कलन गर्दछ र कुनै पनि सम्बन्धित पूर्वनिर्धारित नियमहरूसँग तुलना गर्दछ। यो चित्रण गर्न तल अर्को रेखाचित्र छ। यो चरण कन्सुल सिंहावलोकन रेखाचित्र (चित्र 3) को चरण 4, 5 र 1 सँग मेल खान्छ।
हाम्रो कन्सुल सर्भरले अनुरोधकर्ताको पहिचानको सन्दर्भमा हाम्रो निर्दिष्ट प्राधिकरण विधि नियमहरू (जसलाई हामीले परिभाषित गरेका छौं) अनुसार अनुमतिसहित कन्सुल टोकन उत्पन्न गर्दछ। त्यसपछि त्यो टोकन फिर्ता पठाउनेछ। यो कन्सुल रेखाचित्र (चित्र 6) को चरण 1 सँग मेल खान्छ।
हाम्रो कन्सुल ग्राहकले अनुरोध गर्ने आवेदन वा सेवामा टोकन फर्वार्ड गर्छ।

हाम्रो एप्लिकेसन वा सेवाले अब यो कन्सुल टोकन प्रयोग गर्न सक्छ हाम्रो कन्सुल डाटासँग कुराकानी गर्न, टोकनको विशेषाधिकारले निर्धारण गरे अनुसार।

जादू खुल्यो!

तपाईंहरू मध्ये जो टोपीबाट एउटा खरायो मात्र खुसी हुनुहुन्न र यसले कसरी काम गर्छ भनेर जान्न चाहानुहुन्छ... मलाई "तपाईलाई कति गहिरो देखाउनुहोस् खरायो प्वाल"।

पहिले उल्लेख गरिए अनुसार, हाम्रो "जादू" चरण (चित्र 2: चरण 4) जहाँ कन्सुल सर्भरले अनुरोधलाई प्रमाणीकरण गर्दछ, अनुरोध जानकारी सङ्कलन गर्दछ, र कुनै पनि सम्बन्धित पूर्वनिर्धारित नियमहरूसँग तुलना गर्दछ। यो चरण कन्सुल सिंहावलोकन रेखाचित्र (चित्र 3) को चरण 4, 5 र 1 सँग मेल खान्छ। तल एउटा रेखाचित्र (चित्र 3) छ, जसको उद्देश्य वास्तवमा के भइरहेको छ भनेर स्पष्ट रूपमा देखाउनु हो। हुड मुनि विशिष्ट Kubernetes प्राधिकरण विधि।

रेखाचित्र 3: जादू प्रकट भयो!

सुरूवात बिन्दुको रूपमा, हाम्रो कन्सुल क्लाइन्टले हाम्रो कन्सुल सर्भरमा लगइन अनुरोधलाई Kubernetes खाता टोकन र पहिले सिर्जना गरिएको प्राधिकरण विधिको विशिष्ट उदाहरण नामको साथ फर्वार्ड गर्दछ। यो चरण अघिल्लो सर्किट व्याख्या मा चरण 3 संग मेल खान्छ।
अब कन्सुल सर्भर (वा नेता) ले प्राप्त टोकनको प्रमाणिकता प्रमाणित गर्न आवश्यक छ। त्यसकारण, यसले Kubernetes क्लस्टरसँग परामर्श गर्नेछ (कन्सल ग्राहक मार्फत) र उपयुक्त अनुमतिहरूको साथमा, हामी टोकन वास्तविक हो र यो कसको हो भनेर पत्ता लगाउनेछौं।
पुष्टि गरिएको अनुरोध त्यसपछि कन्सुल नेतालाई फिर्ता गरिन्छ, र कन्सुल सर्भरले लगइन अनुरोध (र कुबेरनेट प्रकार) बाट निर्दिष्ट नामको साथ प्राधिकरण विधि उदाहरण खोज्छ।
कन्सुल नेताले निर्दिष्ट प्राधिकरण विधि उदाहरण (यदि फेला पर्यो भने) पहिचान गर्दछ र यसमा संलग्न बाध्यकारी नियमहरूको सेट पढ्छ। त्यसपछि यसले यी नियमहरू पढ्छ र प्रमाणित पहिचान विशेषताहरूसँग तुलना गर्छ।
TA-dah! अघिल्लो सर्किट व्याख्यामा चरण 5 मा जानुहोस्।

नियमित भर्चुअल मेसिनमा कन्सल-सर्भर चलाउनुहोस्

अब देखि, म प्राय: यो POC कसरी सिर्जना गर्ने भन्ने बारे निर्देशनहरू दिनेछु, प्रायः बुलेट पोइन्टहरूमा, पूर्ण वाक्य स्पष्टीकरण बिना। साथै, पहिले उल्लेख गरिएझैं, म सबै पूर्वाधारहरू सिर्जना गर्न GCP प्रयोग गर्नेछु, तर तपाईंले उही पूर्वाधार अरू कहिँ पनि बनाउन सक्नुहुन्छ।

भर्चुअल मेसिन सुरु गर्नुहोस् (उदाहरण/सर्भर)।

फायरवालको लागि नियम बनाउनुहोस् (AWS मा सुरक्षा समूह):
म नियम र नेटवर्क ट्याग दुवैमा समान मेसिनको नाम तोक्न चाहन्छु, यस अवस्थामा "skywiz-consul-server-poc"।
आफ्नो स्थानीय कम्प्युटरको IP ठेगाना फेला पार्नुहोस् र यसलाई स्रोत IP ठेगानाहरूको सूचीमा थप्नुहोस् ताकि हामी प्रयोगकर्ता इन्टरफेस (UI) पहुँच गर्न सक्छौं।
UI को लागि पोर्ट 8500 खोल्नुहोस्। सिर्जना गर्नुहोस् क्लिक गर्नुहोस्। हामी यो फायरवाल फेरि चाँडै परिवर्तन गर्नेछौं [लिङ्क].
उदाहरणमा फायरवाल नियम थप्नुहोस्। कन्सुल सर्भरको VM ड्यासबोर्डमा फर्कनुहोस् र नेटवर्क ट्याग फिल्डमा "skywiz-consul-server-poc" थप्नुहोस्। बचत क्लिक गर्नुहोस्।

भर्चुअल मेसिनमा कन्सुल स्थापना गर्नुहोस्, यहाँ जाँच गर्नुहोस्। याद गर्नुहोस् तपाईलाई कन्सुल संस्करण ≥ १.५ चाहिन्छ [लिङ्क]
एकल नोड कन्सुल सिर्जना गरौं - कन्फिगरेसन निम्नानुसार छ।

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

"SecretID" मान फेला पार्नुहोस् र UI मा फर्कनुहोस्। ACL ट्याबमा, तपाईंले भर्खरै प्रतिलिपि गर्नुभएको टोकनको गोप्य ID प्रविष्ट गर्नुहोस्। SecretID को कतै प्रतिलिपि गर्नुहोस्, हामीलाई पछि चाहिन्छ।
अब एउटा कुञ्जी/मान जोडी थप्नुहोस्। यो POC को लागि, निम्न थप्नुहोस्: कुञ्जी: "custom-ns/test_key", मान: "म custom-ns फोल्डरमा छु!"

डेमोनसेटको रूपमा कन्सुल क्लाइन्टसँग हाम्रो आवेदनको लागि Kubernetes क्लस्टर सुरु गर्दै

K8s (Kubernetes) क्लस्टर सिर्जना गर्नुहोस्। हामी यसलाई छिटो पहुँचको लागि सर्भरको रूपमा समान क्षेत्रमा सिर्जना गर्नेछौं, र त्यसैले हामी आन्तरिक IP ठेगानाहरूसँग सजिलै जडान गर्न समान सबनेट प्रयोग गर्न सक्छौं। हामी यसलाई "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

जब यो चल्ने प्रयास गर्छ, यसलाई कन्सुल सर्भरको लागि अनुमति चाहिन्छ, त्यसैले तिनीहरूलाई थपौं।
क्लस्टर ड्यासबोर्डमा रहेको "पोड ठेगाना दायरा" नोट गर्नुहोस् र हाम्रो "skywiz-consul-server-poc" फायरवाल नियममा फर्कनुहोस्।
आईपी ठेगानाहरूको सूचीमा पोडको लागि ठेगाना दायरा थप्नुहोस् र 8301 र 8300 पोर्टहरू खोल्नुहोस्।

Consul UI मा जानुहोस् र केहि मिनेट पछि तपाईंले नोड्स ट्याबमा हाम्रो क्लस्टर देख्नुहुनेछ।

Kubernetes संग कन्सुल एकीकरण गरेर प्राधिकरण विधि कन्फिगर गर्दै

कन्सुल सर्भर शेलमा फर्कनुहोस् र तपाईंले पहिले बचत गर्नुभएको टोकन निर्यात गर्नुहोस्:

export CONSUL_HTTP_TOKEN=<SecretID>

प्रमाणीकरण विधिको उदाहरण सिर्जना गर्न हामीलाई हाम्रो Kubernetes क्लस्टरबाट जानकारी चाहिन्छ:
kubernetes-होस्ट

kubectl get endpoints | grep kubernetes

kubernetes-सेवा-खाता-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" फाइलमा लेख्नुहोस्।
अब तपाईंले भर्खरै प्राप्त गर्नुभएको मानहरूसँग प्लेसहोल्डरहरू प्रतिस्थापन गर्दै, प्रमाणीकरण विधिलाई इन्स्ट्याट गर्नुहोस्।

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

त्यसपछि कन्फिगम्याप सिर्जना गर्न निम्न निर्मित आदेश प्रयोग गर्नुहोस् [लिङ्क]। कृपया ध्यान दिनुहोस् कि हामी हाम्रो सेवाको नाम उल्लेख गर्दैछौं, यदि आवश्यक भएमा यसलाई बदल्नुहोस्।

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

कामहरू! कम्तिमा हुनुपर्छ। अब SecretID लिनुहोस् र कुञ्जी/मान पहुँच गर्न प्रयास गर्नुहोस् जुन हामीले पहुँच गर्नुपर्दछ।

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 मा पहुँच प्रदान गर्दैन। "custom-sa" उपसर्ग "custom-ns" लाई प्रतिस्थापन गरेपछि मात्र माथिको आदेश दोहोर्याउनुहोस्।
अनुमति अस्वीकृत।

ओभरले उदाहरण:

यो नोट गर्न लायक छ कि सबै नियम-बाध्यकारी म्यापिङहरू यी अधिकारहरूसँग टोकनमा थपिनेछन्।
हाम्रो कन्टेनर "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 मा प्रत्येक टोकनको लागि निर्दिष्ट प्रमाणहरू हेर्न सक्नुहुन्छ। तपाईंले देख्न सक्नुहुने रूपमा, हाम्रो हालको टोकनमा एउटा मात्र "कस्टम-सा-भूमिका" जोडिएको छ। हामीले हाल प्रयोग गरिरहेको टोकन हामीले लग इन गर्दा उत्पन्न भएको थियो र त्यहाँ एक मात्र नियम-बाध्यकारी थियो जुन त्यसबेला मेल खान्छ। हामीले फेरि लगइन गर्नुपर्छ र नयाँ टोकन प्रयोग गर्नुपर्छ।
सुनिश्चित गर्नुहोस् कि तपाइँ दुबै "कस्टम-सा/" र "डिफल्ट/" kv मार्गहरूबाट पढ्न सक्नुहुन्छ।
सफलता!
यो किनभने हाम्रो "poc-ubuntu-custom-sa" ले "custom-sa" र "default-ns" नियम बाइन्डिङसँग मेल खान्छ।

निष्कर्षमा

TTL टोकन mgmt?

यस लेखनको समयमा, यस प्राधिकरण विधिद्वारा उत्पन्न टोकनहरूको लागि TTL निर्धारण गर्ने कुनै एकीकृत तरिका छैन। यो कन्सुल प्राधिकरण को सुरक्षित स्वचालन प्रदान गर्न को लागी एक शानदार अवसर हुनेछ।

TTL सँग म्यानुअल रूपमा टोकन सिर्जना गर्ने विकल्प छ:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
म्याद सकिने समय - यो टोकन रद्द गरिने समय। (वैकल्पिक; कन्सुल १.५.० मा थपिएको)
म्यानुअल सिर्जना/अपडेटको लागि मात्र अवस्थित छ https://www.consul.io/api/acl/tokens.html#expirationtime

आशा छ निकट भविष्यमा हामी कसरी टोकनहरू उत्पन्न हुन्छन् (प्रति नियम वा प्राधिकरण विधि) नियन्त्रण गर्न र TTL थप्न सक्षम हुनेछौं।

तब सम्म, यो सुझाव दिइन्छ कि तपाइँ तपाइँको तर्क मा लगआउट अन्त्य बिन्दु प्रयोग गर्नुहोस्।

हाम्रो ब्लगमा अन्य लेखहरू पनि पढ्नुहोस्:

स्रोत: www.habr.com

Hashicorp Consul को Kubernetes प्राधिकरण को परिचय