Introduktion till Hashicorp Consuls Kubernetes-autorisering

Allt stämmer, efter lanseringen Hashicorp Consul 1.5.0 i början av maj 2019 kan man autentisera applikationer och tjänster som körs i Kubernetes, nativt i Consul.

I den här guiden kommer vi steg för steg att skapa POC (Proof of concept, PoC — bevis för konceptets genomförbarhet — kommentar till översättningen), och demonstrera denna nya funktion. Du förväntas ha grundläggande kunskaper om Kubernetes och Hashicorp's Consul. Och även om du kan använda vilken molnplattform eller lokal miljö som helst, kommer vi i denna guide att använda Google’s Cloud Platform.

Översikt

Om vi går till Consuls dokumentation om dess autentiseringsmetod, får vi en kort översikt över dess syfte och användningsfall, samt några tekniska detaljer och en allmän översikt över logiken. Jag rekommenderar starkt att du läser igenom det åtminstone en gång innan du fortsätter, eftersom jag nu kommer att förklara och utveckla allt detta.

Schema 1: Officiell översikt över Consuls autentiseringsmetod

Låt oss titta i dokumentationen för den specifika Kubernetes-autentiseringsmetoden.

Självklart finns det användbar information där, men ingen handledning om hur man faktiskt använder allt detta. Så, som varje förnuftig person, söker du på internet efter en guide. Och sedan... råkar du på motgångar. Sådant händer. Låt oss rätta till det.

Innan vi går vidare till att skapa vår POC, låt oss återvända till översikten över Consuls autentiseringsmetoder (Schema 1) och specificera den i kontexten av Kubernetes.

Arkitektur

I denna guide kommer vi att skapa en Consul-server på en separat maskin som kommer att interagera med Kubernetes-klustret där Consul-klienten är installerad. Sedan kommer vi att skapa vår dummyapplikation i en pod och använda vår konfigurerade autentiseringsmetod för att läsa från vårt Consul key/value-lager.

Schemat nedan visar detaljerat arkitekturen som vi skapar i denna guide, samt logiken för autentiseringsmetoden som kommer att förklaras senare.

Schema 2: Översikt över autentisering i Kubernetes

Ett litet meddelande: Consul-servern behöver inte leva utanför Kubernetes-klustret för att detta ska fungera. Men ja, den kan vara både och.

Så, med översiktsschemat för Consul (Schema 1) och tillämpat på Kubernetes, får vi schemat ovan (Schema 2), och logiken kommer att vara följande:

1. Varje pod kommer att kopplas till ett tjänstekonto som innehåller en JWT-token, som genereras av och är känd av Kubernetes. Denna token sätts också in i podden som standard.
2. Vår applikation eller tjänst inom podden initierar en inloggningskommandotill vårt Consul-klient. I inloggningsbegäran kommer även vår token att anges och nämna namnet särskilt skapad auktoriseringsmetod (av typen Kubernetes). Detta steg nummer 2 motsvarar steg 1 i Consul-diagrammet (Diagram 1).
3. Vår Consul-klient kommer sedan att skicka denna begäran till vår Consul-server.
4. MAGI! Det är här som Consul-servern autentiserar begäran, samlar in information om begäran och jämför den med eventuella associerade fördefinierade regler. Nedan finns ett annat diagram för att illustrera detta. Detta steg motsvarar steg 3, 4 och 5 i översiktliga Consul-diagrammet (Diagram 1).
5. Vår Consul-server genererar en Consul-token med behörigheter i enlighet med de regler vi angivit för auktoriseringsmetoden (som vi har definierat) i relation till identiteten hos den som begär.
6. Vår Consul-klient omdirigerar token till den begärande applikationen eller tjänsten.

Vår applikation eller tjänst kan nu använda denna Consul-token för att interagera med våra Consul-data, såsom definierat av token-behörigheterna.

Magin avslöjad!

För er som inte nöjer er med bara en kanin ur hatten och vill veta hur det fungerar… låt mig "visa er hur djup kaninhålet».

Som nämnts tidigare ligger vår "magiska" aspekt (Diagram 2: Steg 4) i att Consul-servern autentiserar begäran, samlar information om begäran och jämför den med eventuella associerade fördefinierade regler. Detta steg motsvarar steg 3, 4 och 5 i översiktliga Consul-diagrammet (Diagram 1). Här är ett diagram (Diagram 3) vars syfte är att visuellt visa vad som faktiskt händer under huven med den specifika Kubernetes-auktoriseringsmetoden.

