Ներածություն Hashicorp հյուպատոսի Kubernetes թույլտվությանը

Ճիշտ է, ազատվելուց հետո Hashicorp հյուպատոս 1.5.0 2019 թվականի մայիսի սկզբին հյուպատոսում կարող եք թույլատրել հավելվածներն ու ծառայությունները, որոնք աշխատում են Կուբերնետեսում բնիկորեն:

Այս ձեռնարկում մենք քայլ առ քայլ կստեղծենք poc (Հայեցակարգի ապացույց, PoC), որը ցույց է տալիս այս նոր հնարավորությունը: Ակնկալվում է, որ դուք կունենաք հիմնական գիտելիքներ Kubernetes-ի և Hashicorp-ի հյուպատոսի մասին: Մինչև դուք կարող եք օգտագործել ցանկացած ամպային հարթակ կամ ներքին միջավայր, այս ձեռնարկում մենք կօգտագործենք Google-ի Cloud Platform-ը:

Վերանայել

Եթե ​​գնանք դեպի Հյուպատոսական փաստաթղթեր դրա թույլտվության մեթոդի վերաբերյալ, մենք կստանանք դրա նպատակի և օգտագործման դեպքի արագ ակնարկ, ինչպես նաև որոշ տեխնիկական մանրամասներ և տրամաբանության ընդհանուր ակնարկ: Խստորեն խորհուրդ եմ տալիս կարդալ այն գոնե մեկ անգամ՝ շարունակելուց առաջ, քանի որ ես հիմա կբացատրեմ և կծամեմ այդ ամենը:

Դիագրամ 1. Հյուպատոսի թույլտվության մեթոդի պաշտոնական ակնարկ

Եկեք ներս նայենք փաստաթղթեր Kubernetes-ի հատուկ թույլտվության մեթոդի համար.

Իհարկե, այնտեղ օգտակար տեղեկատվություն կա, բայց չկա ուղեցույց, թե ինչպես կարելի է իրականում օգտագործել այդ ամենը: Այսպիսով, ինչպես ցանկացած խելամիտ մարդ, դուք փնտրում եք ինտերնետը՝ առաջնորդություն ստանալու համար: Եվ հետո... Դու ձախողվում ես: Պատահում է. Եկեք սա շտկենք:

Նախքան մեր POC-ի ​​ստեղծմանը անցնելը, եկեք վերադառնանք հյուպատոսի թույլտվության մեթոդների ակնարկին (Դիագրամ 1) և ճշգրտենք այն Kubernetes-ի համատեքստում:

ճարտարապետություն

Այս ձեռնարկում մենք կստեղծենք Consul սերվեր առանձին մեքենայի վրա, որը կհաղորդակցի Kubernetes կլաստերի հետ՝ տեղադրված Consul հաճախորդի հետ: Այնուհետև մենք կստեղծենք մեր կեղծ հավելվածը պատիճում և կօգտագործենք մեր կազմաձևված թույլտվության մեթոդը՝ մեր հյուպատոսական բանալին/արժեքի խանութից կարդալու համար:

Ստորև բերված դիագրամը մանրամասնում է ճարտարապետությունը, որը մենք ստեղծում ենք այս ձեռնարկում, ինչպես նաև թույլտվության մեթոդի տրամաբանությունը, որը կբացատրվի ավելի ուշ:

Դիագրամ 2. Kubernetes-ի թույլտվության մեթոդի ակնարկ

Արագ նշում. Consul սերվերը կարիք չունի ապրել Kubernetes կլաստերից դուրս, որպեսզի դա աշխատի: Բայց այո, նա կարող է դա անել այս ու այն կողմ։

Այսպիսով, վերցնելով հյուպատոսի ընդհանուր գծապատկերը (Դիագրամ 1) և կիրառելով Kubernetes-ը դրա վրա, մենք ստանում ենք վերևի դիագրամը (Դիագրամ 2), և այստեղ տրամաբանությունը հետևյալն է.

