🥇Inleiding tot Hashicorp Consul’s Kubernetes Autorisatie

Dat klopt, na de release Hashicorp Consul 1.5.0 in het begin van mei 2019 kunnen toepassingen en services die op Kubernetes draaien, native worden geautoriseerd in Consul.

In deze handleiding zullen we stap voor stap POC (Proof of concept, PoC — bewijzen van [haalbaarheid] van een concept — red.) en deze nieuwe functie demonstreren. Van jou wordt verwacht dat je basiskennis hebt van Kubernetes en Hashicorp's Consul. En hoewel je elk cloudplatform of lokale omgeving kunt gebruiken, zullen we in deze handleiding Google's Cloud Platform gebruiken.

Overzicht

Als we kijken naar de documentatie van Consul over zijn autorisatiemethode, krijgen we een kort overzicht van het doel en de use case, evenals enkele technische details en een algemeen overzicht van de logica. Ik raad je aan om het ten minste één keer te lezen voordat je verder gaat, omdat ik alles nu zal uitleggen en uitwerken.

Figuur 1: Officieel overzicht van de Consul-authorisatiemethode

Laten we kijken naar de documentatie voor de specifieke Kubernetes-autorisatiemethode.

Natuurlijk is er nuttige informatie, maar er is geen handleiding over hoe je dit allemaal daadwerkelijk kunt gebruiken. Dus, zoals elke goeddenkende persoon, doorzoek je het internet op zoek naar een gids. En dan... falen. Dat gebeurt. Laten we dat oplossen.

Voordat we beginnen met het opzetten van onze POC, laten we teruggaan naar het overzicht van de Consul-autorisatiemethoden (Figuur 1) en dit verduidelijken in de context van Kubernetes.

Architectuur

In deze handleiding gaan we een Consul-server op een aparte machine opzetten, die zal communiceren met een Kubernetes-cluster met de geïnstalleerde Consul-client. Vervolgens zullen we onze fictieve applicatie in een pod maken en onze geconfigureerde autorisatiemethode gebruiken om te lezen uit onze Consul key/value-opslag.

De onderstaande figuur toont gedetailleerd de architectuur die we in deze handleiding creëren, evenals de logica van de autorisatiemethode die later zal worden uitgelegd.

Figuur 2: Overzicht van de autorisatiemethode in Kubernetes

Kleine opmerking: De Consul-server hoeft niet buiten het Kubernetes-cluster te leven om te functioneren. Maar ja, dat kan ook op beide manieren.

Dus, door het overzicht van de Consul-schema (Figuur 1) toe te passen op Kubernetes, krijgen we de bovenstaande schema (Figuur 2) en de logica zal als volgt zijn:

Aan elk pod wordt een service-account gehecht met een JWT-token dat door Kubernetes is gegenereerd en bekend is. Dit token wordt ook standaard in de pod ingevoegd.
Onze applicatie of service binnen de pod initieert een aanroep naar onze Consul-client. In de inlogaanroep wordt ook onze token en de naam opgegeven. speciaal gecreëerd autorisatiemethode (Kubernetes-type). Deze stap nummer 2 komt overeen met stap 1 van het Consul-schema (Schema 1).
Onze Consul-client stuurt deze aanvraag vervolgens naar onze Consul-server.
MAGIE! Dit is waar de Consul-server de authenticiteit van de aanvraag controleert, informatie over de identiteit van de aanvraag verzamelt en deze vergelijkt met eventuele bijbehorende vooraf gedefinieerde regels. Hieronder staat een ander schema om dit te illustreren. Deze stap komt overeen met de stappen 3, 4 en 5 van het Consul-overzichtschema (Schema 1).
Onze Consul-server genereert een Consul-token met permissies volgens de door ons opgegeven regels van de autorisatiemethode (deze hebben we gedefinieerd) met betrekking tot de identiteit van de aanvrager. Vervolgens stuurt hij dit token terug. Dit komt overeen met stap 6 van het Consul-schema (Schema 1).
Onze Consul-client leidt het token door naar de aanvragende applicatie of service.

Onze applicatie of service kan nu dit Consul-token gebruiken om verbinding te maken met onze Consul-gegevens, zoals bepaald door de token-permissies.

