See on õige, pärast vabastamist 2019. aasta mai alguses saate Consulis autoriseerida Kubernetes töötavaid rakendusi ja teenuseid.
Selles õpetuses loome samm-sammult (Proof of concept, PoC), mis demonstreerib seda uut funktsiooni. Teilt eeldatakse põhiteadmisi Kubernetese ja Hashicorpi konsuli kohta. Kuigi saate kasutada mis tahes pilveplatvormi või kohapealset keskkonda, kasutame selles õpetuses Google'i pilveplatvormi.
Vaadata
Kui me läheme , saame kiire ülevaate selle eesmärgist ja kasutusjuhtumist, samuti mõningaid tehnilisi üksikasju ja üldise ülevaate loogikast. Soovitan seda enne jätkamist vähemalt korra lugeda, sest nüüd selgitan ja närin seda kõike.
Diagramm 1: Ametlik ülevaade konsuli volitamise meetodist
Vaatame sisse .
Muidugi on seal kasulikku teavet, kuid puudub juhend selle kohta, kuidas seda kõike tegelikult kasutada. Niisiis, nagu iga terve mõistusega inimene, otsite juhiseid Internetist. Ja siis... Sa ebaõnnestud. Juhtub. Teeme selle korda.
Enne kui asume oma POC loomise juurde, pöördume tagasi Consuli autoriseerimismeetodite ülevaate juurde (joonis 1) ja täpsustame seda Kubernetese kontekstis.
arhitektuur
Selles õpetuses loome eraldi masinas Consuli serveri, mis suhtleb Kubernetese klastriga, kuhu on installitud Consuli klient. Seejärel loome kaustas oma näiva rakenduse ja kasutame oma konfigureeritud autoriseerimismeetodit, et lugeda meie konsuli võtme/väärtuste poest.
Allolev diagramm kirjeldab üksikasjalikult arhitektuuri, mida me selles õpetuses loome, ja autoriseerimismeetodi taga olevat loogikat, mida selgitatakse hiljem.
Diagramm 2: Kubernetese autoriseerimismeetodi ülevaade
Kiire märkus: selle toimimiseks ei pea Consul server elama väljaspool Kubernetese klastrit. Aga jah, ta oskab nii ja naa.
Niisiis, võttes konsuli ülevaate diagrammi (diagramm 1) ja rakendades sellele Kubernetes, saame ülaltoodud diagrammi (diagramm 2) ja loogika on järgmine:
- Igale podile on lisatud teenusekonto, mis sisaldab Kubernetesi loodud ja teadaolevat JWT-märki. See märk sisestatakse vaikimisi ka podisse.
- Meie podi sees rakendus või teenus käivitab meie Consul kliendile sisselogimiskäsu. Sisselogimistaotlus sisaldab ka meie tunnust ja nime spetsiaalselt loodud autoriseerimismeetod (Kubernetes tüüpi). See samm #2 vastab konsuli diagrammi 1. etapile (skeem 1).
- Meie Consul klient edastab selle päringu meie konsuli serverisse.
- MAAGIA! See on koht, kus Consul server kontrollib päringu autentsust, kogub teavet päringu identiteedi kohta ja võrdleb seda eelnevalt määratletud reeglitega. Allpool on selle illustreerimiseks veel üks diagramm. See samm vastab konsuli ülevaateskeemi (joonis 3) sammudele 4, 5 ja 1.
- Meie konsuli server genereerib taotleja identiteedi osas lubadega konsuli märgi vastavalt meie määratud autoriseerimismeetodi reeglitele (mille oleme määratlenud). Seejärel saadab see märgi tagasi. See vastab konsuli diagrammi 6. etapile (joonis 1).
- Meie konsul klient edastab märgi taotlevale rakendusele või teenusele.
Meie rakendus või teenus saab nüüd kasutada seda konsuli luba meie konsuli andmetega suhtlemiseks, mis on määratud loa õigustes.
Maagia on paljastatud!
Neile teist, kes ei ole rahul sellega, et jänes on mütsist välja võetud ja soovite teada, kuidas see toimib... las ma näitan teile, kui sügav on jäneseurg'.
Nagu varem mainitud, on meie "maagiline" samm (joonis 2: samm 4), kus Consul server autentib päringu, kogub päringu teavet ja võrdleb seda mis tahes seotud eelmääratletud reeglitega. See samm vastab konsuli ülevaateskeemi (joonis 3) sammudele 4, 5 ja 1. Allpool on diagramm (joonis 3), mille eesmärk on selgelt näidata, mis tegelikult toimub kapoti all spetsiifiline Kubernetese autoriseerimismeetod.
Diagramm 3: Maagia on paljastatud!
- Alustuseks edastab meie Consul klient sisselogimispäringu meie Consuli serverisse Kubernetese konto tunnuse ja varem loodud autoriseerimismeetodi konkreetse eksemplari nimega. See samm vastab 3. sammule eelmises vooluringi selgituses.
- Nüüd peab konsuli server (või juht) kontrollima vastuvõetud märgi autentsust. Seetõttu konsulteerib ta Kubernetese klastriga (Konsuli kliendi kaudu) ja vastavate lubadega selgitame välja, kas token on ehtne ja kellele see kuulub.
- Seejärel tagastatakse kinnitatud päring konsuli juhile ja konsuli server otsib sisselogimistaotlusest (ja Kubernetese tüübist) määratud nimega autoriseerimismeetodi eksemplari.
- Konsuli juht tuvastab määratud autoriseerimismeetodi eksemplari (kui see on leitud) ja loeb sellele lisatud siduvate reeglite komplekti. Seejärel loeb see neid reegleid ja võrdleb neid kinnitatud identiteediatribuutidega.
- TA-dah! Liigume edasi 5. sammu juurde eelmises vooluringi selgituses.
Käivitage Consul-server tavalises virtuaalmasinas
Edaspidi annan enamasti juhiseid selle POC loomise kohta, sageli täppides, ilma täislausete selgitusteta. Nagu varem märgitud, kasutan kogu infrastruktuuri loomiseks GCP-d, kuid sama infrastruktuuri saate luua ka mujal.
- Käivitage virtuaalmasin (eksemplar/server).
- Looge tulemüüri reegel (AWS-i turvarühm):
- Mulle meeldib määrata nii reeglile kui ka võrgusildile sama masina nimi, antud juhul "skywiz-consul-server-poc".
- Otsige üles oma kohaliku arvuti IP-aadress ja lisage see lähte-IP-aadresside loendisse, et saaksime juurdepääsu kasutajaliidesele (UI).
- Avage kasutajaliidese jaoks port 8500. Klõpsake nuppu Loo. Muudame seda tulemüüri varsti uuesti [].
- Lisage eksemplarile tulemüüri reegel. Minge tagasi Consul Serveri VM-i armatuurlauale ja lisage võrgusiltide väljale "skywiz-consul-server-poc". Klõpsake nuppu Salvesta.
- Installige Consul virtuaalsesse masinasse, vaadake siit. Pidage meeles, et vajate Consuli versiooni ≥ 1.5 [link]
- Loome ühe sõlme Consul - konfiguratsioon on järgmine.
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- Üksikasjalikuma juhendi Consuli installimise ja 3 sõlmest koosneva klastri seadistamise kohta vt .
- Looge fail /etc/consul.d/agent.json järgmiselt []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Käivitage meie konsuli server:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Peaksite nägema hunnikut väljundit ja lõppema tekstiga "... värskendus on ACL-ide poolt blokeeritud".
- Otsige üles Consul serveri väline IP-aadress ja avage selle IP-aadressiga brauser pordis 8500. Veenduge, et kasutajaliides avaneb.
- Proovige lisada võtme/väärtuse paar. Peab olema viga. Selle põhjuseks on asjaolu, et laadisime Consuli serverisse ACL-i ja keelasime kõik reeglid.
- Minge tagasi oma kestale Consul serveris ja käivitage protsess taustal või mõnel muul viisil selle käivitamiseks ning sisestage järgmine:
consul acl bootstrap- Leidke väärtus "SecretID" ja naaske kasutajaliidese juurde. Sisestage vahekaardil ACL äsja kopeeritud loa salajane ID. Kopeerige SecretID kuhugi mujale, meil läheb seda hiljem vaja.
- Nüüd lisage võtme/väärtuse paar. Selle POC jaoks lisage järgmine: võti: "custom-ns/test_key", väärtus: "Olen kohandatud-ns-i kaustas!"
Kubernetese klastri käivitamine meie rakenduse jaoks koos Consul kliendiga kui Daemonset
- Looge K8s (Kubernetes) klaster. Loome selle kiiremaks juurdepääsuks serveriga samasse tsooni ja saame kasutada sama alamvõrku, et hõlpsasti sisemiste IP-aadressidega ühenduse luua. Nimetame seda "skywiz-app-with-consul-client-poc".
- Vahemärkusena on siin hea õpetus, milleni sattusin Consul Connectiga POC Consul klastri loomisel.
- Kasutame ka Hashicorpi roolidiagrammi koos laiendatud väärtuste failiga.
- Installige ja konfigureerige Helm. Konfigureerimise sammud:
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- tüürikaart:
- Kasutage järgmist väärtusfaili (märkus, et olen enamiku keelanud):
### 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- Rakenda roolidiagrammi:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kui see proovib käivitada, vajab see Consul serveri õigusi, nii et lisame need.
- Pange tähele klastri armatuurlaual asuvat „Podi aadressivahemikku” ja vaadake tagasi meie tulemüürireeglit „skywiz-consul-server-poc”.
- Lisage kabiini aadressivahemik IP-aadresside loendisse ja avage pordid 8301 ja 8300.
- Minge konsuli kasutajaliidese ja mõne minuti pärast näete sõlmede vahekaardil meie klastrit.
Autoriseerimismeetodi konfigureerimine, integreerides konsuli Kubernetesiga
- Naaske Consul serveri kesta ja eksportige varem salvestatud luba:
export CONSUL_HTTP_TOKEN=<SecretID>- Auth-meetodi eksemplari loomiseks vajame teavet meie Kubernetese klastrist:
- 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 on base64 kodeeritud, nii et dekrüpteerige see oma lemmiktööriista abil []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Võtke "ca.crt" sertifikaat (pärast base64 dekodeerimist) ja kirjutage see faili "ca.crt".
- Nüüd looge autentimismeetod, asendades kohahoidjad äsja saadud väärtustega.
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>"- Järgmisena peame looma reegli ja lisama selle uuele rollile. Selle osa jaoks saate kasutada Consul UI-d, kuid me kasutame käsurida.
- Kirjutage reegel
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Rakenda reeglit
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- Leidke väljundist just loodud reegli ID.
- Looge roll uue reegliga.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Nüüd seostame oma uue rolli autentimismeetodi eksemplariga. Pange tähele, et "valija" lipp määrab, kas meie sisselogimistaotlus saab selle rolli. Siit leiate muid valija valikuid:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Lõpuks konfiguratsioonid
Juurdepääsuõigused
- Loo juurdepääsuõigused. Peame konsulile andma loa K8s teenusekonto loa identiteedi kontrollimiseks ja tuvastamiseks.
- Kirjutage faili järgmine :
###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- Loome juurdepääsuõigused
kubectl create -f skywiz-poc-consul-server_rbac.yamlÜhenduse loomine konsuli kliendiga
- Nagu märgitud Deemonsetiga ühenduse loomiseks on mitu võimalust, kuid liigume edasi järgmise lihtsa lahenduse juurde:
- Rakenda järgmine fail [].
### 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- Seejärel kasutage konfiguratsioonikaardi loomiseks järgmist sisseehitatud käsku []. Pange tähele, et me viitame oma teenuse nimele, vajadusel asendage see.
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}')"]}
EOFAutentimismeetodi testimine
Nüüd vaatame maagiat tegevuses!
- Looge sama ülataseme võtmega veel mitu võtmekausta (st. /sample_key) ja teie valitud väärtus. Looge uute võtmeteede jaoks sobivad poliitikad ja rollid. Sidemed teeme hiljem.
Kohandatud nimeruumi test:
- Loome oma nimeruumi:
kubectl create namespace custom-ns- Loome oma uues nimeruumis kausta. Kirjutage podi konfiguratsioon.
###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- Loo all:
kubectl create -f poc-ubuntu-custom-ns.yaml- Kui konteiner töötab, minge sinna ja installige curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Nüüd saadame konsulile sisselogimistaotluse, kasutades varem loodud autoriseerimismeetodit [].
- Sisestatud märgi vaatamiseks oma teenusekontolt toimige järgmiselt.
cat /run/secrets/kubernetes.io/serviceaccount/token- Kirjutage konteineris olevasse faili järgmine tekst:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Logi sisse!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Ülaltoodud sammude ühe reaga lõpuleviimiseks (kuna teeme mitu testi), saate teha järgmist.
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- Töötab! Vähemalt peaks. Nüüd võtke SecretID ja proovige pääseda juurde võtmele/väärtusele, millele meil peaks olema juurdepääs.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Saate base64 dekodeerida "Väärtuse" ja vaadata, et see ühtiks kasutajaliidese jaotises custom-ns/test_key oleva väärtusega. Kui kasutasite selles õpetuses ülaltoodud väärtust, oleks teie kodeeritud väärtus IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Kasutajateenuse konto test:
- Looge kohandatud teenusekonto, kasutades järgmist käsku [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Looge podi jaoks uus konfiguratsioonifail. Pange tähele, et tööjõu säästmiseks lisasin lokkide paigaldamise :)
###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- Pärast seda käivitage konteineri sees kest.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Logi sisse!
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- Luba ei antud. Oh, me unustasime lisada vastavate õigustega siduvad uued reeglid, teeme seda kohe.
Korrake ülaltoodud eelmisi samme:
a) Looge eesliitele "custom-sa/" identne eeskiri.
b) Looge roll, nimetage seda "kohandatud rolliks"
c) Lisage rollile poliitika.
- Looge reegli sidumine (võimalik ainult cli/api kaudu). Pange tähele valija lipu erinevat tähendust.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Logige uuesti sisse konteinerist "poc-ubuntu-custom-sa". Edu!
- Vaadake meie juurdepääsu custom-sa/ võtmeteele.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Samuti saate tagada, et see luba ei anna juurdepääsu kv-le jaotises "custom-ns/". Lihtsalt korrake ülaltoodud käsku pärast "custom-sa" asendamist eesliitega "custom-ns".
Luba ei antud.
Ülekatte näide:
- Väärib märkimist, et kõik reeglid siduvad vastendused lisatakse nende õigustega märgile.
- Meie konteiner "poc-ubuntu-custom-sa" on vaikenimeruumis – nii et kasutame seda teistsuguse reegli sidumiseks.
- Korrake eelmisi samme:
a) Looge vaikimisi/-klahvi eesliite jaoks identne poliitika.
b) Looge roll, pange sellele nimi "default-ns-role"
c) Lisage rollile poliitika. - Looge reeglite sidumine (võimalik ainult cli/api kaudu)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Minge tagasi meie konteinerisse "poc-ubuntu-custom-sa" ja proovige pääseda juurde kv-teele "default/".
- Luba ei antud.
Saate vaadata kasutajaliidese iga loa määratud mandaate jaotises ACL > Tokens. Nagu näete, on meie praegusel märgil ainult üks kohandatud roll. Praegu kasutatav märk genereeriti sisselogimisel ja siis oli ainult üks reegli sidumine, mis sobis. Peame uuesti sisse logima ja kasutama uut tunnust. - Veenduge, et saaksite lugeda nii "custom-sa/" kui ka "default/" kv-teelt.
Edu!
Seda seetõttu, et meie "poc-ubuntu-custom-sa" vastab "custom-sa" ja "default-ns" reegli sidumistele.
Järeldus
TTL token mgmt?
Selle kirjutamise ajal ei olnud integreeritud viisi selle autoriseerimismeetodi abil loodud žetoonide TTL-i määramiseks. See oleks suurepärane võimalus tagada konsuli volituste turvaline automatiseerimine.
TTL-iga on võimalik märk käsitsi luua:
Aegumisaeg – aeg, mil see märk tühistatakse. (Valikuline; lisatud versioonis Consul 1.5.0)- Olemas ainult käsitsi loomiseks/värskendamiseks
Loodetavasti saame lähitulevikus kontrollida žetoonide genereerimist (reegli või autoriseerimismeetodi järgi) ja lisada TTL-i.
Seni on soovitatav kasutada oma loogikas väljalogimise lõpp-punkti.
Loe ka teisi meie ajaveebi artikleid:
Allikas: www.habr.com