🥇Introduktion til HashiCorp Consuls Kubernetes Autorisation

Det er korrekt, efter udgivelsen Hashicorp Consul 1.5.0 i begyndelsen af maj 2019 kunne man i Consul udføre godkendelse af applikationer og tjenester, der kører i Kubernetes, nativt.

I denne vejledning vil vi trin for trin oprette POC (Proof of concept, PoC — bevis for konceptets [gennemførlighed] — bemærk red.), demonstrerende denne nye funktion. Du forventes at have grundlæggende kendskab til Kubernetes og Hashicorp’s Consul. Selvom du kan bruge enhver cloudplatform eller lokal miljø, vil vi i denne vejledning bruge Google’s Cloud Platform.

Oversigt

Hvis vi ser på dokumentationen for Consul om dens godkendelsesmetode, får vi en kort oversigt over dens formål og brugsscenarier, samt nogle tekniske detaljer og en generel oversigt over logikken. Jeg anbefaler kraftigt at læse den mindst én gang, før vi fortsætter, da jeg nu vil forklare og uddybe alt dette.

Diagram 1: Officiel oversigt over Consuls godkendelsesmetode

Lad os se på dokumentationen for den specifikke Kubernetes godkendelsesmetode.

Selvfølgelig er der nyttig information der, men der er ingen vejledning til, hvordan man virkelig bruger det hele. Derfor, som enhver fornuftig person, gennemser du internettet for at finde en vejledning. Og så… lider du nederlag. Sådan sker det. Lad os rette det.

Før vi går videre med at oprette vores POC, lad os vende tilbage til oversigten over Consuls godkendelsesmetoder (Diagram 1) og tydeliggøre det i konteksten af Kubernetes.

Arkitektur

I denne vejledning vil vi oprette en Consul-server på en separat maskine, der vil interagere med Kubernetes-klusteret med en installeret Consul-klient. Derefter vil vi oprette vores dummy-applikation i en pod og bruge vores konfigurerede godkendelsesmetode til at læse fra vores Consul nøgle/værdi lager.

Diagrammet nedenfor viser detaljeret arkitekturen, som vi opretter i denne vejledning, samt logikken i godkendelsesmetoden, som senere vil blive forklaret.

Diagram 2: Oversigt over godkendelsesmetoden i Kubernetes

En lille bemærkning: Consul-serveren behøver ikke at leve uden for Kubernetes-klusteret for at dette fungerer. Men ja, den kan være der også.

Så ved at tage oversigtsskemaet fra Consul (Diagram 1) og anvende det på Kubernetes, får vi skemaet ovenfor (Diagram 2), og logikken vil være som følger:

Hver pod vil have en servicekonto knyttet til sig, som indeholder en JWT-token, genereret og kendt af Kubernetes. Denne token indsættes også i pod’en som standard.
Vores applikation eller tjeneste inde i pod’en initierer en login-anmodning til vores Consul-klient. I login-anmodningen vil også vores token være angivet samt navnet på en specialoprettet autoriseringsmetode (Kubernetes-type). Dette trin nr. 2 svarer til trin 1 i Consul-schemaren (Schemaren 1).
Vores Consul-klient sender derefter denne anmodning til vores Consul-server.
MAGI! Det er her, Consul-serveren verificerer anmodningens autentitet, indsamler oplysninger om anmodningens identitet og sammenligner dem med eventuelle tilknyttede foruddefinerede regler. Nedenfor vil der være en anden skema for at illustrere dette. Dette trin svarer til trin 3, 4 og 5 i oversigtsskemaren for Consul (Schemaren 1).
Vores Consul-server genererer en Consul-token med de tilladelser, vi har angivet i de regler for autoriseringsmetoden (som vi har defineret) i relation til anmelderens identitet. Derefter sender den denne token tilbage. Dette svarer til trin 6 i Consul-schemaren (Schemaren 1).
Vores Consul-klient videresender token til den anmodende applikation eller tjeneste.

Vores applikation eller tjeneste kan nu benytte denne Consul-token til at kommunikere med vores Consul-data, som er defineret af tokenens privilegier.

Magien er afsløret!