Diagram 3: Magin avslöjad!

1. Som utgångspunkt omdirigerar vår Consul-klient inloggningsbegäran till vår Consul-server med Kubernetes-konto-token och det specifika namnet på instansen av auktoriseringsmetoden som skapades tidigare. Detta steg motsvarar steg 3 i den tidigare förklaringen av diagrammet.
2. Nu måste Consul-servern (eller ledaren) verifiera giltigheten av den mottagna token. Därför kommer den att rådfråga Kubernetes-klustret (via Consul-klienten) och, om rättigheter finns, kommer vi att ta reda på om token är äkta och vem den tillhör.
3. Den verifierade begäran returneras sedan till Consul-ledaren, och på Consul-servern utförs en sökning efter instansen av autentiseringmetoden med det angivna namnet från inloggningsbegäran (och typen Kubernetes).
4. Consul-ledaren identifierar den angivna instansen av autentiseringmetoden (om den hittas) och läser uppsättningen av bindningsregler som kopplats till den. Därefter läser den dessa regler och jämför dem med de verifierade identitetsattributen.
5. Tada! Låt oss gå vidare till steg 5 i den tidigare förklaringen av schemat.

Kör Consul-servern på en vanlig virtuell maskin.

Från och med nu kommer jag mestadels att ge instruktioner om hur man skapar denna POC, ofta i punkter, utan förklarande hela meningar. Även som tidigare nämnts kommer jag att använda GCP för att skapa hela infrastrukturen, men du kan skapa en liknande infrastruktur någon annanstans.

• Starta en virtuell maskin (instans / server).

• Skapa en brandväggsregel (säkerhetsgrupp i AWS):
• Jag gillar att ge samma namn på maskinen till regeln och nätverkstaggen, i det här fallet "skywiz-consul-server-poc".
• Hitta IP-adressen till din lokala dator och lägg till den i listan över ursprungliga IP-adresser, så att vi kan få tillgång till användargränssnittet (UI).
• Öppna port 8500 för UI. Klicka på Skapa. Vi kommer snart att ändra denna brandvägg igen [länk].
• Lägg till en brandväggsregel till instansen. Gå tillbaka till VM-panelen på Consul-servern och lägg till "skywiz-consul-server-poc" i nätverkstagsfältet. Klicka på Spara.

• Installera Consul på den virtuella maskinen, kolla här. Kom ihåg att du behöver Consul version ≥ 1.5 [länk]
• Låt oss skapa en enskild nod Consul — konfigurationen är följande.

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 mer detaljerad guide för att installera Consul och konfigurera ett kluster med 3 noder finner du. här.
• Skapa filen /etc/consul.d/agent.json på följande sätt [länk]:

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

• Starta vår 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 bör se en massa utdata och slutligen "... update blocked by ACLs".
• Hitta den externa IP-adressen för Consul-servern och öppna webbläsaren med den IP-adressen på port 8500. Se till att UI:n öppnas.
• Försök att lägga till ett par nyckel/värde. Det bör bli ett fel. Det är för att vi har laddat Consul-servern med ACL och blockerat alla regler.
• Gå tillbaka till din terminal på Consul-servern och kör processen i bakgrunden eller på något annat sätt så att den fortsätter att köras, och skriv in följande:

consul acl bootstrap

• Hitta värdet "SecretID" och gå tillbaka till UI:n. På fliken "ACL" anger du den hemliga identifieraren för token som du just kopierade. Kopiera SecretID någon annanstans, vi behöver den senare.
• Nu lägg till ett par nyckel/värde. För detta POC lägger vi till följande: nyckel: "custom-ns/test_key", värde: "Jag är i mappen custom-ns!"

Starta Kubernetes-klustret för vår applikation med Consul-klienten som Daemonset.

• Skapa en K8s (Kubernetes) kluster. Vi kommer att skapa den i samma zon som servern för snabbare åtkomst, och så att vi kan använda samma undernät för enkel anslutning med interna IP-adresser. Vi kallar den "skywiz-app-with-consul-client-poc".

