Tako je, nakon izlaska početkom maja 2019., Consul može izvorno ovlastiti aplikacije i usluge koje se pokreću u Kubernetesu.
U ovom vodiču ćemo kreirati korak po korak (Dokaz koncepta, PoC) koji demonstrira ovu novu funkciju. Od vas se očekuje da imate osnovno znanje o Kubernetes-u i Hashicorp-ovom konzulu. I dok možete koristiti bilo koju platformu u oblaku ili lokalno okruženje, u ovom vodiču ćemo koristiti Googleovu Cloud Platformu.
pregled
Ako odemo do , dobićemo kratak pregled njegove svrhe i slučaja upotrebe, kao i neke tehničke detalje i opšti pregled logike. Toplo preporučujem da ga pročitate barem jednom prije nego što nastavite, jer ću sada sve to objasniti i prožvakati.
Šema 1: Zvanični pregled metode autorizacije konzula
Hajde da pogledamo .
Naravno, tu ima korisnih informacija, ali nema vodiča kako se sve to zapravo koristi. Dakle, kao i svaka zdrava osoba, pretražujete internet u potrazi za smjernicama. A onda... Budi poražen. Dešava se. Hajde da popravimo ovo.
Prije nego što pređemo na kreiranje našeg POC-a, vratimo se na pregled metoda autorizacije konzula (dijagram 1) i preciziramo ga u kontekstu Kubernetesa.
arhitektura
U ovom vodiču ćemo kreirati Consul server na zasebnoj mašini koji će komunicirati sa Kubernetes klasterom sa instaliranim Consul klijentom. Zatim ćemo kreirati našu lažnu aplikaciju u pod-u i koristiti našu konfiguriranu metodu autorizacije za čitanje iz našeg skladišta ključeva/vrijednosti Consul.
Donji dijagram detaljno prikazuje arhitekturu koju kreiramo u ovom vodiču, kao i logiku metode autorizacije, koja će biti objašnjena kasnije.
Dijagram 2: Pregled metode Kubernetes autorizacije
Kratka napomena: Consul server ne mora da živi izvan Kubernetes klastera da bi ovo funkcionisalo. Ali da, može na bilo koji način.
Dakle, uzimajući Consul preglednu shemu (Šema 1) i primjenjujući Kubernetes na nju, dobijamo gornju shemu (Šema 2), a ovdje će logika biti sljedeća:
- Svaki pod će imati pridružen servisni nalog, koji sadrži JWT token generisan i poznat od strane Kubernetesa. Ovaj token je također umetnut u pod po defaultu.
- Naša aplikacija ili usluga unutar modula će pokrenuti naredbu za prijavu našem Consul klijentu. Zahtjev za prijavu će također uključivati naš token i ime posebno kreirana metoda autorizacije (kao Kubernetes). Ovaj korak #2 odgovara koraku 1 Konzulskog kruga (Dijagram 1).
- Naš Consul klijent će zatim proslediti ovaj zahtev našem Consul serveru.
- MAGIC! Ovo je mjesto gdje Consul server autentifikuje zahtjev, prikuplja identitet zahtjeva i upoređuje ga sa bilo kojim povezanim unaprijed definiranim pravilima. Ispod je još jedan dijagram koji to ilustruje. Ovaj korak odgovara koracima 3, 4 i 5 preglednog dijagrama konzula (dijagram 1).
- Naš Consul server generiše Consul token sa dozvolama u skladu sa pravilima metode autorizacije koja smo naveli (koje smo definisali) u vezi sa identitetom podnosioca zahteva. Zatim će poslati taj token nazad. Ovo odgovara koraku 6 Konzulske šeme (Dijagram 1).
- Naš klijent Consul prosljeđuje token aplikaciji ili usluzi koja je zatražila.
Naša aplikacija ili usluga sada mogu koristiti ovaj Consul token za komunikaciju s našim podacima Consul, kako je definirano privilegijama tokena.
Magija je otkrivena!
Za one od vas koji nisu zadovoljni samo sa zečićem iz šešira i želite znati kako to funkcionira...dopustite mi da vam "pokažem koliko duboko zečja rupa".
Kao što je ranije spomenuto, naš "magični" korak (Šema 2: Korak 4) je da Consul server autentifikuje zahtjev, prikupi informacije o zahtjevu i uporedi ih sa bilo kojim povezanim unaprijed definiranim pravilima. Ovaj korak odgovara koracima 3, 4 i 5 preglednog dijagrama konzula (dijagram 1). Ispod je dijagram (šema 3), čija je svrha da jasno pokaže šta se zapravo dešava ispod haube specifičan metod autorizacije Kubernetesa.
Dijagram 3: Magija je otkrivena!
- Kao početnu tačku, naš Consul klijent prosljeđuje zahtjev za prijavu na naš Consul server sa tokenom Kubernetes naloga i specifičnim imenom instance metode autorizacije koju smo kreirali ranije. Ovaj korak odgovara koraku 3 u prethodnom objašnjenju dijagrama.
- Sada konzul server (ili vođa) treba da potvrdi autentičnost primljenog tokena. Stoga će se konsultovati sa Kubernetes klasterom (preko Consul klijenta) i, uz odgovarajuće dozvole, saznaćemo da li je token originalan i ko ga poseduje.
- Potvrđeni zahtjev se zatim vraća vođi Consul-a, a na Consul serveru se traži instanca metode autorizacije sa navedenim imenom iz zahtjeva za prijavu (i Kubernetes tipa).
- Konzul vođa određuje specificiranu instancu metode autorizacije (ako je pronađena) i čita skup obavezujućih pravila koja su joj pridružena. Zatim čita ta pravila i uspoređuje ih s provjerenim atributima identiteta.
- TA-dah! Idite na korak 5 u prethodnom objašnjenju kruga.
Pokrenite Consul-server u normalnoj virtuelnoj mašini
Od sada ću uglavnom davati uputstva za kreiranje ovog POC-a, često u paragrafima, bez objašnjenja celih rečenica. Također, kao što je ranije navedeno, koristit ću GCP za kreiranje cjelokupne infrastrukture, ali istu infrastrukturu možete kreirati bilo gdje drugdje.
- Pokrenite virtuelnu mašinu (instancu / server).
- Kreirajte pravilo zaštitnog zida (sigurnosnu grupu u AWS-u):
- Volim da dodijelim isto ime stroja pravilu i mrežnoj oznaci, u ovom slučaju "skywiz-consul-server-poc".
- Pronađite IP adresu vašeg lokalnog računara i dodajte je na listu izvornih IP adresa kako bismo mogli pristupiti korisničkom interfejsu (UI).
- Otvorite port 8500 za korisničko sučelje. Kliknite na Kreiraj. Uskoro ćemo ponovo promijeniti ovaj firewall [].
- Dodajte pravilo zaštitnog zida instanci. Vratite se na VM kontrolnu tablu na Consul serveru i dodajte "skywiz-consul-server-poc" u polje mrežnih oznaka. Kliknite na Save.
- Instalirajte Consul na virtuelnu mašinu, proverite ovde. Zapamtite da vam je potrebna verzija Consul ≥ 1.5 [link]
- Kreirajmo jedan čvor Consul - konfiguracija je sljedeća.
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- Za detaljniji vodič o instaliranju Consul-a i postavljanju klastera s 3 čvora, pogledajte .
- Kreirajte fajl /etc/consul.d/agent.json ovako []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Pokrenite naš Consul server:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Trebali biste vidjeti gomilu izlaza i na kraju "... ažuriranje blokirano od strane ACL-ova".
- Pronađite eksternu IP adresu Consul servera i otvorite pretraživač sa tom IP adresom na portu 8500. Provjerite da li se otvori korisničko sučelje.
- Pokušajte dodati par ključ/vrijednost. Mora da je došlo do greške. To je zato što smo učitali Consul server sa ACL-om i odbili sva pravila.
- Vratite se u svoju ljusku na Consul serveru i pokrenite proces u pozadini ili na neki drugi način da bi funkcionirao i upišite sljedeće:
consul acl bootstrap- Pronađite vrijednost "SecretID" i vratite se na korisničko sučelje. Na kartici ACL unesite tajni ID tokena koji ste upravo kopirali. Kopirajte SecretID negdje drugdje, trebat će nam kasnije.
- Sada dodajte par ključ/vrijednost. Za ovaj POC dodajte sljedeće: ključ: "custom-ns/test_key", vrijednost: "Ja sam u custom-ns folderu!"
Pokretanje Kubernetes klastera za našu aplikaciju sa klijentom Consul kao Daemonset
- Kreirajte klaster K8s (Kubernetes). Napravićemo ga u istoj zoni kao i server radi bržeg pristupa i tako možemo koristiti istu podmrežu za jednostavno povezivanje sa internim IP adresama. Nazvat ćemo ga "skywiz-app-with-consul-client-poc".
- Kao sporedna napomena, evo dobrog vodiča na koji sam naišao prilikom postavljanja Consul POC klastera sa Consul Connect-om.
- Također ćemo koristiti Hashicorp helm chart sa proširenom datotekom vrijednosti.
- Instalirajte i konfigurirajte Helm. Koraci konfiguracije:
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- kormilarska karta:
- Koristite sljedeću datoteku vrijednosti (imajte na umu da sam većinu onemogućio):
### 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- Primijenite grafikon kormila:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kada pokuša da se pokrene, trebaće mu dozvole za Consul server, pa hajde da ih dodamo.
- Obratite pažnju na "opseg pod adresa" koji se nalazi na kontrolnoj tabli klastera i vratite se na naše pravilo zaštitnog zida "skywiz-consul-server-poc".
- Dodajte raspon adresa za pod na listu IP adresa i otvorite portove 8301 i 8300.
- Idite na Consul UI i za nekoliko minuta vidjet ćete da se naš klaster pojavljuje na kartici čvorova.
Prilagođavanje metode autorizacije integracijom Consula sa Kubernetesom
- Vratite se na ljusku Consul servera i izvezite token koji ste ranije sačuvali:
export CONSUL_HTTP_TOKEN=<SecretID>- Potrebne su nam informacije iz našeg Kubernetes klastera za instanciranje metode auth:
- 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 kodiran base64, pa ga dešifrirajte vašim omiljenim alatom []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Uzmite “ca.crt” certifikat (nakon base64 dekodiranja) i stavite ga u “ca.crt” datoteku.
- Sada instancirajte metodu auth, zamjenjujući rezervirane mjesta vrijednostima koje ste upravo primili.
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>"- Zatim moramo kreirati pravilo i priložiti ga novoj ulozi. Za ovaj dio možete koristiti Consul UI, ali mi ćemo koristiti komandnu liniju.
- Napišite pravilo
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Primijenite pravilo
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- Pronađite ID pravila koje ste upravo kreirali iz izlaza.
- Kreirajte ulogu s novim pravilom.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Sada ćemo našu novu ulogu povezati s instancom metode auth. Imajte na umu da oznaka "selektor" određuje da li će naš zahtjev za prijavu primiti ovu ulogu. Ovdje provjerite ostale opcije selektora:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Konfiguracije na kraju
Prava pristupa
- Kreirajte dozvole. Moramo dati dozvolu Konzulu da provjeri i identifikuje identitet K8s tokena usluge.
- Napišite sljedeće u datoteku :
###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- Kreirajmo prava pristupa
kubectl create -f skywiz-poc-consul-server_rbac.yamlPovezivanje na Consul Client
- Kao što je navedeno , postoji nekoliko opcija za povezivanje sa daemonsetom, ali preći ćemo na sljedeće jednostavno rješenje:
- Primijenite sljedeći fajl [].
### 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- Zatim koristite sljedeću ugrađenu naredbu da kreirate configmap []. Imajte na umu da se pozivamo na naziv naše usluge, promijenite ga ako je potrebno.
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}')"]}
EOFTestiranje metode auth
A sada da vidimo magiju na djelu!
- Kreirajte još nekoliko ključnih foldera sa istim ključem najvišeg nivoa (tj. /sample_key) i vrijednost po vašem izboru. Kreirajte odgovarajuće politike i uloge za nove ključne puteve. Vezivanje ćemo uraditi kasnije.
Test prilagođenog imenskog prostora:
- Kreirajmo vlastiti imenski prostor:
kubectl create namespace custom-ns- Kreirajmo pod u našem novom imenskom prostoru. Napišite konfiguraciju za 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- Kreiraj pod:
kubectl create -f poc-ubuntu-custom-ns.yaml- Kada se kontejner pokrene, idite tamo i instalirajte curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Sada ćemo poslati zahtjev za prijavu Konzulu koristeći metodu autorizacije koju smo kreirali ranije [].
- Da vidite uneseni token sa vašeg servisnog računa:
cat /run/secrets/kubernetes.io/serviceaccount/token- Napišite sljedeće u datoteku unutar kontejnera:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Ulogovati se!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Da biste pokrenuli gore navedene korake u jednom redu (pošto ćemo izvoditi više testova), možete učiniti sljedeće:
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- Works! Trebalo bi, barem. Sada uzmite SecretID i pokušajte pristupiti ključu/vrijednosti kojem trebamo imati pristup.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Možete dekodirati "Value" base64 i vidjeti da odgovara vrijednosti u custom-ns/test_key u korisničkom sučelju. Ako ste koristili istu vrijednost datu ranije u ovom vodiču, vaša kodirana vrijednost bi bila IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Test korisničkog računa:
- Kreirajte prilagođeni ServiceAccount sa sljedećom naredbom [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Kreirajte novu konfiguracijsku datoteku za pod. Imajte na umu da sam uključio instalaciju curl kako bih uštedio rad :)
###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- Nakon toga pokrenite školjku unutar kontejnera.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Ulogovati 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- Dozvola odbijena. Oh, zaboravili smo dodati novo vezivanje pravila sa odgovarajućim dozvolama, uradimo to sada.
Ponovite prethodne korake iznad:
a) Kreirajte identičnu Politiku za prefiks "custom-sa/".
b) Kreirajte ulogu, nazovite je "custom-sa-role"
c) Priložiti Politiku Ulozi.
- Kreirajte Vezivanje pravila (moguće samo iz cli/api). Obratite pažnju na različitu vrijednost zastavice selektora.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Pokušajte se ponovo prijaviti iz "poc-ubuntu-custom-sa" kontejnera. Uspjeh!
- Provjerite naš pristup putanji custom-sa/ key.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Također možete osigurati da ovaj token ne daje pristup kv-u u "custom-ns/". Samo ponovite gornju naredbu nakon što zamenite "custom-sa" prefiksom "custom-ns".
Dozvola odbijena.
Primjer prekrivanja:
- Vrijedi napomenuti da će sva podudaranja koja obavezuju pravila biti dodana tokenu sa ovim pravima.
- Naš "poc-ubuntu-custom-sa" kontejner je u podrazumevanom imenskom prostoru - pa hajde da ga koristimo za još jedno vezivanje pravila.
- Ponovite prethodne korake:
a) Kreirajte identičnu Politiku za prefiks ključa "default/".
b) Kreirajte ulogu, nazovite je “default-ns-role”
c) Priložiti Politiku Ulozi. - Kreirajte Vezivanje pravila (moguće samo iz 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"'- Vratite se na naš "poc-ubuntu-custom-sa" kontejner i pokušajte pristupiti "default/" kv putanji.
- Dozvola odbijena.
Navedene vjerodajnice za svaki token možete vidjeti u korisničkom sučelju pod ACL > Tokeni. Kao što vidite, postoji samo jedna "custom-sa-role" vezana za naš trenutni token. Token koji trenutno koristimo je generiran kada smo se prijavili i tada je postojalo samo jedno vezivanje pravila koje se podudaralo. Moramo se ponovo prijaviti i koristiti novi token. - Uvjerite se da možete pročitati i "custom-sa/" i "default/" kv putanje.
Uspjeh!
To je zato što se naš "poc-ubuntu-custom-sa" poklapa sa vezama pravila "custom-sa" i "default-ns".
zaključak
TTL token mgmt?
Od ovog pisanja, ne postoji integrirani način za određivanje TTL-a za tokene generirane ovom metodom autorizacije. Bila bi to fantastična prilika da se Konzulu obezbijedi sigurna automatizacija autorizacije.
Postoji opcija da ručno kreirate token sa TTL:
Vrijeme isteka - Vrijeme kada će ovaj token biti opozvan. (Neobavezno; dodano u Consul 1.5.0)- Postoji samo za ručno kreiranje/ažuriranje
Nadamo se da ćemo uskoro moći kontrolirati kako se tokeni generiraju (za svako pravilo ili metodu autorizacije) i dodati TTL.
Do tada se predlaže korištenje krajnje točke odjave u svojoj logici.
Pročitajte i druge članke na našem blogu:
izvor: www.habr.com