Přesně tak, po vydání na začátku května 2019 může Consul nativně autorizovat aplikace a služby běžící v Kubernetes.
V tomto tutoriálu budeme tvořit krok za krokem (Proof of concept, PoC) demonstrující tuto novou funkci. Očekává se, že budete mít základní znalosti o Kubernetes a Hashicorp's Consul. A i když můžete používat jakoukoli cloudovou platformu nebo místní prostředí, v tomto tutoriálu budeme používat cloudovou platformu Google.
Recenze
Pokud půjdeme do , získáme stručný přehled jeho účelu a případu použití, dále některé technické detaily a obecný přehled o logice. Vřele doporučuji přečíst si to alespoň jednou, než budete pokračovat, protože to teď všechno vysvětlím a rozkousám.
Schéma 1: Oficiální přehled způsobu autorizace Consul
Pojďme se podívat do .
Užitečné informace tam samozřejmě jsou, ale chybí návod, jak to všechno vlastně využít. Takže, jako každý rozumný člověk, prohledáváte internet a hledáte návod. A pak... Buď poražen. Stalo se to. Pojďme to napravit.
Než přejdeme k vytváření našeho POC, vraťme se k přehledu metod autorizace Consul (Obrázek 1) a upřesněte jej v kontextu Kubernetes.
architektura
V tomto tutoriálu vytvoříme server Consul na samostatném počítači, který bude komunikovat s clusterem Kubernetes s nainstalovaným klientem Consul. Poté vytvoříme naši fiktivní aplikaci v modulu a použijeme naši nakonfigurovanou metodu autorizace ke čtení z našeho úložiště klíčů/hodnot konzul.
Níže uvedený diagram podrobně ukazuje architekturu, kterou vytváříme v tomto tutoriálu, a také logiku autorizační metody, která bude vysvětlena později.
Diagram 2: Přehled způsobu autorizace Kubernetes
Rychlá poznámka: Aby to fungovalo, server Consul nemusí žít mimo cluster Kubernetes. Ale ano, může tak či tak.
Takže když vezmeme schéma přehledu Consul (schéma 1) a použijeme na něj Kubernetes, dostaneme schéma výše (schéma 2) a zde bude logika následující:
- Každý modul bude mít připojený servisní účet obsahující token JWT vygenerovaný a známý Kubernetes. Tento token je také standardně vložen do podu.
- Naše aplikace nebo služba uvnitř modulu zahájí přihlašovací příkaz k našemu klientovi Consul. Žádost o přihlášení bude také obsahovat náš token a jméno speciálně vytvořené způsob autorizace (jako Kubernetes). Tento krok #2 odpovídá kroku 1 obvodu Consul (Schéma 1).
- Náš klient Consul poté předá tuto žádost našemu serveru Consul.
- KOUZLO! Zde server Consul ověřuje požadavek, shromažďuje identitu požadavku a porovnává jej s jakýmikoli přidruženými předdefinovanými pravidly. Níže je další diagram, který to ilustruje. Tento krok odpovídá krokům 3, 4 a 5 přehledového diagramu Consul (Obrázek 1).
- Náš server Consul generuje token Consul s oprávněními podle pravidel autorizační metody, která jsme specifikovali (která jsme definovali) ohledně identity žadatele. Poté pošle tento token zpět. To odpovídá kroku 6 schématu Consul (Schéma 1).
- Náš klient Consul předá token žádající aplikaci nebo službě.
Naše aplikace nebo služba nyní může používat tento token konzula ke komunikaci s daty našeho konzula, jak je definováno v právech tokenu.
Kouzlo je odhaleno!
Pro ty z vás, kteří nejsou spokojeni s pouhým zajíčkem z klobouku a chtějí vědět, jak to funguje... dovolte mi „ukázat vám, jak hluboko králičí nora".
Jak již bylo zmíněno dříve, náš „magický“ krok (Schéma 2: Krok 4) je pro server Consul, aby ověřil požadavek, shromáždil informace o požadavku a porovnal jej s jakýmikoli přidruženými předdefinovanými pravidly. Tento krok odpovídá krokům 3, 4 a 5 přehledového diagramu Consul (Obrázek 1). Níže je schéma (schéma 3), jehož účelem je názorně ukázat, co se vlastně děje pod kapotou konkrétní způsob autorizace Kubernetes.
Diagram 3: Kouzlo je odhaleno!
- Jako výchozí bod náš klient Consul předá žádost o přihlášení na náš server Consul s tokenem účtu Kubernetes a názvem konkrétní instance autorizační metody, kterou jsme vytvořili dříve. Tento krok odpovídá kroku 3 v předchozím vysvětlení diagramu.
- Nyní konzulský server (nebo vedoucí) potřebuje ověřit pravost přijatého tokenu. Poradí se tedy s clusterem Kubernetes (přes klienta Consul) a s příslušnými oprávněními zjistíme, zda je token pravý a kdo jej vlastní.
- Ověřený požadavek se poté vrátí vedoucímu konzula a na serveru konzul se vyhledá instance metody autorizace se zadaným názvem z požadavku na přihlášení (a typu Kubernetes).
- Vedoucí konzul určí specifikovanou instanci autorizační metody (pokud je nalezena) a přečte sadu závazných pravidel, která jsou k ní připojena. Poté tato pravidla přečte a porovná je s ověřenými atributy identity.
- TA-dah! Přejděte ke kroku 5 v předchozím vysvětlení obvodu.
Spusťte Consul-server na normálním virtuálním počítači
Od této chvíle budu dávat hlavně návody na tvorbu tohoto POC, často v odstavcích, bez vysvětlujících celých vět. Také, jak již bylo uvedeno dříve, použiji GCP k vytvoření celé infrastruktury, ale stejnou infrastrukturu můžete vytvořit kdekoli jinde.
- Spusťte virtuální počítač (instanci / server).
- Vytvořte pravidlo brány firewall (skupina zabezpečení v AWS):
- Rád bych pravidlu a značce sítě přiřadil stejný název stroje, v tomto případě „skywiz-consul-server-poc“.
- Najděte IP adresu svého místního počítače a přidejte ji do seznamu zdrojových IP adres, abychom měli přístup k uživatelskému rozhraní (UI).
- Otevřete port 8500 pro uživatelské rozhraní. Klikněte na Vytvořit. Brzy tento firewall znovu změníme [].
- Přidejte do instance pravidlo brány firewall. Vraťte se na řídicí panel virtuálního počítače na serveru Consul a do pole značek sítě přidejte „skywiz-consul-server-poc“. Klikněte na Uložit.
- Nainstalujte Consul na virtuální počítač, zkontrolujte zde. Nezapomeňte, že potřebujete verzi Consul ≥ 1.5 [odkaz]
- Vytvořme jeden uzel 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ší průvodce instalací Consul a nastavením clusteru se 3 uzly naleznete v části .
- Vytvořte soubor /etc/consul.d/agent.json takto []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Spusťte náš Consul server:
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č s touto IP adresou na portu 8500. Ujistěte se, že se otevře uživatelské rozhraní.
- Zkuste přidat pár klíč/hodnota. Musí tam být chyba. Je to proto, že jsme nahráli server Consul s ACL a odepřeli všechna pravidla.
- Vraťte se do svého shellu na serveru Consul a spusťte proces na pozadí nebo jiným způsobem, aby fungoval, a zadejte následující:
consul acl bootstrap- Najděte hodnotu „SecretID“ a vraťte se do uživatelského rozhraní. Na kartě ACL zadejte ID tajného tokenu, které jste právě zkopírovali. Zkopírujte SecretID někam jinam, budeme ho potřebovat později.
- Nyní přidejte pár klíč/hodnota. Pro tento POC přidejte následující: klíč: "custom-ns/test_key", hodnota: "Jsem ve složce custom-ns!"
Spuštění clusteru Kubernetes pro naši aplikaci s klientem Consul jako daemonset
- Vytvořte cluster K8s (Kubernetes). Vytvoříme ho ve stejné zóně jako server pro rychlejší přístup a můžeme tak použít stejnou podsíť pro snadné připojení k interním IP. Pojmenujeme to „skywiz-app-with-consul-client-poc“.
- Jako vedlejší poznámku, zde je dobrý průvodce, na který jsem narazil při nastavování clusteru Consul POC s Consul Connect.
- Použijeme také graf kormidla Hashicorp s rozšířeným souborem hodnot.
- Nainstalujte a nakonfigurujte Helm. Kroky 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- helmchart:
- Použijte následující soubor hodnot (všimněte si, že většinu jsem zakázal):
### 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- Použít tabulku kormidla:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Když se pokusí spustit, bude potřebovat oprávnění pro server Consul, takže je přidejte.
- Všimněte si "Rozsahu adres pod" umístěného na řídicím panelu clusteru a vraťte se k našemu pravidlu brány 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 do uživatelského rozhraní Consul a za několik minut uvidíte, že se na kartě uzlů objeví náš cluster.
Přizpůsobení metody autorizace integrací Consul s Kubernetes
- Vraťte se do shellu serveru Consul a exportujte token, který jste dříve uložili:
export CONSUL_HTTP_TOKEN=<SecretID>- K vytvoření instance metody ověřování potřebujeme informace z našeho clusteru Kubernetes:
- hostitel kubernetes
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:- Token je kódován base64, takže jej dešifrujte pomocí svého oblíbeného nástroje []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Vezměte certifikát „ca.crt“ (po dekódování base64) a vložte jej do souboru „ca.crt“.
- Nyní vytvořte instanci metody auth a nahraďte zástupné symboly hodnotami, které jste právě obdrželi.
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>"- Dále musíme vytvořit pravidlo a připojit ho k nové roli. Pro tuto část můžete použít Consul UI, ale my použijeme příkazový řádek.
- Napište pravidlo
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Použijte pravidlo
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- Najděte ID 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 "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Nyní přidružíme naši novou roli k instanci metody auth. Všimněte si, že příznak „selektor“ určuje, zda náš požadavek na přihlášení obdrží tuto roli. Podívejte se na další možnosti výběru:
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 na závěr
Přístupová práva
- Vytvořit oprávnění. Potřebujeme dát povolení konzulovi k ověření a identifikaci identity tokenu servisního účtu K8s.
- Do souboru zapište následující :
###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- Pojďme vytvořit přístupová práva
kubectl create -f skywiz-poc-consul-server_rbac.yamlPřipojování ke klientovi Consul
- Jak bylo zmíněno , existuje několik možností připojení k daemonsetu, ale přejdeme k dalšímu jednoduchému řešení:
- Použijte následující soubor [].
### 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é pomocí následujícího vestavěného příkazu vytvořte konfigurační mapu []. Upozorňujeme, že odkazujeme na název naší služby, v případě potřeby jej změň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}')"]}
EOFTestování metody auth
Nyní se podívejme na kouzlo v akci!
- Vytvořte několik dalších klíčových složek se stejným klíčem nejvyšší úrovně (tj. /ukázkový_klíč) a hodnotu dle vašeho výběru. Vytvořte vhodné zásady a role pro nové klíčové cesty. Vazby uděláme později.
Test vlastního jmenného prostoru:
- Vytvořme si vlastní jmenný prostor:
kubectl create namespace custom-ns- Pojďme vytvořit pod v našem novém jmenném prostoru. Napište konfiguraci modulu.
###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řit pod:
kubectl create -f poc-ubuntu-custom-ns.yaml- Jakmile je kontejner v provozu, jděte tam 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í konzulovi pomocí autorizační metody, kterou jsme vytvořili dříve [].
- Chcete-li zobrazit zadaný token ze svého servisního účtu:
cat /run/secrets/kubernetes.io/serviceaccount/token- Do souboru uvnitř kontejneru zapište následující:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Přihlásit se!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Chcete-li provést výše uvedené kroky na jednom řádku (protože budeme spouštět více testů), můžete provést 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ěl by, alespoň. Nyní vezměte SecretID a pokuste se získat přístup ke klíči/hodnotě, ke kterému potřebujeme mít přístup.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Můžete dekódovat "Value" base64 a uvidíte, že odpovídá hodnotě v custom-ns/test_key v uživatelském rozhraní. Pokud jste použili stejnou hodnotu uvedenou dříve v této příručce, vaše zakódovaná hodnota by byla IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Test uživatelského servisního účtu:
- Vytvořte vlastní servisní účet pomocí následujícího příkazu [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Vytvořte nový konfigurační soubor pro modul. Vezměte prosím na vědomí, že jsem zahrnul instalaci curl pro úsporu 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ř nádoby.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Přihlásit se!
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- Přístup odepřen. Oh, zapomněli jsme přidat novou vazbu pravidla s příslušnými oprávněními, udělejme to teď.
Opakujte předchozí kroky výše:
a) Vytvořte identickou politiku pro předponu „custom-sa/“.
b) Vytvořte roli, pojmenujte ji „custom-sa-role“
c) Připojte zásady k roli.
- Vytvořte vazbu pravidel (možné pouze z cli/api). Všimněte si jiné hodnoty příznaku 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"'- Zkuste se znovu přihlásit z kontejneru „poc-ubuntu-custom-sa“. Úspěch!
- Zkontrolujte náš přístup k cestě custom-sa/key.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Můžete se také ujistit, že tento token neuděluje přístup ke kv v "custom-ns/". Stačí zopakovat výše uvedený příkaz po nahrazení "custom-sa" předponou "custom-ns".
Přístup odepřen.
Příklad překryvné vrstvy:
- Stojí za zmínku, že všechny shody s vazbou na pravidla budou přidány do tokenu s těmito právy.
- Náš kontejner "poc-ubuntu-custom-sa" je ve výchozím jmenném prostoru - takže jej použijeme pro další vázání pravidel.
- Opakujte předchozí kroky:
a) Vytvořte identickou politiku pro předponu klíče "default/".
b) Vytvořte roli, pojmenujte ji „default-ns-role“
c) Připojte zásady k roli. - Vytvořte vazbu pravidel (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 do našeho kontejneru "poc-ubuntu-custom-sa" a pokuste se získat přístup k "default/" kv cestě.
- Přístup odepřen.
Zadaná pověření pro každý token můžete zobrazit v uživatelském rozhraní pod ACL > Tokeny. Jak vidíte, k našemu aktuálnímu tokenu je připojena pouze jedna „custom-sa-role“. Token, který aktuálně používáme, byl vygenerován, když jsme se přihlásili, a tehdy existovala pouze jedna shoda s pravidly. Musíme se znovu přihlásit a použít nový token. - Ujistěte se, že můžete číst kv cesty "custom-sa/" i "default/".
Úspěch!
Je to proto, že naše „poc-ubuntu-custom-sa“ odpovídá vazbám pravidel „custom-sa“ a „default-ns“.
Závěr
TTL token mgmt?
V době psaní tohoto článku neexistuje žádný integrovaný způsob, jak určit TTL pro tokeny generované touto metodou autorizace. Byla by to fantastická příležitost poskytnout konzulovi bezpečnou automatizaci autorizace.
Existuje možnost ručně vytvořit token s TTL:
Doba platnosti – Doba, kdy bude tento token odvolán. (Volitelné; přidáno v Consul 1.5.0)- Existuje pouze pro ruční vytváření/aktualizaci
Doufejme, že brzy budeme moci kontrolovat, jak se generují tokeny (pro každé pravidlo nebo způsob autorizace) a přidat TTL.
Do té doby se doporučuje používat ve vaší logice koncový bod pro odhlášení.
Přečtěte si také další články na našem blogu:
Zdroj: www.habr.com