• Som en anteckning, här är en bra guide som jag stötte på när jag konfigurerade POC Consul-klustret med Consul Connect.
• Vi kommer också att använda Hashicorp helm chart med en utökad värdefil.
• Installera och konfigurera Helm. Konfigurationsstegen:

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
• Använd följande värdefil (notera, jag stängde av de flesta):

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

• Tillämpa helm chart:

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

• När du försöker starta den, kommer den att behöva behörigheter för Consul-servern, så låt oss lägga till dem.
• Observera "pod-adressintervallet" som finns på klusterpanelen, och gå tillbaka till vår brandväggsregel "skywiz-consul-server-poc".
• Lägg till pod-adressintervallet till listan över IP-adresser och öppna portarna 8301 och 8300.

• Gå till Consul UI, och efter några minuter ser du att vårt kluster dyker upp på nodfliken.

Konfigurera autentiseringsmetod genom att integrera Consul med Kubernetes.

• Gå tillbaka till terminalen på Consul-servern och exportera token som du sparade tidigare:

export CONSUL_HTTP_TOKEN=

• Vi behöver information från vår Kubernetes-kluster för att skapa en instans av autentiseringsmetoden:
• 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:

• Token är kodad i base64, så dekoda det med ditt favoritverktyg [länk]
• kubernetes-ca-cert

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

• Ta certifikatet “ca.crt” (efter att det har dekodats från base64) och skriv in det i filen “ca.crt”.
• Skapa nu en instans av autentiseringsmetoden, ersätt platshållarna med de värden som du just har fått.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "Detta är en autentiseringsmetod som använder kubernetes för klustret skywiz-app-with-consul-client-poc" 
-kubernetes-host "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

• Vidare måste vi skapa en regel och koppla den till den nya rollen. För denna del kan du använda Consul UI, men vi kommer att använda kommandoraden.
• Skriv regeln

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

• Tillämpa regeln

consul acl policy create 
-name kv-custom-ns-policy 
-description "Detta är ett exempel på en policy för kv på custom-ns/" 
-rules @kv-custom-ns-policy.hcl

• Hitta id:t för regeln som du just har skapat från utdata.
• Skapa en roll med den nya regeln.

consul acl role create 
-name "custom-ns-role" 
-description "Detta är ett exempel på en roll för custom-ns-namnrymden" 
-policy-id

• Nu kopplar vi vår nya roll till instansen av autentiseringsmetoden. Observera att flaggan 'selektor' bestämmer om vår inloggningsbegäran kommer att få denna roll. Kontrollera här andra selektoralternativ: 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"'

Konfigurationer till sist

Åtkomstbehörigheter

• Skapa åtkomstbehörigheter. Vi behöver ge Consul tillstånd att verifiera och identifiera token-ID:t för K8s tjänsteerkännande.
• Skriv följande i filen [länk]:

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

• Låt oss skapa åtkomstbehörigheter

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

Anslutning till Consul Client

• Som nämnts här, finns det flera alternativ för att ansluta till daemonset, men vi går vidare till nästa enklare lösning:
• Tillämpa följande fil [länk].

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

• Tillämpa sedan följande inbyggda kommando för att skapa configmap [länk]. Observera att vi refererar till namnet på vår tjänst, byt ut det vid behov.

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

Testa auth-metoden

Nu ska vi titta på magin i aktion!

• Skapa ytterligare några nyckelmappare med samma övre nivånyckel (dvs. /sample_key) och värde av ditt val. Skapa motsvarande policyer och roller för de nya nyckelvägarna. Vi kommer att göra bindningar senare.

Användartest av namnutrymme:

• Låt oss skapa vårt eget namnutrymme:

kubectl create namespace custom-ns

• Låt oss skapa en pod i vårt nya namnutrymme. Skriv konfigurationen för podden.

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

• Skapa pod:

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

• Så snart containern är igång, gå in där och installera curl.

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

• Nu ska vi skicka en inloggningsbegäran till Consul, med hjälp av den autentiseringsmetod vi skapade tidigare [länk].
• För att se den inmatade token från ditt tjänsteprogram:

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

• Skriv följande i en fil inuti containern:

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

• Logga in!

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

