Hashicorp консулының Кубернетес авторизациясына кіріспе

Дұрыс, босатылғаннан кейін Hashicorp Consul 1.5.0 2019 жылдың мамыр айының басында Консулда Kubernetes-те жұмыс істейтін қолданбалар мен қызметтерге жергілікті түрде авторизациялауға болады.

Бұл оқулықта біз кезең-кезеңімен жасаймыз POC (Тұжырымдаманың дәлелі, PoC) осы жаңа мүмкіндікті көрсетеді. Сізде Kubernetes және Hashicorp консулы туралы негізгі білім болуы керек. Кез келген бұлттық платформаны немесе жергілікті ортаны пайдалана алатын болсаңыз да, бұл оқулықта біз Google бұлттық платформасын қолданамыз.

қайта қарау

барсақ Оның рұқсат беру әдісі туралы консулдық құжаттама, біз оның мақсаты мен пайдалану жағдайын жылдам шолуды, сондай-ақ кейбір техникалық мәліметтерді және логикаға жалпы шолуды аламыз. Жалғастырмас бұрын мен оны кем дегенде бір рет оқып шығуды ұсынамын, өйткені мен қазір бәрін түсіндіріп, шайнайтын боламын.

1-диаграмма: Консулдың рұқсат беру әдісіне ресми шолу

Кірейік арнайы Kubernetes авторизация әдісіне арналған құжаттама.

Әрине, онда пайдалы ақпарат бар, бірақ оның барлығын қалай пайдалану керектігі туралы нұсқаулық жоқ. Сонымен, кез келген есі дұрыс адам сияқты, сіз Интернетті нұсқаулық үшін іздейсіз. Сосын... Сіз сәтсіздікке ұшырайсыз. Осылай болады. Осыны түзетейік.

POC құруға көшпес бұрын, Консулдың рұқсат беру әдістеріне (1-диаграмма) оралып, оны Кубернетес контекстінде нақтылайық.

сәулет

Бұл оқулықта біз Консул клиенті орнатылған Kubernetes кластерімен байланысатын бөлек құрылғыда Консул серверін жасаймыз. Содан кейін біз подкастта жалған қолданбаны жасаймыз және Консул кілті/құн дүкенінен оқу үшін конфигурацияланған авторизация әдісімізді қолданамыз.

Төмендегі диаграмма осы оқулықта жасап жатқан архитектураны, сондай-ақ кейінірек түсіндірілетін авторизация әдісінің логикасын егжей-тегжейлі сипаттайды.

2-диаграмма: Кубернетес авторизациялау әдісіне шолу

Қысқаша ескерту: Консул сервері бұл жұмыс істеуі үшін Kubernetes кластерінен тыс жерде тұрудың қажеті жоқ. Бірақ иә, ол мұны былай және былай істей алады.

Сонымен, Консулдың шолу диаграммасын (1-диаграмма) алып, оған Кубернетесті қолдана отырып, біз жоғарыдағы диаграмманы аламыз (2-диаграмма) және мұнда логика келесідей:

1. Әрбір подводқа Kubernetes жасаған және белгілі JWT таңбалауышы қосылған қызмет тіркелгісі болады. Бұл таңбалауыш әдепкі бойынша қосқышқа да кірістіріледі.
2. Қолданба немесе қызмет подкаст ішіндегі консулдық клиентке кіру пәрменін бастайды. Жүйеге кіру сұрауында біздің таңбалауышымыз бен атымыз да болады арнайы құрылған авторизация әдісі (Кубернетес түрі). Бұл №2 қадам Консул диаграммасының 1-қадамына сәйкес келеді (1-сызба).
3. Консул клиенті бұл сұрауды Консул серверіне жібереді.
4. СИҚЫРЛЫ! Бұл жерде Консул сервері сұраудың түпнұсқалығын тексереді, сұраудың сәйкестігі туралы ақпаратты жинайды және оны кез келген байланысты алдын ала анықталған ережелермен салыстырады. Төменде мұны көрсету үшін тағы бір диаграмма берілген. Бұл қадам Консулды шолу диаграммасының 3, 4 және 5 қадамдарына сәйкес келеді (1-диаграмма).
5. Консул серверіміз сұраушының жеке басына қатысты көрсетілген авторизация әдісі ережелеріне (біз анықтаған) сәйкес рұқсаттары бар Консул токенін жасайды. Содан кейін ол таңбалауышты кері жібереді. Бұл Консул диаграммасының 6-қадамына сәйкес келеді (1-диаграмма).
6. Консул клиентіміз таңбалауышты сұрау салған қолданбаға немесе қызметке жібереді.

Біздің қосымшамыз немесе қызметіміз енді осы Консул токенін токеннің артықшылықтарымен анықталған консул деректерімен байланысу үшін пайдалана алады.

Сиқыр ашылды!

