🥇 Kynning á Kubernetes leyfi Hashicorp Consul

Það er rétt, eftir útgáfu Hashicorp ræðismaður 1.5.0 í byrjun maí 2019, í Consul geturðu heimilað forrit og þjónustu sem keyrir innfæddur í Kubernetes.

Í þessari kennslu munum við búa til skref fyrir skref POC (Proof of concept, PoC) sem sýnir þennan nýja eiginleika. Gert er ráð fyrir að þú hafir grunnþekkingu á Kubernetes og ræðismanni Hashicorp. Þó að þú getir notað hvaða skýjapallur sem er eða umhverfi á staðnum, þá munum við nota skýjapallinn frá Google í þessari kennslu.

Skoða

Ef við förum til Skoðaðu skjöl um heimildaraðferð þess, fáum við fljótt yfirlit yfir tilgang þess og notkunartilvik, auk nokkurra tæknilegra upplýsinga og almennt yfirlit yfir rökfræðina. Ég mæli eindregið með því að lesa hana að minnsta kosti einu sinni áður en lengra er haldið, þar sem ég mun nú útskýra og tyggja þetta allt saman.

Mynd 1: Opinbert yfirlit yfir leyfisaðferð ræðismanns

Við skulum líta inn skjöl fyrir tiltekna Kubernetes heimildaraðferð.

Vissulega eru gagnlegar upplýsingar þar, en það er engin leiðarvísir um hvernig eigi að nota þær í raun og veru. Svo, eins og hver heilvita maður, leitar þú á netinu til að fá leiðbeiningar. Og svo... Þú mistakast. Það gerist. Við skulum laga þetta.

Áður en við förum að búa til POC okkar skulum við fara aftur í yfirlitið yfir heimildaraðferðir Consul (Mynd 1) og betrumbæta það í samhengi við Kubernetes.

arkitektúr

Í þessari kennslu munum við búa til Consul miðlara á sérstakri vél sem mun hafa samskipti við Kubernetes þyrping með Consul biðlara uppsettan. Við munum síðan búa til dummy-forritið okkar í hólfinu og nota uppsettu heimildaraðferðina okkar til að lesa úr Consul lykil-/gildaversluninni okkar.

Skýringarmyndin hér að neðan sýnir arkitektúrinn sem við erum að búa til í þessari kennslu, sem og rökfræðina á bak við heimildaraðferðina, sem verður útskýrð síðar.

Mynd 2: Yfirlit yfir Kubernetes heimildaraðferð

Fljótleg athugasemd: Consul-þjónninn þarf ekki að búa utan Kubernetes-klasans til að þetta virki. En já, hann getur gert þetta svona og svona.

Svo, með því að taka Consul yfirlitsmyndina (Mynd 1) og nota Kubernetes á það, fáum við skýringarmyndina hér að ofan (Mynd 2), og rökfræðin hér er sem hér segir:

Hver belg mun hafa þjónustureikning tengdan við sig sem inniheldur JWT tákn sem er búið til og þekkt af Kubernetes. Þessi tákn er líka sjálfgefið sett inn í hólfið.
Forritið okkar eða þjónusta inni í hólfinu kemur af stað innskráningarskipun til Consul viðskiptavinar okkar. Innskráningarbeiðnin mun einnig innihalda auðkenni okkar og nafn sérstaklega búið til heimildaraðferð (gerð Kubernetes). Þetta skref #2 samsvarar skrefi 1 í skýringarmyndinni Consul (Skema 1).
Consul viðskiptavinur okkar mun síðan senda þessa beiðni til Consul netþjónsins okkar.
GALDRAR! Þetta er þar sem Consul-þjónninn sannreynir áreiðanleika beiðninnar, safnar upplýsingum um auðkenni beiðninnar og ber þær saman við allar tengdar fyrirfram skilgreindar reglur. Hér að neðan er önnur skýringarmynd til að sýna þetta. Þetta skref samsvarar skrefum 3, 4 og 5 á yfirlitsmynd ræðismanns (Mynd 1).
Consul-þjónninn okkar býr til Consul-tákn með heimildum í samræmi við tilgreindar heimildaraðferðarreglur okkar (sem við höfum skilgreint) varðandi auðkenni beiðanda. Það mun síðan senda þessi tákn til baka. Þetta samsvarar skrefi 6 á ræðismyndinni (mynd 1).
Consul viðskiptavinur okkar sendir táknið til umsóknar eða þjónustu sem biður um.