For dem af jer, der ikke er tilfredse med blot en kanin fra hatten og vil vide, hvordan det virker... lad mig "vise jer, hvor dyb kaninhullet».

Som nævnt tidligere, er vores “magiske” skridt (Schemaren 2: Skridt 4) det, at Consul-serveren verificerer anmodningens autentitet, indsamler oplysninger om anmodningen og sammenligner dem med eventuelle tilknyttede foruddefinerede regler. Dette trin svarer til trin 3, 4 og 5 i oversigtsskemaren for Consul (Schemaren 1). Nedenfor er en skema (Schemaren 3), hvis formål er klart at vise, hvad der faktisk sker under panseret af den specifikke Kubernetes-autoriseringsmetode.

Schemaren 3: Magien er afsløret!

Som udgangspunkt videresender vores Consul-klient login-anmodningen til vores Consul-server med Kubernetes-kontoens token og det specifikke navn på instansen af autoriseringsmetoden, som blev oprettet tidligere. Dette trin svarer til trin 3 i den tidligere forklaring af skemaet.
Nu skal Consul-serveren (eller lederen) bekræfte legitimiteten af den modtagne token. Derfor vil den konsultere Kubernetes-klusteret (gennem Consul-klienten), og hvis der gives de rette tilladelser, vil vi finde ud af, om token'en er ægte, og hvem den tilhører.
Derefter returneres den validerede anmodning til Consul-lederen, og der udføres et opslag af instansen af godkendelsesmetoden med det angivne navn fra login-anmodningen (og typen Kubernetes) på Consul-serveren.
Consul-lederen identificerer den angivne instans af godkendelsesmetoden (hvis den findes) og læser det sæt bindingsregler, der er knyttet til den. Derefter læser den disse regler og sammenligner dem med de validerede identitetsattributter.
Sådan! Vi går videre til trin 5 i den tidligere beskrivelse af diagrammet.

Start Consul-serveren på en almindelig virtuel maskine

Fra dette punkt vil jeg primært give instruktioner til oprettelse af denne POC, ofte i punkter, uden forklarende sammenhængende sætninger. Som nævnt tidligere vil jeg bruge GCP til at oprette hele infrastrukturen, men du kan oprette en lignende infrastruktur et andet sted.

Start den virtuelle maskine (instans / server).

Opret en firewallregel (sikkerhedsgruppe i AWS):
Jeg kan godt lide at give den samme navn til maskinen, reglen og netværkstaget, i dette tilfælde er det 'skywiz-consul-server-poc'.
Find IP-adressen på din lokale computer, og tilføj den til listen over tilladte IP-adresser, så vi kan få adgang til brugergrænsefladen (UI).
Åbn port 8500 for UI. Klik på Create. Vi vil snart ændre denne firewall igen [link].
Tilføj en regel til firewallen for instansen. Gå tilbage til VM-overvågningspanelet på Consul-serveren og tilføj 'skywiz-consul-server-poc' i feltet for netværkstags. Klik på Save.

Installer Consul på den virtuelle maskine, kontroller her. Husk, at du har brug for en Consul-version ≥ 1.5 [link]
Lad os oprette en enkelt node Consul - konfigurationen er som følger.

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

En mere detaljeret vejledning til installation af Consul og opsætning af en klynge med 3 noder findes her. her.
Opret filen /etc/consul.d/agent.json som følger [link]:

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

Start vores Consul-server:

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

Du skal se en masse output og i sidste ende „… update blocked by ACLs“.
Find den eksterne IP-adresse på Consul-serveren og åbne en browser med denne IP-adresse på port 8500. Sørg for, at UI'en åbnes.
Prøv at tilføje et par nøgle/værdi. Der bør være en fejl. Dette skyldes, at vi har indlæst Consul-serveren med ACL og forbudt alle regler.
Gå tilbage til din shell på Consul-serveren og kør processen i baggrunden eller på anden måde, så den kører, og indtast følgende:

consul acl bootstrap

