Tiesa, po paleidimo 2019 m. gegužės mėn. pradžioje „Consul“ galite autorizuoti programas ir paslaugas, veikiančias „Kubernetes“ vietoje.
Šioje pamokoje mes sukursime žingsnis po žingsnio (Koncepcijos įrodymas, PoC), demonstruojantis šią naują funkciją. Tikimasi, kad turėsite pagrindinių žinių apie Kubernetes ir Hashicorp konsulą. Nors galite naudoti bet kurią debesies platformą arba vietinę aplinką, šioje mokymo programoje naudosime „Google“ debesies platformą.
Peržiūrėti
Jei eisime į , gausime greitą jo paskirties ir naudojimo atvejo apžvalgą, taip pat kai kurias technines detales ir bendrą logikos apžvalgą. Labai rekomenduoju jį perskaityti bent kartą prieš tęsiant, nes dabar viską paaiškinsiu ir kramtysiu.
1 diagrama: Oficiali konsulo leidimo metodo apžvalga
Pažiūrėkime .
Žinoma, ten yra naudingos informacijos, bet nėra vadovo, kaip iš tikrųjų visa tai panaudoti. Taigi, kaip ir bet kuris sveiko proto žmogus, ieškote patarimų internete. Ir tada... Tau nepavyks. Taip atsitinka. Pataisykime tai.
Prieš pereidami prie mūsų POC kūrimo, grįžkime prie Consul autorizacijos metodų apžvalgos (1 diagrama) ir patobulinkime ją Kubernetes kontekste.
Architektūra
Šioje pamokoje mes sukursime Consul serverį atskirame įrenginyje, kuris bendraus su Kubernetes grupe su įdiegtu Consul klientu. Tada sukursime savo fiktyviąją programą podelyje ir naudosime sukonfigūruotą autorizacijos metodą, kad skaitytume iš mūsų konsulinio rakto / vertės saugyklos.
Toliau pateiktoje diagramoje išsamiai aprašoma architektūra, kurią kuriame šiame vadove, ir autorizavimo metodo logika, kuri bus paaiškinta vėliau.
2 diagrama: Kubernetes autorizacijos metodo apžvalga
Greita pastaba: kad tai veiktų, Consul serveris neturi gyventi už Kubernetes klasterio ribų. Bet taip, jis gali tai padaryti taip ir kitaip.
Taigi, paėmę konsulo apžvalgos diagramą (1 diagrama) ir pritaikę jai Kubernetes, gauname aukščiau pateiktą diagramą (2 diagrama), o logika čia yra tokia:
- Prie kiekvieno bloko bus pridėta paslaugos paskyra, kurioje yra JWT prieigos raktas, sugeneruotas ir žinomas Kubernetes. Šis prieigos raktas pagal numatytuosius nustatymus taip pat įterpiamas į rinkinį.
- Mūsų programa arba paslauga podyje inicijuoja prisijungimo komandą mūsų „Consul“ klientui. Prisijungimo užklausoje taip pat bus nurodytas mūsų prieigos raktas ir vardas specialiai sukurtas autorizacijos metodas (Kubernetes tipas). Šis 2 veiksmas atitinka konsulo diagramos 1 veiksmą (1 schema).
- Tada mūsų „Consul“ klientas perduos šią užklausą mūsų „Consul“ serveriui.
- MAGIJA! Čia Consul serveris patikrina užklausos autentiškumą, renka informaciją apie užklausos tapatybę ir lygina ją su visomis susijusiomis iš anksto nustatytomis taisyklėmis. Žemiau yra kita diagrama, iliustruojanti tai. Šis žingsnis atitinka konsulo apžvalgos diagramos 3, 4 ir 5 žingsnius (1 diagrama).
- Mūsų konsulinis serveris generuoja konsulinį prieigos raktą su leidimais pagal mūsų nurodytas autorizavimo metodo taisykles (kurias apibrėžėme) dėl prašytojo tapatybės. Tada jis atsiųs tą žetoną atgal. Tai atitinka konsulo diagramos 6 veiksmą (1 diagrama).
- Mūsų konsulo klientas persiunčia žetoną prašančiai programai ar tarnybai.
Mūsų programa arba paslauga dabar gali naudoti šį konsulinį prieigos raktą, kad susisiektų su mūsų konsulo duomenimis, atsižvelgiant į prieigos rakto privilegijas.
Magija atsiskleidžia!
Tiems iš jūsų, kurie nesidžiaugia tik triušiu iš skrybėlės ir nori sužinoti, kaip tai veikia... leiskite man parodyti, kaip giliai Triušio skylė".
Kaip minėta anksčiau, mūsų „stebuklingas“ veiksmas (2 pav.: 4 veiksmas) yra tas, kai „Consul“ serveris patvirtina užklausą, surenka užklausos informaciją ir palygina ją su bet kokiomis susijusiomis iš anksto nustatytomis taisyklėmis. Šis žingsnis atitinka konsulo apžvalgos diagramos 3, 4 ir 5 žingsnius (1 diagrama). Žemiau yra diagrama (3 diagrama), kurios tikslas yra aiškiai parodyti, kas iš tikrųjų vyksta po gaubtu konkretus Kubernetes autorizacijos metodas.
3 diagrama: magija atskleista!
- Iš pradžių mūsų Consul klientas persiunčia prisijungimo užklausą į mūsų Consul serverį su Kubernetes paskyros prieigos raktu ir konkrečiu anksčiau sukurto autorizacijos metodo egzemplioriaus pavadinimu. Šis veiksmas atitinka 3 veiksmą ankstesniame grandinės paaiškinime.
- Dabar Consul serveris (arba vadovas) turi patikrinti gauto prieigos rakto autentiškumą. Todėl jis konsultuos „Kubernetes“ klasterį (per „Consul“ klientą) ir, turėdamas atitinkamus leidimus, išsiaiškinsime, ar tokenas yra tikras ir kam jis priklauso.
- Tada patvirtinta užklausa grąžinama konsulo vadovui, o „Consul“ serveris suranda autorizavimo metodo egzempliorių nurodytu pavadinimu iš prisijungimo užklausos (ir „Kubernetes“ tipo).
- Konsulo vadovas nustato nurodytą autorizacijos metodo egzempliorių (jei randamas) ir perskaito prie jo pridedamą privalomų taisyklių rinkinį. Tada jis perskaito šias taisykles ir palygina jas su patvirtintais tapatybės atributais.
- TA-dah! Pereikime prie 5 žingsnio ankstesniame grandinės paaiškinime.
Paleiskite „Consul-server“ įprastoje virtualioje mašinoje
Nuo šiol dažniausiai pateiksiu instrukcijas, kaip sukurti šį POC, dažnai ženkleliais, be visų sakinių paaiškinimų. Be to, kaip minėta anksčiau, naudosiu GCP, kad sukurčiau visą infrastruktūrą, bet jūs galite sukurti tą pačią infrastruktūrą bet kur kitur.
- Paleiskite virtualią mašiną (pavyzdį / serverį).
- Sukurkite užkardos taisyklę (saugos grupė AWS):
- Man patinka priskirti tą patį įrenginio pavadinimą ir taisyklei, ir tinklo žymai, šiuo atveju „skywiz-consul-server-poc“.
- Raskite vietinio kompiuterio IP adresą ir pridėkite jį prie šaltinio IP adresų sąrašo, kad galėtume pasiekti vartotojo sąsają (UI).
- Atidarykite 8500 prievadą vartotojo sąsajai. Spustelėkite Sukurti. Greitai vėl pakeisime šią užkardą [].
- Į egzempliorių pridėkite ugniasienės taisyklę. Grįžkite į VM prietaisų skydelį „Consul Server“ ir tinklo žymų lauke pridėkite „skywiz-consul-server-poc“. Spustelėkite Išsaugoti.
- Įdiekite „Consul“ virtualioje mašinoje, patikrinkite čia. Atminkite, kad jums reikia „Consul“ versijos ≥ 1.5 [nuoroda]
- Sukurkime vieną mazgą Consul – konfigūracija tokia.
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- Išsamesnį vadovą, kaip įdiegti „Consul“ ir nustatyti 3 mazgų grupę, žr .
- Sukurkite failą /etc/consul.d/agent.json taip []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Paleiskite mūsų Consul serverį:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Turėtumėte pamatyti daugybę išvesties ir baigti „... naujinimą blokavo ACL“.
- Suraskite išorinį Consul serverio IP adresą ir atidarykite naršyklę su šiuo IP adresu 8500 prievade. Įsitikinkite, kad atidaroma vartotojo sąsaja.
- Pabandykite pridėti rakto / vertės porą. Turi būti klaida. Taip yra todėl, kad įkėlėme Consul serverį ACL ir išjungėme visas taisykles.
- Grįžkite į savo apvalkalą Consul serveryje ir pradėkite procesą fone arba kitu būdu, kad jis paleistų, ir įveskite:
consul acl bootstrap- Raskite „SecretID“ reikšmę ir grįžkite į vartotojo sąsają. ACL skirtuke įveskite slaptą ką tik nukopijuoto prieigos rakto ID. Nukopijuokite SecretID kur nors kitur, mums jo prireiks vėliau.
- Dabar pridėkite rakto / vertės porą. Šiam POC pridėkite: raktas: "custom-ns/test_key", reikšmė: "Aš esu custom-ns aplanke!"
„Kubernetes“ klasterio paleidimas mūsų programai su „Consul“ klientu kaip „Daemonset“.
- Sukurkite K8s (Kubernetes) klasterį. Sukursime jį toje pačioje zonoje kaip ir serveris, kad prieiga būtų greitesnė, todėl galėsime naudoti tą patį potinklį, kad lengvai prisijungtume prie vidinių IP adresų. Pavadinsime tai „skywiz-app-with-consul-client-poc“.
- Pastaba: čia yra gera pamoka, su kuria susidūriau kurdamas POC Consul grupę su Consul Connect.
- Taip pat naudosime Hashicorp vairo diagramą su išplėstiniu verčių failu.
- Įdiekite ir sukonfigūruokite „Helm“. Konfigūravimo žingsniai:
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- vairo diagrama:
- Naudokite šį vertės failą (atminkite, kad daugumą išjungiau):
### 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- Taikykite vairo diagramą:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kai jis bandys paleisti, jam reikės „Consul“ serverio teisių, todėl pridėkime juos.
- Atkreipkite dėmesį į „Pod Address Range“, esantį klasterio prietaisų skydelyje, ir grįžkite į „skywiz-consul-server-poc“ užkardos taisyklę.
- Pridėkite grupės adresų diapazoną prie IP adresų sąrašo ir atidarykite 8301 ir 8300 prievadus.
- Eikite į „Consul“ vartotojo sąsają ir po kelių minučių mazgų skirtuke pamatysite mūsų klasterį.
Autorizacijos metodo konfigūravimas integruojant konsulą su Kubernetes
- Grįžkite į Consul serverio apvalkalą ir eksportuokite anksčiau išsaugotą prieigos raktą:
export CONSUL_HTTP_TOKEN=<SecretID>- Mums reikės informacijos iš mūsų „Kubernetes“ klasterio, kad sukurtume autentifikavimo metodo pavyzdį:
- 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:- Žetonas yra užkoduotas base64, todėl iššifruokite jį naudodami savo mėgstamą įrankį []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Paimkite „ca.crt“ sertifikatą (po „base64“ dekodavimo) ir įrašykite jį į „ca.crt“ failą.
- Dabar sukurkite autentifikavimo metodą, pakeisdami vietos rezervavimo ženklus ką tik gautomis reikšmėmis.
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>"- Tada turime sukurti taisyklę ir pridėti ją prie naujo vaidmens. Šiai daliai galite naudoti Consul UI, bet mes naudosime komandinę eilutę.
- Parašykite taisyklę
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Taikykite taisyklę
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- Iš išvesties raskite ką tik sukurtos taisyklės ID.
- Sukurkite vaidmenį naudodami naują taisyklę.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Dabar mes susiesime savo naują vaidmenį su autentifikavimo metodo pavyzdžiu. Atminkite, kad žyma „selector“ nustato, ar mūsų prisijungimo užklausa gaus šį vaidmenį. Čia rasite kitų parinkimo parinkčių:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Galiausiai konfigūracijos
Prieigos teisės
- Sukurti prieigos teises. Turime duoti konsului leidimą patikrinti ir nustatyti K8s paslaugos paskyros prieigos rakto tapatybę.
- Į failą įrašykite šiuos dalykus :
###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- Sukurkime prieigos teises
kubectl create -f skywiz-poc-consul-server_rbac.yamlPrisijungimas prie konsulinio kliento
- Kaip pažymėta Yra keletas prisijungimo prie demonset parinkčių, tačiau pereisime prie šio paprasto sprendimo:
- Taikykite šį failą [].
### 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- Tada naudokite šią integruotą komandą, kad sukurtumėte konfigūracijos žemėlapį []. Atkreipkite dėmesį, kad mes nurodome savo paslaugos pavadinimą, jei reikia, pakeiskite jį.
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}')"]}
EOFAutentinimo metodo testavimas
Dabar pažiūrėkime, kaip magija veikia!
- Sukurkite dar kelis raktinius aplankus naudodami tą patį aukščiausio lygio klavišą (t. y. /sample_key) ir jūsų pasirinkta vertė. Sukurkite tinkamas strategijas ir vaidmenis naujiems pagrindiniams keliams. Surišimus atliksime vėliau.
Pasirinktinės vardų erdvės testas:
- Sukurkime savo vardų erdvę:
kubectl create namespace custom-ns- Sukurkime grupę naujoje vardų erdvėje. Parašykite bloko konfigūraciją.
###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- Sukurti pagal:
kubectl create -f poc-ubuntu-custom-ns.yaml- Kai konteineris veikia, eikite ten ir įdiekite curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Dabar mes išsiųsime konsului prisijungimo užklausą naudodami anksčiau sukurtą autorizacijos metodą [].
- Norėdami peržiūrėti įvestą prieigos raktą iš savo paslaugos paskyros:
cat /run/secrets/kubernetes.io/serviceaccount/token- Į failą konteinerio viduje įrašykite:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Prisijungti!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Norėdami atlikti pirmiau nurodytus veiksmus vienoje eilutėje (nes vykdysime kelis bandymus), galite atlikti šiuos veiksmus:
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- Veikia! Bent jau turėtų. Dabar paimkite SecretID ir pabandykite pasiekti raktą / vertę, prie kurios turėtume turėti prieigą.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Galite „base64“ iššifruoti „vertę“ ir pamatyti, ar ji atitinka vartotojo sąsajos reikšmę custom-ns/test_key. Jei šioje mokymo programoje naudojote tą pačią vertę, užkoduota vertė būtų IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Vartotojo paslaugos paskyros testas:
- Sukurkite tinkintą paslaugos paskyrą naudodami šią komandą [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Sukurkite naują rinkinio konfigūracijos failą. Atkreipkite dėmesį, kad sutaupiau darbo jėgos, įtraukiau garbanos įrengimą :)
###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- Po to konteinerio viduje paleiskite apvalkalą.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Prisijungti!
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- Leidimas nesuteiktas. Oi, pamiršome pridėti naujas taisykles, privalomas su atitinkamais leidimais, padarykime tai dabar.
Pakartokite anksčiau nurodytus veiksmus:
a) Sukurkite identišką politiką priešdėliui „custom-sa/“.
b) Sukurkite vaidmenį, pavadinkite jį „priskirtu vaidmeniu“
c) Pridėkite politiką prie vaidmens.
- Sukurkite taisyklę (galima tik iš cli/api). Atkreipkite dėmesį į skirtingą parinkiklio vėliavėlės reikšmę.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Prisijunkite dar kartą naudodami konteinerį „poc-ubuntu-custom-sa“. Sėkmė!
- Patikrinkite mūsų prieigą prie pasirinktinio-sa/ key kelio.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Taip pat galite užtikrinti, kad šis prieigos raktas nesuteiktų prieigos prie kv „custom-ns/“. Tiesiog pakartokite aukščiau pateiktą komandą, pakeitę „custom-sa“ priešdėliu „custom-ns“.
Leidimas nesuteiktas.
Perdangos pavyzdys:
- Verta paminėti, kad visi taisykles privalomi atvaizdai bus įtraukti į prieigos raktą su šiomis teisėmis.
- Mūsų sudėtinis rodinys „poc-ubuntu-custom-sa“ yra numatytojoje vardų erdvėje, todėl naudokite jį kitokiam taisyklių surišimui.
- Pakartokite ankstesnius veiksmus:
a) Sukurkite identišką „numatytasis/“ rakto priešdėlio politiką.
b) Sukurkite vaidmenį, pavadinkite jį „default-ns-role“
c) Pridėkite politiką prie vaidmens. - Sukurkite taisyklę (galima tik iš 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"'- Grįžkite į mūsų „poc-ubuntu-custom-sa“ konteinerį ir pabandykite pasiekti „numatytąjį/“ kv kelią.
- Leidimas nesuteiktas.
Nurodytus kiekvieno prieigos rakto kredencialus galite peržiūrėti UI dalyje ACL > Ženklai. Kaip matote, mūsų dabartinis prieigos raktas turi tik vieną „pasirinktinį vaidmenį“. Žetonas, kurį šiuo metu naudojame, buvo sugeneruotas prisijungus ir tada atitiko tik viena taisyklė. Turime vėl prisijungti ir naudoti naują prieigos raktą. - Įsitikinkite, kad galite skaityti iš „custom-sa/“ ir „default/“ kv kelių.
Sėkmė!
Taip yra todėl, kad mūsų „poc-ubuntu-custom-sa“ atitinka „custom-sa“ ir „default-ns“ taisyklių susiejimą.
išvada
TTL prieigos raktas mgmt?
Šio rašymo metu nėra integruoto būdo nustatyti žetonų, sugeneruotų naudojant šį autorizacijos metodą, TTL. Tai būtų puiki galimybė užtikrinti saugų konsulo įgaliojimų automatizavimą.
Yra galimybė rankiniu būdu sukurti prieigos raktą naudojant TTL:
Galiojimo laikas – laikas, kada šis prieigos raktas bus atšauktas. (Pasirenkama; įtraukta į Consul 1.5.0)- Yra tik rankiniam kūrimui / atnaujinimui
Tikimės, kad artimiausiu metu galėsime kontroliuoti, kaip generuojami žetonai (pagal taisyklę arba autorizacijos metodą) ir pridėti TTL.
Iki tol savo logikoje siūloma naudoti atsijungimo galinį tašką.
Taip pat skaitykite kitus mūsų tinklaraščio straipsnius:
Šaltinis: www.habr.com