De magie is onthuld!

Voor degenen onder jullie die niet tevreden zijn met alleen een konijn uit de hoed en willen weten hoe dit werkt... laat me jullie "laten zien hoe diep de konijnenhol gaat. konijnenhol».

Zoals eerder vermeld, is onze "magische" stap (Schema 2: Stap 4) dat de Consul-server de authenticiteit van de aanvraag controleert, informatie over de aanvraag verzamelt en deze vergelijkt met enige bijbehorende vooraf gedefinieerde regels. Deze stap komt overeen met de stappen 3, 4 en 5 van het Consul-overzichtschema (Schema 1). Hieronder is een schema (Schema 3) dat visueel wil tonen wat er eigenlijk gebeurt. onder de motorkap van de specifieke Kubernetes-autorisatiemethode.

Schema 3: De magie is onthuld!

Als uitgangspunt leidt onze Consul-client de inlogaanroep naar onze Consul-server met het Kubernetes-accounttoken en de specifieke naam van de autorisatiemethode-instantie die eerder is aangemaakt. Deze stap komt overeen met stap 3 in de vorige uitleg van het schema.
Nu moet de Consul-server (of leider) het ontvangen token verifiëren. Daarom raadpleegt hij de Kubernetes-cluster (via de Consul-client) en, mits de juiste permissies aanwezig zijn, zullen we bepalen of het token echt is en aan wie het toebehoort.
Vervolgens wordt het geverifieerde verzoek teruggestuurd naar de Consul-leider, en op de Consul-server wordt een instantie van de autorisatiemethode gezocht met de gespecificeerde naam uit het inlogverzoek (van het type Kubernetes).
De Consul-leider identificeert de opgegeven instantie van de autorisatiemethode (indien gevonden) en leest de set bindregels die eraan zijn gekoppeld. Vervolgens leest hij deze regels en compareert deze met de geverifieerde identiteitseigenschappen.
Tada! We gaan naar stap 5 in de vorige uitleg van het schema.

Start de Consul-server op een gewone virtuele machine.

Vanaf dit moment zal ik voornamelijk instructies geven voor het creëren van deze POC, vaak in punten, zonder aanvullende uitleg in volledige zinnen. Zoals eerder vermeld, zal ik GCP gebruiken om de gehele infrastructuur te bouwen, maar je kunt dezelfde infrastructuur overal anders opzetten.

Start de virtuele machine (instantie / server).

Maak een regel voor de firewall (beveiligingsgroep in AWS):
Ik vind het prettig om dezelfde naam te geven aan de machine als aan de regel en het netwerklabel, in dit geval is dat 'skywiz-consul-server-poc'.
Vind het IP-adres van je lokale computer en voeg dit toe aan de lijst van toegestane IP-adressen, zodat we toegang hebben tot de gebruikersinterface (UI).
Open poort 8500 voor de UI. Klik op Create (Aanmaken). We zullen deze firewall binnenkort opnieuw wijzigen [link].
Voeg een regel voor de firewall toe aan de instantie. Ga terug naar het VM-dashboard op de Consul-server en voeg 'skywiz-consul-server-poc' toe aan het veld netlabel. Klik op Save (Opslaan).

Installeer Consul op de virtuele machine, controleer hier. Vergeet niet dat je versie Consul ≥ 1.5 nodig hebt [link]
Laten we een single node Consul creëren — de configuratie is als volgt.

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

Een meer gedetailleerde gids voor de installatie van Consul en het instellen van een cluster van 3 nodes vind je hier. hier.
Maak het bestand /etc/consul.d/agent.json als volgt [link]:

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

Start onze Consul-server:

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

U zou een hoop uitvoer moeten zien en uiteindelijk "... update blocked by ACLs".
Zoek het externe IP-adres van de Consul-server en open een browser met dat IP-adres op poort 8500. Zorg ervoor dat de UI opent.
Probeer een paar sleutel/waardeparen toe te voegen. Er zou een fout moeten zijn. Dit komt omdat we de Consul-server met ACL hebben geladen en alle regels hebben geblokkeerd.
Ga terug naar je shell op de Consul-server en voer het proces op de achtergrond of op een andere manier uit, zodat het draait, en typ het volgende in:

consul acl bootstrap

Zoek de waarde "SecretID" en keer terug naar de UI. Voer op het tabblad "ACL" de geheime identificator in die je zojuist hebt gekopieerd. Kopieer de SecretID ook ergens anders naartoe, we hebben het later nodig.
Voeg nu een paar sleutel/waardeparen toe. Voor deze POC voegen we het volgende toe: sleutel: "custom-ns/test_key", waarde: "Ik ben in de custom-ns map!"

Een Kubernetes-cluster opzetten voor onze applicatie met de Consul-client als Daemonset

Maak een K8s (Kubernetes) cluster aan. We zullen dit in dezelfde zone maken als de server voor snellere toegang, en daarom kunnen we hetzelfde subnet gebruiken voor eenvoudige verbinding met interne IP-adressen. We zullen het "skywiz-app-with-consul-client-poc" noemen.

Als opmerking, hier is een goede handleiding die ik tegenkwam bij het opzetten van de POC Consul-cluster met Consul Connect.
We zullen ook de Hashicorp helm chart gebruiken met een uitgebreid waardenbestand.
Installeer en configureer Helm. Configuratiestappen:

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
Gebruik het volgende waardenbestand (let op, ik heb de meeste uitgeschakeld):

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

Pas de helm chart toe:

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

Bij het proberen te starten, heeft het toestemming nodig voor de Consul-server, laten we die toevoegen.
Let op het "Pod IP-range" dat op het cluster-dashboard staat en keer terug naar onze firewallregel "skywiz-consul-server-poc".
Voeg het IP-bereik voor de pod toe aan de lijst met IP-adressen en open de poorten 8301 en 8300.

Ga naar de Consul UI en na een paar minuten zie je dat onze cluster op het knooppunt-tabblad verschijnt.

Configureer de autorisatiemethode door Consul met Kubernetes te integreren.

Ga terug naar de shell van de Consul-server en exporteer de token die je eerder hebt opgeslagen:

export CONSUL_HTTP_TOKEN=

We need information from our Kubernetes cluster to create an auth method instance:
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:

The token is encoded in base64, so decode it using your favorite tool [link]
kubernetes-ca-cert

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

Take the certificate “ca.crt” (after decoding from base64) and write it to the file “ca.crt”.
Now create an auth method instance, replacing the placeholders with the values you just obtained.

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 "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

Next, we need to create a policy and attach it to the new role. For this part, you can use the Consul UI, but we will use the command line.
Write the policy

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

Apply the policy

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

Find the ID of the policy you just created from the output.
Create a role with the new policy.

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id

Now we will link our new role to the auth method instance. Note that the selector flag determines whether our login request will receive this role. Check here for other selector options: 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"'

Configurations for the end

Access Rights

Create access rights. We need to grant Consul permission to verify and identify the token credentials of the K8s service account.
Write the following to a file [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

Let's create access rights

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

Connecting to Consul Client

As noted hier, there are several options for connecting to the daemonset, but we will move on to the next simple solution:
Apply the following file [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

Then apply the following built-in command to create the configmap [link]. Note that we reference the name of our service, replace it if necessary.

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

Auth-methode testen

Laten we nu de magie in actie bekijken!

Maak nog een paar sleutelmappen met dezelfde hoofdsleutel (d.w.z. /sample_key) en een waarde naar keuze. Maak bijbehorende beleidsregels en rollen voor de nieuwe sleutelpaden. We zullen later bindings maken.

Gebruikertest van de namespace:

Laten we onze eigen namespace maken:

kubectl create namespace custom-ns

Laten we een pod maken in onze nieuwe namespace. Schrijf de configuratie voor de 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

Maak de pod:

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

Zodra de container draait, ga daarheen en installeer curl.

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

Nu gaan we een inlogverzoek naar Consul sturen met behulp van de autorisatiemethode die we eerder hebben gemaakt [link].
Om de ingevoerde token uit je serviceaccount te bekijken:

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

Schrijf het volgende in een bestand binnen de container:

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

Inloggen!

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

Om bovenstaande stappen in één regel uit te voeren (aangezien we meerdere tests zullen uitvoeren), kun je het volgende doen:

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

Het werkt! Tenminste, dat zou het moeten. Neem nu de SecretID en probeer toegang te krijgen tot de key/value waar we toegang toe zouden moeten hebben.

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

Je kunt de 'Value' base64 decoderen en zien dat deze overeenkomt met de waarde in custom-ns/test_key in de UI. Als je dezelfde waarde hebt gebruikt die hierboven in deze gids is gegeven, zal je gecodeerde waarde IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi zijn.

Test van de gebruiker's serviceaccount:

Maak een gebruiker's ServiceAccount met de volgende opdracht [link].

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

Maak een nieuw configuratiebestand voor de pod. Let op, ik heb curl ingesteld voor minder werk 🙂

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

Start daarna een shell binnen de container.

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

Inloggen!

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

Toegang geweigerd. Oh, we zijn vergeten een nieuwe regelbinding toe te voegen met de bijbehorende machtigingen, laten we dat nu doen.

Herhaal de voorgaande stappen:
a) Maak een identiek beleid voor het prefix 'custom-sa/'.
b) Maak een rol aan en noem deze 'custom-sa-role'.
c) Koppel het beleid aan de rol.