1. Յուրաքանչյուր pod կունենա իրեն կցված ծառայության հաշիվ, որը պարունակում է JWT նշան, որը ստեղծվել և հայտնի է Kubernetes-ի կողմից: Այս նշանը նաև լռելյայն տեղադրվում է պատիճում:
2. Մեր հավելվածը կամ ծառայությունը պատի ներսում սկսում է մուտքի հրաման մեր հյուպատոս հաճախորդին: Մուտքի հարցումը կներառի նաև մեր նշանն ու անունը հատուկ ստեղծված թույլտվության մեթոդ (Kubernetes տեսակ): Այս քայլը #2 համապատասխանում է հյուպատոսական դիագրամի 1-ին քայլին (սխեմա 1):
3. Մեր հյուպատոս հաճախորդն այնուհետև այս հարցումը կուղարկի մեր հյուպատոսի սերվերին:
4. Կախարդական! Սա այն վայրն է, որտեղ հյուպատոսի սերվերը ստուգում է հարցումի իսկությունը, հավաքում է հարցումի ինքնության մասին տեղեկատվություն և այն համեմատում նախապես սահմանված կանոնների հետ: Ստորև բերված է մեկ այլ դիագրամ, որը ցույց է տալիս դա: Այս քայլը համապատասխանում է հյուպատոսի ընդհանուր գծապատկերի 3-րդ, 4-րդ և 5-րդ քայլերին (Դիագրամ 1):
5. Մեր հյուպատոսի սերվերը ստեղծում է Consul token թույլտվություններով՝ համաձայն մեր սահմանված թույլտվության մեթոդի կանոնների (որ մենք սահմանել ենք)՝ կապված հայցողի ինքնության հետ: Այնուհետև այն հետ կուղարկի այդ նշանը: Սա համապատասխանում է հյուպատոսական դիագրամի 6-րդ քայլին (Դիագրամ 1):
6. Մեր հյուպատոս հաճախորդը փոխանցում է նշանը հայցող դիմումին կամ ծառայությանը:

Մեր դիմումը կամ ծառայությունն այժմ կարող է օգտագործել այս հյուպատոսի նշանը մեր հյուպատոսի տվյալների հետ հաղորդակցվելու համար, ինչպես որոշվում է նշանի արտոնություններով:

Կախարդությունը բացահայտված է:

Ձեզանից նրանց համար, ովքեր գոհ չեն միայն գլխարկից դուրս գտնվող նապաստակով և ցանկանում են իմանալ, թե ինչպես է այն աշխատում... թույլ տվեք «ցույց տալ ձեզ, թե որքան խորն է նապաստակի փոս.

Ինչպես նշվեց ավելի վաղ, մեր «կախարդական» քայլը (Նկար 2. Քայլ 4) այն է, որտեղ հյուպատոսի սերվերը վավերացնում է հարցումը, հավաքում է հարցումի մասին տեղեկատվություն և այն համեմատում է ցանկացած առնչվող նախապես սահմանված կանոնների հետ: Այս քայլը համապատասխանում է հյուպատոսի ընդհանուր գծապատկերի 3-րդ, 4-րդ և 5-րդ քայլերին (Դիագրամ 1): Ստորև ներկայացված է գծապատկեր (Դիագրամ 3), որի նպատակն է հստակ ցույց տալ, թե ինչ է իրականում տեղի ունենում. կափարիչի տակ հատուկ Kubernetes թույլտվության մեթոդ:

Դիագրամ 3. Կախարդությունը բացահայտված է:

