🥇Úvod do autorizačního systému Kubernetes Hashicorp Consul

Vše je správně, po vydání Hashicorp Consul 1.5.0 na začátku května 2019 bylo v Consul možné nativně provádět autorizaci aplikací a služeb spuštěných v Kubernetes.

V této příručce krok za krokem vytvoříme POC (Proof of concept, PoC — důkaz [proveditelnosti] konceptu — pozn. překl.), demonstrujeme tuto novou funkci. Očekávají se od vás základní znalosti o Kubernetes a Hashicorp’s Consul. I když můžete použít jakoukoli cloudovou platformu nebo místní prostředí, v této příručce použijeme Google Cloud Platform.

Přehled

Pokud přejdeme k dokumentaci Consul ke jeho metodě autorizace, dostaneme krátký přehled jeho účelu a použití, jakož i některé technické detaily a obecný přehled logiky. Důrazně doporučuji si to přečíst alespoň jednou, než pokračovat, protože teď to všechno vysvětlím a osvětlím.

Obrázek 1: Oficiální přehled metody autorizace Consul

Podívejme se na dokumentaci k specifické metodě autorizace Kubernetes.

Samozřejmě, je tam užitečné informace, ale žádné pokyny, jak to skutečně použít. Takže, jako každý rozumný člověk, prohledáváte internet za účelem nalezení příručky. A pak… zakopnete. To se stává. Pojďme to napravit.

Dříve než přejdeme k vytváření našeho POC, vraťme se k přehledu metod autorizace Consul (Obrázek 1) a vyjasněme ho v kontextu Kubernetes.

Architektura

V této příručce vytvoříme server Consul na samostatném stroji, který bude komunikovat s Kubernetes klastrem s nainstalovaným klientem Consul. Poté vytvoříme naši fiktivní aplikaci v podu a použijeme náš nastavený způsob autorizace k četbě z našeho Consul key/value úložiště.

Obrázek níže podrobně ukazuje architekturu, kterou vytváříme v této příručce, jakož i logiku metody autorizace, která bude vysvětlena později.

Obrázek 2: Přehled metody autorizace v Kubernetes

Malá poznámka: Server Consul nemusí žít mimo Kubernetes klastr, aby to fungovalo. Ale ano, může být tak, jak tak.

Takže, vezmeme-li přehledovou schéma Consul (Obrázek 1) a aplikujeme ji na Kubernetes, dostaneme schéma výše (Obrázek 2), a logika bude následující:

Každému podu bude přidělena služební účet, který obsahuje JWT token vygenerovaný a známý Kubernetes. Tento token je také vložen do podu jako výchozí.
Naše aplikace nebo služba uvnitř podu iniciuje příkaz k přihlášení do našeho Consul klienta. V žádosti o přihlášení bude uveden náš token a název speciálně vytvořeného metody autorizace (typ Kubernetes). Tento krok č. 2 odpovídá kroku 1 schématu Consul (Schéma 1).
Náš Consul klient pak nasměruje tuto žádost na náš Consul server.
KOUZLO! Zde Consul server ověřuje platnost žádosti, shromažďuje údaje o identitě žádosti a porovnává je s jakýmikoli asociovanými předdefinovanými pravidly. Níže bude další schéma, které to ilustruje. Tento krok odpovídá krokům 3, 4 a 5 přehledového schématu Consul (Schéma 1).
Náš Consul server generuje Consul token s oprávněními podle námi zadaných pravidel metody autorizace (které jsme definovali) ve vztahu k identitě žadatele. Poté tento token vrátí zpět. To odpovídá kroku 6 schématu Consul (Schéma 1).
Náš Consul klient přesměruje token žadatelské aplikaci nebo službě.

Naše aplikace nebo služba nyní mohou použít tento Consul token k interakci s našimi Consul daty, jak bylo definováno oprávněními tokenu.

Kouzlo odhaleno!

Pro ty z vás, kdo nejsou spokojeni s pouhým králíkem z klobouku a chtějí vědět, jak to funguje… dovolte mi, abych vám 'ukázal, jak hluboká králičí nora».

Jak bylo zmíněno dříve, náš 'magický' krok (Schéma 2: Krok 4) spočívá v tom, že Consul server ověřuje platnost žádosti, shromažďuje údaje o žádosti a porovnává je s jakýmikoli asociovanými předdefinovanými pravidly. Tento krok odpovídá krokům 3, 4 a 5 přehledového schématu Consul (Schéma 1). Níže je schéma (Schéma 3), jehož cílem je názorně ukázat, co se ve skutečnosti děje pod kapotou konkrétní metody autorizace Kubernetes.

Schéma 3: Kouzlo odhaleno!

Jako výchozí bod náš Consul klient přesměruje žádost o přihlášení na náš Consul server s tokenem účtu Kubernetes a konkrétním názvem instance metody autorizace, která byla vytvořena dříve. Tento krok odpovídá kroku 3 v předchozím vysvětlení schématu.
Nyní musí server Consul (nebo jeho vůdce) ověřit platnost obdrženého tokenu. Proto se poradí s klastrem Kubernetes (přes klienta Consul) a pokud jsou udělena příslušná oprávnění, zjistíme, zda je token platný a komu patří.
Ověřený požadavek se poté vrací zpět k vůdci Consul a na serveru Consul se vyhledá instance autorizační metody se jménem uvedeným v požadavku na přihlášení (a typu Kubernetes).
Vůdce Consul určí uvedenou instanci autorizační metody (pokud je nalezena) a přečte sadu pravidel přidružených k ní. Poté tato pravidla přečte a porovná je s ověřenými atributy identity.
Tada! Přecházíme k kroku 5 v předchozím vysvětlení schématu.

Spusťte server Consul na běžném virtuálním stroji.

Od tohoto okamžiku budu převážně poskytovat pokyny k vytvoření tohoto POC, často bodově, bez vysvětlujících celých vět. Jak bylo již dříve uvedeno, budu používat GCP k vytvoření celé infrastruktury, ale můžete vytvořit stejnou infrastrukturu kdekoli jinde.

Spusťte virtuální stroj (instanci / server).

Vytvořte pravidlo pro firewall (skupina zabezpečení v AWS):
Rád přiděluji stejné jméno stroje pravidlu a síťovému tagu, v tomto případě je to „skywiz-consul-server-poc“.
Najděte IP adresu vašeho lokálního počítače a přidejte ji na seznam odchozích IP adres, abychom mohli získat přístup k uživatelskému rozhraní (UI).
Otevřete port 8500 pro UI. Klikněte na Vytvořit. Tento firewall brzy opět změníme [odkaz].
Přidejte pravidlo pro firewall k instanci. Vraťte se na řídicí panel VM na serveru Consul a do pole síťových tagů přidejte „skywiz-consul-server-poc“. Klikněte na Uložit.

Nainstalujte Consul na virtuální stroj, ověřte zde. Pamatujte, že potřebujete verzi Consul ≥ 1.5 [odkaz]
Vytvoříme single node Consul — konfigurace je následující.

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

Podrobnější návod na instalaci Consul a nastavení klastru z 3 nodů viz. zde.
Vytvořte soubor /etc/consul.d/agent.json následujícím způsobem [odkaz]:

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

Spusťte náš server Consul:

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

Měli byste vidět spoustu výstupů a nakonec „… aktualizace blokována ACL“.
Najděte externí IP adresu serveru Consul a otevřete prohlížeč na této IP adrese na portu 8500. Ujistěte se, že se otevře UI.
Zkuste přidat pár klíč/hodnota. Měla by být chyba. To je proto, že jsme server Consul spustili pomocí ACL a zakázali všechna pravidla.
Vraťte se ke své shellové relaci na serveru Consul a spusťte proces na pozadí nebo jiným způsobem, aby běžel, a zadejte následující:

consul acl bootstrap

Najděte hodnotu „SecretID“ a vraťte se do UI. Na kartě „ACL“ zadejte tajný identifikátor tokenu, který jste právě zkopírovali. Zkopírujte SecretID ještě někam jinam, později ho budeme potřebovat.
Nyní přidejte pár klíč/hodnota. Pro tento POC přidáme následující: klíč: „custom-ns/test_key“, hodnota: „Jsem ve složce custom-ns!“

