Alles richtig, nach der Veröffentlichung Anfang Mai 2019 kann man in Consul die Authentifizierung von Anwendungen und Diensten, die in Kubernetes ausgeführt werden, nativ durchführen.
In diesem Leitfaden erstellen wir Schritt für Schritt (Proof of Concept – Machbarkeitsnachweis) und demonstrieren diese neue Funktion. Sie sollten grundlegende Kenntnisse über Kubernetes und Hashicorp’s Consul haben. Obwohl Sie jede Cloud-Plattform oder lokale Umgebung verwenden können, werden wir in diesem Leitfaden die Google Cloud Platform nutzen.
Überblick
Wenn wir zur , erhalten wir eine kurze Übersicht über den Zweck und die Anwendungsfälle sowie einige technische Details und eine allgemeine Übersicht über die Logik. Ich empfehle dringend, es mindestens einmal zu lesen, bevor wir fortfahren, da ich jetzt alles erklären und aufschlüsseln werde.
Schema 1: Offizielle Übersicht über die Authentifizierungsmethode von Consul
Lassen Sie uns in die .
Natürlich gibt es dort hilfreiche Informationen, aber kein Leitfaden, wie man das alles wirklich nutzt. Also durchforsten Sie das Internet nach einem Leitfaden. Und dann… scheitern Sie. Das passiert. Lassen Sie uns das beheben.
Bevor wir mit der Erstellung unseres POC beginnen, kehren wir zur Übersicht der Authentifizierungsmethoden von Consul (Schema 1) zurück und verfeinern diese im Kontext von Kubernetes.
Architektur
In diesem Leitfaden erstellen wir einen Consul-Server auf einer separaten Maschine, der mit einem Kubernetes-Cluster interagiert, in dem der Consul-Client installiert ist. Dann erstellen wir unsere Dummy-Anwendung in einem Pod und verwenden unsere konfigurierte Authentifizierungsmethode, um aus unserem Consul Key/Value-Speicher zu lesen.
Das folgende Schema zeigt detailliert die Architektur, die wir in diesem Leitfaden erstellen, sowie die Logik der Authentifizierungsmethode, die später erklärt wird.
Schema 2: Übersicht über die Authentifizierungsmethode in Kubernetes
Eine kleine Anmerkung: Der Consul-Server muss nicht außerhalb des Kubernetes-Clusters leben, damit das funktioniert. Aber ja, er kann auch so oder so agieren.
Also, indem wir das Übersichtsschema von Consul (Schema 1) nehmen und es auf Kubernetes anwenden, erhalten wir das obige Schema (Schema 2), und die Logik wird folgendermassen sein:
- Jeder Pod wird mit einem Service-Konto verknüpft, das einen von Kubernetes generierten und bekannten JWT-Token enthält. Dieser Token wird auch standardmäßig in den Pod eingefügt.
- Unsere Anwendung oder unser Dienst innerhalb des Pods initiiert einen Anmeldebefehl an unseren Consul-Client. Im Anmeldeantrag wird auch unser Token angegeben und der Name genannt spezifisch erstellt der Autorisierungsmethode (Typ Kubernetes). Dieser Schritt Nr. 2 entspricht Schritt 1 des Consul-Schemas (Schema 1).
- Unser Consul-Client leitet diese Anfrage dann an unseren Consul-Server weiter.
- MAGIE! Genau hier überprüft der Consul-Server die Authentizität der Anfrage, sammelt Informationen zur Identität der Anfrage und vergleicht diese mit den zugehörigen vordefinierten Regeln. Weiter unten wird ein anderes Schema zur Veranschaulichung bereitgestellt. Dieser Schritt entspricht den Schritten 3, 4 und 5 des Überblickschemas für Consul (Schema 1).
- Unser Consul-Server generiert einen Consul-Token mit Berechtigungen gemäß den von uns angegebenen Regeln der Autorisierungsmethode (die wir definiert haben) in Bezug auf die Identität des Anfragenden. Dann wird dieser Token zurückgesendet. Dies entspricht Schritt 6 des Consul-Schemas (Schema 1).
- Unser Consul-Client leitet den Token an die anfragende Anwendung oder den Dienst weiter.
Unsere Anwendung oder unser Dienst können nun diesen Consul-Token verwenden, um mit unseren Consul-Daten zu kommunizieren, wie es die Berechtigungen des Tokens vorsehen.
Die Magie ist enthüllt!
Für diejenigen von Ihnen, die mit einem einfachen Hasen aus dem Hut nicht zufrieden sind und wissen wollen, wie es funktioniert… lassen Sie mich „Ihnen zeigen, wie tief die Hasenloch».
Wie bereits erwähnt, besteht unser „magischer“ Schritt (Schema 2: Schritt 4“ darin, dass der Consul-Server die Authentifizierung der Anfrage überprüft, Informationen zur Anfrage sammelt und diese mit zugehörigen vordefinierten Regeln vergleicht. Dieser Schritt entspricht den Schritten 3, 4 und 5 des Überblickschemas für Consul (Schema 1). Im Folgenden finden Sie ein Schema (Schema 3), dessen Ziel es ist, anschaulich darzustellen, was tatsächlich geschieht unter der Haube der spezifischen Autorisierungsmethode Kubernetes.
Schema 3: Die Magie ist enthüllt!
- Als Ausgangspunkt leitet unser Consul-Client die Anmeldeanfrage an unseren Consul-Server weiter, zusammen mit dem Token des Kubernetes-Kontos und dem spezifischen Namen der zuvor erstellten Autorisierungsmethode. Dieser Schritt entspricht Schritt 3 der vorherigen Erklärung des Schemas.
- Jetzt muss der Consul-Server (oder der Leader) die Authentizität des erhaltenen Tokens überprüfen. Daher wird er sich mit dem Kubernetes-Cluster (über den Consul-Client) beraten und, sofern die entsprechenden Berechtigungen vorliegen, feststellen, ob das Token authentisch ist und wem es gehört.
- Anschließend wird die überprüfte Anfrage an den Consul-Leader zurückgegeben, und auf dem Consul-Server wird nach der Instanz der Autorisierungs-Methode mit dem im Login-Request angegebenen Namen (und vom Typ Kubernetes) gesucht.
- Der Consul-Leader identifiziert die angegebene Instanz der Autorisierungs-Methode (falls vorhanden) und liest die angehängten Bindungsregeln. Danach liest er diese Regeln und vergleicht sie mit den überprüften Identitätsattributen.
- Tada! Wir gehen zu Schritt 5 in der vorherigen Erläuterung des Schemas.
Starten Sie den Consul-Server auf einer normalen virtuellen Maschine
Ab diesem Punkt werde ich hauptsächlich Anweisungen zur Erstellung dieses POCs geben, oft in Punkten, ohne erklärende vollständige Sätze. Wie bereits erwähnt, werde ich GCP zur Erstellung der gesamten Infrastruktur verwenden, aber Sie können eine ähnliche Infrastruktur auch woanders erstellen.
- Starten Sie die virtuelle Maschine (Instanz / Server).
- Erstellen Sie eine Regel für die Firewall (Sicherheitsgruppe in AWS):
- Ich mag es, der Regel und dem Netzwerkkartentag denselben Namen zuzuweisen, in diesem Fall "skywiz-consul-server-poc".
- Finden Sie die IP-Adresse Ihres lokalen Computers und fügen Sie sie zur Liste der Quell-IP-Adressen hinzu, damit wir auf die Benutzeroberfläche (UI) zugreifen können.
- Öffnen Sie den Port 8500 für die UI. Klicken Sie auf Erstellen. Wir werden diese Firewall bald wieder ändern [].
- Fügen Sie der Instanz eine Regel für die Firewall hinzu. Gehen Sie zurück zum VM-Dashboard auf dem Consul-Server und fügen Sie "skywiz-consul-server-poc" in das Feld für die Netzwerkkartentags ein. Klicken Sie auf Speichern.
- Installieren Sie Consul auf der virtuellen Maschine, hier überprüfen. Denken Sie daran, dass Sie eine Version von Consul ≥ 1.5 benötigen [link]
- Lassen Sie uns einen einzelnen Knoten Consul erstellen – 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 detailliertere Anleitung zur Installation von Consul und zur Einrichtung eines Clusters aus 3 Knoten finden Sie unter. .
- Erstellen Sie die Datei /etc/consul.d/agent.json wie folgt []:
### /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 Menge Ausgaben sehen und letztendlich „… update blocked by ACLs“.
- Finden Sie die externe IP-Adresse des Consul-Servers und öffnen Sie den Browser mit dieser IP-Adresse an Port 8500. Stellen Sie sicher, dass die Benutzeroberfläche geöffnet wird.
- Versuchen Sie, ein paar Schlüssel/Werte hinzuzufügen. Es sollte einen Fehler geben. Das liegt daran, dass wir den Consul-Server mit ACLs geladen haben und alle Regeln verboten haben.
- Gehen Sie zurück zu Ihrem Terminal auf dem Consul-Server und führen Sie den Prozess im Hintergrund oder auf andere Weise aus, damit er läuft, und geben Sie folgendes ein:
consul acl bootstrap- Suchen Sie nach dem Wert „SecretID“ und gehen Sie zurück zur Benutzeroberfläche. Geben Sie auf der Registerkarte „ACL“ die geheime Identifikationsnummer des Tokens ein, die Sie gerade kopiert haben. Kopieren Sie SecretID noch woanders hin, es wird später benötigt.
- Jetzt fügen Sie ein paar Schlüssel/Werte hinzu. Für dieses POC fügen wir Folgendes hinzu: Schlüssel: „custom-ns/test_key“, Wert: „Ich bin im custom-ns-Ordner!“
Starten eines Kubernetes-Clusters für unsere Anwendung mit einem Consul-Client als Daemonset.
- Erstellen Sie ein K8s (Kubernetes) Cluster. Wir werden es in derselben Zone wie den Server erstellen, um schnelleren Zugriff zu ermöglichen, und deshalb können wir dasselbe Subnetz für eine einfache Verbindung mit internen IP-Adressen verwenden. Wir werden es „skywiz-app-with-consul-client-poc“ nennen.
- Als Hinweis, hier ist ein gutes Handbuch, auf das ich gestoßen bin, als ich das POC Consul-Cluster mit Consul Connect einrichtete.
- Wir werden auch das Hashicorp Helm-Chart mit einer erweiterten Wertedatei verwenden.
- Installieren und konfigurieren Sie Helm. 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- helm chart:
- Verwenden Sie die folgende Werte-Datei (beachten Sie, dass ich die meisten deaktiviert habe):
### 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- Wenden Sie das Helm-Chart an:
./helm install -f poc-helm-consul-values.yaml ./consul-helm -name skywiz-app-with-consul-client-poc- Bei dem Versuch, es zu starten, benötigt es Berechtigungen für den Consul-Server, also lassen Sie uns diese hinzufügen.
- Beachten Sie den „Pod-IP-Bereich“, der auf dem Dashboard des Clusters angezeigt wird, und gehen Sie zurück zu unserer Regel für die Firewall „skywiz-consul-server-poc“.
- Fügen Sie den Pod-IP-Bereich zur IP-Liste hinzu und öffnen Sie die Ports 8301 und 8300.
- Gehen Sie zur Consul UI, und nach ein paar Minuten werden Sie sehen, dass unser Cluster auf der Knoten-Registerkarte erscheint.
Einrichtung der Autorisierungsmethode durch Integration von Consul mit Kubernetes.
- Gehen Sie zurück zum Terminal des Consul-Servers und exportieren Sie das Token, das Sie zuvor gespeichert haben:
export CONSUL_HTTP_TOKEN=- 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 -consul-client -o yaml | grep "- name:"
kubectl get secret -o yaml | grep token:- Das Token ist in base64 kodiert, entschlüsseln Sie es daher mit Ihrem bevorzugten Werkzeug []
- kubernetes-ca-cert
kubectl get secret -o yaml | grep ca.crt:- Nehmen Sie das Zertifikat „ca.crt“ (nach der Dekodierung mit base64) und speichern Sie es in die Datei „ca.crt“.
- Erstellen Sie jetzt eine Instanz der Authentifizierungsmethode, indem Sie die Platzhalter durch die Werte ersetzen, die Sie gerade erhalten haben.
consul acl auth-method create
-type "kubernetes"
-name "auth-method-skywiz-consul-poc"
-description "Dies ist eine Authentifizierungsmethode, die Kubernetes für den Cluster skywiz-app-with-consul-client-poc verwendet"
-kubernetes-host ""
-kubernetes-ca-cert=@ca.crt
-kubernetes-service-account-
jwt=""- Als nächstes müssen wir eine Regel erstellen und sie an die neue Rolle anhängen. Für diesen Teil können Sie das Consul UI verwenden, wir werden jedoch die Kommandozeile verwenden.
- Schreiben Sie die Regel
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Wenden Sie die Regel an
consul acl policy create
-name kv-custom-ns-policy
-description "Dies ist eine Beispielrichtlinie für kv in custom-ns/"
-rules @kv-custom-ns-policy.hcl- Suchen Sie die Identifikationsnummer der gerade erstellten Regel aus der Ausgabe.
- Erstellen Sie eine Rolle mit der neuen Regel.
consul acl role create
-name "custom-ns-role"
-description "Dies ist eine Beispielrolle für den Namensraum custom-ns"
-policy-id- Nun verknüpfen wir unsere neue Rolle mit der Instanz der Authentifizierungsmethode. Beachten Sie, dass das Flag „Selector“ bestimmt, ob unsere Anmeldanfrage diese Rolle erhält. Überprüfen Sie hier andere Optionen für den Selector:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Konfigurationen zum Schluss
Zugriffsrechte
- Erstellen Sie Zugriffsrechte. Wir müssen Consul die Berechtigung erteilen, das Token-Identitätszertifikat der K8s-Dienstkonten zu überprüfen und zu identifizieren.
- Schreiben Sie Folgendes in eine 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- Lassen Sie uns Zugriffsrechte erstellen
kubectl create -f skywiz-poc-consul-server_rbac.yamlVerbindung zum Consul Client
- Wie bereits erwähnt, , gibt es mehrere Optionen, um sich mit dem Daemonset zu verbinden, aber wir werden zur nächsten einfachen Lösung übergehen:
- Wenden Sie die folgende Datei an [].
### 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- Wenden Sie dann den folgenden eingebauten Befehl an, um das ConfigMap zu erstellen []. Beachten Sie, dass wir uns auf den Namen unseres Dienstes beziehen, ersetzen Sie ihn nach Bedarf.
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}')"]}
EOFTesten der Auth-Methode
Nun schauen wir uns die Magie in Aktion an!
- Erstellen Sie weitere Schlüsselordner mit dem gleichen übergeordneten Schlüssel (d. h. /sample_key) und einem Wert Ihrer Wahl. Erstellen Sie entsprechende Richtlinien und Rollen für die neuen Schlüsselpfade. Wir werden die Bindungen später vornehmen.
Benutzertest für den Namensraum:
- Lassen Sie uns unseren eigenen Namensraum erstellen:
kubectl create namespace custom-ns- Lassen Sie uns einen Pod in unserem neuen Namensraum erstellen. Schreiben Sie die Konfiguration für den Pod.
###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 erstellen:
kubectl create -f poc-ubuntu-custom-ns.yaml- Sobald der Container läuft, betreten Sie ihn und installieren Sie curl.
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 zum Login in Consul, indem wir die zuvor erstellte Authentifizierungsmethode verwenden [].
- Um das eingegebene Token aus Ihrem Dienstkonto anzuzeigen:
cat /run/secrets/kubernetes.io/serviceaccount/token- Schreiben Sie das Folgende in eine Datei innerhalb des Containers:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Login!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Um die obigen Schritte in einer Zeile auszuführen (da wir mehrere Tests durchfü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! Sollte es zumindest. Holen Sie sich jetzt die SecretID und versuchen Sie, auf den Schlüssel/Wert zuzugreifen, auf den wir Zugriff haben sollten.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: ”- Sie können den „Wert“ base64 dekodieren und sehen, dass er dem Wert in custom-ns/test_key in der UI entspricht. Wenn Sie den gleichen oben in diesem Handbuch angegebenen Wert verwendet haben, wird Ihr kodierter Wert IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi sein.
Test des Dienstkontos:
- Erstellen Sie ein benutzerdefiniertes Servicekonto mit dem folgenden Befehl [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Erstellen Sie eine neue Konfigurationsdatei für den Pod. Beachten Sie, dass ich die Installation von curl zur Arbeitserleichterung hinzugefügt habe 🙂
###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- Starten Sie danach die Shell innerhalb des Containers.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- 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- Zugriff verweigert. Oh, wir haben vergessen, eine neue Regelbindung mit den entsprechenden Berechtigungen hinzuzufügen, lass uns das jetzt tun.
Wiederholen Sie die oben beschriebenen Schritte:
a) Erstellen Sie eine identische Richtlinie für das Präfix „custom-sa/“.
b) Erstellen Sie eine Rolle, nennen Sie sie „custom-sa-role“
c) Fügen Sie die Richtlinie zur Rolle hinzu.
- Erstellen Sie eine Regelbindung (möglich nur über cli / api). Achten Sie auf den anderen Wert des Selektors.
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 im Container „poc-ubuntu-custom-sa“ an. Erfolg!
- Überprüfen Sie unseren Zugriff auf den Schlüsselpfad custom-sa/.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header "X-Consul-Token: "- Sie können auch sicherstellen, dass dieses Token keinen Zugriff auf kv in „custom-ns/“ gewährt. Führen Sie einfach den obigen Befehl erneut aus, indem Sie „custom-sa“ durch das Präfix „custom-ns“ ersetzen.
Zugriff verweigert.
Beispiel für Overlay:
- Es ist anzumerken, dass alle Zuordnungen der Regelbindung in das Token mit diesen Rechten aufgenommen werden.
- Unser Container „poc-ubuntu-custom-sa“ befindet sich im Standard-Namensraum – also lassen Sie uns diesen für eine andere Regelbindung verwenden.
- Wiederholen Sie die vorherigen Schritte:
a) Erstellen Sie eine identische Richtlinie für das Schlüsselpräfix „default/“.
b) Erstellen Sie eine Rolle, nennen Sie sie „default-ns-role“
c) Fügen Sie die Richtlinie zur Rolle hinzu. - Erstellen Sie eine Regelbindung (möglich nur über 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"'- Kehren Sie zu unserem Container „poc-ubuntu-custom-sa“ zurück und versuchen Sie, auf den Pfad „default/“ kv zuzugreifen.
- Zugriff verweigert.
Sie können die angegebenen Anmeldeinformationen für jedes Token im UI im Abschnitt ACL > Tokens einsehen. Wie Sie sehen können, ist nur eine „custom-sa-role“ an unser aktuelles Token angehängt. Das Token, das wir derzeit verwenden, wurde erstellt, als wir uns angemeldet haben, und zu diesem Zeitpunkt gab es nur eine Regelbindung, die zu diesem Zeitpunkt 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!
Das liegt daran, dass unser „poc-ubuntu-custom-sa“ mit den Regelbindungen „custom-sa“ und „default-ns“ übereinstimmt.
Fazit
TTL-Token-Management?
Zum Zeitpunkt des Verfassens dieses Artikels gibt es keinen integrierten Weg, um TTL für die durch diese Authentifizierungsmethode generierten Tokens festzustellen. Das wäre eine fantastische Möglichkeit, eine sichere Automatisierung der Authentifizierung in Consul zu ermöglichen.
Es gibt die Möglichkeit, ein Token mit TTL manuell zu erstellen:
Expiration Time (Ablaufzeit) — die Zeit, zu der dieses Token widerrufen wird. (Optional; hinzugefügt in Consul 1.5.0)- Nur verfügbar für manuelle Erstellung / Aktualisierung
Ich hoffe, dass wir bald kontrollieren können, wie Tokens (für jede Regel oder Methode der Autorisierung) generiert werden und TTL hinzufügen können.
Bis dahin wird empfohlen, in Ihrer Logik den Endpunkt zum Ausloggen zu verwenden.
Lesen Sie auch andere Artikel in unserem Blog:
Quelle: habr.com