1. Որպես ելակետ՝ մեր հյուպատոս հաճախորդը մուտքի հարցումն ուղարկում է մեր հյուպատոսի սերվերին՝ Kubernetes հաշվի նշանով և ավելի վաղ ստեղծված թույլտվության մեթոդի հատուկ օրինակի անունով: Այս քայլը համապատասխանում է նախորդ սխեմայի բացատրության 3-րդ քայլին:
2. Այժմ հյուպատոս սերվերը (կամ ղեկավարը) պետք է ստուգի ստացված նշանի իսկությունը: Հետևաբար, նա կխորհրդակցի Kubernetes կլաստերի հետ (Հյուպատոս հաճախորդի միջոցով) և համապատասխան թույլտվություններով մենք կպարզենք, թե արդյոք նշանն իսկական է և ում է պատկանում:
3. Վավերացված հարցումն այնուհետև վերադարձվում է հյուպատոսի ղեկավարին, և հյուպատոսի սերվերը մուտքի հարցումից (և Kubernetes տեսակի) որոնում է թույլտվության մեթոդի օրինակը նշված անունով:
4. Հյուպատոսի ղեկավարը նույնականացնում է նշված թույլտվության մեթոդի օրինակը (եթե գտնվել է) և կարդում է պարտադիր կանոնների փաթեթը, որոնք կցված են դրան: Այնուհետև այն կարդում է այս կանոնները և համեմատում դրանք հաստատված ինքնության հատկանիշների հետ:
5. TA-dah! Եկեք անցնենք 5-րդ քայլին նախորդ սխեմայի բացատրության մեջ:

Գործարկեք Consul-server-ը սովորական վիրտուալ մեքենայի վրա

Այսուհետ, ես հիմնականում հրահանգներ կտամ, թե ինչպես ստեղծել այս POC-ը, հաճախ կետերով, առանց նախադասության ամբողջական բացատրությունների: Նաև, ինչպես նշվեց ավելի վաղ, ես կօգտագործեմ GCP-ն ամբողջ ենթակառուցվածքը ստեղծելու համար, բայց դուք կարող եք ստեղծել նույն ենթակառուցվածքը ցանկացած այլ վայրում:

• Գործարկեք վիրտուալ մեքենան (օրինակ/սերվեր):

• Ստեղծեք կանոն firewall-ի համար (անվտանգության խումբ AWS-ում).
• Ես սիրում եմ վերագրել նույն մեքենայի անունը և՛ կանոնին, և՛ ցանցային պիտակին, այս դեպքում՝ «skywiz-consul-server-poc»:
• Գտեք ձեր տեղական համակարգչի IP հասցեն և ավելացրեք այն աղբյուրի IP հասցեների ցանկում, որպեսզի կարողանանք մուտք գործել օգտատիրոջ միջերես (UI):
• Բացեք 8500 պորտը UI-ի համար: Սեղմեք Ստեղծել: Մենք շուտով նորից կփոխենք այս firewall-ը [ՈՒղեցույց].
• Օրինակին ավելացրեք firewall կանոն: Վերադարձեք Consul Server-ի VM վահանակ և ավելացրեք «skywiz-consul-server-poc» ցանցի պիտակների դաշտում: Սեղմեք Պահպանել:

• Տեղադրեք Consul-ը վիրտուալ մեքենայի վրա, ստուգեք այստեղ: Հիշեք, որ ձեզ անհրաժեշտ է Consul տարբերակը ≥ 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 հետևյալ կերպ [ՈՒղեցույց]:

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

• Դուք պետք է տեսնեք ելքերի մի փունջ և ավարտեք «... թարմացումն արգելափակված է ACL-ների կողմից»:
• Գտեք Consul սերվերի արտաքին IP հասցեն և բացեք զննարկիչ այս IP հասցեով 8500 նավահանգստում: Համոզվեք, որ UI-ը բացվում է:
• Փորձեք ավելացնել բանալի/արժեք զույգ: Պետք է սխալմունք լինի։ Դա պայմանավորված է նրանով, որ մենք բեռնել ենք Consul սերվերը ACL-ով և անջատել ենք բոլոր կանոնները:
• Վերադարձեք ձեր կեղևը Consul սերվերի վրա և սկսեք գործընթացը հետին պլանում կամ այն ​​գործարկելու այլ եղանակով և մուտքագրեք հետևյալը.

consul acl bootstrap

• Գտեք «SecretID» արժեքը և վերադարձեք UI: ACL ներդիրում մուտքագրեք ձեր նոր պատճենած նշանի գաղտնի ID-ն: Պատճենեք SecretID-ը մեկ այլ տեղ, այն մեզ ավելի ուշ պետք կգա:
• Այժմ ավելացրեք բանալի/արժեք զույգ: Այս POC-ի ​​համար ավելացրեք հետևյալը. բանալին՝ «custom-ns/test_key», արժեքը՝ «Ես custom-ns թղթապանակում եմ»:

Գործարկելով Kubernetes կլաստերը մեր հավելվածի համար Consul հաճախորդի հետ որպես Daemonset

• Ստեղծեք K8s (Kubernetes) կլաստեր: Մենք այն կստեղծենք նույն գոտում, ինչ սերվերը՝ ավելի արագ մուտք գործելու համար, և այնպես որ մենք կարող ենք օգտագործել նույն ենթացանցը՝ ներքին IP հասցեների հետ հեշտությամբ միանալու համար: Մենք այն կանվանենք «skywiz-app-with-consul-client-poc»:

• Որպես կողմնակի նշում, ահա մի լավ ձեռնարկ, որը ես հանդիպեցի Consul Connect-ի հետ POC Consul կլաստերը ստեղծելիս:
• Մենք նաև կօգտագործենք Hashicorp ղեկային աղյուսակը ընդլայնված արժեքների ֆայլով:
• Տեղադրեք և կարգավորեք Helm-ը: Կազմաձևման քայլեր.

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

• Երբ այն փորձի գործարկել, այն թույլտվությունների կարիք կունենա Consul սերվերի համար, ուստի եկեք դրանք ավելացնենք:
• Նկատի ունեցեք «Pod Address Range»-ը, որը գտնվում է կլաստերի վահանակի վրա և վերադառնաք մեր «skywiz-consul-server-poc» firewall կանոնին:
• IP հասցեների ցանկին ավելացրեք պատի հասցեների տիրույթը և բացեք 8301 և 8300 նավահանգիստները:

• Գնացեք Consul UI և մի քանի րոպե անց կտեսնեք, որ մեր կլաստերը հայտնվում է հանգույցների ներդիրում:

Լիազորման մեթոդի կարգավորում՝ ինտեգրելով հյուպատոսը Kubernetes-ի հետ

• Վերադարձեք Consul server shell-ին և արտահանեք ավելի վաղ պահպանված նշանը.

export CONSUL_HTTP_TOKEN=<SecretID>

• Մեզ անհրաժեշտ կլինի տեղեկատվություն մեր Kubernetes կլաստերից՝ auth մեթոդի օրինակ ստեղծելու համար.
• 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» վկայագիրը (base64 ապակոդավորումից հետո) և գրեք այն «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, բայց մենք կօգտագործենք հրամանի տողը:
• Գրեք կանոն

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

• Արդյունքից գտեք ձեր նոր ստեղծած կանոնի ID-ն:
• Ստեղծեք դեր նոր կանոնով:

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

• Այժմ մենք մեր նոր դերը կապելու ենք auth մեթոդի օրինակի հետ: Նկատի ունեցեք, որ «ընտրիչ» դրոշը որոշում է, թե արդյոք մեր մուտքի հարցումը կստանա այս դերը: Ընտրիչի այլ տարբերակների համար ստուգեք այստեղ՝ 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

Միացում հյուպատոս հաճախորդին

• Ինչպես նշվեց այստեղDaemonset-ին միանալու մի քանի տարբերակ կա, բայց մենք կանցնենք հետևյալ պարզ լուծմանը.
• Կիրառեք հետևյալ ֆայլը [ՈՒղեցույց].

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

• Երբ կոնտեյները աշխատում է, գնացեք այնտեղ և տեղադրեք curl:

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

• Դուք կարող եք base64 ապակոդավորել «Արժեքը» և տեսնել, որ այն համապատասխանում է UI-ի custom-ns/test_key արժեքին: Եթե ​​դուք օգտագործել եք վերը նշված նույն արժեքը այս ձեռնարկում, ձեր կոդավորված արժեքը կլինի IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi:

Օգտագործողի ծառայության հաշվի փորձարկում.