Find værdien „SecretID“ og gå tilbage til UI'en. På fanen „ACL“ indtast den hemmelige token-identifikator, som du lige har kopieret. Kopier SecretID til et andet sted, vi får brug for det senere.
Nu, tilføj et par nøgle/værdi. For denne POC tilføjer vi følgende: nøgle: „custom-ns/test_key“, værdi: „Jeg er i mappen custom-ns!“

Start Kubernetes-klusteret for vores applikation med Consul-klienten som Daemonset

Opret et K8s (Kubernetes) kluster. Vi vil oprette det i samme zone som serveren for hurtigere adgang, og derfor kan vi bruge det samme subnet til nem tilslutning med interne IP-adresser. Vi vil kalde det „skywiz-app-with-consul-client-poc“.

Som en note, her er en god vejledning, jeg stødte på, mens jeg satte POC Consul-klusteret op med Consul Connect.
Vi vil også bruge Hashicorp helm chart med en udvidet værdifil.
Installer og konfigurer Helm. Konfigurationstrinene:

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
Brug følgende værdifil (bemærk, at jeg har deaktiveret det meste):

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

Anvend helm chart:

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

Når du prøver at starte den, vil den have brug for tilladelser til Consul-serveren, så lad os tilføje dem.
Bemærk „Pod adresseområdet“, der er placeret på klusterets dashboard, og gå tilbage til vores firewallregel „skywiz-consul-server-poc“.
Tilføj adresseområdet for pod'en til listen over IP-adresser og åbn portene 8301 og 8300.

Gå til Consul UI, og efter et par minutter vil du se, at vores kluster vises under noden.

Opsætning af autorisationsmetode ved at integrere Consul med Kubernetes

Gå tilbage til shellen på Consul-serveren og eksporter den token, du gemte tidligere:

export CONSUL_HTTP_TOKEN=

Vi har brug for information fra vores Kubernetes-klynge for at oprette en instans af auth-metoden:
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:

Tokenet er kodet i base64, så dekod det med dit foretrukne værktøj [link]
kubernetes-ca-cert

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

Tag certifikatet “ca.crt” (efter dekodning fra base64) og skriv det i filen “ca.crt”.
Opret nu en instans af auth-metoden, og erstat pladsholdere med de værdier, du lige har modtaget.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "Dette er en auth-metode, der bruger kubernetes til klyngen skywiz-app-with-consul-client-poc" 
-kubernetes-host "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

Herefter skal vi oprette en regel og knytte den til den nye rolle. Til denne del kan du bruge Consul UI, men vi vil bruge kommandolinjen.
Skriv regel

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

Anvend regel

consul acl policy create 
-name kv-custom-ns-policy 
-description "Dette er et eksempel på en politik for kv ved custom-ns/" 
-rules @kv-custom-ns-policy.hcl

Find identifikatoren for den regel, du lige har oprettet, i output.
Opret en rolle med den nye regel.

consul acl role create 
-name "custom-ns-role" 
-description "Dette er et eksempel på en rolle for custom-ns-navnerum" 
-policy-id

Nu vil vi knytte vores nye rolle til instansen af auth-metoden. Bemærk, at flaget «selector» bestemmer, om vores indgangsanmodning vil få denne rolle. Tjek her for andre selector-muligheder: 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"'

Konfigurationerne til sidst

Adgangsrettigheder