Forritið okkar eða þjónusta getur nú notað þetta Consul-tákn til að hafa samskipti við Consul-gögnin okkar, eins og ákvarðað er af forréttindum táknsins.

Galdurinn kemur í ljós!

Fyrir ykkur sem eruð ekki ánægð með bara kanínu úr hatti og viljið vita hvernig það virkar... leyfið mér að "sýna ykkur hversu djúpt kanínuholu'.

Eins og fyrr segir er „töfra“ skrefið okkar (Mynd 2: Skref 4) þar sem Consul-þjónninn sannvotir beiðnina, safnar upplýsingum um beiðnina og ber þær saman við allar tengdar fyrirfram skilgreindar reglur. Þetta skref samsvarar skrefum 3, 4 og 5 á yfirlitsmynd ræðismanns (Mynd 1). Hér að neðan er skýringarmynd (Mynd 3) en tilgangur hennar er að sýna skýrt hvað er í raun að gerast undir húddinu sérstök Kubernetes heimildaraðferð.

Mynd 3: Galdurinn kemur í ljós!

Sem upphafspunktur sendir Consul viðskiptavinur okkar innskráningarbeiðnina til Consul netþjónsins okkar með Kubernetes reikningslykilinu og tilteknu tilviksheiti heimildaraðferðarinnar sem var stofnuð áður. Þetta skref samsvarar skrefi 3 í fyrri hringrásarskýringunni.
Nú þarf ræðisþjónninn (eða leiðtoginn) að sannreyna áreiðanleika móttekins tákns. Þess vegna mun það hafa samráð við Kubernetes klasann (í gegnum Consul viðskiptavininn) og, með viðeigandi heimildum, munum við komast að því hvort táknið sé ósvikið og hverjum það tilheyrir.
Staðfesta beiðninni er síðan skilað til Consul leiðtogans og Consul þjónninn flettir upp heimildaraðferðartilvikinu með tilgreindu nafni úr innskráningarbeiðninni (og Kubernetes gerð).
Ræðismaður leiðtogi auðkennir tilgreint heimildaraðferðartilvik (ef það finnst) og les sett af bindandi reglum sem fylgja því. Það les síðan þessar reglur og ber þær saman við staðfesta auðkenniseiginleika.
TA-dah! Höldum áfram í skref 5 í fyrri hringrásarskýringunni.

Keyra Consul-miðlara á venjulegri sýndarvél

Héðan í frá mun ég að mestu gefa leiðbeiningar um hvernig á að búa til þennan POC, oft í punktum, án skýringa á fullum setningum. Eins og áður hefur komið fram mun ég nota GCP til að búa til alla innviði, en þú getur búið til sömu innviði hvar sem er annars staðar.

Ræstu sýndarvélina (tilvik/þjónn).

Búðu til reglu fyrir eldvegginn (öryggishópur í AWS):
Mér finnst gaman að úthluta sama vélarheiti fyrir bæði regluna og netmerkið, í þessu tilviki "skywiz-consul-server-poc".
Finndu IP tölu staðbundinnar tölvunnar þinnar og bættu því við listann yfir uppruna IP tölur svo við getum fengið aðgang að notendaviðmótinu (UI).
Opnaðu port 8500 fyrir UI. Smelltu á Búa til. Við munum breyta þessum eldvegg aftur fljótlega [tengill].
Bættu eldveggsreglu við tilvikið. Farðu aftur í VM mælaborðið á Consul Server og bættu „skywiz-consul-server-poc“ við netmerkisreitinn. Smelltu á Vista.