Spuštění Kubernetes clusteru pro naši aplikaci s klientem Consul jako Daemonset.

Vytvořte klastr K8s (Kubernetes). Vytvoříme ho ve stejné zóně jako server, pro rychlejší přístup, a proto můžeme použít stejnou podsíť pro snadné připojení s interními IP adresami. Nazveme ho „skywiz-app-with-consul-client-poc“.

Jako poznámku, zde je dobrý návod, na který jsem narazil při nastavování POC Consul clusteru s Consul Connect.
Také budeme používat Hashicorp helm chart s rozšířeným souborem hodnot.
Nainstalujte a nakonfigurujte Helm. Krokový proces konfigurace:

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
Použijte následující soubor hodnot (všimněte si, že většinu jsem vypnul):

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

Aplikujte helm chart:

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

Při pokusu o spuštění budou potřebná oprávnění pro server Consul, tak je přidejme.
Všimněte si „rozsahu adres Pod“ umístěného na panelu clusteru a vraťte se k našemu pravidlu pro firewall „skywiz-consul-server-poc“.
Přidejte rozsah adres pro pod do seznamu IP adres a otevřete porty 8301 a 8300.

Přejděte na UI Consul, a za několik minut uvidíte, že se náš klastr objeví na kartě uzlů.

Nastavení metody autorizace integrací Consul s Kubernetes.

Vraťte se do shellu serveru Consul a exportujte token, který jste uložili dříve:

export CONSUL_HTTP_TOKEN=

Budeme potřebovat informace z našeho Kubernetes clusteru k vytvoření instance metody auth:
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 je zakódován v base64, proto ho dešifrujte pomocí svého oblíbeného nástroje [odkaz]
kubernetes-ca-cert

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

Vezměte certifikát "ca.crt" (po dešifrování z base64) a vložte ho do souboru "ca.crt".
Nyní vytvořte instanci metody auth, přičemž záměny placeholders za hodnoty, které jste právě získali.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "Toto je metoda autorizace využívající kubernetes pro cluster skywiz-app-with-consul-client-poc" 
-kubernetes-host "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

Dále musíme vytvořit pravidlo a přiřadit ho nové roli. Pro tuto část můžete použít uživatelské rozhraní Consul, ale použijeme příkazový řádek.
Napište pravidlo

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

Aplikujte pravidlo

consul acl policy create 
-name kv-custom-ns-policy 
-description "Toto je příklad pravidla pro kv na custom-ns/" 
-rules @kv-custom-ns-policy.hcl

Najděte identifikátor pravidla, které jste právě vytvořili, z výstupu.
Vytvořte roli s novým pravidlem.

consul acl role create 
-name "custom-ns-role" 
-description "Toto je příklad role pro custom-ns namespace" 
-policy-id

Nyní propojíme naši novou roli s instancí metody auth. Všimněte si, že příznak "selector" určuje, zda bude náš vstupní požadavek tuto roli získávat. Zde si zkontrolujte další možnosti selektoru: 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"'

Konfigurace nakonec

Práva přístupu

Vytvořte oprávnění. Musíme dát Consulu povolení k ověřování a identifikaci tokenu služby K8s.
Zapište do souboru následující [odkaz]:

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

Vytvoříme oprávnění

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

Připojení k Consul Client

Jak bylo zmíněno zde, existuje několik možností pro připojení k daemonset, ale přejdeme k následujícímu jednoduššímu řešení:
Aplikujte následující soubor [odkaz].

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

Poté aplikujte následující vestavěný příkaz pro vytvoření configmap [odkaz]. Všimněte si, že odkazujeme na název naší služby, v případě potřeby ho nahraďte.

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

Testování auth-metody

Teď se podívejme na kouzlo v akci!

Vytvořte další klíčové složky se stejným klíčem nejvyšší úrovně (tj. /sample_key) a hodnotou dle vašeho výběru. Vytvořte odpovídající politiky a role pro nové klíčové cesty. Odkazy uděláme později.

Uživatelské testování prostoru názvů:

Vytvoříme svůj vlastní prostor názvů:

kubectl create namespace custom-ns

Vytvoříme pod v našem novém prostoru názvů. Napište konfiguraci pro 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

Vytvořte pod:

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

Jakmile se kontejner spustí, přihlaste se a nainstalujte curl.

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

Nyní odešleme žádost o přihlášení do Consul pomocí auth-metody, kterou jsme vytvořili dříve [odkaz].
Abyste zobrazili zadaný token ze svého servisního účtu:

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

Napište následující do souboru uvnitř kontejneru:

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

Přihlášení!

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

Chcete-li provést výše uvedené kroky v jednom příkazu (protože provedeme několik testů), můžete udělat následující:

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

Funguje! Mělo by aspoň. Teď vezměte SecretID a zkuste získat přístup k klíči/hodnotě, ke které bychom měli mít přístup.

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

Můžete dekódovat „Value“ base64 a uvidíte, že odpovídá hodnotě v custom-ns/test_key v UI. Pokud jste použili stejnou hodnotu uvedenou výše v této příručce, vaše zakódovaná hodnota bude IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Test uživatelského servisního účtu:

Vytvořte uživatelský ServiceAccount pomocí následujícího příkazu [odkaz].

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

Vytvořte nový konfigurační soubor pro pod. Všimněte si, že jsem zahrnul instalaci curl pro usnadnění práce 🙂

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

Poté spusťte shell uvnitř kontejneru.

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

Přihlášení!

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

Odmítnutí přístupu. Omlouváme se, zapomněli jsme přidat nové pravidlo s odpovídajícími oprávněními, pojďme to teď udělat.

Opakujte předchozí kroky výše:
a) Vytvořte identickou politiku pro prefix „custom-sa/“.
b) Vytvořte roli a nazvěte ji „custom-sa-role“.
c) Připojte politiku k roli.

Vytvořte pravidlo propojení (možné pouze z cli / api). Všimněte si jiného hodnoty flagu selektoru.

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

Znovu se přihlaste do kontejneru „poc-ubuntu-custom-sa“. Úspěch!
Zkontrolujte náš přístup ke klíčové cestě custom-sa/.

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

Můžete si také být jisti, že tento token neposkytuje přístup k kv v „custom-ns/“. Stačí zopakovat výše uvedený příkaz po výměně „custom-sa“ za prefix „custom-ns“.
Odmítnutí přístupu.

Příklad překryvu:

Je třeba poznamenat, že všechna pravidla propojení budou přidána k tokenu s těmito právy.
Náš kontejner „poc-ubuntu-custom-sa“ se nachází ve výchozím prostoru názvů – takže jej použijeme pro další propojení pravidla.
Opakujte předchozí kroky:
a) Vytvořte identickou politiku pro prefix klíče „default/“.
b) Vytvořte roli a nazvěte ji “default-ns-role”.
c) Připojte politiku k roli.
Vytvořte pravidlo propojení (možné pouze z 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"'

Vraťte se k našemu kontejneru „poc-ubuntu-custom-sa“ a pokuste se získat přístup k cestě „default/“ kv.
Odmítnutí přístupu.
Můžete si prohlédnout zadané údaje pro každý token v UI v sekci ACL > Tokens. Jak vidíte, k našemu aktuálnímu tokenu je připojena pouze jedna „custom-sa-role“. Token, který momentálně používáme, byl vygenerován, když jsme se přihlásili, a tehdy mělo pouze jedno pravidlo propojení, které odpovídalo. Je třeba se znovu přihlásit a použít nový token.
Ujistěte se, že můžete číst jak z cest „custom-sa/“, tak „default/“ kv.
Úspěch!
To je způsobeno tím, že náš „poc-ubuntu-custom-sa“ odpovídá pravidlům propojení „custom-sa“ a „default-ns“.

Závěr

TTL správa tokenů?

V době psaní tohoto článku neexistuje integrovaný způsob, jak určit TTL pro tokeny generované tímto metodou autorizace. Byla by to fantastická možnost – zajistit bezpečnou automatizaci autorizace Consul.

Existuje možnost ručně vytvořit token s TTL: