Richtig , nach der Veröffentlichung von Hashicorp Consul 1.5.0 Anfang Mai 2019 in Consul können Sie Anwendungen und Dienste autorisieren, die in Kubernetes nativ ausgeführt werden.
In diesem Tutorial erstellen wir Schritt für Schritt einen POC (Proof of Concept, PoC - Proof of Concept), der diese neue Funktion demonstriert. Grundkenntnisse über Kubernetes und Hashicorps Konsul werden von Ihnen erwartet. Und obwohl Sie Sie können jede Cloud-Plattform oder lokale Umgebung verwenden. In diesem Handbuch verwenden wir die Cloud-Plattform von Google.
Rückblick
Wenn wir uns der Consul-Dokumentation zu ihrer Autorisierungsmethode zuwenden, erhalten wir einen kurzen Überblick über ihren Zweck und Anwendungsfall sowie einige technische Details und einen allgemeinen Überblick über die Logik. Ich empfehle dringend, es mindestens einmal zu lesen, bevor Sie fortfahren, da ich jetzt alles erklären und kauen werde.
Abbildung 1: Übersicht über die offizielle Konsulautorisierungsmethode
Werfen wir einen Blick auf die Dokumentation zur spezifischen Kubernetes-Autorisierungsmethode .
Natürlich gibt es nützliche Informationen, aber es gibt keine Anleitung, wie man all dies tatsächlich nutzt. Daher durchsuchen Sie wie jede vernünftige Person das Internet nach Anleitungen. Und dann ... besiegt werden. Es passiert. Lass es uns reparieren.
Bevor wir mit der Erstellung unseres POC fortfahren, kehren wir zur Übersicht über die Consul-Autorisierungsmethoden (Abbildung 1) zurück und verfeinern sie im Kontext von Kubernetes.
Architektur
In diesem Handbuch erstellen wir einen Consul-Server auf einem separaten Computer, der mit dem installierten Consul-Client mit dem Kubernetes-Cluster interagiert. Anschließend erstellen wir unsere Dummy-Anwendung im Kamin und verwenden unsere angepasste Autorisierungsmethode, um aus unserem Konsul-Schlüssel- / Wert-Repository zu lesen.
Das folgende Diagramm zeigt detailliert die Architektur, die wir in diesem Handbuch erstellen, sowie die Logik der Autorisierungsmethode, die später erläutert wird.
Abbildung 2: Übersicht über die Autorisierungsmethode in Kubernetes
Ein kurzer Hinweis: Der Konsulsserver muss nicht außerhalb des Kubernetes-Clusters leben, damit dies funktioniert. Aber ja, er kann dies und das tun.
Wenn wir also das Konsul-Übersichtsdiagramm (Schema 1) nehmen und Kubernetes darauf anwenden, erhalten wir das obige Diagramm (Schema 2), und hier lautet die Logik wie folgt:
- Jedem Pod ist ein Dienstkonto beigefügt, das ein von Kubernetes generiertes und bekanntes JWT-Token enthält. Dieses Token wird standardmäßig auch in das Sub eingefügt.
- Unsere Anwendung oder unser Service im Kamin löst einen Befehl zur Eingabe unseres Konsul-Clients aus. In der Anmeldeanforderung werden auch unser Token und der Name einer speziell erstellten Autorisierungsmethode (z. B. Kubernetes) angegeben. Dieser Schritt Nr. 2 entspricht Schritt 1 des Konsulschemas (Schema 1).
- Unser Consul-Client leitet diese Anfrage dann an unseren Consul-Server weiter.
- MAGIE! Hier überprüft der Consul-Server die Authentizität der Anforderung, sammelt Informationen über die Identität der Anforderung und vergleicht sie mit den zugehörigen vordefinierten Regeln. Unten sehen Sie ein weiteres Diagramm, um dies zu veranschaulichen. Dieser Schritt entspricht den Schritten 3, 4 und 5 des Konsul-Übersichtsdiagramms (Schema 1).
- Unser Consul-Server generiert ein Consul-Token mit Berechtigungen gemäß den Regeln der Autorisierungsmethode, die wir in Bezug auf die Identität des Anforderers angegeben haben (die wir festgelegt haben). Dann wird er diesen Token zurückschicken. Dies entspricht Schritt 6 des Konsulschemas (Schema 1).
- Unser Consul-Client leitet das Token an die anfordernde Anwendung oder den anfordernden Dienst weiter.
Unsere Anwendung oder unser Dienst kann dieses Consul-Token jetzt verwenden, um mit unseren Consul-Daten zu kommunizieren, wie durch die Token-Berechtigungen bestimmt.
Die Magie wird offenbart!
Für diejenigen unter Ihnen, die nicht nur mit dem Kaninchen im Hut zufrieden sind und wissen möchten, wie es funktioniert ... lassen Sie mich "Ihnen zeigen, wie tief das Kaninchenloch ist ".
Wie bereits erwähnt, besteht unser „magischer“ Schritt (Schema 2: Schritt 4) darin, dass der Consul-Server die Authentizität der Anforderung überprüft, Informationen über die Anforderung sammelt und diese mit den zugehörigen vordefinierten Regeln vergleicht. Dieser Schritt entspricht den Schritten 3, 4 und 5 des Konsul-Übersichtsdiagramms (Schema 1). Unten sehen Sie ein Diagramm (Schema 3), mit dem klar dargestellt werden soll, was tatsächlich unter der Haube einer bestimmten Kubernetes-Autorisierungsmethode geschieht.
Schema 3: Die Magie wird enthüllt!
- Als Ausgangspunkt leitet unser Consul-Client die Anmeldeanforderung mit dem Kubernetes-Kontotoken und dem spezifischen Namen der Instanz der zuvor erstellten Autorisierungsmethode an unseren Consul-Server weiter. Dieser Schritt entspricht Schritt 3 in der vorherigen Erläuterung der Schaltung.
- Jetzt muss der Consul-Server (oder Leader) die Authentizität des empfangenen Tokens überprüfen. Daher wird er sich mit dem Kubernetes-Cluster (über den Consul-Client) beraten und mit den entsprechenden Berechtigungen herausfinden, ob das Token echt ist und wem es gehört.
- Anschließend wird die verifizierte Anforderung an den Konsulleiter zurückgegeben, und der Konsul-Server sucht in der Anmeldeanforderung nach einer Instanz der Autorisierungsmethode mit dem angegebenen Namen (und gibt Kubernetes ein).
- Der Konsulführer bestimmt die angegebene Instanz der Autorisierungsmethode (falls eine gefunden wird) und liest die damit verbundenen Bindungsregeln. Anschließend liest er diese Regeln und vergleicht sie mit verifizierten Identitätsattributen.
- Tada! Fahren Sie mit Schritt 5 in der vorherigen Erläuterung der Schaltung fort.
Führen Sie Consul-Server auf einer normalen virtuellen Maschine aus
Von nun an werde ich hauptsächlich Anweisungen zum Erstellen dieses POC geben, oft in Punkten, ohne erklärende ganze Sätze. Wie bereits erwähnt, werde ich GCP verwenden, um die gesamte Infrastruktur zu erstellen, aber Sie können dieselbe Infrastruktur überall anders erstellen.
- Starten Sie die virtuelle Maschine (Instanz / Server).
- Erstellen Sie eine Regel für die Firewall (Sicherheitsgruppe in AWS):
- Ich möchte der Regel und dem Netzwerk-Tag den gleichen Computernamen zuweisen, in diesem Fall ist es "skywiz-consul-server-poc".
- Suchen Sie die IP-Adresse Ihres lokalen Computers und fügen Sie sie der Liste der Quell-IP-Adressen hinzu, damit wir auf die Benutzeroberfläche zugreifen können.
- Öffnen Sie Port 8500 für die Benutzeroberfläche. Klicken Sie auf Erstellen. Wir werden diese Firewall [ Link ] bald wieder ändern.
- Fügen Sie der Instanz die Regel für die Firewall hinzu. Kehren Sie zum VM-Dashboard auf dem Consul-Server zurück und fügen Sie dem Feld "Netzwerk-Tag" "skywiz-consul-server-poc" hinzu. Klicken Sie auf Speichern.
- Installieren Sie Consul auf einer virtuellen Maschine. Überprüfen Sie dies hier. Denken Sie daran, dass Sie die Consul-Version ≥ 1.5 benötigen [Link]
- Erstellen Sie einen Konsul mit einem einzelnen Knoten - die Konfiguration ist wie folgt.
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
- Eine ausführlichere Anleitung zur Installation von Consul und zum Einrichten eines Clusters mit 3 Knoten finden Sie hier .
- Erstellen Sie die Datei /etc/consul.d/agent.json wie folgt [ Link ]:
### /etc/consul.d/agent.json { "acl" : { "enabled": true, "default_policy": "deny", "enable_token_persistence": true } }
- Starten Sie unseren Consul-Server:
consul agent \ -server \ -ui \ -client 0.0.0.0 \ -data-dir=/var/lib/consul \ -bootstrap-expect=1 \ -config-dir=/etc/consul.d
- Sie sollten eine Reihe von Ausgaben sehen und am Ende "... Update durch ACLs blockiert" erhalten.
- Suchen Sie die externe IP-Adresse des Consul-Servers und öffnen Sie einen Browser mit dieser IP-Adresse an Port 8500. Stellen Sie sicher, dass die Benutzeroberfläche geöffnet ist.
- Versuchen Sie, ein Schlüssel / Wert-Paar hinzuzufügen. Es muss ein Fehler sein. Dies liegt daran, dass wir den Consul-Server mithilfe der ACL geladen und alle Regeln abgelehnt haben.
- Kehren Sie zu Ihrer Shell auf dem Consul-Server zurück, starten Sie den Vorgang im Hintergrund oder auf andere Weise, damit er funktioniert, und geben Sie Folgendes ein:
consul acl bootstrap
- Suchen Sie den Wert "SecretID" und kehren Sie zur Benutzeroberfläche zurück. Geben Sie auf der Registerkarte ACL die geheime Kennung des gerade kopierten Tokens ein. Kopieren Sie SecretID woanders, wir werden es später brauchen.
- Fügen Sie nun ein Schlüssel / Wert-Paar hinzu. Fügen Sie für diesen POC Folgendes hinzu: key: "custom-ns / test_key", Wert: "Ich bin im Ordner custom-ns!"
Starten Sie Kubernetes Cluster für unsere Anwendung mit Consul Client als Daemonset
- Erstellen Sie einen K8s-Cluster (Kubernetes). Wir werden es für den schnelleren Zugriff in derselben Zone wie der Server erstellen und können daher dasselbe Subnetz für die einfache Verbindung mit internen IP-Adressen verwenden. Wir werden es skywiz-app-with-consul-client-poc nennen.
- Hier ist eine gute Anleitung, die mir beim Einrichten eines POC Consul-Clusters mit Consul Connect begegnet ist.
- Wir werden auch das Hashicorp-Helmdiagramm mit einer erweiterten Wertedatei verwenden.
- Helm installieren und konfigurieren. Konfigurationsschritte:
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
- Wenn Sie versuchen zu starten, benötigen Sie Berechtigungen für den Consul-Server. Fügen Sie diese also hinzu.
- Beachten Sie den "Pod-Adressbereich" im Cluster-Dashboard und kehren Sie zu unserer Regel für die Skywiz-Consul-Server-Poc-Firewall zurück.
- Fügen Sie den Adressbereich für die IPA zur Liste der IP-Adressen und offenen Ports 8301 und 8300 hinzu.
- Gehen Sie zur Consul-Benutzeroberfläche, und in wenigen Minuten sehen Sie, dass unser Cluster auf der Registerkarte "Knoten" angezeigt wird.
Konfigurieren Sie die Autorisierungsmethode durch Integration von Consul in Kubernetes
- Kehren Sie zur Shell des Consul-Servers zurück und exportieren Sie das zuvor gespeicherte Token:
export CONSUL_HTTP_TOKEN=<SecretID>
- Wir benötigen Informationen aus unserem Kubernetes-Cluster, um eine Instanz der Authentifizierungsmethode zu erstellen:
- 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:
- Das Token ist in base64 codiert, entschlüsseln Sie es also mit Ihrem bevorzugten Tool [ Link ]
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:
- Nehmen Sie das Zertifikat "ca.crt" (nach dem Dekodieren mit base64) und schreiben Sie es in die Datei "ca.crt".
- Erstellen Sie nun eine Instanz der Auth-Methode und ersetzen Sie die Platzhalter durch die soeben erhaltenen Werte.
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>" \ -kubernetes-ca-cert=@ca.crt \ -kubernetes-service-account- jwt="<decoded_token_retrieved_earlier>"
- Als Nächstes müssen wir eine Regel erstellen und sie an die neue Rolle anhängen. Sie können die Consul-Benutzeroberfläche für diesen Teil verwenden, wir verwenden jedoch die Befehlszeile.
- Schreibe eine Regel
### 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
- Suchen Sie die Kennung der Regel, die Sie gerade aus der Ausgabe erstellt haben.
- Erstellen Sie eine Rolle mit einer neuen Regel.
consul acl role create \ -name "custom-ns-role" \ -description "This is an example role for custom-ns namespace" \ -policy-id <policy_id>
consul acl binding-rule create \ -method=auth-method-skywiz-consul-poc \ -bind-type=role \ -bind-name='custom-ns-role' \ -selector='serviceaccount.namespace=="custom-ns"'
Letzte Konfigurationen
Zugangsrechte
- Erstellen Sie Berechtigungen. Wir müssen dem Konsul die Erlaubnis erteilen, die Token-Identität des K8-Dienstkontos zu überprüfen und zu identifizieren.
- Schreiben Sie den folgenden [Link] in die Datei:
###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
Stellen Sie eine Verbindung zum Consul-Client her
- Wie hier erwähnt , gibt es verschiedene Möglichkeiten, eine Verbindung zu Daemonset herzustellen. Wir werden jedoch mit der folgenden einfachen Lösung fortfahren:
- Wenden Sie die folgende Datei an [ 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
- Verwenden Sie dann den folgenden integrierten Befehl, um die Konfigurationskarte [ Link ] zu erstellen. Bitte beachten Sie, dass wir uns auf den Namen unseres Service beziehen. Ersetzen Sie ihn gegebenenfalls.
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
Testen der Auth-Methode
Schauen wir uns jetzt die Magie in Aktion an!
- Erstellen Sie einige weitere Schlüsselordner mit demselben Schlüssel der obersten Ebene (d. H. <Neuer_Ordner> / Beispielschlüssel) und dem Wert Ihrer Wahl. Erstellen Sie geeignete Richtlinien und Rollen für neue Schlüsselpfade. Wir werden die Bindungen später machen.
Benutzerdefinierter Namespace-Test:
- Erstellen Sie unseren eigenen Namespace:
kubectl create namespace custom-ns
- Erstellen Sie unter in unserem neuen Namespace. Schreiben Sie die Konfiguration für den Herd.
###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
- Sobald der Container startet, gehen Sie dorthin und installieren Sie die Locke.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash apt-get update && apt-get install curl -y
- Jetzt senden wir eine Anfrage zur Eingabe von Consul mit der zuvor erstellten Autorisierungsmethode [ Link ].
- So zeigen Sie das eingegebene Token in Ihrem Dienstkonto an:
cat /run/secrets/kubernetes.io/serviceaccount/token
- Schreiben Sie Folgendes in eine Datei im Container:
### 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
- Um die obigen Schritte in einer einzigen Zeile auszuführen (da wir mehrere Tests ausführen werden), können Sie Folgendes tun:
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
- Es funktioniert! Muss zumindest sein. Nehmen Sie nun die SecretID und versuchen Sie, auf den Schlüssel / Wert zuzugreifen, auf den wir Zugriff haben müssen.
curl \ consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”
- Sie können den Basiswert "Wert" 64 dekodieren und feststellen, dass er mit dem Wert in custom-ns / test_key in der Benutzeroberfläche übereinstimmt. Wenn Sie den gleichen Wert wie in diesem Handbuch verwenden, lautet Ihr codierter Wert IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
User Service Account Test:
- Erstellen Sie ein benutzerdefiniertes ServiceAccount mit dem folgenden Befehl [ Link ].
kubectl apply -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: custom-sa EOF
- Erstellen Sie eine neue Konfigurationsdatei für den Herd. Bitte beachten Sie, dass ich die Curl-Installation aktiviert habe, um Arbeit zu sparen :)
###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
- Führen Sie danach die Shell im Container aus.
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
- Erlaubnis verweigert. Oh, wir haben vergessen, eine neue Regelbindung mit den entsprechenden Berechtigungen hinzuzufügen. Lassen Sie es uns jetzt tun.
Wiederholen Sie die obigen Schritte:
a) Erstellen Sie eine identische Richtlinie für das Präfix "custom-sa /".
b) Erstellen Sie eine Rolle und nennen Sie sie "custom-sa-role".
c) Hängen Sie die Richtlinie an die Rolle an.
- Erstellen Sie eine Regelbindung (nur über cli / api möglich). Beachten Sie den unterschiedlichen Wert des Auswahlflags.
consul acl binding-rule create \ -method=auth-method-skywiz-consul-poc \ -bind-type=role \ -bind-name='custom-sa-role' \ -selector='serviceaccount.name=="custom-sa"'
- Melden Sie sich erneut über den Container poc-ubuntu-custom-sa an. Erfolg!
- Überprüfen Sie unseren Zugriff auf den Pfad custom-sa / key.
curl \ consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”
- Sie können auch sicherstellen, dass dieses Token keinen Zugriff auf kv in "custom-ns /" bietet. Wiederholen Sie einfach den obigen Befehl, nachdem Sie "custom-sa" durch das Präfix "custom-ns" ersetzt haben.
Erlaubnis verweigert.
Überlagerungsbeispiel:
- Es ist zu beachten, dass alle regelbindenden Zuordnungen mit diesen Rechten zum Token hinzugefügt werden.
- Unser poc-ubuntu-custom-sa-Container befindet sich im Standard-Namespace. Verwenden wir ihn also für eine andere Regelbindung.
- Wiederholen Sie die vorherigen Schritte:
a) Erstellen Sie eine identische Richtlinie für das Schlüsselpräfix "default /".
b) Erstellen Sie eine Rolle und nennen Sie sie "default-ns-role".
c) Hängen Sie die Richtlinie an die Rolle an. - Regelbindung erstellen (nur über cli / api möglich)
consul acl binding-rule create \ -method=auth-method-skywiz-consul-poc \ -bind-type=role \ -bind-name='default-ns-role' \ -selector='serviceaccount.namespace=="default"'
- Gehen Sie zurück zu unserem poc-ubuntu-custom-sa-Container und versuchen Sie, auf den Standardpfad / kv zuzugreifen.
- Erlaubnis verweigert.
Sie können die angegebenen Anmeldeinformationen für jedes Token in der Benutzeroberfläche unter ACL> Token anzeigen. Wie Sie sehen können, ist unserem aktuellen Token nur eine "benutzerdefinierte Rolle" zugeordnet. Das Token, das wir derzeit verwenden, wurde beim Anmelden generiert, und dann gab es nur eine Regelbindung, die dann entsprach. Wir müssen uns erneut anmelden und das neue Token verwenden. - Stellen Sie sicher, dass Sie sowohl aus den Pfaden "custom-sa /" als auch "default /" kv lesen können.
Erfolg!
Dies liegt daran, dass unser poc-ubuntu-custom-sa mit den Bindungen der Regeln custom-sa und default-ns übereinstimmt.
Fazit
TTL Token mgmt?
Zum Zeitpunkt dieses Schreibens gibt es keine integrierte Möglichkeit, die TTL für Token zu bestimmen, die mit dieser Autorisierungsmethode generiert wurden. Es wäre eine fantastische Gelegenheit, die Konsulautorisierung sicher zu automatisieren.
Es ist möglich, ein Token manuell mit TTL zu erstellen:
Ich hoffe, dass wir in naher Zukunft steuern können, wie Token generiert werden (für jede Regel oder Autorisierungsmethode) und TTL hinzufügen können.
Bis dahin wird vorgeschlagen, in Ihrer Logik den Endpunkt des Austritts aus dem System zu verwenden.
Lesen Sie auch andere Artikel in unserem Blog: