Энэ нь суллагдсаны дараа зөв юм 2019 оны XNUMX-р сарын эхээр Консулд та Kubernetes-д ажиллаж байгаа програмууд болон үйлчилгээнүүдэд зөвшөөрөл олгох боломжтой.
Энэ зааварт бид алхам алхмаар бүтээх болно (Үзэл баримтлалын баталгаа, PoC) энэ шинэ функцийг харуулж байна. Та Kubernetes болон Hashicorp-ийн консулын талаар анхан шатны мэдлэгтэй байх ёстой. Та ямар ч үүлэн платформ эсвэл дотоод орчныг ашиглах боломжтой боловч энэ зааварт бид Google-ийн Cloud Platform-ийг ашиглах болно.
тойм
Хэрэв бид очвол , бид түүний зорилго, ашиглалтын тухай товч тойм, түүнчлэн зарим техникийн дэлгэрэнгүй мэдээлэл, логикийн ерөнхий тоймыг авах болно. Би үргэлжлүүлэхээсээ өмнө дор хаяж нэг удаа уншихыг зөвлөж байна, учир нь би одоо бүгдийг нь тайлбарлаж, зажлах болно.
Диаграм 1: Консулын зөвшөөрлийн аргын албан ёсны тойм
Дотогшоо харцгаая .
Мэдээж хэрэг, тэнд хэрэгтэй мэдээлэл байгаа ч энэ бүгдийг хэрхэн ашиглах талаар заавар байхгүй. Тиймээс та ямар ч эрүүл ухаантай хүний адил заавар авахын тулд интернетээр хайдаг. Тэгээд... Чи бүтэлгүйтлээ. Энэ нь тохиолддог. Үүнийг засъя.
Бид POC-ээ үүсгэхийн өмнө Консулын зөвшөөрлийн аргуудын тойм руу буцаж очоод (Диаграм 1) Кубернетесийн контекстэд оруулъя.
архитектур
Энэ зааварт бид Консулын үйлчлүүлэгчийг суулгасан Kubernetes кластертай харилцах тусдаа машин дээр Консулын сервер үүсгэх болно. Дараа нь бид pod-д хуурамч програмаа үүсгэж, Консулын түлхүүр/үнэ цэнэгийн дэлгүүрээс уншихын тулд тохируулсан зөвшөөрлийн аргыг ашиглана.
Доорх диаграммд бидний энэ зааварт бий болгож буй архитектур, мөн зөвшөөрлийн аргын цаадах логикийн талаар дэлгэрэнгүй тайлбарлах бөгөөд үүнийг дараа нь тайлбарлах болно.
Диаграм 2: Kubernetes-ийн зөвшөөрлийн аргын тойм
Шуурхай тэмдэглэл: Консулын сервер үүнийг ажиллуулахын тулд Кубернетес кластераас гадуур амьдрах шаардлагагүй. Гэхдээ тийм ээ, тэр үүнийг ингэж, тэгж чадна.
Тиймээс Консулын тойм диаграмыг (1-р диаграмм) авч, Кубернетесийг ашигласнаар дээрх диаграммыг (диаграм 2) авах бөгөөд энд логик нь дараах байдалтай байна.
- Под бүр Kubernetes-ийн үүсгэсэн, мэддэг JWT токен агуулсан үйлчилгээний данстай байх болно. Энэ токеныг мөн анхдагчаар pod-д оруулсан болно.
- Под доторх манай програм эсвэл үйлчилгээ нь манай консулын үйлчлүүлэгч рүү нэвтрэх командыг эхлүүлдэг. Нэвтрэх хүсэлтэд бидний жетон болон нэрийг мөн оруулна тусгайлан бүтээсэн зөвшөөрлийн арга (Кубернетес төрөл). Энэ алхам №2 нь Консулын диаграммын 1-р алхамтай тохирч байна (Схем 1).
- Манай консулын үйлчлүүлэгч энэ хүсэлтийг манай консулын сервер рүү дамжуулах болно.
- ШИДЭТ! Энд Консулын сервер хүсэлтийн үнэн зөвийг шалгаж, хүсэлтийн хувийн мэдээллийг цуглуулж, холбогдох урьдчилан тодорхойлсон дүрмүүдтэй харьцуулдаг. Үүнийг харуулах өөр нэг диаграмыг доор харуулав. Энэ алхам нь Консулын тойм диаграмын 3, 4, 5-р алхамтай тохирч байна (диаграм 1).
- Манай Консулын сервер нь хүсэлт гаргагчийн хувийн мэдээлэлтэй холбоотой бидний тодорхойлсон зөвшөөрлийн аргын дүрмийн дагуу (бидний тодорхойлсон) зөвшөөрлийн дагуу консулын жетон үүсгэдэг. Дараа нь тэр жетоныг буцааж илгээх болно. Энэ нь Консулын диаграммын 6-р алхамтай тохирч байна (диаграм 1).
- Манай консулын үйлчлүүлэгч жетоныг хүсэлт гаргасан програм эсвэл үйлчилгээ рүү дамжуулдаг.
Манай аппликейшн эсвэл үйлчилгээ нь жетоны давуу эрхээр тодорхойлогдсон Консулын мэдээлэлтэй холбогдохын тулд энэхүү Консул жетоныг ашиглах боломжтой боллоо.
Ид шид илчлэв!
Зөвхөн малгайнаас гарсан туулайд сэтгэл хангалуун бус, энэ нь хэрхэн ажилладагийг мэдэхийг хүсч буй хүмүүст зориулав... Туулайн нүх".
Өмнө дурьдсанчлан, бидний "шидэт" алхам (Зураг 2: Алхам 4) нь Консулын сервер хүсэлтийг баталгаажуулж, хүсэлтийн талаарх мэдээллийг цуглуулж, холбогдох урьдчилан тодорхойлсон дүрмүүдтэй харьцуулах явдал юм. Энэ алхам нь Консулын тойм диаграмын 3, 4, 5-р алхамтай тохирч байна (диаграм 1). Доорх нь диаграмм (диаграмм 3) бөгөөд түүний зорилго нь юу болж байгааг тодорхой харуулах явдал юм хамар доор Kubernetes зөвшөөрлийн тусгай арга.
Диаграм 3: Ид шид илчлэв!
- Эхлэх цэг болгон манай консулын үйлчлүүлэгч Кубернетес дансны токен болон өмнө нь үүсгэсэн зөвшөөрлийн аргын тодорхой жишээний нэрээр нэвтрэх хүсэлтийг манай консулын сервер рүү илгээдэг. Энэ алхам нь өмнөх хэлхээний тайлбарын 3-р алхамтай тохирч байна.
- Одоо Консулын сервер (эсвэл удирдагч) хүлээн авсан жетоны жинхэнэ эсэхийг шалгах шаардлагатай. Тиймээс энэ нь Кубернетес кластертай (Консул үйлчлүүлэгчээр дамжуулан) зөвлөгөө өгөх бөгөөд зохих зөвшөөрлийн дагуу бид жетон жинхэнэ эсэх, хэнд хамаарах болохыг олж мэдэх болно.
- Баталгаажсан хүсэлтийг дараа нь консулын ахлагч руу буцааж өгөх ба Консулын сервер нэвтрэх хүсэлтээс (болон Kubernetes төрлийн) заасан нэр бүхий зөвшөөрлийн аргын жишээг хайдаг.
- Консулын удирдагч заасан зөвшөөрлийн аргын жишээг (хэрэв олдвол) тодорхойлж, түүнд хавсаргасан заавал биелүүлэх дүрмийн багцыг уншина. Дараа нь эдгээр дүрмийг уншиж, баталгаажуулсан таних шинж чанаруудтай харьцуулна.
- ТА-дах! Өмнөх хэлхээний тайлбарын 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" утгыг олоод UI руу буцна уу. ACL таб дээр саяхан хуулсан жетоны нууц ID-г оруулна уу. SecretID-г өөр газар хуулна уу, бидэнд дараа хэрэгтэй болно.
- Одоо түлхүүр/утга хос нэмнэ үү. Энэ POC-д дараахыг нэмнэ үү: түлхүүр: "custom-ns/test_key", утга: "Би custom-ns хавтсанд байна!"
Консулын үйлчлүүлэгчтэй Демонсет хэлбэрээр манай програмд зориулж Kubernetes кластер ажиллуулж байна
- K8s (Kubernetes) кластер үүсгэ. Бид үүнийг сервертэй нэг бүсэд үүсгэх бөгөөд ингэснээр бид ижил дэд сүлжээг ашиглан дотоод IP хаягтай хялбар холбогдох боломжтой болно. Бид үүнийг "skywiz-app-with-consul-client-poc" гэж нэрлэх болно.
- Хажуугийн тэмдэглэл болгон Consul Connect-тэй POC Consul кластер байгуулах явцад олж мэдсэн сайн зааварчилгааг энд оруулав.
- Мөн бид өргөтгөсөн утгын файл бүхий Hashicorp helm chart-ийг ашиглах болно.
- 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- жолооны диаграм:
- Дараах утгын файлыг ашиглана уу (би ихэнхийг идэвхгүй болгосон гэдгийг анхаарна уу):
### 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 Address Range"-г тэмдэглээд манай "skywiz-consul-server-poc" галт ханын дүрмийг эргэн харна уу.
- Под хаягийн мужийг IP хаягуудын жагсаалтад нэмээд 8301 болон 8300 портуудыг нээнэ үү.
- Консулын UI руу очоод хэдэн минутын дараа зангилааны таб дээр манай кластер гарч ирэхийг харах болно.
Консулыг Кубернетестэй нэгтгэх замаар зөвшөөрөл олгох аргыг тохируулах
- Консул серверийн бүрхүүл рүү буцаж, өмнө нь хадгалсан токеноо экспортлоорой:
export CONSUL_HTTP_TOKEN=<SecretID>- Баталгаажуулах аргын жишээг үүсгэхийн тулд бидэнд Кубернетес кластераас мэдээлэл хэрэгтэй болно.
- 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" файл руу бичнэ үү.
- Одоо баталгаажуулах аргыг эхлүүлж, орлуулагчдыг саяхан хүлээн авсан утгуудаар солино.
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 аргын жишээтэй холбох болно. "Сонгогч" туг нь бидний нэвтрэх хүсэлтийг энэ үүргийг хүлээн авах эсэхийг тодорхойлдог гэдгийг анхаарна уу. Сонгогчийн бусад сонголтыг эндээс шалгана уу:
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Баталгаажуулах аргыг туршиж байна
Одоо ид шидийг хэрхэн ажиллаж байгааг харцгаая!
- Ижил дээд түвшний түлхүүрээр хэд хэдэн түлхүүр хавтас үүсгэнэ үү (жишээ нь. / дээжийн_түлхүүр) болон таны сонгосон утга. Шинэ гол замуудад тохирох бодлого, үүргийг бий болго. Бид дараа нь бэхэлгээ хийх болно.
Тусгай нэрийн орон зайн тест:
- Өөрийн нэрийн орон зайг үүсгэцгээе:
kubectl create namespace custom-ns- Шинэ нэрийн талбартаа pod үүсгэцгээе. Pod-ийн тохиргоог бичнэ үү.
###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 байх болно.
Хэрэглэгчийн үйлчилгээний бүртгэлийн тест:
- Дараах тушаалыг ашиглан захиалгат ServiceAccount үүсгэнэ үү.].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Pod-д зориулж шинэ тохиргооны файл үүсгэ. Хөдөлмөр хэмнэхийн тулд би curl суулгацыг оруулсан гэдгийг анхаарна уу :)
###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/” угтвартай ижил бодлого үүсгэнэ үү.
б) Дүрийг бий болгож, үүнийг "захиалгат үүрэг" гэж нэрлэнэ
в) Бодлогыг үүрэгт хавсаргана.
- Дүрмийг холбох (зөвхөн 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) "Анхдагч/" товчлуурын угтвартай ижил бодлогыг үүсгэ.
б) Үүрэг үүсгээд, үүнийг "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" контейнер руу буцаж очоод "өгөгдмөл/" kv зам руу нэвтрэхийг оролдоно уу.
- Зөвшөөрөл татгалзсан.
Та UI дахь токен бүрийн заасан итгэмжлэлүүдийг ACL > Токенууд хэсгээс харах боломжтой. Таны харж байгаагаар манай одоогийн жетон түүнд зөвхөн нэг “захиалгат үүрэг” хавсаргасан байна. Бидний одоо ашиглаж байгаа токен нь биднийг нэвтрэх үед үүсгэгдсэн бөгөөд тухайн үед таарч байсан ганц дүрэм журамтай байсан. Бид дахин нэвтэрч, шинэ токен ашиглах хэрэгтэй. - Та "custom-sa/" болон "default/" kv замыг хоёуланг нь уншиж чадах эсэхээ шалгаарай.
Амжилт!
Учир нь манай "poc-ubuntu-custom-sa" нь "custom-sa" болон "default-ns" дүрмийн холболттой таарч байгаа юм.
дүгнэлт
TTL жетон мгмт?
Үүнийг бичиж байх үед энэ зөвшөөрлийн аргаар үүсгэсэн жетонуудын TTL-ийг тодорхойлох нэгдсэн арга байхгүй. Энэ нь Консулын зөвшөөрлийг найдвартай автоматжуулах гайхалтай боломж байх болно.
TTL-ээр токеныг гараар үүсгэх сонголт байдаг:
Дуусах хугацаа - Энэ жетон хүчингүй болох цаг. (Заавал биш; Консул 1.5.0-д нэмсэн)- Зөвхөн гараар үүсгэх/шинэчлэх зориулалттай
Ойрын ирээдүйд бид жетоныг хэрхэн үүсгэхийг (дүрэм эсвэл зөвшөөрлийн аргын дагуу) хянаж, TTL нэмэх боломжтой болно гэж найдаж байна.
Тэр болтол логикдоо гарах төгсгөлийн цэгийг ашиглахыг зөвлөж байна.
Мөн манай блог дээрх бусад нийтлэлүүдийг уншина уу:
Эх сурвалж: www.habr.com