🥇Bevezetés a Hashicorp Consul Kubernetes Hitelesítésébe

Teljesen helyes, a kiadás után Hashicorp Consul 1.5.0 2019 május elején a Consul lehetővé teszi, hogy nativ módon autentikálj alkalmazásokat és szolgáltatásokat, amelyek Kubernetes alatt futnak.

Ebben a útmutatóban lépésről lépésre létrehozunk POC (Proof of concept, PoC — a koncepció megvalósíthatóságának bizonyítása — ford. megj.), bemutatva ezt az új funkciót. Alapvető tudás szükséges a Kubernetesről és a Hashicorp Consulról. Bár bármilyen felhőplatformot vagy helyi környezetet használhatsz, ebben az útmutatóban a Google Cloud Platformot fogjuk használni.

Áttekintés

Ha áttérünk a Consul dokumentációjára az autentikációs módszerével kapcsolatban, egy rövid áttekintést kapunk a céljáról és felhasználási lehetőségéről, valamint néhány technikai részletet és a logika általános áttekintését. Határozottan ajánlom, hogy legalább egyszer olvasd el, mielőtt folytatod, mert most ezt mind el fogom magyarázni és részletesen átbeszélni.

1. ábra: A Consul autentikációs módszerének hivatalos áttekintése

Nézzük meg a Kubernetes autentikációs módszerének dokumentációját.

Természetesen van hasznos információ, de nincs útmutató arról, hogyan kell valójában használni az egészet. Tehát, mint bármely józan ésszel rendelkező ember, átkutatod az internetet egy útmutatót keresve. Aztán... vereséget szenvedsz. Ez megtörténik. Javítsuk ki ezt.

Mielőtt elkezdenénk a POC létrehozását, térjünk vissza a Consul autentikációs módszereinek áttekintéséhez (1. ábra) és pontosítsuk azt a Kubernetes kontextusában.

Architektúra

Ebben az útmutatóban egy külön gépen létrehozunk egy Consul szervert, amely együttműködik a Kubernetes klaszterével, ahol a Consul kliens telepítve van. Ezt követően létrehozzuk a hamis alkalmazásunkat egy podban, és a beállított autentikációs módszerünkkel olvasunk a Consul kulcs/érték tárolónkból.

Az alábbi ábra részletesen bemutatja azt az architektúrát, amelyet ebben az útmutatóban létrehozunk, valamint az autentikációs módszer logikáját, amelyet később fogunk megmagyarázni.

2. ábra: Az autentikációs módszer áttekintése a Kubernetesben

Egy kis megjegyzés: A Consul szervernek nem szükséges a Kubernetes klaszteren kívül élni ahhoz, hogy a dolog működjön. De igen, lehet így is, úgy is.

Tehát, ha átveszünk egy átfogó Consul ábrát (1. ábra) és alkalmazzuk a Kubernetesre, a fenti ábrát kapjuk (2. ábra), és itt a logika a következőképpen alakul:

Minden podhoz egy szolgáltatói fiók lesz csatolva, amely tartalmaz egy általunk ismert és a Kubernetes által generált JWT tokent. Ez a token alapértelmezés szerint be lesz ágyazva a podba.
Alkalmazásunk vagy szolgáltatásunk, amely a podon belül működik, elindítja a bejelentkezési parancsot a Consul-kliensemhez. A bejelentkezési kérésben a tokenünk és egy név is meg lesz adva. külön erre létrehozott hitelesítési módszer (Kubernetes típus). Ez a 2. lépés megfelel a Consul séma 1. lépésének.
A Consul-klienseink ezután ezt a kérést a Consul-serverünk felé irányítják.
VARÁZSLAT! Itt a Consul-server ellenőrzi a kérés hitelességét, összegyűjti a kérés identitására vonatkozó információkat, és összehasonlítja őket bármely társított előre meghatározott szabályzattal. Alább látható egy másik séma, hogy ezt illusztrálja. Ez a lépés megfelel a Consul séma 1. lépésének 3., 4. és 5. részének.
A Consul-server egy Consul tokent generál az általunk megadott hitelesítési módszer alapján (amelyeket meghatároztunk) a kérő személyazonossága szerint. Ezután visszaküldi ezt a tokent. Ez a Consul séma 1. lépésének 6. lépésével felel meg.
A Consul-klienseink átirányítják a tokent a kérő alkalmazásnak vagy szolgáltatásnak.

Most a mi alkalmazásunk vagy szolgáltatásunk ezt a Consul tokent használhatja a Consul adataival való kommunikációhoz, ahogyan azt a token privilégiumai meghatározzák.

Felfedve a varázslatot!

Azoknak, akik nem elégedettek csupán egy kalapból húzott nyúllal, és szeretnék tudni, hogyan működik ez... hadd „mutassam meg, mennyire mély a nyúl üreg».

Ahogyan korábban említettem, a „varázslatos” lépésünk (Séma 2: 4. lépés) abban rejlik, hogy a Consul-server hitelesíti a kérdést, összegyűjti a kérdésre vonatkozó információkat, és összehasonlítja őket a bármely társított előre meghatározott szabályzóval. Ez a lépés a Consul séma 1. lépésének 3., 4. és 5. részével felel meg. Alább bemutatunk egy sémát (Séma 3), amely célja, hogy világosan bemutassa, mi is történik valójában a motorháztető alatt konkrét Kubernetes hitelesítési módszerét.

Séma 3: Felfedve a varázslatot!

Kiindulópontként a Consul-kliensem a bejelentkezési kérést a Consul-serverünkhöz irányítja a Kubernetes fiókhoz tartozó tokennel és az előzőleg létrehozott hitelesítési módszer konkrét nevét. Ez a lépés megfelel a korábbi séma 3. lépésének.
Most már a Consul-szervernek (vagy vezetőnek) ellenőriznie kell a kapott token érvényességét. Ezért konzultál a Kubernetes klaszterre (a Consul kliensen keresztül), és a megfelelő engedélyek birtokában kiderítjük, hogy a token érvényes-e, és kié.
Ezután a hitelesített kérés visszatér a Consul-vezetőhöz, és a Consul szerveren keresni fogjuk az engedélyezési módszer példányát, amelyet a bejelentkezési kérésben megadott név és típus (Kubernetes) határoz meg.
A Consul-vezető meghatározza a megadott engedélyezési módszer példányt (ha megtalálható), és elolvassa a hozzá kapcsolódó kapcsolódó szabályok készletét. Ezt követően elolvassa ezeket a szabályokat, és összehasonlítja őket a hitelesített azonossági attribútumokkal.
Tada! Most lépjünk a fent említett séma 5. lépésére.

Indítsa el a Consul-szervert egy hagyományos virtuális gépen.

Innét kezdve elsősorban a POC létrehozására vonatkozó utasításokat fogom adni, gyakran pontokban, magyarázó teljes mondatok nélkül. Ahogy korábban említettem, a teljes infrastruktúrához a GCP-t fogom használni, de ugyanezt az infrastruktúrát bármely más helyen is létrehozhatja.

Indítsa el a virtuális gépet (példány/szerver).

Hozzon létre egy tűzfalszabályt (biztonsági csoport AWS-ben):
Szeretem ugyanazt a nevet adni a gépnek és a hálózati címkének, ebben az esetben ez a „skywiz-consul-server-poc”.
Keresse meg a helyi számítógépe IP-címét, és adja hozzá a forrás IP-címek listájához, hogy hozzáférhessünk a felhasználói felülethez (UI).
Nyissa meg a 8500-as portot az UI számára. Kattintson a Create (Létrehozás) gombra. Hamarosan újra módosítjuk ezt a tűzfalat [link].
Adjon hozzá tűzfalszabályt a példányhoz. Térjen vissza a Consul-szerver VM irányítópultjára, és adja hozzá a „skywiz-consul-server-poc”-t a hálózati címkék mezőhöz. Kattintson a Save (Mentés) gombra.

