Усё дакладна, пасля рэлізу у пачатку траўня 2019 года ў Consul можна рабіць аўтарызацыю прыкладанняў і службаў, запушчаных у Kubernetes, натыўна.
У гэтым кіраўніцтве мы крок за крокам створым (Праверка канцэпцыі (Proof of concept, PoC - доказ [ажыццяўнасці] канцэпцыі - заўв. перакл.), прадэманстраваўшы гэтую новую функцыю. Ад вас чакаюцца базавыя веды аб Kubernetes і Hashicorp's Consul. І хоць вы можаце выкарыстоўваць любую хмарную платформу або лакальнае асяроддзе, у гэтым кіраўніцтве мы будзем выкарыстоўваць Google's Cloud Platform.
Агляд
Калі мы пяройдзем да , мы атрымаем кароткі агляд яго прызначэння і варыянту выкарыстання, а таксама некаторыя тэхнічныя дэталі і агульны агляд логікі. Я настойліва рэкамендую прачытаць яе прынамсі адзін раз, перш чым працягнуць, бо зараз я буду ўсё гэта тлумачыць і разжоўваць.
Схема 1: Афіцыйны агляд метаду аўтарызацыі Consul
Давайце паглядзім у .
Вядома, там ёсць карысная інфармацыя, але няма кіраўніцтва аб тым, як насамрэч усё гэта выкарыстоўваць. Таму, як любы разважны чалавек, вы прачэсваеце Інтэрнэт у пошуках кіраўніцтва. А потым... Цярпіце паражэнне. Так бывае. Давайце гэта выправім.
Перш чым мы пяройдзем да стварэння нашага POC, давайце вернемся да агляду метадаў аўтарызацыі Consul (Схема 1) і ўдакладнім яго ў кантэксце Kubernetes.
Архітэктура
У гэтым кіраўніцтве мы будзем ствараць Consul-сервер на асобнай машыне, якая будзе ўзаемадзейнічаць з кластарам Kubernetes з усталяваным кліентам Consul. Затым мы створым наша фіктыўнае прыкладанне ў подзе і выкарыстоўваем наш наладжаны метад аўтарызацыі для чытання з нашага Consul key/value сховішчы.
Схема ніжэй дэталёва паказвае архітэктуру, якую мы ствараем у гэтым кіраўніцтве, а таксама логіку метаду аўтарызацыі, якая будзе растлумачана пазней.
Схема 2: Агляд метаду аўтарызацыі ў Kubernetes
Невялікая заўвага: Consul-серверу не трэба жыць за межамі кластара Kubernetes, каб гэта працавала. Але так, ён можа і так і сяк.
Такім чынам, узяўшы аглядную схему Consul (Схема 1) і ўжыўшы да яе Kubernetes, мы атрымліваем схему вышэй (Схема 2), і тут логіка будзе наступная:
- Да кожнага поду будзе прымацаваны службовы ўліковы запіс, які змяшчае токен JWT, згенераваны і вядомы Kubernetes. Гэты токен таксама ўстаўляецца ў пад па змаўчанні.
- Наша дадатак або сэрвіс ўнутры пода ініцыюе каманду ўваходу ў наш Consul-кліент. У запыце на ўваход у сістэму таксама будзе пазначаны наш токен і пазначана імя спецыяльна створанага метаду аўтарызацыі (тыпу Kubernetes). Гэты крок № 2 адпавядае кроку 1 схемы Consul (Схема 1).
- Наш Consul-кліент затым накіруе гэты запыт на наш Consul-сервер.
- МАГІЯ! Менавіта тут Consul-сервер правярае сапраўднасць запыту, збірае звесткі аб ідэнтычнасці запыту і параўноўвае іх з якімі-небудзь асацыяванымі наканаванымі правіламі. Ніжэй будзе іншая схема, каб гэта праілюстраваць. Гэты крок адпавядае крокам 3, 4 і 5 агляднай схемы Consul (Схема 1).
- Наш Consul-сервер генеруе Consul токен з дазволамі ў адпаведнасці з паказанымі намі правіламі метаду аўтарызацыі (якія мы вызначылі) у дачыненні да асобы запытваючага. Затым ён адправіць гэты токен назад. Гэта адпавядае кроку 6 схемы Consul (Схема 1).
- Наш Consul-кліент перанакіроўвае токен запытвальнага з дадаткам або сэрвісу.
Наша дадатак або сэрвіс зараз могуць выкарыстоўваць гэты Consul токен для сувязі з нашымі дадзенымі Consul, як было вызначана прывілеямі токена.
Чараўніцтва раскрыта!
Для тых з вас, хто не задаволены ўсяго толькі трусам з капелюша і хоча ведаць, як гэта працуе… дазвольце мне «паказаць вам, наколькі глыбокая Трусіная нара.
Як згадвалася раней, наш "магічны" крок (Схема 2: Крок 4) складаецца ў тым, што Consul-сервер правярае сапраўднасць запыту, збірае звесткі аб запыце і параўноўвае іх з любымі асацыяванымі наканаванымі правіламі. Гэты крок адпавядае крокам 3, 4 і 5 агляднай схемы Consul (Схема 1). Ніжэй прыведзена схема (Схема 3), мэта якой наглядна паказаць, што насамрэч адбываецца пад капотам канкрэтнага метаду аўтарызацыі Kubernetes.
Схема 3: Чараўніцтва раскрытае!
- У якасці адпраўной кропкі, наш Consul-кліент перанакіроўвае запыт на ўваход на наш Consul-сервер з токенам ўліковага запісу Kubernetes і канкрэтным імем інстанса метаду аўтарызацыі, які быў створаны раней. Гэты крок адпавядае кроку 3 у папярэднім тлумачэнні схемы.
- Цяпер Consul-серверу (ці лідэру) неабходна праверыць сапраўднасць атрыманага токена. Таму ён пракансультуецца з кластарам Kubernetes (праз Consul-кліент) і, пры наяўнасці адпаведных дазволаў, мы высветлім, ці з'яўляецца токен сапраўдным, і каму ён належыць.
- Затым правераны запыт вяртаецца да Consul-лідэра, і на серверы Consul выконваецца пошук інстансу метаду аўтарызацыі з паказаным імем з запыту на ўваход у сістэму (і тыпу Kubernetes).
- Consul-лідэр вызначае ўказаны інстанс метаду аўтарызацыі (калі ён знойдзены) і чытае набор правіл прывязкі, якія да яго прымацаваныя. Затым ён чытае гэтыя правілы і параўноўвае іх з праверанымі атрыбутамі ідэнтычнасці.
- Тады! Пераходзім да кроку 5 у папярэднім тлумачэнні схемы.
Запусціце Consul-server на звычайнай віртуальнай машыне
З гэтага моманту я ў асноўным буду даваць інструкцыі па стварэнні гэтага POC, часта ў пунктах, без тлумачальных цэлых прапаноў. Таксама, як адзначалася раней, я буду выкарыстоўваць GCP для стварэння ўсёй інфраструктуры, але вы можаце стварыць такую ж інфраструктуру ў любым іншым месцы.
- Запусціце віртуальную машыну (інстанс / сервер).
- Стварыце правіла для firewall (група бяспекі ў AWS):
- Мне падабаецца прысвойваць адно і тое ж імя машыны правілу і сеткаваму тэгу, у дадзеным выпадку гэта skywiz-consul-server-poc .
- Знайдзіце IP-адрас вашага лакальнага кампутара і дадайце яго ў спіс зыходных IP-адрасоў, каб мы маглі атрымаць доступ да інтэрфейсу карыстальніка (UI).
- Адкрыйце порт 8500 для UI. Націсніце Create (Стварыць). Мы хутка зноў зменім гэты firewall [].
- Дадайце правіла для firewall да інстанса. Калі ласка, вярніцеся на панэль маніторынгу VM на Consul-серверы і дадайце "skywiz-consul-server-poc" у поле сеткавых тэгаў. Націсніце Save (Захаваць).
- Усталюйце Consul на віртуальную машыну, праверце тут. Памятайце, што вам патрэбна версія Consul ≥ 1.5 [спасылка]
- Створым single node 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- Больш падрабязнае кіраўніцтва па ўстаноўцы Consul і наладзе кластара з 3 нод гл. .
- Стварыце файл /etc/consul.d/agent.json наступным чынам []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Запусціце наш Consul-сервер:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Вы павінны ўбачыць кучу выходных дадзеных і ў канчатковым выніку "… update blocked by ACLs".
- Знайдзіце вонкавы IP-адрас Consul-сервера і адкрыйце браўзэр з гэтым IP-адрасам на порце 8500. Пераканайцеся, што адчыняецца UI.
- Паспрабуйце дадаць пару ключ/значэнне. Павінна быць памылка. Гэта таму, што мы загрузілі Consul-сервер з дапамогай ACL і забаранілі ўсе правілы.
- Калі ласка, вярніцеся да сваёй абалонцы на Consul-серверы і запусціце працэс у фонавым рэжыме або якім-небудзь іншым спосабам, каб ён працаваў, і ўвядзіце наступнае:
consul acl bootstrap- Знайдзіце значэнне "SecretID" і вярніцеся да UI. На ўкладцы "ACL" увядзіце сакрэтны ідэнтыфікатар токена, які вы толькі што скапіявалі. Скапіюйце SecretID яшчэ куды-небудзь, ён спатрэбіцца нам пазней.
- Цяпер дадайце пару ключ/значэнне. Для гэтага POC дадамо наступнае: ключ: "custom-ns/test_key", значэнне: "I'm in the custom-ns folder!"
Запуск Kubernetes-кластара для нашага прыкладання з Consul-кліентам у якасці Daemonset
- Стварыце кластар K8s (Kubernetes). Мы створым яго ў той жа зоне, што і сервер, для хутчэйшага доступу, і таму мы можам выкарыстоўваць тую ж падсетку для простага падлучэння з унутранымі IP-адрасамі. Мы назавем яго "skywiz-app-with-consul-client-poc".
- Як нататка, вось добрае кіраўніцтва, з якім я сутыкнуўся пры наладзе POC Consul-кластара з Consul Connect.
- Мы таксама будзем выкарыстоўваць 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- helm chart:
- Выкарыстоўвайце наступны файл значэнняў (звярніце ўвагу, большасць я адключыў):
### 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 chart:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Пры спробе запуску, яму спатрэбяцца дазволы для Consul-сервера, так што давайце дадамо іх.
- Звярніце ўвагу на "дыяпазон адрасоў Pod", размешчаны на прыборнай панэлі кластара, і вярніцеся да нашага правіла для firewall "skywiz-consul-server-poc".
- Дадайце дыяпазон адрасоў для пода ў спіс IP-адрасоў і адкрыйце парты 8301 і 8300.
- Перайдзіце да Consul UI, і праз некалькі хвілін вы ўбачыце, што наш кластар з'явіцца на ўкладцы нод.
Настройка метаду аўтарызацыі шляхам інтэграцыі Consul з Kubernetes
- Калі ласка, вярніцеся ў абалонку Consul-сервера і экспартуйце токен, які вы захавалі раней:
export CONSUL_HTTP_TOKEN=<SecretID>- Нам спатрэбіцца інфармацыя з нашага Kubernetes-кластара, каб стварыць інстанс метаду auth:
- kubernetes-host
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, замяніўшы placeholders на значэння, якія вы толькі што атрымалі.
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. Звярніце ўвагу, што сцяг селектар вызначае, ці будзе наш запыт на ўваход атрымліваць гэтую ролю. Праверце тут іншыя опцыі селектара:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Канфігурацыі напрыканцы
Правы доступу
- Стварыце правы доступу. Нам трэба даць дазвол Consul на праверку і ідэнтыфікацыю пасведчання токена ўліковага запісу службы 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Падключэнне да Consul Client
- Як адзначалася , ёсць некалькі опцый для падлучэння да 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- Затым ужывяце наступную ўбудаваную каманду для стварэння configmap []. Звярніце ўвагу, што мы спасылаемся на назву нашага сэрвісу, заменіце яго пры неабходнасці.
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Тэставанне auth-метаду
Цяпер давайце паглядзім на магію ў дзеянні!
- Стварыце яшчэ некалькі ключавых тэчак з тым жа ключом верхняга ўзроўня (г.зн. /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- Цяпер мы адправім запыт на ўваход у Consul, выкарыстоўваючы метад аўтарызацыі, які мы стварылі раней [].
- Каб прагледзець уведзены токен са свайго ўліковага запісу службы:
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>”- Вы можаце дэкадаваць «Value» base64 і ўбачыць, што яно адпавядае значэнню ў custom-ns/test_key у UI. Калі вы выкарыстоўвалі тое ж значэнне, прыведзенае вышэй у гэтым кіраўніцтве, ваша кадаванае значэнне будзе IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Тэст уліковага запісу карыстацкай службы:
- Стварыце карыстацкі ServiceAccount з дапамогай наступнай каманды [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Стварыце новы файл канфігурацыі для пода. Звярніце ўвагу, што я ўключыў ўстаноўку 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- Permission denied. О, мы забыліся дадаць новую прывязку правілаў з адпаведнымі дазволамі, давайце зробім гэта зараз.
Паўтарыце папярэднія крокі вышэй:
а) Стварыце ідэнтычную Палітыку для прэфікса "custom-sa/".
б) Стварыце Role, назавіце яе "custom-sa-role"
в) Прымацуеце Палітыку да Role.
- Стварыце 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". Success!
- Праверце наш доступ да ключавога шляху custom-sa/.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Вы таксама можаце пераканацца, што гэты токен не дае доступ да kv у "custom-ns/". Проста паўтарыце прыведзеную вышэй каманду пасля замены "custom-sa" на прэфікс "custom-ns".
У доступе адмоўлена.
Прыклад оверлея:
- Варта адзначыць, што ўсе супастаўленні rule-binding будуць дададзены ў токен з гэтымі правамі.
- Наш кантэйнер "poc-ubuntu-custom-sa" знаходзіцца ў прасторы імёнаў па змаўчанні - так што давайце выкарыстоўваць яго для іншай rule-binding.
- Паўтарыце папярэднія крокі:
а) Стварыце ідэнтычную Палітыку для прэфікса ключа "default/".
б) Стварыце Role, назавіце яе "default-ns-role"
в) Прымацуеце Палітыку да Role. - Стварыце Rule-Binding (магчыма толькі з 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". Токен, які мы выкарыстоўваем у цяперашні час, быў згенераваны, калі мы ўвайшлі ў сістэму, і тады было толькі адно rule-binding, якое тады адпавядала. Нам трэба зноў увайсці ў сістэму і выкарыстоўваць новы токен. - Пераканайцеся, што вы можаце чытаць як са шляхоў "custom-sa/", так і "default/" kv.
Поспех!
Гэта звязана з тым, што наш "poc-ubuntu-custom-sa" адпавядае прывязкам правілаў "custom-sa" і "default-ns".
Заключэнне
TTL token mgmt?
На момант напісання гэтага артыкула не існуе інтэграванага спосабу вызначэння TTL для токенаў, згенераваных гэтым метадам аўтарызацыі. Гэта была б фантастычная магчымасць - забяспечыць бяспечную аўтаматызацыю аўтарызацыі Consul.
Існуе магчымасць уручную стварыць токен з TTL:
Expiration Time (Час заканчэння) - час, калі гэты токен будзе адкліканы. (Неабавязкова; дададзена ў Consul 1.5.0)- Існуе толькі для ручнога стварэння / абнаўлення
Спадзяюся, у бліжэйшы час мы зможам кантраляваць, як генеруюцца токены (для кожнага правіла або метаду аўтарызацыі), і дадаваць TTL.
Датуль прапануецца выкарыстоўваць у сваёй логіцы канчатковы пункт выхаду з сістэмы.
Таксама чытайце іншыя артыкулы ў нашым блогу:
Крыніца: habr.com