Settu upp Consul á sýndarvél, athugaðu hér. Mundu að þú þarft Consul útgáfu ≥ 1.5 [tengill]
Við skulum búa til einn hnút Consul - uppsetningin er sem hér segir.

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

Fyrir ítarlegri leiðbeiningar um uppsetningu Consul og uppsetningu þyrpingar af 3 hnútum, sjá hér.
Búðu til skrá /etc/consul.d/agent.json sem hér segir [tengill]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

Byrjaðu Consul netþjóninn okkar:

consul agent 
-server 
-ui 
-client 0.0.0.0 
-data-dir=/var/lib/consul 
-bootstrap-expect=1 
-config-dir=/etc/consul.d

Þú ættir að sjá fullt af úttak og enda með "... uppfærsla lokað af ACLs."
Finndu ytri IP tölu Consul netþjónsins og opnaðu vafra með þessari IP tölu á port 8500. Gakktu úr skugga um að notendaviðmótið opnast.
Prófaðu að bæta við lykil/gildi pari. Það hlýtur að vera mistök. Þetta er vegna þess að við hlóðum Consul netþjóninn með ACL og slökktum á öllum reglum.
Farðu aftur í skelina þína á Consul netþjóninum og byrjaðu ferlið í bakgrunni eða á annan hátt til að koma því í gang og sláðu inn eftirfarandi:

consul acl bootstrap

Finndu "SecretID" gildið og farðu aftur í notendaviðmótið. Í ACL flipanum, sláðu inn leynikenni auðkennisins sem þú varst að afrita. Afritaðu SecretID einhvers staðar annars staðar, við munum þurfa það síðar.
Bættu nú við lykil/gildi pari. Fyrir þennan POC skaltu bæta við eftirfarandi: lykill: "custom-ns/test_key", gildi: "Ég er í sérsniðnu-ns möppunni!"

Ræsa Kubernetes klasa fyrir forritið okkar með Consul viðskiptavininum sem Daemonset

Búðu til K8s (Kubernetes) þyrping. Við munum búa það til á sama svæði og þjónninn til að fá hraðari aðgang og þannig getum við notað sama undirnetið til að tengjast innri IP tölum auðveldlega. Við munum kalla það "skywiz-app-með-ráðgjafa-viðskiptavini-poc".

Til hliðar, hér er gott námskeið sem ég rakst á þegar ég setti upp POC Consul cluster með Consul Connect.
Við munum einnig nota Hashicorp hjálmtöflu með útvíkkaðri gildisskrá.
Settu upp og stilltu Helm. Stillingarskref:

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

stýritöflu: https://www.consul.io/docs/platform/k8s/helm.html
Notaðu eftirfarandi gildisskrá (athugið að ég hef gert flest óvirkt):

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

Notaðu stýritöflu:

./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc

Þegar það reynir að keyra mun það þurfa heimildir fyrir Consul netþjóninn, svo við skulum bæta þeim við.
Athugaðu „Pod Address Range“ sem er staðsett á mælaborði klasans og vísaðu aftur til „skywiz-consul-server-poc“ eldveggsreglunnar okkar.
Bættu vistfangasviðinu fyrir hólfið við listann yfir IP-tölur og opnaðu tengi 8301 og 8300.

Farðu í Consul UI og eftir nokkrar mínútur muntu sjá klasann okkar birtast á hnútaflipanum.

Að stilla heimildaraðferð með því að samþætta Consul við Kubernetes

Farðu aftur í Consul netþjónsskelina og fluttu út táknið sem þú vistaðir áðan:

export CONSUL_HTTP_TOKEN=<SecretID>

