To'g'ri, ozod qilingandan keyin 2019 yil may oyi boshida Konsulda siz Kubernetes-da ishlaydigan ilovalar va xizmatlarga avtorizatsiya qilishingiz mumkin.
Ushbu qo'llanmada biz bosqichma-bosqich yaratamiz Bu yangi xususiyatni namoyish qiluvchi (kontseptsiya isboti, PoC). Sizdan Kubernetes va Hashicorp konsuli haqida asosiy bilimlarga ega boʻlishingiz kutiladi. Har qanday bulutli platforma yoki mahalliy muhitdan foydalanishingiz mumkin boʻlsa-da, bu qoʻllanmada biz Google bulutli platformasidan foydalanamiz.
haqida umumiy ma'lumot
Agar borsak , biz uning maqsadi va foydalanish holatlari, shuningdek, ba'zi texnik tafsilotlar va mantiqning umumiy ko'rinishi haqida qisqacha ma'lumotga ega bo'lamiz. Davom etishdan oldin uni hech bo'lmaganda bir marta o'qishni tavsiya etaman, chunki endi hammasini tushuntirib beraman.
1-diagramma: Konsul ruxsat berish usulining rasmiy sharhi
Keling, ichkariga qaraymiz .
Albatta, u erda foydali ma'lumotlar bor, lekin ulardan qanday foydalanish bo'yicha qo'llanma yo'q. Shunday qilib, har qanday aqli raso odam singari, siz ham yo'l-yo'riq uchun Internetni qidirasiz. Va keyin ... Siz muvaffaqiyatsizlikka uchraysiz. Bo'lib turadi. Keling, buni tuzataylik.
POC-ni yaratishga o'tishdan oldin, keling, konsulning ruxsat berish usullarining umumiy ko'rinishiga qaytaylik (1-diagramma) va uni Kubernetes kontekstida aniqlaymiz.
arxitektura
Ushbu qo'llanmada biz Konsul mijozi o'rnatilgan Kubernetes klasteri bilan aloqa qiladigan alohida mashinada Konsul serverini yaratamiz. Keyin biz podda o'z qo'lbola ilovamizni yaratamiz va Konsul kalit/qiymat do'konimizdan o'qish uchun sozlangan avtorizatsiya usulimizdan foydalanamiz.
Quyidagi diagrammada biz ushbu qoʻllanmada yaratilayotgan arxitektura hamda avtorizatsiya usuli mantigʻi batafsil tavsiflanadi, bu haqda keyinroq tushuntiriladi.
2-diagramma: Kubernetes avtorizatsiya usuliga umumiy nuqtai
Tezkor eslatma: buning ishlashi uchun konsul serveri Kubernetes klasteridan tashqarida yashashi shart emas. Lekin ha, u buni u yo'l bilan qila oladi.
Shunday qilib, Konsulning umumiy diagrammasini (1-diagramma) olib, unga Kubernetesni qo'llash orqali biz yuqoridagi diagrammani olamiz (2-diagramma) va bu erda mantiq quyidagicha:
- Har bir podkada Kubernetes tomonidan ishlab chiqarilgan va ma'lum bo'lgan JWT tokenini o'z ichiga olgan xizmat hisobi biriktirilgan bo'ladi. Ushbu token sukut bo'yicha podka ham kiritiladi.
- Pod ichidagi ilovamiz yoki xizmatimiz konsul mijozimizga kirish buyrug'ini boshlaydi. Kirish so'rovida bizning tokenimiz va ismimiz ham bo'ladi maxsus yaratilgan avtorizatsiya usuli (Kubernetes turi). Ushbu №2 bosqich Konsul diagrammasining 1-bosqichiga mos keladi (1-sxema).
- Keyin bizning konsul mijozimiz ushbu so'rovni konsul serverimizga yuboradi.
- MAGIC! Bu erda Konsul serveri so'rovning haqiqiyligini tekshiradi, so'rovning identifikatori haqida ma'lumot to'playdi va uni oldindan belgilangan qoidalar bilan taqqoslaydi. Quyida buni tasvirlash uchun yana bir diagramma keltirilgan. Ushbu bosqich Konsulning umumiy ko'rinishi diagrammasining 3, 4 va 5 bosqichlariga mos keladi (1-diagramma).
- Konsul serverimiz so'rovchining shaxsiga oid ko'rsatilgan avtorizatsiya usuli qoidalariga (biz belgilagan) muvofiq ruxsatnomalar bilan Konsul tokenini yaratadi. Keyin u tokenni qaytarib yuboradi. Bu Konsul diagrammasining 6-bosqichiga mos keladi (1-diagramma).
- Bizning konsul mijozimiz tokenni so'ralayotgan dastur yoki xizmatga yuboradi.
Bizning ilovamiz yoki xizmatimiz endi token imtiyozlari bilan belgilanadigan konsul maʼlumotlari bilan bogʻlanish uchun ushbu Konsul tokenidan foydalanishi mumkin.
Sehr oshkor bo'ldi!
Shunchaki shlyapadan chiqqan quyondan mamnun bo'lmagan va uning qanday ishlashini bilmoqchi bo'lganlar uchun... sizga qanchalik chuqurligini ko'rsataman. quyon teshigi".
Yuqorida aytib o'tilganidek, bizning "sehrli" qadamimiz (2-rasm: 4-bosqich) bu erda Konsul serveri so'rovni autentifikatsiya qiladi, so'rov ma'lumotlarini to'playdi va uni har qanday bog'liq oldindan belgilangan qoidalar bilan taqqoslaydi. Ushbu bosqich Konsulning umumiy ko'rinishi diagrammasining 3, 4 va 5 bosqichlariga mos keladi (1-diagramma). Quyida diagramma keltirilgan (3-diagramma), uning maqsadi aslida nima sodir bo'layotganini aniq ko'rsatishdir kaput ostida maxsus Kubernetes avtorizatsiya usuli.
3-diagramma: Sehr oshkor bo'ldi!
- Boshlanish nuqtasi sifatida bizning konsul mijozimiz kirish so'rovini Kubernetes hisob qaydnomasi tokeni va avval yaratilgan avtorizatsiya usulining maxsus namunasi nomi bilan konsul serverimizga yuboradi. Ushbu qadam oldingi sxema tushuntirishidagi 3-bosqichga mos keladi.
- Endi Konsul serveri (yoki rahbar) olingan tokenning haqiqiyligini tekshirishi kerak. Shuning uchun u Kubernetes klasteri bilan maslahatlashadi (Konsul mijozi orqali) va tegishli ruxsatnomalar bilan biz token haqiqiy yoki kimga tegishli ekanligini bilib olamiz.
- Tasdiqlangan so'rov konsul rahbariga qaytariladi va konsul serveri kirish so'rovidan (va Kubernetes turi) ko'rsatilgan nom bilan avtorizatsiya usuli misolini qidiradi.
- Konsul rahbari ko'rsatilgan ruxsat berish usuli misolini (agar topilsa) aniqlaydi va unga biriktirilgan majburiy qoidalar to'plamini o'qiydi. Keyin u ushbu qoidalarni o'qiydi va ularni tasdiqlangan identifikatsiya atributlari bilan taqqoslaydi.
- TA-dah! Oldingi sxemani tushuntirishda 5-bosqichga o'tamiz.
Konsul-serverni oddiy virtual mashinada ishga tushiring
Bundan buyon men asosan ushbu POCni qanday yaratish bo'yicha ko'rsatmalar beraman, ko'pincha o'q nuqtalarida, to'liq jumla tushuntirishlarisiz. Bundan tashqari, yuqorida ta'kidlab o'tilganidek, men barcha infratuzilmani yaratish uchun GCP dan foydalanaman, lekin siz boshqa joyda bir xil infratuzilmani yaratishingiz mumkin.
- Virtual mashinani ishga tushiring (misol/server).
- Xavfsizlik devori uchun qoida yarating (AWSda xavfsizlik guruhi):
- Men qoidaga ham, tarmoq tegiga ham bir xil mashina nomini belgilashni yaxshi ko'raman, bu holda "skywiz-consul-server-poc".
- Mahalliy kompyuteringizning IP manzilini toping va uni manba IP manzillar ro'yxatiga qo'shing, shunda biz foydalanuvchi interfeysiga (UI) kiramiz.
- UI uchun 8500 portini oching. Yaratish-ni bosing. Tez orada bu xavfsizlik devorini yana o'zgartiramiz [].
- Misol uchun xavfsizlik devori qoidasini qo'shing. Konsul serveridagi VM asboblar paneliga qayting va tarmoq teglari maydoniga "skywiz-consul-server-poc" ni qo'shing. Saqlash tugmasini bosing.
- Konsulni virtual mashinaga o'rnating, bu erda tekshiring. Esda tutingki, sizga Konsul versiyasi ≥ 1.5 [havola]
- Keling, bitta tugun konsul yarataylik - konfiguratsiya quyidagicha.
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- Konsulni o'rnatish va 3 ta tugunli klasterni o'rnatish bo'yicha batafsil qo'llanma uchun qarang .
- Quyidagi tarzda /etc/consul.d/agent.json faylini yarating []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Konsul serverimizni ishga tushiring:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Siz bir nechta chiqishni ko'rishingiz va "... ACL tomonidan bloklangan yangilanish" bilan yakunlashingiz kerak.
- Konsul serverining tashqi IP-manzilini toping va 8500-portda ushbu IP-manzil bilan brauzerni oching. UI ochilganligiga ishonch hosil qiling.
- Kalit/qiymat juftligini qo‘shib ko‘ring. Bu yerda xato bo'lishi kerak. Buning sababi, biz Konsul serverini ACL bilan yukladik va barcha qoidalarni o'chirib qo'ydik.
- Konsul serveridagi qobiqqa qayting va uni ishga tushirish uchun jarayonni fonda yoki boshqa usulda boshlang va quyidagilarni kiriting:
consul acl bootstrap- "SecretID" qiymatini toping va foydalanuvchi interfeysiga qayting. ACL yorlig'ida siz ko'chirilgan tokenning maxfiy identifikatorini kiriting. SecretID-ni boshqa joyga nusxalash, keyinroq kerak bo'ladi.
- Endi kalit/qiymat juftligini qo'shing. Ushbu POC uchun quyidagilarni qo'shing: kalit: “custom-ns/test_key”, qiymat: “Men custom-ns papkasidaman!”
Daemonset sifatida konsul mijozi bilan bizning dasturimiz uchun Kubernetes klasterini ishga tushirish
- K8s (Kubernetes) klasterini yarating. Tezroq kirish uchun biz uni server bilan bir zonada yaratamiz va shuning uchun ichki IP manzillar bilan osongina ulanish uchun bir xil quyi tarmoqdan foydalanishimiz mumkin. Biz uni “skywiz-app-with-consul-client-poc” deb ataymiz.
- Yon eslatma sifatida, Consul Connect bilan POC Konsul klasterini o'rnatish paytida men ko'rgan yaxshi qo'llanma.
- Shuningdek, biz kengaytirilgan qiymatlar fayli bilan Hashicorp rul jadvalidan foydalanamiz.
- Helm-ni o'rnating va sozlang. Konfiguratsiya bosqichlari:
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- rul jadvali:
- Quyidagi qiymat faylidan foydalaning (e'tibor bering, men eng ko'p o'chirib qo'yganman):
### 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- Rulda diagrammasini qo'llash:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Ishlamoqchi bo'lganida, konsul serveri uchun ruxsatlar kerak bo'ladi, shuning uchun ularni qo'shamiz.
- Klaster asboblar panelida joylashgan "Pod manzillar diapazoni" ga e'tibor bering va "skywiz-consul-server-poc" xavfsizlik devori qoidasiga qayting.
- Pod uchun manzillar oralig'ini IP manzillar ro'yxatiga qo'shing va 8301 va 8300 portlarini oching.
- Konsul foydalanuvchi interfeysiga o'ting va bir necha daqiqadan so'ng tugunlar yorlig'ida bizning klasterimiz paydo bo'lishini ko'rasiz.
Konsulni Kubernetes bilan integratsiyalash orqali avtorizatsiya usulini sozlash
- Konsul serverining qobig'iga qayting va avval saqlangan tokenni eksport qiling:
export CONSUL_HTTP_TOKEN=<SecretID>- Auth usulining namunasini yaratish uchun bizga Kubernetes klasterimizdan ma'lumot kerak bo'ladi:
- kubernetes-xost
kubectl get endpoints | grep kubernetes- kubernetes-xizmat-hisob-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:- Token base64 kodlangan, shuning uchun uni sevimli vositangiz yordamida hal qiling []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- "ca.crt" sertifikatini oling (base64 dekodlashdan keyin) va uni "ca.crt" fayliga yozing.
- Endi autentifikatsiya usulini ishga tushiring, to'ldiruvchilarni hozirgina olingan qiymatlar bilan almashtiring.
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>"- Keyin biz qoida yaratishimiz va uni yangi rolga biriktirishimiz kerak. Ushbu qism uchun siz Konsul UI dan foydalanishingiz mumkin, ammo biz buyruq qatoridan foydalanamiz.
- Qoida yozing
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Qoidani qo'llang
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- Chiqishdan hozirgina yaratgan qoida identifikatorini toping.
- Yangi qoida bilan rol yarating.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Endi biz yangi rolimizni auth usuli misoli bilan bog'laymiz. E'tibor bering, "selektor" bayrog'i bizning kirish so'rovimiz ushbu rolni oladimi yoki yo'qligini aniqlaydi. Boshqa tanlov variantlari uchun bu yerni tekshiring:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Nihoyat konfiguratsiyalar
ruxsatlar
- Kirish huquqlarini yarating. Biz konsulga K8s xizmat hisobi tokenini tekshirish va aniqlash uchun ruxsat berishimiz kerak.
- Faylga quyidagilarni yozing :
###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- Keling, kirish huquqlarini yarataylik
kubectl create -f skywiz-poc-consul-server_rbac.yamlKonsul mijoziga ulanish
- Qayd etilganidek Demonsetga ulanishning bir nechta variantlari mavjud, ammo biz quyidagi oddiy yechimga o'tamiz:
- Quyidagi faylni qo'llang [].
### 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- Keyin konfiguratsiya xaritasini yaratish uchun quyidagi o'rnatilgan buyruqdan foydalaning []. Iltimos, biz xizmatimiz nomini nazarda tutayotganimizni unutmang, agar kerak bo'lsa, uni almashtiring.
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}')"]}
EOFAutentifikatsiya usulini sinab ko'rish
Endi sehrni amalda ko'raylik!
- Xuddi shu yuqori darajadagi kalit bilan yana bir nechta kalit papkalarni yarating (ya'ni. /sample_key) va siz tanlagan qiymat. Yangi asosiy yo'llar uchun tegishli siyosat va rollarni yarating. Biz bog'lashni keyinroq qilamiz.
Maxsus nom maydoni testi:
- Keling, o'z nom maydonimizni yarataylik:
kubectl create namespace custom-ns- Keling, yangi nomlar maydonida pod yarataylik. Pod uchun konfiguratsiyani yozing.
###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- Quyidagi ostida yarating:
kubectl create -f poc-ubuntu-custom-ns.yaml- Konteyner ishlagandan so'ng, u erga boring va jingalakni o'rnating.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Endi biz ilgari yaratgan avtorizatsiya usulidan foydalangan holda konsulga kirish so'rovini yuboramiz [].
- Kiritilgan tokenni xizmat qaydnomangizdan ko'rish uchun:
cat /run/secrets/kubernetes.io/serviceaccount/token- Konteyner ichidagi faylga quyidagilarni yozing:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Tizimga kirish!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Yuqoridagi amallarni bir qatorda bajarish uchun (chunki biz bir nechta testlarni o'tkazamiz), siz quyidagilarni qilishingiz mumkin:
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- Ishlaydi! Hech bo'lmaganda shunday bo'lishi kerak. Endi SecretID-ni oling va biz kirishimiz kerak bo'lgan kalit/qiymatga kirishga harakat qiling.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Siz base64 "Qiymat" kodini dekodlashingiz va u foydalanuvchi interfeysidagi custom-ns/test_key qiymatiga mos kelishini ko'rishingiz mumkin. Agar siz ushbu qoʻllanmada yuqoridagi qiymatdan foydalansangiz, kodlangan qiymatingiz IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi boʻladi.
Foydalanuvchi xizmati hisobi testi:
- Quyidagi buyruq yordamida maxsus ServiceAccount yarating [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Pod uchun yangi konfiguratsiya faylini yarating. Iltimos, mehnatni tejash uchun jingalak o'rnatishni qo'shganimni unutmang :)
###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- Shundan so'ng, konteyner ichidagi qobiqni ishga tushiring.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Tizimga kirish!
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- Ruxsat berilmadi. Oh, biz tegishli ruxsatnomalar bilan majburiy bo'lgan yangi qoidalarni qo'shishni unutib qo'ydik, buni hozir qilaylik.
Yuqoridagi oldingi amallarni takrorlang:
a) “custom-sa/” prefiksi uchun bir xil Siyosat yarating.
b) Rol yarating, uni "mos-sa-rol" deb nomlang
c) Siyosatni rolga biriktiring.
- Majburiy qoidalarni yarating (faqat cli/api-dan mumkin). Selektor bayrog'ining turli ma'nosiga e'tibor bering.
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" konteyneridan yana tizimga kiring. Muvaffaqiyat!
- Custom-sa/ kalit yo'liga kirishimizni tekshiring.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Shuningdek, ushbu token "custom-ns/" da kv ga ruxsat bermasligiga ishonch hosil qilishingiz mumkin. "custom-sa" ni "custom-ns" prefiksi bilan almashtirgandan so'ng yuqoridagi buyruqni takrorlang.
Ruxsat berilmadi.
Overlay misoli:
- Shuni ta'kidlash kerakki, barcha qoidalarni bog'laydigan xaritalar ushbu huquqlar bilan tokenga qo'shiladi.
- Bizning "poc-ubuntu-custom-sa" konteynerimiz standart nomlar maydonida - shuning uchun uni boshqa qoidalarni bog'lash uchun ishlataylik.
- Oldingi amallarni takrorlang:
a) “standart/” kalit prefiksi uchun bir xil Siyosat yarating.
b) Rol yarating, uni “default-ns-role” deb nomlang
c) Siyosatni rolga biriktiring. - Qoidalarni bog'lash (faqat cli/api orqali mumkin)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Bizning "poc-ubuntu-custom-sa" konteynerimizga qayting va "standart/" kv yo'liga kirishga harakat qiling.
- Ruxsat berilmadi.
Siz har bir token uchun belgilangan hisobga olish maʼlumotlarini UIda ACL > Tokenlar ostida koʻrishingiz mumkin. Ko'rib turganingizdek, bizning joriy tokenimiz unga faqat bitta "odatiy rol" biriktirilgan. Biz hozirda foydalanayotgan token tizimga kirganimizda yaratilgan va o'sha paytda mos keladigan faqat bitta qoida majburiy edi. Biz yana tizimga kirishimiz va yangi tokendan foydalanishimiz kerak. - Ikkala "custom-sa/" va "standart/" kv yo'llaridan o'qishingiz mumkinligiga ishonch hosil qiling.
Muvaffaqiyat!
Buning sababi, bizning "poc-ubuntu-custom-sa" miz "custom-sa" va "default-ns" qoidalariga mos keladi.
xulosa
TTL tokeni mgmt?
Ushbu yozish vaqtida ushbu avtorizatsiya usuli bilan yaratilgan tokenlar uchun TTLni aniqlashning integratsiyalashgan usuli yo'q. Bu Konsul ruxsatini xavfsiz avtomatlashtirishni ta'minlash uchun ajoyib imkoniyat bo'lar edi.
TTL yordamida tokenni qo'lda yaratish imkoniyati mavjud:
Yaroqlilik muddati - bu token bekor qilinadigan vaqt. (Ixtiyoriy; Konsul 1.5.0 ga qo'shilgan)- Faqat qo'lda yaratish/yangilash uchun mavjud
Umid qilamizki, yaqin kelajakda biz tokenlar qanday yaratilishini nazorat qila olamiz (qoida yoki avtorizatsiya usuli bo'yicha) va TTL qo'shamiz.
Ungacha mantiqingizda chiqish so'nggi nuqtasidan foydalanish tavsiya etiladi.
Shuningdek, bizning blogimizdagi boshqa maqolalarni o'qing:
Manba: www.habr.com