• För att utföra de ovanstående stegen i en rad (eftersom vi kommer att köra flera tester), kan du göra följande:

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 fungerar! Åtminstone borde det. Nu tar du SecretID och försöker få åtkomst till nyckeln/värdet som vi ska ha åtkomst till.

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

• Du kan avkoda "Value" base64 och se att det motsvarar värdet i custom-ns/test_key i UI. Om du använde samma värde som anges ovan i denna handbok, kommer ditt kodade värde att vara IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Test av användarkonto för tjänsten:

• Skapa ett anpassat ServiceAccount med följande kommando [länk].

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

• Skapa en ny konfigurationsfil för podden. Observera att jag inkluderade installationen av curl för att spara arbete 🙂

###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 detta, kör en shell inuti containern.

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

• Logga in!

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

• Åtkomst nekad. Oops, vi glömde att lägga till en ny regelbindning med motsvarande behörigheter, låt oss göra det nu.

Upprepa de tidigare stegen ovan:
a) Skapa en identisk policy för prefixet "custom-sa/".
b) Skapa en roll, kalla den "custom-sa-role"
c) Koppla policyn till rollen.

• Skapa en regelbindning (kan endast göras via cli / api). Observera det andra värdet för selektorflaggan.

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

• Upprepa inloggningen från containern "poc-ubuntu-custom-sa". Lyckat!
• Kontrollera vår åtkomst till den nyckfulla vägen custom-sa/.

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

• Du kan också säkerställa att denna token inte ger åtkomst till kv i "custom-ns/". Upprepa helt enkelt kommandot ovan efter att du har bytt ut "custom-sa" mot prefixet "custom-ns".
  Åtkomst nekad.

Exempel på överlägg:

• Det är värt att notera att alla regelbindningar kommer att läggas till token med dessa rättigheter.
• Vår container "poc-ubuntu-custom-sa" finns i standardnamnområdet - låt oss använda den för en annan regelbindning.
• Upprepa de tidigare stegen:
  a) Skapa en identisk policy för nyckelprefixet "default/".
  b) Skapa en roll, kalla den "default-ns-role"
  c) Koppla policyn till rollen.
• Skapa en regelbindning (kan endast göras 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"'

• Återgå till vår container "poc-ubuntu-custom-sa" och försök få åtkomst till vägen "default/" kv.
• Åtkomst nekad.
  Du kan se de angivna uppgifterna för varje token i UI under ACL > Tokens. Som du ser har vår nuvarande token endast en tillagd "custom-sa-role". Token som vi använder för tillfället genererades när vi loggade in, och då fanns det bara en regelbindning som stämde. Vi behöver logga in igen och använda en ny token.
• Se till att du kan läsa både från "custom-sa/" och "default/" kv.
  Lyckat!
  Detta beror på att vår "poc-ubuntu-custom-sa" matchar regelbindningarna "custom-sa" och "default-ns".

Slutsats

TTL token hantering?

Vid tidpunkten för denna artikel finns det inget integrerat sätt att bestämma TTL för token som genererats med denna autentiseringsmetod. Det skulle vara en fantastisk möjlighet - att möjliggöra säker automatisering av autentisering i Consul.

Det finns möjlighet att manuellt skapa en token med TTL:

• https://www.consul.io/docs/acl/acl-system.html#acl-tokens
  Expiration Time (Utgångstid) – tidpunkten då denna token kommer att återkallas. (Valfritt; tillagt i Consul 1.5.0)
• Finns endast för manuell skapelse / uppdatering https://www.consul.io/api/acl/tokens.html#expirationtime

Jag hoppas att vi snart kan kontrollera hur tokens genereras (för varje regel eller autentiseringsmetod) och lägga till TTL.

Tills dess föreslås det att använda en utloggningsendpoint i sin logik.

• https://www.consul.io/api/acl/acl.html#logout-from-auth-method
• https://www.consul.io/docs/acl/acl-auth-methods.html#overall-login-process

Läs även andra artiklar i vår blogg:

• Vad migreringen från ClickHouse utan autentisering till ClickHouse med autentisering ledde till
• Hur man kör flera pipelines med GitLab CI/CD
• Tre enkla knep för att minska Docker-bilder
• Traefik som Ingress-controller för K8S
• Backup av ett stort antal heterogena web-projekt
• Telegram-bot för Redmine. Hur man förenklar livet för sig själv och andra

Källa: habr.com