To je pravda, po prepustení začiatkom mája 2019 môžete v Consul autorizovať aplikácie a služby bežiace v Kubernetes natívne.
V tomto návode vytvoríme krok za krokom (Proof of concept, PoC) demonštrujúci túto novú funkciu. Očakáva sa, že budete mať základné znalosti o Kubernetes a Hashicorp's Consul. Aj keď môžete použiť akúkoľvek cloudovú platformu alebo lokálne prostredie, v tomto návode budeme používať cloudovú platformu Google.
Recenzia
Ak pôjdeme do , získame rýchly prehľad jeho účelu a prípadu použitia, ako aj niektoré technické detaily a všeobecný prehľad o logike. Dôrazne odporúčam prečítať si to aspoň raz, kým budete pokračovať, pretože teraz to všetko vysvetlím a prežúvam.
Diagram 1: Oficiálny prehľad spôsobu autorizácie konzulom
Pozrime sa dovnútra .
Iste, sú tam užitočné informácie, no chýba návod, ako to všetko vlastne využiť. Takže, ako každý rozumný človek, prehľadávate internet a hľadáte návod. A potom... Zlyháš. To sa stáva. Poďme to napraviť.
Skôr než prejdeme k vytvoreniu nášho POC, vráťme sa k prehľadu autorizačných metód konzula (Schéma 1) a spresnime ho v kontexte Kubernetes.
architektúra
V tomto návode vytvoríme server Consul na samostatnom počítači, ktorý bude komunikovať s klastrom Kubernetes s nainštalovaným klientom Consul. Potom vytvoríme našu fiktívnu aplikáciu v module a použijeme našu nakonfigurovanú metódu autorizácie na čítanie z nášho úložiska kľúča/hodnoty konzula.
Nižšie uvedený diagram podrobne popisuje architektúru, ktorú vytvárame v tomto návode, ako aj logiku spôsobu autorizácie, ktorá bude vysvetlená neskôr.
Diagram 2: Prehľad spôsobu autorizácie Kubernetes
Rýchla poznámka: Server Consul nemusí žiť mimo klastra Kubernetes, aby to fungovalo. Ale áno, môže to urobiť takto a takto.
Takže, keď vezmeme diagram prehľadu Consul (Schéma 1) a použijeme naň Kubernetes, dostaneme diagram uvedený vyššie (Diagram 2) a logika je tu nasledovná:
- Ku každému modulu bude pripojený servisný účet obsahujúci token JWT vygenerovaný a známy spoločnosťou Kubernetes. Tento token je tiež štandardne vložený do modulu.
- Naša aplikácia alebo služba vo vnútri modulu spustí príkaz na prihlásenie do nášho klienta Consul. Žiadosť o prihlásenie bude obsahovať aj náš token a meno špeciálne vytvorené spôsob autorizácie (typ Kubernetes). Tento krok #2 zodpovedá kroku 1 Consul diagramu (Schéma 1).
- Náš klient Consul potom pošle túto požiadavku na náš server Consul.
- MAGIE! Toto je miesto, kde server Consul overí pravosť žiadosti, zhromažďuje informácie o identite žiadosti a porovnáva ju s akýmikoľvek súvisiacimi preddefinovanými pravidlami. Nižšie je uvedený ďalší diagram, ktorý to ilustruje. Tento krok zodpovedá krokom 3, 4 a 5 prehľadového diagramu konzula (graf 1).
- Náš server Consul generuje token Consul s povoleniami podľa našich špecifikovaných pravidiel spôsobu autorizácie (ktoré sme definovali) v súvislosti s identitou žiadateľa. Potom pošle tento token späť. To zodpovedá kroku 6 Konzulského diagramu (Schéma 1).
- Náš klient konzul odošle token žiadajúcej aplikácii alebo službe.
Naša aplikácia alebo služba môže teraz používať tento token konzula na komunikáciu s údajmi nášho konzula, ako to určujú privilégiá tokenu.
Kúzlo je odhalené!
Pre tých z vás, ktorým nestačí len králik z klobúka a chcete vedieť, ako to funguje... dovoľte mi, aby som vám ukázal, ako hlboko Zajačia diera".
Ako už bolo spomenuté, náš „magický“ krok (Obrázok 2: Krok 4) je miesto, kde server Consul autentifikuje požiadavku, zhromažďuje informácie o žiadosti a porovnáva ju s akýmikoľvek súvisiacimi preddefinovanými pravidlami. Tento krok zodpovedá krokom 3, 4 a 5 prehľadového diagramu konzula (graf 1). Nižšie je uvedený diagram (Schéma 3), ktorého účelom je názorne ukázať, čo sa vlastne deje pod kapotou špecifický spôsob autorizácie Kubernetes.
Diagram 3: Kúzlo je odhalené!
- Ako východiskový bod náš klient Consul prepošle požiadavku na prihlásenie na náš server Consul s tokenom účtu Kubernetes a konkrétnym názvom inštancie metódy autorizácie, ktorá bola vytvorená skôr. Tento krok zodpovedá kroku 3 v predchádzajúcom vysvetlení obvodu.
- Teraz musí konzulský server (alebo vedúci) overiť pravosť prijatého tokenu. Prekonzultuje teda klaster Kubernetes (cez klienta Consul) a s príslušnými povoleniami zistíme, či je token pravý a komu patrí.
- Overená požiadavka sa potom vráti vedúcemu konzula a server konzulátu vyhľadá inštanciu metódy autorizácie so zadaným názvom zo žiadosti o prihlásenie (a typu Kubernetes).
- Vedúci konzula identifikuje špecifikovanú inštanciu metódy autorizácie (ak sa nájde) a prečíta súbor záväzných pravidiel, ktoré sú k nej pripojené. Potom prečíta tieto pravidlá a porovná ich s overenými atribútmi identity.
- TA-dah! Prejdime na krok 5 v predchádzajúcom vysvetlení obvodu.
Spustite Consul-server na bežnom virtuálnom počítači
Odteraz budem väčšinou dávať pokyny na vytvorenie tohto POC, často v odrážkach, bez vysvetlenia celých viet. Ako už bolo uvedené, na vytvorenie celej infraštruktúry použijem GCP, ale rovnakú infraštruktúru môžete vytvoriť kdekoľvek inde.
- Spustite virtuálny počítač (inštancia/server).
- Vytvorte pravidlo pre bránu firewall (skupina zabezpečenia v AWS):
- Rád priraďujem rovnaký názov stroja pravidlu aj značke siete, v tomto prípade „skywiz-consul-server-poc“.
- Nájdite IP adresu svojho lokálneho počítača a pridajte ju do zoznamu zdrojových IP adries, aby sme mali prístup k používateľskému rozhraniu (UI).
- Otvorte port 8500 pre používateľské rozhranie. Kliknite na Vytvoriť. Tento firewall čoskoro znova zmeníme [].
- Pridajte do inštancie pravidlo brány firewall. Vráťte sa na ovládací panel VM na serveri Consul a do poľa sieťových značiek pridajte „skywiz-consul-server-poc“. Kliknite na tlačidlo Uložiť.
- Nainštalujte Consul na virtuálny počítač, skontrolujte tu. Nezabudnite, že potrebujete verziu Consul ≥ 1.5 [odkaz]
- Vytvorme jeden uzol Consul - konfigurácia je nasledovná.
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- Podrobnejšieho sprievodcu inštaláciou Consul a nastavením klastra 3 uzlov nájdete v časti .
- Vytvorte súbor /etc/consul.d/agent.json nasledovne []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Spustite 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- Mali by ste vidieť veľa výstupov a skončiť s „... aktualizácia blokovaná zoznamami ACL“.
- Nájdite externú IP adresu servera Consul a otvorte prehliadač s touto IP adresou na porte 8500. Uistite sa, že sa otvorilo používateľské rozhranie.
- Skúste pridať pár kľúč/hodnota. Musí tam byť chyba. Dôvodom je, že sme nahrali server Consul s ACL a deaktivovali všetky pravidlá.
- Vráťte sa do svojho shellu na serveri Consul a spustite proces na pozadí alebo iným spôsobom, ako ho spustiť, a zadajte nasledujúce:
consul acl bootstrap- Nájdite hodnotu „SecretID“ a vráťte sa do používateľského rozhrania. Na karte ACL zadajte tajné ID tokenu, ktorý ste práve skopírovali. Skopírujte SecretID niekde inde, budeme ho potrebovať neskôr.
- Teraz pridajte pár kľúč/hodnota. Pre tento POC pridajte nasledovné: kľúč: “custom-ns/test_key”, hodnota: “Som v priečinku custom-ns!”
Spustenie klastra Kubernetes pre našu aplikáciu s klientom Consul ako daemonset
- Vytvorte klaster K8s (Kubernetes). Vytvoríme ho v rovnakej zóne ako server pre rýchlejší prístup, a tak môžeme použiť rovnakú podsieť na jednoduché pripojenie s internými IP adresami. Budeme to nazývať „skywiz-app-with-consul-client-poc“.
- Ako vedľajšiu poznámku tu je dobrý návod, na ktorý som narazil pri nastavovaní klastra POC Consul s Consul Connect.
- Budeme tiež používať tabuľku kormidla Hashicorp s rozšíreným súborom hodnôt.
- Nainštalujte a nakonfigurujte Helm. Kroky konfigurácie:
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- graf kormidla:
- Použite nasledujúci súbor hodnôt (všimnite si, že väčšinu som 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žiť tabuľku kormidla:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Keď sa pokúsi spustiť, bude potrebovať povolenia pre server Consul, takže ich pridajte.
- Všimnite si „Rozsah adries pod“ umiestnený na ovládacom paneli klastra a pozrite si naše pravidlo brány firewall „skywiz-consul-server-poc“.
- Pridajte rozsah adries pre modul do zoznamu adries IP a otvorte porty 8301 a 8300.
- Prejdite do používateľského rozhrania Consul a po niekoľkých minútach uvidíte, že sa na karte uzlov objaví náš klaster.
Konfigurácia metódy autorizácie integráciou Consul s Kubernetes
- Vráťte sa do shell servera Consul a exportujte token, ktorý ste predtým uložili:
export CONSUL_HTTP_TOKEN=<SecretID>- Na vytvorenie inštancie metódy auth budeme potrebovať informácie z nášho klastra Kubernetes:
- kubernetes-host
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ódovaný base64, takže ho dešifrujte pomocou svojho obľúbeného nástroja []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Vezmite certifikát „ca.crt“ (po dekódovaní base64) a zapíšte ho do súboru „ca.crt“.
- Teraz vytvorte inštanciu metódy overenia a nahraďte zástupné symboly hodnotami, ktoré ste práve dostali.
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>"- Ďalej musíme vytvoriť pravidlo a pripojiť ho k novej úlohe. Pre túto časť môžete použiť používateľské rozhranie Consul, ale použijeme príkazový riadok.
- Napíš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 "This is an example policy for kv at custom-ns/"
-rules @kv-custom-ns-policy.hcl- Nájdite ID pravidla, ktoré ste práve vytvorili z výstupu.
- Vytvorte rolu s novým pravidlom.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Teraz spojíme našu novú rolu s inštanciou metódy auth. Všimnite si, že príznak „selektor“ určuje, či naša žiadosť o prihlásenie získa túto rolu. Ďalšie možnosti výberu nájdete tu:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Nakoniec konfigurácie
Prístupové práva
- Vytvorte prístupové práva. Potrebujeme dať konzulovi povolenie na overenie a identifikáciu identity tokenu servisného účtu K8s.
- Do súboru zapíšte nasledovné :
###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- Vytvorme prístupové práva
kubectl create -f skywiz-poc-consul-server_rbac.yamlPripája sa ku klientovi Consul
- Ako bolo uvedené Existuje niekoľko možností na pripojenie k démonu, ale prejdeme k nasledujúcemu jednoduchému riešeniu:
- Použite nasledujúci súbor [].
### 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- Potom použite nasledujúci vstavaný príkaz na vytvorenie konfiguračnej mapy []. Upozorňujeme, že odkazujeme na názov našej služby, v prípade potreby ho vymeň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}')"]}
EOFTestovanie metódy auth
Teraz sa pozrime na kúzlo v akcii!
- Vytvorte niekoľko ďalších kľúčových priečinkov s rovnakým kľúčom najvyššej úrovne (t. j. /ukážkový_kľúč) a hodnotu podľa vášho výberu. Vytvorte vhodné politiky a roly pre nové kľúčové cesty. Väzby urobíme neskôr.
Test vlastného menného priestoru:
- Vytvorme si vlastný menný priestor:
kubectl create namespace custom-ns- Poďme vytvoriť modul v našom novom mennom priestore. Napíšte konfiguráciu 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- Vytvoriť pod:
kubectl create -f poc-ubuntu-custom-ns.yaml- Keď je kontajner spustený, choďte tam a nainštalujte curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Teraz odošleme žiadosť o prihlásenie konzulovi pomocou autorizačnej metódy, ktorú sme vytvorili predtým [].
- Ak chcete zobraziť zadaný token z vášho servisného účtu:
cat /run/secrets/kubernetes.io/serviceaccount/token- Do súboru v kontajneri zapíšte nasledovné:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Prihlásiť sa!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Ak chcete vykonať vyššie uvedené kroky v jednom riadku (keďže budeme spúšťať viacero testov), môžete urobiť nasledovné:
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- Tvorba! Aspoň by malo. Teraz vezmite SecretID a pokúste sa získať prístup ku kľúču/hodnote, ku ktorému by sme mali mať prístup.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- "Value" môžete dekódovať pomocou base64 a uvidíte, že sa zhoduje s hodnotou v custom-ns/test_key v používateľskom rozhraní. Ak ste použili rovnakú hodnotu vyššie v tomto návode, vaša zakódovaná hodnota by bola IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Test účtu používateľskej služby:
- Vytvorte si vlastný ServiceAccount pomocou nasledujúceho príkazu [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Vytvorte nový konfiguračný súbor pre modul. Upozorňujeme, že som zahrnul inštaláciu curl, aby som ušetril prácu :)
###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- Potom spustite škrupinu vo vnútri nádoby.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Prihlásiť sa!
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- Prístup zamietnutý. Och, zabudli sme pridať nové pravidlá záväzné s príslušnými povoleniami, urobme to teraz.
Opakujte vyššie uvedené kroky:
a) Vytvorte identickú politiku pre predponu „custom-sa/“.
b) Vytvorte rolu, nazvite ju „custom-sa-role“
c) Pripojte politiku k úlohe.
- Vytvorte viazanie pravidiel (možné iba z cli/api). Všimnite si odlišný význam príznaku výberu.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Prihláste sa znova z kontajnera „poc-ubuntu-custom-sa“. Úspech!
- Pozrite si náš prístup k vlastnej sa/kľúčovej ceste.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Môžete tiež zabezpečiť, aby tento token neudeľoval prístup ku kv v "custom-ns/". Stačí zopakovať vyššie uvedený príkaz po nahradení "custom-sa" predponou "custom-ns".
Prístup zamietnutý.
Príklad prekrytia:
- Stojí za zmienku, že všetky mapovania viažuce pravidlá budú pridané do tokenu s týmito právami.
- Náš kontajner „poc-ubuntu-custom-sa“ je v predvolenom priestore názvov – takže ho použime na iné viazanie pravidiel.
- Opakujte predchádzajúce kroky:
a) Vytvorte identickú politiku pre predponu kľúča „default/“.
b) Vytvorte rolu, pomenujte ju „default-ns-role“
c) Pripojte politiku k úlohe. - Vytvorte väzbu s pravidlami (možné len 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"'- Vráťte sa do nášho kontajnera "poc-ubuntu-custom-sa" a pokúste sa získať prístup k "default/" kv ceste.
- Prístup zamietnutý.
Zadané poverenia pre každý token môžete zobraziť v používateľskom rozhraní v časti ACL > Tokeny. Ako vidíte, náš aktuálny token má priradenú iba jednu „vlastnú rolu“. Token, ktorý momentálne používame, bol vygenerovaný, keď sme sa prihlásili, a vtedy existovalo iba jedno pravidlo viazania. Musíme sa znova prihlásiť a použiť nový token. - Uistite sa, že môžete čítať z ciest kv "custom-sa/" a "default/".
Úspech!
Je to preto, že naše „poc-ubuntu-custom-sa“ sa zhoduje s väzbami pravidiel „custom-sa“ a „default-ns“.
Záver
TTL token mgmt?
V čase písania tohto článku neexistuje integrovaný spôsob, ako určiť TTL pre tokeny vygenerované touto metódou autorizácie. Bola by to fantastická príležitosť poskytnúť bezpečnú automatizáciu autorizácie konzulov.
Existuje možnosť manuálneho vytvorenia tokenu s TTL:
Čas vypršania platnosti – Čas, kedy bude tento token odvolaný. (Voliteľné; pridané v Consul 1.5.0)- Existuje len na manuálne vytvorenie/aktualizáciu
Dúfajme, že v blízkej budúcnosti budeme môcť kontrolovať spôsob generovania tokenov (podľa pravidla alebo spôsobu autorizácie) a pridať TTL.
Dovtedy sa odporúča, aby ste vo svojej logike používali koncový bod odhlásenia.
Prečítajte si aj ďalšie články na našom blogu:
Zdroj: hab.com