• Ստեղծեք հատուկ ծառայության հաշիվ՝ օգտագործելով հետևյալ հրամանը [ՈՒղեցույց].

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

• Ստեղծեք նոր կազմաձևման ֆայլ pod-ի համար: Խնդրում ենք նկատի ունենալ, որ ես ներառել եմ գանգուրների տեղադրում՝ աշխատուժը խնայելու համար :)

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

• Թույլտվությունը մերժվել է: Օ, մենք մոռացել ենք ավելացնել նոր կանոններ, որոնք պարտադիր են համապատասխան թույլտվություններով, եկեք դա անենք հիմա:

Կրկնեք վերը նշված նախորդ քայլերը.
ա) Ստեղծեք նույնական քաղաքականություն «custom-sa/» նախածանցի համար:
բ) Ստեղծեք դեր, անվանեք այն «պատվերով դեր»
գ) Քաղաքականությունը կցել դերին:

• Ստեղծեք Rule-Binding (հնարավոր է միայն 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» կոնտեյներից: Հաջողություն:
• Ստուգեք մեր մուտքը դեպի 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» կոնտեյները գտնվում է լռելյայն անվանատարածքում, ուստի եկեք այն օգտագործենք այլ կանոնների պարտադիր կապի համար:
• Կրկնել նախորդ քայլերը.
  ա) Ստեղծեք նույնական քաղաքականություն «default/» ստեղնի նախածանցի համար:
  բ) Ստեղծեք դեր, անվանեք այն «default-ns-role»
  գ) Քաղաքականությունը կցել դերին:
• Ստեղծեք կանոն-պարտադիր (հնարավոր է միայն 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 ուղին:
• Թույլտվությունը մերժվել է:
  Դուք կարող եք դիտել նշված հավատարմագրերը յուրաքանչյուր նշանի համար UI-ում ACL > Tokens-ում: Ինչպես տեսնում եք, մեր ներկայիս նշանը դրան կցված է միայն մեկ «custom-sa-role»: Թոքենը, որը մենք ներկայումս օգտագործում ենք, ստեղծվել է այն ժամանակ, երբ մենք մուտք գործեցինք, և կար միայն մեկ կանոն պարտադիր, որը համընկավ այն ժամանակ: Մենք պետք է նորից մուտք գործենք և օգտագործենք նոր նշանը:
• Համոզվեք, որ կարող եք կարդալ ինչպես «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
  Ժամկետը - Ժամկետ, երբ այս նշանը կչեղարկվի: (Ըստ ցանկության; ավելացվել է Consul 1.5.0-ում)
• Առկա է միայն ձեռքով ստեղծելու/թարմացման համար https://www.consul.io/api/acl/tokens.html#expirationtime

Հուսով ենք, որ մոտ ապագայում մենք կկարողանանք վերահսկել, թե ինչպես են ստեղծվում նշանները (ըստ կանոնի կամ թույլտվության մեթոդի) և ավելացնել TTL:

Մինչ այդ, առաջարկվում է, որ ձեր տրամաբանության մեջ օգտագործեք դուրս գալու վերջնակետ:

• https://www.consul.io/api/acl/acl.html#logout-from-auth-method
• https://www.consul.io/docs/acl/acl-auth-methods.html#overall-login-process

Կարդացեք նաև մեր բլոգի այլ հոդվածներ.

• Ինչի՞ հանգեցրեց միգրացիան ClickHouse-ից առանց թույլտվության դեպի ClickHouse թույլտվությամբ:
• Ինչպես գործարկել մի քանի խողովակաշարեր՝ օգտագործելով GitLab CI/CD
• Երեք պարզ հնարք՝ Docker պատկերները փոքրացնելու համար
• Traefik որպես Ingress վերահսկիչ K8S-ի համար
• Մեծ թվով տարասեռ վեբ նախագծերի կրկնօրինակում
• Telegram բոտ Redmine-ի համար։ Ինչպես պարզեցնել կյանքը ձեր և ուրիշների համար

Source: www.habr.com