Telepítse a Consult a virtuális gépre, ellenőrizze itt. Ne feledje, hogy a Consul ≥ 1.5 verzióra van szükség [link]
Hozzunk létre egy single node Consul-t — a konfiguráció a következő.

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

Részletesebb útmutató a Consul telepítéséről és a 3 node-ból álló klaszter beállításáról: itt.
Hozza létre a fájlt /etc/consul.d/agent.json a következőképpen [link]:

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

Indítsa el a Consul-szerverünket:

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

Látnod kell rengeteg kimenetet, végül pedig a „… update blocked by ACLs” üzenetet.
Keresse meg a Consul-szerver külső IP-címét, és nyisson meg egy böngészőt ezzel az IP-címmel a 8500-as porton. Győződjön meg róla, hogy megnyílik a felhasználói felület.
Próbáljon meg hozzáadni egy kulcs/érték párt. Hibaüzenetet kell kapnia. Ez azért van, mert az ACL segítségével betöltöttük a Consul-szervert, és megtiltottuk minden szabályt.
Térjen vissza a Consul-szerver parancssorához, és futtassa a folyamatot háttérben, vagy más módon, hogy folytatódjon, majd írja be a következőt:

consul acl bootstrap

Keresse meg a „SecretID” értéket, és térjen vissza a felhasználói felülethez. Az „ACL” fülön adja meg a titkos azonosítót, amelyet éppen most másolt. Másolja a SecretID-t máshova is, mert később szükségünk lesz rá.
Most adjon hozzá egy kulcs/érték párt. Ezen POC számára a következőt fogjuk hozzáadni: kulcs: „custom-ns/test_key”, érték: „A custom-ns mappában vagyok!”

Kubernetes klaszter indítása az alkalmazásunk számára, a Consul klienssel Daemonsetként.

Hozzon létre egy K8s (Kubernetes) klasztert. Ezt abban a zónában fogjuk létrehozni, ahol a szerver is van, hogy gyorsabb hozzáférést biztosítsunk, és így a belső IP-címek egyszerű csatlakozása érdekében ugyanazt a tartományt használhassuk. A neve: „skywiz-app-with-consul-client-poc”.

Megjegyzésként, itt van egy jó útmutató, amellyel találkoztam a POC Consul klaszter beállításakor a Consul Connect segítségével.
Használni fogjuk a Hashicorp helm sheetet kiterjesztett értékfájlal.
Telepítse és konfigurálja a Helm-et. A konfigurációs lépések:

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: https://www.consul.io/docs/platform/k8s/helm.html
Használja a következő értékfájlt (jegyezze meg, hogy a legtöbbet kikapcsoltam):

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

Alkalmazza a helm chart-ot:

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

A futtatás megkísérlésekor szüksége lesz engedélyekre a Consul-szerverhez, így adjon hozzájuk.
Figyelje meg a klaszter vezérlőpultján található „Pod címzési tartományt”, és térjen vissza a tűzfal szabályhoz „skywiz-consul-server-poc”.
Adja hozzá a pod címzési tartományt az IP-címek listájához, és nyissa meg a 8301-es és 8300-as portokat.

Lépjen a Consul UI-ra, és néhány perc múlva meglátja, hogy a klaszterünk megjelenik a csomópontok fülön.

Az engedélyezési módszer beállítása a Consul és a Kubernetes integrálásával.

Térjen vissza a Consul-szerver parancssorához, és exportálja a korábban elmentett tokent:

export CONSUL_HTTP_TOKEN=

Szükségünk lesz információra a Kubernetes klaszterünkből, hogy létrehozhassunk egy authentikáló metódust:
kubernetes-host

kubectl get endpoints | grep kubernetes

kubernetes-service-account-jwt

kubectl get sa -consul-client -o yaml | grep "- name:"
kubectl get secret  -o yaml | grep token:

A token base64 formátumban van kódolva, ezért dekódold a kedvenc eszközöddel [link]
kubernetes-ca-cert

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

Vedd el a „ca.crt” tanúsítványt (a base64 dekódolása után), és írd bele a “ca.crt” fájlba.
Most hozz létre egy authentikáló metódus példányt, helyettesítve a helyőrzőket az előbb kapott értékekkel.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "Ez egy authentikáló metódus, amely a kubernetes-t használja a skywiz-app-with-consul-client-poc klaszterhez" 
-kubernetes-host "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

Ezután létre kell hoznunk egy szabályt és hozzárendelni az új szerepkörhöz. Ehez használhatod a Consul UI-t, de mi a parancssort fogjuk használni.
Írj egy szabályt

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

Alkalmazd a szabályt

consul acl policy create 
-name kv-custom-ns-policy 
-description "Ez egy példa szabály a kv-hez a custom-ns/-ben" 
-rules @kv-custom-ns-policy.hcl

Találd meg a szabály azonosítóját, amit éppen létrehoztál, a kimenetből.
Hozz létre egy szerepkört az új szabállyal.

consul acl role create 
-name "custom-ns-role" 
-description "Ez egy példa szerepkör a custom-ns névtérhez" 
-policy-id

Most összekapcsoljuk az új szerepkörünket az authentikáló metódus példányával. Ne feledd, hogy a „selector” zászló határozza meg, hogy a belépési kérelmünk megkapja-e ezt a szerepkört. Itt ellenőrizheted a selector egyéb lehetőségeit: 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"'

Végül a konfigurációk

Hozzáférési jogok

Hozz létre hozzáféréseket. Engedélyeznünk kell a Consul számára, hogy ellenőrizze és azonosítsa a K8s szolgáltató fiók tokenjét.
Írd be a fájlba a következőt [link]:

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

Létrehozunk hozzáféréseket

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

Kapcsolódás a Consul Clienthez

Mint említettük, itt, több lehetőség van a daemonsethez való csatlakozásra, de mi a következő egyszerű megoldásra fogunk áttérni:
Alkalmazd a következő fájlt [link].

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

Ezután alkalmazd a következő beépített parancsot a configmap létrehozásához [link]. Ne feledd, hogy a szolgáltatásunk nevét hivatkozzuk rá, cseréld le szükség szerint.

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

Az auth-módszer tesztelése

Most nézzük meg a varázslatot a gyakorlatban!

Hozzon létre még néhány kulcs mappát ugyanazzal a felső szintű kulccsal (pl. /sample_key), és értékét tetszőlegesen válassza ki. Hozzon létre megfelelő policy-kat és szerepeket az új kulcsútvonalakhoz. Később kötéseket hozunk létre.

Felhasználói teszt névtérben:

Hozzuk létre a saját névterünket:

kubectl create namespace custom-ns

Hozzunk létre egy pod-ot az új névtérben. Írja meg a pod konfigurációját.

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

Pod létrehozása:

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

Amint a konténer elindul, lépjen be és telepítse a curl-t.

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

Most egy bejelentkezési kérés küldését fogjuk végrehajtani a Consul-ra, a korábban létrehozott hitelesítési módszer segítségével [link].
A szolgáltatás fiókjából beírt token megtekintéséhez:

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

Írja be a következőt a fájlba a konténeren belül:

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

Bejelentkezés!

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

A fenti lépések egy sorba való végrehajtásához (mivel több tesztet fogunk végezni) a következőket teheti:

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

Működik! Legalábbis ennek így kellene lennie. Most vegye el a SecretID-t, és próbáljon hozzáférni ahhoz a kulcshoz/értékhez, amelyhez hozzáférésünknek lennie kell.

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

A "Value" base64 dekódolásával láthatja, hogy megegyezik a custom-ns/test_key UI-beli értékével. Ha az ebben az útmutatóban megadott azonos értéket használta, a kódolt értéke IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi lesz.

Felhasználói szolgáltatás fiók teszt:

Hozzon létre egy felhasználói ServiceAccount-ot a következő parancs segítségével [link].

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

Hozzon létre egy új konfigurációs fájlt a pod számára. Vegye észre, hogy a curl telepítését is beleírtam a munka megkönnyítése érdekében 🙂

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

Ezután indítson shell-t a konténeren belül.

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

Bejelentkezés!

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

Hozzáférés megtagadva. Ó, elfelejtettük hozzáadni az új szabálykötést a megfelelő engedélyekkel, tegyük ezt meg most.

Ismételje meg a fenti lépéseket:
a) Hozzon létre egy azonos Politika a „custom-sa/” előtaghoz.
b) Hozzon létre egy Szerepkört, és nevezze el „custom-sa-role”-nak.
c) Csatolja a Szabályt a Szerepkörhöz.

Hozzon létre Szabálykötést (csak cli / api-ból lehetséges). Figyeljen a kiválasztó zászló más értékére.

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

Ismételje meg a rendszerbe való bejelentkezést a „poc-ubuntu-custom-sa” konténerből. Sikerült!
Ellenőrizze a hozzáférésünket a kulcspont „custom-sa/”-hoz.

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

Azt is ellenőrizheti, hogy ez a token nem biztosít hozzáférést a kv-hez a „custom-ns/” alatt. Csak ismételje meg a fent említett parancsot úgy, hogy a „custom-sa”-t a „custom-ns” előtagra cseréli.
Hozzáférés megtagadva.

Overlay példa:

Meg kell jegyezni, hogy minden szabálykötés hozzáadódik a tokenhez ezekkel a jogokkal.
A „poc-ubuntu-custom-sa” konténere a默认 névtérben található - így ezt használjuk egy másik szabálykötéshez.
Ismételje meg a fenti lépéseket:
a) Hozzon létre egy azonos Politika a „default/” kulcsszóhoz.
b) Hozzon létre egy Szerepkört, és nevezze el „default-ns-role”-nak.
c) Csatolja a Szabályt a Szerepkörhöz.
Hozzon létre Szabálykötést (csak cli / api-ból lehetséges).

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

Térjen vissza a „poc-ubuntu-custom-sa” konténerhez, és próbálja meg elérni a „default/” kv útvonalat.
Hozzáférés megtagadva.
Megtekintheti az adott tokenekhez tartozó hitelesítő adatokat a felhasználói felületen az ACL > Tokenek szakaszban. Ahogy láthatja, a jelenlegi tokenünkhöz csak egy „custom-sa-role” van csatolva. A jelenleg használt token a bejelentkezéskor lett generálva, és akkor csak egy szabálykötés volt, ami akkor érvényes volt. Újra be kell jelentkeznie, és új tokent kell használnia.
Győződjön meg róla, hogy tud olvasni mind a „custom-sa/”, mind a „default/” kv útvonalakról.
Sikerült!
Ez azért van, mert a „poc-ubuntu-custom-sa” megfelel a „custom-sa” és a „default-ns” szabálykötéseknek.

Zárás

TTL token kezelés?

A cikk írásának időpontjában nem létezik beépített mód a TTL meghatározására az ilyen módon generált tokenek esetén. Ez fantasztikus lehetőség lenne — biztonságos automatizálás biztosítása a Consul hitelesítéséhez.

Lehetséges manuálisan létrehozni egy TTL-tokent:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
Expiration Time (Lejárati idő) — az az időpont, amikor ezt a tokent visszavonják. (Nem kötelező; a Consul 1.5.0-ban került bevezetésre)
Csak manuális létrehozásra / frissítésre áll rendelkezésre https://www.consul.io/api/acl/tokens.html#expirationtime

Remélem, a közeljövőben ellenőrizni tudjuk, hogyan generálódnak a tokenek (minden szabály vagy hitelesítési módszer esetén), és hozzáadhatunk TTL-t.

Addig azt javaslom, hogy használja a kijelentkezési végpontot a logikájában.