Við munum þurfa upplýsingar frá Kubernetes þyrpingunni okkar til að búa til dæmi um auðkenningaraðferðina:
kubernetes-gestgjafi

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:

Táknið er base64 kóðað, svo afkóða það með uppáhalds tólinu þínu [tengill]
kubernetes-ca-cert

kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:

Taktu "ca.crt" vottorðið (eftir base64 afkóðun) og skrifaðu það inn í "ca.crt" skrána.
Stofnaðu nú auðkenningaraðferðina og skiptu um staðgengla fyrir gildin sem þú fékkst nýlega.

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>"

Næst þurfum við að búa til reglu og festa hana við nýja hlutverkið. Fyrir þennan hluta geturðu notað Consul UI, en við munum nota skipanalínuna.
Skrifaðu reglu

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

Notaðu regluna

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

Finndu auðkenni reglunnar sem þú bjóst til úr úttakinu.
Búðu til hlutverk með nýrri reglu.

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id <policy_id>

Nú munum við tengja nýja hlutverkið okkar við heimildaraðferðartilvikið. Athugaðu að "selektor" fáninn ákvarðar hvort innskráningarbeiðni okkar mun fá þetta hlutverk. Athugaðu hér fyrir aðra valmöguleika: 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"'

Að lokum stillingar

Aðgangsréttur

Búðu til aðgangsréttindi. Við þurfum að gefa Consul leyfi til að staðfesta og bera kennsl á auðkenni K8s þjónustureikningsins.
Skrifaðu eftirfarandi í skrána [tengill]:

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

Búum til aðgangsréttindi

kubectl create -f skywiz-poc-consul-server_rbac.yaml

Tengist Consul Client

Eins og fram kemur hérÞað eru nokkrir möguleikar til að tengjast daemonset, en við munum halda áfram í eftirfarandi einfalda lausn:
Notaðu eftirfarandi skrá [tengill].

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

Notaðu síðan eftirfarandi innbyggða skipun til að búa til configmap [tengill]. Vinsamlegast athugaðu að við erum að vísa til nafns þjónustu okkar, skiptu um það ef þörf krefur.

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

Prófa auðkenningaraðferðina

Nú skulum við sjá töfrana í verki!

Búðu til fleiri lykilmöppur með sama efsta stigi (þ.e. /sample_key) og gildi að eigin vali. Búðu til viðeigandi stefnur og hlutverk fyrir nýjar lykilleiðir. Við gerum bindingarnar síðar.

Sérsniðið nafnrýmispróf:

Við skulum búa til okkar eigið nafnrými:

kubectl create namespace custom-ns

Búum til hólf í nýja nafnarýminu okkar. Skrifaðu uppsetninguna fyrir hólfið.

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

Búðu til undir:

kubectl create -f poc-ubuntu-custom-ns.yaml

Þegar ílátið er í gangi, farðu þangað og settu upp krulla.

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

Nú munum við senda innskráningarbeiðni til Consul með heimildaraðferðinni sem við bjuggum til áðan [tengill].
Til að skoða innslátt táknið af þjónustureikningnum þínum:

cat /run/secrets/kubernetes.io/serviceaccount/token

Skrifaðu eftirfarandi í skrá inni í ílátinu:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

Skrá inn!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

Til að ljúka ofangreindum skrefum í einni línu (þar sem við munum keyra mörg próf) geturðu gert eftirfarandi:

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

Virkar! Það ætti að minnsta kosti að gera það. Taktu nú SecretID og reyndu að fá aðgang að lykilnum/gildinu sem við ættum að hafa aðgang að.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”

Þú getur base64 afkóða "Value" og séð að það passar við gildið í custom-ns/test_key í notendaviðmótinu. Ef þú notaðir sama gildi hér að ofan í þessari kennslu, þá væri kóðað gildi þitt IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Próf notendaþjónustureiknings:

Búðu til sérsniðinn þjónustureikning með því að nota eftirfarandi skipun [tengill].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