Opret adgangsrettigheder. Vi skal give Consul tilladelse til at validere og identificere identiteten af K8s service account token.
Skriv følgende i filen [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

Lad os oprette adgangsrettigheder

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

Forbindelse til Consul Client

Som nævnt her, er der flere muligheder for at forbinde til daemonset, men vi går videre til den næste enkle løsning:
Anvend den følgende fil [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

Anvend derefter den følgende indbyggede kommando for at oprette configmap [link]. Bemærk, at vi henviser til navnet på vores service, erstat det om nødvendigt.

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

Test af auth-metoden

Lad os nu se magien i aktion!

Opret flere nøglemapper med den samme øverste nøgle (dvs. /sample_key) og en værdi efter dit valg. Opret de relevante politikker og roller for de nye nøglebaner. Vi vil lave bindinger senere.

Brugerdefineret test af navnerum:

Lad os oprette vores eget navnerum:

kubectl create namespace custom-ns

Lad os oprette en pod i vores nye navnerum. Skriv konfigurationen til pod'en.

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

Opret pod:

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

Når containeren er startet, skal du logge ind og installere curl.

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

Nu vil vi sende en anmodning om login til Consul ved hjælp af den autoriseringsmetode, vi oprettede tidligere [link].
For at se den indtastede token fra din servicekonto:

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

Skriv følgende i en fil inden i containeren:

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

For at udføre ovenstående trin i én linje (da vi vil køre flere tests), kan du gøre følgende:

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

Det virker! Det skulle, i det mindste. Nu tag SecretID og prøv at få adgang til nøgle/værdi, som vi skulle have adgang til.

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

Du kan dekode "Value" base64 og se, at det svarer til værdien i custom-ns/test_key i UI. Hvis du har brugt den samme værdi, som nævnt ovenfor i denne vejledning, vil din kodede værdi være IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Test af den brugerdefinerede servicekonto:

Opret en brugerdefineret ServiceAccount med følgende kommando [link].

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

Opret en ny konfigurationsfil til pod'en. Bemærk, at jeg har inkluderet installationen af curl for at spare arbejde 🙂

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

Efter dette skal du starte en shell inde i containeren.

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

Adgang nægtet. Åh, vi glemte at tilføje det nye regelbinding med de relevante tilladelser, lad os gøre det nu.

Gentag de foregående trin ovenfor:
a) Opret en identisk politik for præfixet "custom-sa/".
b) Opret en rolle, kald den "custom-sa-role"
c) Vedhæft politikken til rollen.

Opret en regelbinding (kan kun gøres fra cli/api). Bemærk den forskellige værdi af selector-flaget.

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 ind igen fra containeren "poc-ubuntu-custom-sa". Success!
Kontroller vores adgang til nøglevejen custom-sa/.

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

Du kan også sikre dig, at denne token ikke giver adgang til kv i "custom-ns/". Gentag blot den ovenstående kommando efter at have ændret "custom-sa" til præfixet "custom-ns".
Adgang nægtet.

Eksempel på overlay:

Det er værd at bemærke, at alle matchende regelbindinger vil blive tilføjet til tokenet med disse rettigheder.
Vores container "poc-ubuntu-custom-sa" er i standardnavnerum - så lad os bruge det til en anden regelbinding.
Gentag de tidligere trin:
a) Opret en identisk politik for nøglepræfixet "default/".
b) Opret en rolle, kald den "default-ns-role"
c) Vedhæft politikken til rollen.
Opret en regelbinding (kan kun gøres fra 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"'

Gå tilbage til vores container "poc-ubuntu-custom-sa" og prøv at få adgang til vejen "default/" kv.
Adgang nægtet.
Du kan se de angivne legitimationsoplysninger for hver token i UI under ACL > Tokens. Som du kan se, er der kun knyttet én "custom-sa-role" til vores nuværende token. Den token, vi bruger lige nu, blev genereret, da vi loggede ind, og der var dengang kun én regelbinding, der matchede. Vi skal logge ind igen og bruge det nye token.
Sikre dig, at du kan læse både fra "custom-sa/" og "default/" kv.
Success!
Dette skyldes, at vores "poc-ubuntu-custom-sa" matcher regelbindingerne "custom-sa" og "default-ns".

Konklusion

TTL token mgmt?

På tidspunktet for denne artikels skrivning findes der ikke en integreret måde at bestemme TTL for de tokens, der genereres med denne autorisationsmetode. Det ville være en fantastisk mulighed - at sikre sikker automatisering af Consul-autorisation.

Der er mulighed for manuelt at oprette en token med TTL:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
Udløbstid (Expiration Time) — det tidspunkt, hvor denne token vil blive tilbagekaldt. (Ikke obligatorisk; tilføjet i Consul 1.5.0)
Findes kun til manuel oprettelse / opdatering https://www.consul.io/api/acl/tokens.html#expirationtime

Jeg håber, at vi snart kan kontrollere, hvordan tokens genereres (for hver regel eller autorisationsmetode), og tilføje TTL.

Indtil da anbefales det at bruge udgangsendpointen i din logik.