Das stimmt, nach der Veröffentlichung Ab Anfang Mai 2019 können Sie in Consul Anwendungen und Dienste nativ autorisieren, die in Kubernetes ausgeführt werden.
In diesem Tutorial erstellen wir Schritt für Schritt (Proof of Concept, PoC) zur Demonstration dieser neuen Funktion. Es wird erwartet, dass Sie über Grundkenntnisse von Kubernetes und Hashicorps Consul verfügen. Während Sie jede Cloud-Plattform oder lokale Umgebung verwenden können, verwenden wir in diesem Tutorial die Cloud-Plattform von Google.
Beschreibung
Wenn wir gehen erhalten wir einen kurzen Überblick über Zweck und Anwendungsfall sowie einige technische Details und einen allgemeinen Überblick über die Logik. Ich empfehle dringend, es mindestens einmal zu lesen, bevor ich fortfahre, da ich jetzt alles erklären und durchkauen werde.
Diagramm 1: Offizielle Übersicht über die Consul-Autorisierungsmethode
Schauen wir rein .
Natürlich gibt es dort nützliche Informationen, aber es gibt keine Anleitung, wie man alles tatsächlich nutzt. Also durchforsten Sie, wie jeder vernünftige Mensch, das Internet nach Orientierung. Und dann... Du scheiterst. Es passiert. Lassen Sie uns das beheben.
Bevor wir mit der Erstellung unseres POC fortfahren, kehren wir zur Übersicht über die Autorisierungsmethoden von Consul zurück (Diagramm 1) und verfeinern sie im Kontext von Kubernetes.
Architektur
In diesem Tutorial erstellen wir einen Consul-Server auf einem separaten Computer, der mit einem Kubernetes-Cluster kommuniziert, auf dem der Consul-Client installiert ist. Anschließend erstellen wir unsere Dummy-Anwendung im Pod und verwenden unsere konfigurierte Autorisierungsmethode, um aus unserem Consul-Schlüssel-/Wertspeicher zu lesen.
Das folgende Diagramm beschreibt detailliert die Architektur, die wir in diesem Tutorial erstellen, sowie die Logik hinter der Autorisierungsmethode, die später erläutert wird.
Diagramm 2: Übersicht über die Kubernetes-Autorisierungsmethode
Ein kurzer Hinweis: Damit dies funktioniert, muss sich der Consul-Server nicht außerhalb des Kubernetes-Clusters befinden. Aber ja, er kann es so und so machen.
Wenn wir also das Consul-Übersichtsdiagramm (Diagramm 1) nehmen und Kubernetes darauf anwenden, erhalten wir das obige Diagramm (Diagramm 2), und die Logik hier ist wie folgt:
- An jeden Pod ist ein Dienstkonto angehängt, das ein von Kubernetes generiertes und bekanntes JWT-Token enthält. Dieses Token wird standardmäßig auch in den Pod eingefügt.
- Unsere Anwendung oder unser Dienst im Pod initiiert einen Anmeldebefehl für unseren Consul-Client. Die Login-Anfrage enthält auch unser Token und unseren Namen speziell erstellt Autorisierungsmethode (Kubernetes-Typ). Dieser Schritt Nr. 2 entspricht Schritt 1 des Consul-Diagramms (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 Anfrage, sammelt Informationen über die Identität der Anfrage und vergleicht sie mit allen zugehörigen vordefinierten Regeln. Nachfolgend finden Sie ein weiteres Diagramm zur Veranschaulichung. Dieser Schritt entspricht den Schritten 3, 4 und 5 des Consul-Übersichtsdiagramms (Diagramm 1).
- Unser Consul-Server generiert ein Consul-Token mit Berechtigungen gemäß unseren angegebenen Autorisierungsmethodenregeln (die wir definiert haben) in Bezug auf die Identität des Anforderers. Anschließend wird das Token zurückgesendet. Dies entspricht Schritt 6 des Consul-Diagramms (Diagramm 1).
- Unser Consul-Client leitet das Token an die anfragende Anwendung oder den anfragenden Dienst weiter.
Unsere Anwendung oder unser Dienst kann dieses Consul-Token nun verwenden, um mit unseren Consul-Daten zu kommunizieren, je nach den Berechtigungen des Tokens.
Der Zauber wird offenbart!
Für diejenigen unter Ihnen, die nicht nur mit einem Kaninchen aus dem Hut zufrieden sind und wissen möchten, wie es funktioniert ... lassen Sie mich Ihnen zeigen, wie tief Kaninchenbau".
Wie bereits erwähnt, besteht unser „magischer“ Schritt (Abbildung 2: Schritt 4) darin, dass der Consul-Server die Anfrage authentifiziert, die Anfrageinformationen sammelt und sie mit allen zugehörigen vordefinierten Regeln vergleicht. Dieser Schritt entspricht den Schritten 3, 4 und 5 des Consul-Übersichtsdiagramms (Diagramm 1). Nachfolgend finden Sie ein Diagramm (Diagramm 3), das deutlich machen soll, was tatsächlich passiert unter der Haube spezifische Kubernetes-Autorisierungsmethode.
Diagramm 3: Die Magie wird enthüllt!
- Als Ausgangspunkt leitet unser Consul-Client die Anmeldeanforderung mit dem Kubernetes-Kontotoken und dem spezifischen Instanznamen der zuvor erstellten Autorisierungsmethode an unseren Consul-Server weiter. Dieser Schritt entspricht Schritt 3 in der vorherigen Schaltungserklärung.
- Jetzt muss der Consul-Server (oder Anführer) die Authentizität des empfangenen Tokens überprüfen. Daher wird es den Kubernetes-Cluster konsultieren (über den Consul-Client) und mit den entsprechenden Berechtigungen herausfinden, ob das Token echt ist und wem es gehört.
- Die validierte Anfrage wird dann an den Consul-Leiter zurückgegeben und der Consul-Server sucht die Autorisierungsmethodeninstanz mit dem angegebenen Namen aus der Anmeldeanforderung (und dem Kubernetes-Typ).
- Der Konsulleiter identifiziert die angegebene Autorisierungsmethodeninstanz (falls gefunden) und liest den Satz an Bindungsregeln, die ihr zugeordnet sind. Anschließend liest es diese Regeln und vergleicht sie mit den verifizierten Identitätsattributen.
- TA Dah! Fahren wir mit Schritt 5 der vorherigen Schaltungserklärung fort.
Führen Sie Consul-Server auf einer regulären virtuellen Maschine aus
Von nun an werde ich hauptsächlich Anweisungen zum Erstellen dieses POC geben, oft in Aufzählungspunkten, ohne Erklärungen in ganzen Sätzen. Außerdem werde ich, wie bereits erwähnt, GCP verwenden, um die gesamte Infrastruktur zu erstellen, aber Sie können dieselbe Infrastruktur auch anderswo erstellen.
- Starten Sie die virtuelle Maschine (Instanz/Server).
- Erstellen Sie eine Regel für die Firewall (Sicherheitsgruppe in AWS):
- Ich möchte sowohl der Regel als auch dem Netzwerk-Tag denselben Maschinennamen zuweisen, in diesem Fall „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 (UI) zugreifen können.
- Öffnen Sie Port 8500 für die Benutzeroberfläche. Klicken Sie auf Erstellen. Wir werden diese Firewall bald wieder ändern [].
- Fügen Sie der Instanz eine Firewall-Regel hinzu. Gehen Sie zurück zum VM-Dashboard auf Consul Server und fügen Sie „skywiz-consul-server-poc“ zum Feld „Netzwerktags“ hinzu. Klicken Sie auf Speichern.
- Installieren Sie Consul auf einer virtuellen Maschine, siehe hier. Denken Sie daran, dass Sie eine Consul-Version ≥ 1.5 benötigen [Link]
- Erstellen wir einen einzelnen Knoten Consul – 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 aus drei Knoten finden Sie unter .
- Erstellen Sie eine 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 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 auf Port 8500. Stellen Sie sicher, dass die Benutzeroberfläche geöffnet wird.
- Versuchen Sie, ein Schlüssel/Wert-Paar hinzuzufügen. Da muss ein Irrtum vorliegen. Dies liegt daran, dass wir den Consul-Server mit einer ACL geladen und alle Regeln deaktiviert haben.
- Gehen Sie zurück zu Ihrer Shell auf dem Consul-Server und starten Sie den Prozess im Hintergrund oder auf andere Weise, um ihn zum Laufen zu bringen, 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 ID des Tokens ein, den Sie gerade kopiert haben. Kopieren Sie SecretID woanders hin, 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: Schlüssel: „custom-ns/test_key“, Wert: „Ich befinde mich im Ordner „custom-ns“!“
Starten eines Kubernetes-Clusters für unsere Anwendung mit dem Consul-Client als Daemonset
- Erstellen Sie einen K8s-Cluster (Kubernetes). Für einen schnelleren Zugriff erstellen wir es in derselben Zone wie der Server, sodass wir dasselbe Subnetz verwenden können, um problemlos eine Verbindung mit internen IP-Adressen herzustellen. Wir nennen es „skywiz-app-with-consul-client-poc“.
- Als Randbemerkung hier ist ein gutes Tutorial, auf das ich beim Einrichten eines POC Consul-Clusters mit Consul Connect gestoßen bin.
- Wir werden auch das Hashicorp-Helmdiagramm 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- Steuertafel:
- Verwenden Sie die folgende Wertedatei (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- Ruderkarte anwenden:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Wenn es ausgeführt werden soll, sind Berechtigungen für den Consul-Server erforderlich. Fügen wir diese also hinzu.
- Beachten Sie den „Pod-Adressbereich“ im Cluster-Dashboard und verweisen Sie auf unsere Firewall-Regel „skywiz-consul-server-poc“.
- Fügen Sie den Adressbereich für den Pod zur Liste der IP-Adressen hinzu und öffnen Sie die Ports 8301 und 8300.
- Gehen Sie zur Consul-Benutzeroberfläche und nach ein paar Minuten sehen Sie, dass unser Cluster auf der Registerkarte „Knoten“ angezeigt wird.
Konfigurieren einer Autorisierungsmethode durch Integration von Consul in Kubernetes
- Kehren Sie zur Consul-Server-Shell 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:- Der Token ist Base64-kodiert, also entschlüsseln Sie ihn mit Ihrem Lieblingstool []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Nehmen Sie das „ca.crt“-Zertifikat (nach der Base64-Dekodierung) und schreiben Sie es in die Datei „ca.crt“.
- Instanziieren Sie nun die Authentifizierungsmethode und ersetzen Sie die Platzhalter durch die Werte, die Sie gerade erhalten haben.
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>"- Als nächstes müssen wir eine Regel erstellen und sie der neuen Rolle zuordnen. Für diesen Teil können Sie die Consul-Benutzeroberfläche verwenden, wir verwenden jedoch die Befehlszeile.
- Schreiben Sie eine 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 "This is an example policy for kv at custom-ns/"
-rules @kv-custom-ns-policy.hcl- Suchen Sie in der Ausgabe nach der ID der Regel, die Sie gerade 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>- Jetzt verknüpfen wir unsere neue Rolle mit der Instanz der Authentifizierungsmethode. Beachten Sie, dass das Flag „Selektor“ bestimmt, ob unsere Anmeldeanfrage diese Rolle erhält. Weitere Auswahloptionen finden Sie hier:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Zuletzt Konfigurationen
Zugangsrechte
- Zugriffsrechte erstellen. Wir müssen Consul die Erlaubnis erteilen, die Identität des K8s-Dienstkonto-Tokens 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 Zugriffsrechte erstellen
kubectl create -f skywiz-poc-consul-server_rbac.yamlVerbindung zum Consul-Client herstellen
- Wie bereits erwähnt Es gibt mehrere Möglichkeiten, eine Verbindung zum Daemonset herzustellen, aber wir gehen zu der folgenden 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- Verwenden Sie dann den folgenden integrierten Befehl, um eine Konfigurationszuordnung zu erstellen []. Bitte beachten Sie, dass wir uns auf den Namen unseres Dienstes beziehen. Ersetzen Sie diesen 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}')"]}
EOFTesten der Authentifizierungsmethode
Jetzt sehen wir uns die Magie in Aktion an!
- Erstellen Sie mehrere weitere Schlüsselordner mit demselben Schlüssel der obersten Ebene (d. h. /sample_key) und einen Wert Ihrer Wahl. Erstellen Sie geeignete Richtlinien und Rollen für neue Schlüsselpfade. Die Bindungen machen wir später.
Benutzerdefinierter Namespace-Test:
- Erstellen wir unseren eigenen Namensraum:
kubectl create namespace custom-ns- Lassen Sie uns einen Pod in unserem neuen Namespace 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- Erstellen unter:
kubectl create -f poc-ubuntu-custom-ns.yaml- Sobald der Container ausgeführt wird, gehen Sie dorthin 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 Anmeldeanfrage an Consul mit der zuvor erstellten Autorisierungsmethode [].
- 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>"
}- Anmeldung!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Um die oben genannten 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- Funktioniert! Zumindest sollte es so sein. Nehmen Sie nun die SecretID und versuchen Sie, auf den Schlüssel/Wert zuzugreifen, auf den wir Zugriff haben sollen.
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 „Wert“ mit Base64 dekodieren und sehen, dass er mit dem Wert in „custom-ns/test_key“ in der Benutzeroberfläche übereinstimmt. Wenn Sie in diesem Tutorial den gleichen Wert wie oben verwendet hätten, wäre Ihr codierter Wert IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Test des Benutzerdienstkontos:
- Erstellen Sie ein benutzerdefiniertes ServiceAccount 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. Bitte beachten Sie, dass ich die Curl-Installation beigefügt 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 anschließend eine Shell im Container aus.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Anmeldung!
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, das machen wir jetzt.
Wiederholen Sie die vorherigen Schritte oben:
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 die unterschiedliche Bedeutung des Selektorflags.
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!
- Sehen Sie sich unseren Zugriff auf den Schlüsselpfad „custom-sa/“ an.
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/“ gewährt. Wiederholen Sie einfach den obigen Befehl, nachdem Sie „custom-sa“ durch das Präfix „custom-ns“ ersetzt haben.
Erlaubnis verweigert.
Overlay-Beispiel:
- Es ist zu beachten, dass alle Regelbindungszuordnungen mit diesen Rechten zum Token hinzugefügt werden.
- Unser Container „poc-ubuntu-custom-sa“ 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. - Erstellen Sie eine Regelbindung (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 Container „poc-ubuntu-custom-sa“ und versuchen Sie, auf den KV-Pfad „default/“ zuzugreifen.
- Erlaubnis verweigert.
Sie können die angegebenen Anmeldeinformationen für jedes Token in der Benutzeroberfläche unter ACL > Tokens anzeigen. Wie Sie sehen, ist mit unserem aktuellen Token nur eine „Custom-Sa-Rolle“ verknüpft. Der Token, den wir derzeit verwenden, wurde generiert, als wir uns angemeldet haben, und es gab damals nur eine Regelbindung, die übereinstimmte. Wir müssen uns erneut anmelden und das neue Token verwenden. - Stellen Sie sicher, dass Sie sowohl die kv-Pfade „custom-sa/“ als auch „default/“ lesen können.
Success!
Dies liegt daran, dass unser „poc-ubuntu-custom-sa“ mit den Regelbindungen „custom-sa“ und „default-ns“ übereinstimmt.
Abschluss
TTL-Token-Management?
Zum Zeitpunkt des Schreibens dieses Artikels gibt es keine integrierte Möglichkeit, die TTL für Token zu bestimmen, die mit dieser Autorisierungsmethode generiert werden. Es wäre eine fantastische Gelegenheit, eine sichere Automatisierung der Konsul-Autorisierung bereitzustellen.
Es gibt eine Option zum manuellen Erstellen eines Tokens mit TTL:
Ablaufzeit – Der Zeitpunkt, zu dem dieses Token widerrufen wird. (Optional; hinzugefügt in Consul 1.5.0)- Existiert nur für die manuelle Erstellung/Aktualisierung
Hoffentlich können wir in naher Zukunft steuern, wie Token generiert werden (per Regel oder Autorisierungsmethode) und TTL hinzufügen.
Bis dahin wird empfohlen, in Ihrer Logik einen Abmeldeendpunkt zu verwenden.
Lesen Sie auch andere Artikel in unserem Blog:
Source: habr.com