Búðu til nýja stillingarskrá fyrir hólfið. Vinsamlega athugið að ég lét setja upp krullur til að spara vinnu :)

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

Eftir það skaltu keyra skel inni í ílátinu.

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

Skrá inn!

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

Leyfi hafnað. Ó, við gleymdum að bæta við nýjum reglum sem eru bindandi með viðeigandi heimildum, við skulum gera það núna.

Endurtaktu fyrri skref hér að ofan:
a) Búðu til eins stefnu fyrir forskeytið „custom-sa/“.
b) Búðu til hlutverk, kallaðu það „custom-sa-role“
c) Hengdu stefnuna við hlutverkið.

Búðu til reglubindingu (aðeins hægt frá cli/api). Athugaðu mismunandi merkingu valfánans.

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-sa-role' 
-selector='serviceaccount.name=="custom-sa"'

Skráðu þig aftur úr "poc-ubuntu-custom-sa" ílátinu. Árangur!
Skoðaðu aðgang okkar að sérsniðnu sa/ lyklaleiðinni.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”

Þú getur líka tryggt að þessi auðkenni veiti ekki aðgang að kv í "custom-ns/". Endurtaktu bara skipunina hér að ofan eftir að hafa skipt út "custom-sa" með forskeytinu "custom-ns".
Leyfi hafnað.

Yfirlagsdæmi:

Þess má geta að öllum reglubindandi kortlagningum verður bætt við táknið með þessum réttindum.
Ílátið okkar „poc-ubuntu-custom-sa“ er í sjálfgefna nafnrýminu - svo við skulum nota það fyrir aðra reglubindingu.
Endurtaktu fyrri skref:
a) Búðu til eins stefnu fyrir „sjálfgefið/“ lykilforskeytið.
b) Búðu til hlutverk, nefndu það „default-ns-role“
c) Hengdu stefnuna við hlutverkið.
Búðu til reglubindingu (aðeins hægt frá 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"'

Farðu aftur í "poc-ubuntu-custom-sa" gáminn okkar og reyndu að fá aðgang að "default/" kv slóðinni.
Leyfi hafnað.
Þú getur skoðað tilgreind skilríki fyrir hvert tákn í notendaviðmótinu undir ACL > Tokens. Eins og þú sérð hefur núverandi táknið okkar aðeins eitt „sérsniðið hlutverk“ tengt við það. Táknið sem við erum að nota var búið til þegar við skráðum okkur inn og það var aðeins ein reglubinding sem passaði þá. Við þurfum að skrá okkur inn aftur og nota nýja táknið.
Gakktu úr skugga um að þú getir lesið bæði úr "custom-sa/" og "default/" kv slóðum.
Velgengni!
Þetta er vegna þess að „poc-ubuntu-custom-sa“ okkar passar við „custom-sa“ og „default-ns“ reglubindingarnar.

Ályktun

TTL token mgmt?

Þegar þetta er skrifað er engin samþætt leið til að ákvarða TTL fyrir tákn sem myndast með þessari heimildaraðferð. Það væri frábært tækifæri til að veita örugga sjálfvirkni ræðismannsheimildar.

Það er möguleiki að búa til tákn handvirkt með TTL:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
Fyrningartími - Tíminn sem þessi tákn verður afturkallaður. (Valfrjálst; bætt við í Consul 1.5.0)
Er aðeins til fyrir handvirka sköpun/uppfærslu https://www.consul.io/api/acl/tokens.html#expirationtime

Vonandi getum við í náinni framtíð stjórnað því hvernig tákn eru mynduð (samkvæmt reglu eða heimildaraðferð) og bætt við TTL.

Þangað til þá er lagt til að þú notir útskráningarendapunkt í rökfræðinni þinni.

Lestu einnig aðrar greinar á blogginu okkar:

Heimild: www.habr.com

Kynning á Kubernetes heimild Hashicorp Consul