Шляпадан шыққан қоянға риза болмайтындар және оның қалай жұмыс істейтінін білгісі келетіндер үшін... мен сізге қаншалықты терең екенін көрсетуге рұқсат етіңіз қоян шұңқыры«.

Бұрын айтылғандай, біздің «сиқырлы» қадамымыз (2-сурет: 4-қадам) Консул сервері сұраудың түпнұсқалығын растайтын, сұрау туралы ақпаратты жинайтын және оны кез келген байланысты алдын ала анықталған ережелермен салыстыратын жер. Бұл қадам Консулды шолу диаграммасының 3, 4 және 5 қадамдарына сәйкес келеді (1-диаграмма). Төменде диаграмма (3-диаграмма) берілген, оның мақсаты нақты не болып жатқанын нақты көрсету болып табылады сорғыштың астында арнайы Kubernetes авторизациялау әдісі.

3-сызба: Сиқыр ашылды!

1. Бастапқы нүкте ретінде біздің консул клиентіміз кіру сұрауын Консул серверіне Kubernetes тіркелгі белгісімен және бұрын жасалған авторизация әдісінің нақты данасы атауымен жібереді. Бұл қадам алдыңғы схема түсіндірмесіндегі 3-қадамға сәйкес келеді.
2. Енді консул сервері (немесе көшбасшы) алынған таңбалауыштың түпнұсқалығын тексеруі керек. Сондықтан ол Kubernetes кластеріне кеңес береді (Консул клиенті арқылы) және тиісті рұқсаттармен біз токеннің шынайы екенін және оның кімге тиесілі екенін анықтаймыз.
3. Содан кейін расталған сұрау Консул жетекшісіне қайтарылады және Консул сервері кіру сұрауынан (және Kubernetes түрі) көрсетілген атаумен авторизация әдісі данасын іздейді.
4. Консул жетекшісі көрсетілген рұқсат әдісі данасын (егер табылса) анықтайды және оған қоса берілген міндетті ережелер жинағын оқиды. Содан кейін ол осы ережелерді оқиды және оларды тексерілген сәйкестік атрибуттарымен салыстырады.
5. TA-dah! Алдыңғы тізбекті түсіндірудегі 5-қадамға көшейік.

Консул-серверді кәдімгі виртуалды машинада іске қосыңыз

Бұдан былай мен негізінен осы POC-ті қалай жасау керектігі туралы нұсқауларды, көбінесе таңбалауыш нүктелерде, толық сөйлемді түсіндірместен беретін боламын. Сондай-ақ, бұрын айтылғандай, мен барлық инфрақұрылымды жасау үшін GCP қолданамын, бірақ сіз сол инфрақұрылымды кез келген жерде жасай аласыз.

• Виртуалды машинаны (дананы/серверді) іске қосыңыз.

• Брандмауэр үшін ереже жасаңыз (AWS қауіпсіздік тобы):
• Мен ережеге де, желі тегіне де бірдей машина атауын тағайындауды ұнатамын, бұл жағдайда «skywiz-consul-server-poc».
• Жергілікті компьютердің IP мекенжайын тауып, оны бастапқы IP мекенжайларының тізіміне қосыңыз, осылайша біз пайдаланушы интерфейсіне (UI) қол жеткізе аламыз.
• UI үшін 8500 портын ашыңыз. Жасау түймесін басыңыз. Жақында осы брандмауэрді қайтадан өзгертеміз [байланыс].
• Данаға брандмауэр ережесін қосыңыз. Консул серверіндегі VM бақылау тақтасына оралыңыз және желі тегтері өрісіне “skywiz-consul-server-poc” қосыңыз. Сақтау түймесін басыңыз.

• Консулды виртуалды машинаға орнатыңыз, мына жерден тексеріңіз. Сізге Консул нұсқасы ≥ 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

• Сіз көптеген шығыстарды көресіз және «... ACL бұғатталған жаңартумен» аяқталуы керек.
• Консул серверінің сыртқы IP мекенжайын тауып, 8500 портында осы IP мекенжайы бар шолғышты ашыңыз. UI ашылғанына көз жеткізіңіз.
• Кілт/мән жұбын қосып көріңіз. Бұнда қате болу керек. Себебі біз Консул серверін ACL арқылы жүктеп, барлық ережелерді өшірдік.
• Консул серверіндегі қабықшаңызға оралыңыз және оны іске қосу үшін фондық режимде немесе басқа жолмен процесті бастаңыз және келесіні енгізіңіз:

consul acl bootstrap

• «SecretID» мәнін тауып, пайдаланушы интерфейсіне оралыңыз. ACL қойындысында жаңа ғана көшірілген таңбалауыштың құпия идентификаторын енгізіңіз. SecretID идентификаторын басқа жерге көшіріңіз, ол бізге кейінірек қажет болады.
• Енді кілт/мән жұбын қосыңыз. Бұл POC үшін келесіні қосыңыз: кілт: «custom-ns/test_key», мән: «Мен custom-ns қалтасындамын!»

Консул клиентімен Daemonset ретінде біздің қолданбамыз үшін Kubernetes кластерін іске қосу

• K8s (Kubernetes) кластерін жасаңыз. Біз оны жылдамырақ кіру үшін сервермен бір аймақта жасаймыз, осылайша ішкі IP мекенжайларымен оңай қосылу үшін бір ішкі желіні пайдалана аламыз. Біз оны «skywiz-app-with-consul-client-poc» деп атаймыз.

• Қосымша ескертпе ретінде, Consul Connect көмегімен POC Консул кластерін құру кезінде мен кездестірген жақсы оқулық.
• Сондай-ақ, біз кеңейтілген мәндер файлы бар 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

• Ол іске қосуға тырысқанда, Консул сервері үшін рұқсаттар қажет болады, сондықтан оларды қосамыз.
• Кластердің бақылау тақтасында орналасқан «Pod мекенжай ауқымына» назар аударыңыз және біздің «skywiz-consul-server-poc» брандмауэр ережесін қараңыз.
• IP мекенжайлар тізіміне подкасттың мекенжай ауқымын қосыңыз және 8301 және 8300 порттарын ашыңыз.

• Консул пайдаланушы интерфейсіне өтіңіз және бірнеше минуттан кейін түйіндер қойындысында біздің кластер пайда болғанын көресіз.

Консулды Кубернетеспен біріктіру арқылы авторизациялау әдісін конфигурациялау

• Консул серверінің қабығына оралыңыз және бұрын сақталған таңбалауышты экспорттаңыз:

export CONSUL_HTTP_TOKEN=<SecretID>

• Аутентификация әдісінің данасын жасау үшін бізге Kubernetes кластерінен ақпарат қажет болады:
• kubernetes-хост

kubectl get endpoints | grep kubernetes

• kubernetes-service-count-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» файлына жазыңыз.
• Енді толтырғыштарды жаңа алынған мәндермен ауыстырып, аутентификация әдісін жасаңыз.

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>

• Енді біз жаңа рөлімізді 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

Консул клиентіне қосылу

• атап өткендей осындаДемонсетке қосылудың бірнеше нұсқасы бар, бірақ біз келесі қарапайым шешімге көшеміз:
• Келесі файлды қолданыңыз [байланыс].

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

• base64 "Мәнді" декодтауға және оның пайдаланушы интерфейсіндегі custom-ns/test_key ішіндегі мәнге сәйкес келетінін көруге болады. Осы оқулықта жоғарыдағы бірдей мәнді пайдалансаңыз, кодталған мәніңіз IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi болады.

Пайдаланушы қызметі тіркелгісінің сынағы:

• Келесі пәрменді пайдаланып теңшелетін ServiceAccount жасаңыз [байланыс].

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

• Рұқсат беруден бас тартылды. О, біз тиісті рұқсаттармен байланыстыратын жаңа ережелерді қосуды ұмытып кеттік, мұны қазір жасайық.

Жоғарыдағы алдыңғы қадамдарды қайталаңыз:
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" контейнерінен қайта кіріңіз. Жетістік!
• 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" контейнері әдепкі аттар кеңістігінде - сондықтан оны басқа ережені байланыстыру үшін қолданайық.
• Алдыңғы қадамдарды қайталаңыз:
  a) «әдепкі/» перне префиксі үшін бірдей Саясат жасаңыз.
  ә) Рөл жасаңыз, оны «әдепкі-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» контейнеріне оралыңыз және «әдепкі/» kv жолына кіріп көріңіз.
• Рұқсат беруден бас тартылды.
  UI ішіндегі әрбір таңбалауыш үшін көрсетілген тіркелгі деректерін ACL > Токендер астында көруге болады. Көріп отырғаныңыздай, біздің ағымдағы таңбалауышта оған тек бір ғана «арнайы-са-рөл» бекітілген. Қазіргі уақытта біз пайдаланып жатқан таңбалауыш жүйеге кірген кезде жасалды және сол кезде сәйкес келетін бір ғана ережені байлау болды. Бізге қайта кіріп, жаңа токенді пайдалану керек.
• "Custom-sa/" және "default/" kv жолдарының екеуінен де оқи алатыныңызға көз жеткізіңіз.
  Жетістік!
  Себебі біздің «poc-ubuntu-custom-sa» «custom-sa» және «әдепкі-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 қоса аламыз деп үміттенеміз.

Осы уақытқа дейін логикаңызда жүйеден шығудың соңғы нүктесін пайдалану ұсынылады.

• 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 K8S үшін кіріс контроллері ретінде
• Біртекті емес веб-жобалардың үлкен санының сақтық көшірмесі
• Redmine үшін Telegram боты. Өзіңіз үшін және басқалар үшін өмірді қалай жеңілдетуге болады

Ақпарат көзі: www.habr.com