Maak een regelbinding (alleen mogelijk via cli / api). Let op de andere waarde van de selector-vlag.

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

Log opnieuw in vanuit de container 'poc-ubuntu-custom-sa'. Succes!
Controleer onze toegang tot het sleutelpad custom-sa/.

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

Je kunt ook controleren of deze token geen toegang geeft tot kv in 'custom-ns/'. Voer gewoon het bovenstaande commando opnieuw uit, waarbij je 'custom-sa' vervangt door het prefix 'custom-ns'.
Toegang geweigerd.

Voorbeeld van overlay:

Het is belangrijk op te merken dat alle overeenkomsten van de regelbinding aan de token met deze rechten zullen worden toegevoegd.
Onze container 'poc-ubuntu-custom-sa' bevindt zich in de standaard namespace — laten we deze gebruiken voor een andere regelbinding.
Herhaal de voorgaande stappen:
a) Maak een identiek beleid voor het sleutelprefix 'default/'.
b) Maak een rol aan en noem deze 'default-ns-role'.
c) Koppel het beleid aan de rol.
Maak een regelbinding (alleen mogelijk via 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"'

Ga terug naar onze container 'poc-ubuntu-custom-sa' en probeer toegang te krijgen tot het 'default/' kv-pad.
Toegang geweigerd.
Je kunt de opgegeven referenties voor elke token bekijken in de UI onder ACL > Tokens. Zoals je kunt zien, heeft onze huidige token alleen de 'custom-sa-role' eraan gekoppeld. De token die we momenteel gebruiken, werd gegenereerd toen we inlogden, en toen was er slechts één regelbinding die toen overeenkwam. We moeten opnieuw inloggen en de nieuwe token gebruiken.
Zorg ervoor dat je zowel van de paden 'custom-sa/' als 'default/' kv kunt lezen.
Succes!
Dit komt doordat onze 'poc-ubuntu-custom-sa' overeenkomt met de regelbindingen 'custom-sa' en 'default-ns'.

Conclusie

TTL token mgmt?

Op het moment van schrijven van dit artikel is er geen ingebouwde manier om de TTL voor tokens die met deze autorisatiemethode zijn gegenereerd, te bepalen. Dit zou een fantastische functie zijn — veilige automatisering van Consul-autorisatie bieden.

Er is de mogelijkheid om handmatig een token met TTL te creëren:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
Expiration Time (Tijdstip van vervaldatum) - het moment waarop deze token wordt ingetrokken. (Optioneel; toegevoegd in Consul 1.5.0)
Alleen beschikbaar voor handmatige creatie / update https://www.consul.io/api/acl/tokens.html#expirationtime

Ik hoop dat we binnenkort controle hebben over hoe tokens worden gegenereerd (voor elke regel of autorisatiemethode) en TTL kunnen toevoegen.

Tot die tijd wordt aangeraden om in je logica het logout-eindpunt te gebruiken.