Genau, nach der Veröffentlichung Anfang Mai 2019 kann Consul die Authentifizierung von Anwendungen und Diensten, die in Kubernetes ausgeführt werden, nativ unterstützen.
In diesem Leitfaden erstellen wir Schritt für Schritt (Proof of Concept, PoC – Nachweis der Machbarkeit der Konzeptidee – Anmerkung des Übersetzers), um diese neue Funktion zu demonstrieren. Grundkenntnisse über Kubernetes und Hashicorp's Consul werden von Ihnen erwartet. Obwohl Sie jede Cloud-Plattform oder lokale Umgebung verwenden können, werden wir in diesem Leitfaden die Google Cloud Platform nutzen.
Übersicht
Wenn wir zur wechseln, erhalten wir eine kurze Übersicht über deren Zweck und Anwendungsfall sowie einige technische Details und einen allgemeinen Überblick über die Logik. Ich empfehle dringend, sie mindestens einmal zu lesen, bevor Sie fortfahren, da ich alles jetzt erklären und detailliert erläutern werde.
Schema 1: Offizielle Übersicht über die Authentifizierungsmethoden von Consul
Lassen Sie uns die .
Natürlich gibt es nützliche Informationen, aber keine Anleitung dazu, wie man all dies tatsächlich nutzt. Daher durchforsten Sie, wie jeder vernünftige Mensch, das Internet auf der Suche nach einer Anleitung. Und dann… scheitern Sie. So ist es. Lassen Sie uns das ändern.
Bevor wir mit der Erstellung unseres POCs fortfahren, lassen Sie uns einen Blick auf die Autorisierungsmethoden von Consul werfen (Schema 1) und diese im Kontext von Kubernetes präzisieren.
Architektur von
In diesem Leitfaden werden wir einen Consul-Server auf einer separaten Maschine erstellen, die mit einem Kubernetes-Cluster interagiert, auf dem der Consul-Client installiert ist. Anschließend erstellen wir unser fiktives Anwendung innerhalb eines Pods und verwenden unsere konfigurierte Autorisierungsmethode, um aus unserem Consul Key/Value-Speicher zu lesen.
Das folgende Schema zeigt im Detail die Architektur, die wir in diesem Leitfaden erstellen, sowie die Logik der Autorisierungsmethode, die später erklärt wird.
Schema 2: Überblick über die Autorisierungsmethode in Kubernetes
Eine kleine Anmerkung: Der Consul-Server muss nicht außerhalb des Kubernetes-Clusters betrieben werden, damit dies funktioniert. Aber ja, er kann sowohl drinnen als auch draußen sein.
Wenn wir das Übersichtsschema von Consul (Schema 1) nehmen und es auf Kubernetes anwenden, erhalten wir das obenstehende Schema (Schema 2). Die Logik wird dann wie folgt sein:
- Jeder Pod wird mit einem Dienstkonto verbunden, das ein JWT-Token enthält, das von Kubernetes generiert und bekannt ist. Dieses Token wird auch standardmäßig in den Pod eingefügt.
- Unsere Anwendung oder der Dienst innerhalb des Pods initiiert einen Anmeldeversuch bei unserem Consul-Clienten. Im Anmeldeantrag wird auch unser Token angegeben und der Name eines speziell erstellten Autorisierungsmethoden (vom Typ Kubernetes). Dieser Schritt Nr. 2 entspricht Schritt 1 des Consul-Schemas (Schema 1).
- Unser Consul-Client wird dann diese Anfrage an unseren Consul-Server weiterleiten.
- MAGIE! An dieser Stelle überprüft der Consul-Server die Authentizität der Anfrage, sammelt Identitätsinformationen der Anfrage und vergleicht sie mit vorgegebenen Regeln. Im Folgenden wird ein weiteres Schema bereitgestellt, um dies zu veranschaulichen. Dieser Schritt entspricht den Schritten 3, 4 und 5 des Übersichtsschemas von Consul (Schema 1).
- Unser Consul-Server generiert ein Consul-Token mit Berechtigungen gemäß den von uns festgelegten Autorisierungsrichtlinien, die wir für die Identität des Anfragenden definiert haben. Anschließend sendet er dieses Token zurück. Dies entspricht Schritt 6 des Consul-Schemas (Schema 1).
- Unser Consul-Client leitet das Token an die anfragende Anwendung oder den Dienst weiter.
Unsere Anwendung oder der Dienst kann nun dieses Consul-Token nutzen, um mit unseren Consul-Daten zu kommunizieren, wie es die Berechtigungen des Tokens definieren.
Die Magie ist enthüllt!
Für diejenigen von Ihnen, die sich nicht mit einem einfachen Kaninchen aus dem Hut zufrieden geben und wissen möchten, wie es funktioniert… lassen Sie mich Ihnen zeigen, wie tief die Hasenlager».
Wie bereits erwähnt, besteht unser 'magischer' Schritt (Schema 2: Schritt 4) darin, dass der Consul-Server die Authentizität der Anfrage überprüft, Informationen über die Anfrage sammelt und diese mit etwaigen vordefinierten Regeln vergleicht. Dieser Schritt entspricht den Schritten 3, 4 und 5 im Überblicks-Schema von Consul (Schema 1). Im Folgenden finden Sie eine Grafik (Schema 3), die verdeutlicht, was tatsächlich unter der Haube der spezifische Kubernetes-Authorisierungsansatz ist.
Schema 3: Das Geheimnis enthüllt!
- Als Ausgangspunkt leitet unser Consul-Client die Anfrage an unseren Consul-Server mit dem Kubernetes-Konto-Token und dem spezifischen Namen der Autorisierungsmethode weiter, die zuvor erstellt wurde. Dieser Schritt entspricht Schritt 3 in der vorherigen Erklärung des Schemas.
- Jetzt muss der Consul-Server (oder der Leader) das erhaltene Token authentifizieren. Dazu konsultiert er den Kubernetes-Cluster (über den Consul-Client), und bei Vorliegen der entsprechenden Berechtigungen werden wir feststellen, ob das Token gültig ist und wem es gehört.
- Anschließend wird die geprüfte Anfrage an den Consul-Leader zurückgegeben, und auf dem Consul-Server wird die Instanz der Autorisierungsmethode mit dem im Login-Request angegebenen Namen (und Typ Kubernetes) gesucht.
- Der Consul-Leader identifiziert die angegebene Instanz der Autorisierungsmethode (falls gefunden) und liest die an sie angehängten Binding-Regeln. Danach liest er diese Regeln und vergleicht sie mit den geprüften Identitätsattributen.
- Tada! Wir kommen zu Schritt 5 in der vorherigen Erklärung des Schemas.
Starten Sie den Consul-Server auf einer regulären virtuellen Maschine.
Ab diesem Moment werde ich hauptsächlich Anweisungen zur Erstellung dieses POCs geben, oft stichpunktartig, ohne erklärende vollständige Sätze. Wie bereits erwähnt, werde ich GCP verwenden, um die gesamte Infrastruktur zu erstellen, aber Sie können eine ähnliche Infrastruktur auch anderswo aufbauen.
- Starten Sie eine virtuelle Maschine (Instanz / Server).
- Erstellen Sie eine Regel für die Firewall (Sicherheitsgruppe in AWS):
- Ich bevorzuge es, der Maschine den gleichen Namen wie der Regel und dem Netzwerktag zuzuweisen, in diesem Fall ist es "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 eine Regel für die Firewall zur Instanz 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 Netzwerktags ein. Klicken Sie auf Speichern.
- Installieren Sie Consul auf der virtuellen Maschine; überprüfen Sie dies hier. Denken Sie daran, dass Sie eine Consul-Version ≥ 1.5 benötigen [link]
- Lassen Sie uns einen Single Node 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 ausführlichere Anleitung zur Installation von Consul und zur Einrichtung eines Clusters mit 3 Knoten finden Sie hier. .
- 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 schließlich „… update blocked by ACLs“.
- Finden Sie die externe IP-Adresse des Consul-Servers und öffnen Sie Ihren Browser mit dieser IP-Adresse auf Port 8500. Stellen Sie sicher, dass die Benutzeroberfläche angezeigt wird.
- Versuchen Sie, ein paar Schlüssel/Werte hinzuzufügen. Es sollte ein Fehler auftreten. Dies liegt daran, dass wir den Consul-Server mit ACLs konfiguriert haben und alle Regeln gesperrt sind.
- Gehen Sie zurück zu Ihrer Shell auf dem Consul-Server und starten Sie den Prozess im Hintergrund oder auf andere Weise, damit er weiterläuft, 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 geheimen Identifikationsnummer des Tokens ein, die Sie gerade kopiert haben. Kopieren Sie den SecretID noch an einen anderen Ort, er wird später benötigt.
- Fügen Sie jetzt ein paar Schlüssel/Werte hinzu. Dafür fügen wir folgendes zu POC hinzu: Schlüssel: „custom-ns/test_key“, Wert: „Ich bin im custom-ns-Ordner!“
Starten des Kubernetes-Clusters für unsere Anwendung mit dem Consul-Client als Daemonset.
- Erstellen Sie ein K8s (Kubernetes)-Cluster. Wir werden es in derselben Zone wie den Server erstellen, um schnelleren Zugriff zu haben, und deshalb können wir dasselbe Subnetz für einfache Verbindungen mit internen IP-Adressen verwenden. Wir nennen es „skywiz-app-with-consul-client-poc“.
- Zur Info: Hier ist eine gute Anleitung, auf die ich gestoßen bin, während ich das POC für den Consul-Cluster mit Consul Connect eingerichtet habe.
- Wir werden auch das Hashicorp Helm-Chart mit einer erweiterten Werte-Datei 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- Beim Versuch, es zu starten, benötigt es Berechtigungen für den Consul-Server, also lassen Sie uns diese hinzufügen.
- Achten Sie auf den 'Pod-IP-Bereich' im Dashboard des Clusters und kehren Sie zu unserer Regel für die Firewall 'skywiz-consul-server-poc' zurück.
- Fügen Sie den Pod-IP-Bereich zur Liste der IP-Adressen hinzu und öffnen Sie die Ports 8301 und 8300.
- Gehen Sie zum Consul UI, und nach ein paar Minuten wird unser Cluster im Knoten-Tab sichtbar sein.
Konfigurieren Sie die Authentifizierungsmethode, indem Sie Consul mit Kubernetes integrieren.
- Gehen Sie zurück zur Shell 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 mit Ihrem bevorzugten Tool []
- kubernetes-ca-cert
kubectl get secret -o yaml | grep ca.crt:- Nehmen Sie das Zertifikat 'ca.crt' (nach der base64-Dekodierung) und schreiben Sie es in die Datei 'ca.crt'.
- Erstellen Sie nun 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-mit-consul-klient-poc verwendet"
-kubernetes-host ""
-kubernetes-ca-cert=@ca.crt
-kubernetes-service-account-
jwt=""- Nun müssen wir eine Regel erstellen und sie an eine neue Rolle anhängen. Für diesen Teil können Sie die Consul-Benutzeroberfläche verwenden, aber wir werden die Befehlszeile benutzen.
- Regel schreiben
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Regel anwenden
consul acl policy create
-name kv-custom-ns-policy
-description "Dies ist eine Beispielrichtlinie für kv im custom-ns/"
-rules @kv-custom-ns-policy.hcl- Finden Sie die ID der Regel, die Sie gerade erstellt haben, 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 custom-ns-Namespace"
-policy-id- Jetzt verbinden wir unsere neue Rolle mit der Authentifizierungsmethode. Beachten Sie, dass das Flag „Selektor“ bestimmt, ob unsere Anfrage für den Zugriff diese Rolle erhalten wird. Überprüfen Sie hier andere Selektoroptionen:
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 Abschluss
Zugriffsrechte
- Erstellen Sie Zugriffsrechte. Wir müssen Consul die Erlaubnis erteilen, die Token-ID der K8s-Dienstkonto zu überprüfen und zu identifizieren.
- Schreiben Sie Folgendes 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- Lassen Sie uns Berechtigungen erstellen
kubectl create -f skywiz-poc-consul-server_rbac.yamlVerbindung zum Consul-Client
- Wie bereits erwähnt , gibt es mehrere Optionen zum Verbinden mit dem Daemonset, aber wir gehen zu der nächsten einfachen Lösung über:
- 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 die ConfigMap [] zu erstellen. Beachten Sie, dass wir uns auf den Namen unseres Dienstes beziehen, ersetzen Sie ihn bei 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 Authentifizierungsmethode
Jetzt schauen wir uns die Magie in Aktion an!
- Erstellen Sie einige weitere Schlüsselordner mit demselben obersten 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 des Namensraums:
- Lassen Sie uns unseren eigenen Namensraum erstellen:
kubectl create namespace custom-ns- Wir erstellen ein Pod in unserem neuen Namensraum. Schreiben Sie die Konfiguration für das 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 gestartet ist, greifen Sie darauf zu 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 zur Anmeldung bei Consul, unter Verwendung der vorher erstellten Authentifizierungsmethode [].
- Um das eingegebene Token aus Ihrem Dienstkonto anzuzeigen:
cat /run/secrets/kubernetes.io/serviceaccount/token- Schreiben Sie Folgendes in eine Datei innerhalb des Containers:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Anmelden!
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! Zumindest sollte es das. Jetzt holen Sie sich 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 "Value" in base64 decodieren und sehen, dass er dem Wert im custom-ns/test_key im UI entspricht. Wenn Sie den oben in dieser Anleitung angegebenen Wert verwendet haben, wird Ihr codierter Wert IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi sein.
Test der Kundenservice-Konten:
- Erstellen Sie ein benutzerdefiniertes ServiceAccount mit folgendem 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 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- Führen Sie danach die Shell innerhalb des Containers aus.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Anmelden!
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, die neue Regelbindung mit den entsprechenden Berechtigungen hinzuzufügen. Lassen Sie uns das jetzt erledigen.
Wiederholen Sie die obigen Schritte:
a) Erstellen Sie eine identische Politik für den Präfix „custom-sa/“.
b) Erstellen Sie eine Rolle und benennen Sie sie „custom-sa-role“
c) Verknüpfen Sie die Politik mit der Rolle.
- Erstellen Sie eine Regelbindung (möglicherweise nur über CLI / API). Beachten Sie den anderen Wert des Selektor-Flags.
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 vom Container „poc-ubuntu-custom-sa“ an. Erfolg!
- Überprüfen Sie unseren Zugang zum 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 Zugang zu kv in „custom-ns/“ gewährt. Führen Sie einfach den oben genannten Befehl aus, nachdem Sie „custom-sa“ durch den Präfix „custom-ns“ ersetzt haben.
Zugriff verweigert.
Beispiel für Overlay:
- Es ist bemerkenswert, dass alle Zuordnungen rule-binding mit diesen Berechtigungen zum Token hinzugefügt werden.
- Unser Container „poc-ubuntu-custom-sa“ befindet sich im Standard-Namespace – lassen Sie uns ihn für ein weiteres rule-binding verwenden.
- Wiederholen Sie die vorherigen Schritte:
a) Erstellen Sie eine identische Richtlinie für den Schlüsselpräfix „default/“.
b) Erstellen Sie eine Rolle und nennen Sie sie „default-ns-role“
c) Verknüpfen Sie die Politik mit der Rolle. - Erstellen Sie eine Rule-Binding (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"'- Gehen Sie zurück zu unserem Container „poc-ubuntu-custom-sa“ und versuchen Sie, auf den Pfad „default/“ kv zuzugreifen.
- Zugriff verweigert.
Sie können die angegebenen Anmeldeinformationen für jedes Token im UI unter ACL > Tokens einsehen. Wie Sie sehen können, ist unserem aktuellen Token nur eine „custom-sa-role“ zugeordnet. Das aktuell verwendete Token wurde generiert, als wir uns angemeldet haben, und es gab zu diesem Zeitpunkt nur eine Regelbindung, die zutraf. Wir müssen uns erneut anmelden und ein neues Token verwenden. - Stellen Sie sicher, dass Sie sowohl aus den Pfaden „custom-sa/“ als auch „default/“ lesen können.
Erfolg!
Dies liegt daran, dass unser „poc-ubuntu-custom-sa“ mit den Regelbindungen „custom-sa“ und „default-ns“ übereinstimmt.
Fazit
TTL Token-Verwaltung?
Zum Zeitpunkt des Schreibens dieses Artikels gibt es keinen integrierten Weg, um TTL für Tokens zu bestimmen, die mit dieser Autorisierungsmethode generiert wurden. Das wäre eine großartige Funktion – sichere Automatisierung der Consul-Autorisierung zu ermöglichen.
Es besteht die Möglichkeit, manuell ein Token mit TTL zu erstellen:
Ablaufzeit – der Zeitpunkt, zu dem dieses Token widerrufen wird. (Optional; hinzugefügt in Consul 1.5.0)- Nur für die manuelle Erstellung / Aktualisierung verfügbar.
Ich hoffe, dass wir in naher Zukunft kontrollieren können, wie Token generiert werden (für jede Regel oder Authentifizierungsmethode) und TTL hinzufügen können.
Bis dahin wird empfohlen, den Logout-Endpunkt in Ihrer Logik zu verwenden.
Lesen Sie auch andere Artikel in unserem Blog:
Quelle: habr.com
