Tako je, nakon puštanja na slobodu početkom svibnja 2019. u Consulu možete autorizirati aplikacije i usluge koje se izvode u Kubernetesu nativno.
U ovom vodiču ćemo kreirati korak po korak (Dokaz koncepta, PoC) koji demonstrira ovu novu značajku. Od vas se očekuje da imate osnovno znanje o Kubernetesu i Hashicorpovom Consulu. Iako možete koristiti bilo koju platformu u oblaku ili lokalno okruženje, u ovom ćemo vodiču koristiti Googleovu platformu u oblaku.
Pregled
Ako odemo na , dobit ćemo brzi pregled njegove namjene i slučaja uporabe, kao i neke tehničke detalje i opći pregled logike. Toplo preporučam da ga pročitate barem jednom prije nego što nastavite, jer ću sada sve objašnjavati i žvakati.
Dijagram 1: Službeni pregled metode ovlaštenja konzula
Pogledajmo unutra .
Naravno, ondje ima korisnih informacija, ali nema vodiča o tome kako ih sve zapravo koristiti. Dakle, kao svaka zdrava osoba, pretražujete Internet u potrazi za smjernicama. A onda... Ne uspijete. Događa se. Popravimo ovo.
Prije nego što prijeđemo na kreiranje našeg POC-a, vratimo se pregledu Consulovih metoda autorizacije (Dijagram 1) i doradimo ga u kontekstu Kubernetesa.
arhitektura
U ovom vodiču ćemo kreirati Consul poslužitelj na zasebnom računalu koji će komunicirati s Kubernetes klasterom s instaliranim Consul klijentom. Zatim ćemo kreirati našu lažnu aplikaciju u modulu i koristiti našu konfiguriranu metodu autorizacije za čitanje iz naše Consul pohrane ključeva/vrijednosti.
Donji dijagram detaljno opisuje arhitekturu koju stvaramo u ovom vodiču, kao i logiku iza metode autorizacije, koja će biti objašnjena kasnije.
Dijagram 2: Pregled metode autorizacije Kubernetesa
Kratka napomena: poslužitelj Consul ne mora živjeti izvan Kubernetes klastera da bi ovo funkcioniralo. Ali da, može i ovako i onako.
Dakle, uzimajući Consul pregledni dijagram (Dijagram 1) i primjenjujući Kubernetes na njega, dobivamo gornji dijagram (Dijagram 2), a logika je sljedeća:
- Svaki pod imat će priložen račun usluge koji sadrži JWT token koji je generirao i poznat Kubernetesu. Ovaj je token također umetnut u pod prema zadanim postavkama.
- Naša aplikacija ili usluga unutar modula pokreće naredbu za prijavu našem Consul klijentu. Zahtjev za prijavu također će sadržavati naš token i ime posebno stvorena način autorizacije (tip Kubernetes). Ovaj korak #2 odgovara koraku 1 Consul dijagrama (shema 1).
- Naš Consul klijent će zatim proslijediti ovaj zahtjev našem Consul serveru.
- MAGIJA! Ovdje Consul poslužitelj provjerava autentičnost zahtjeva, prikuplja informacije o identitetu zahtjeva i uspoređuje ga sa svim povezanim unaprijed definiranim pravilima. Ispod je još jedan dijagram koji to ilustrira. Ovaj korak odgovara koracima 3, 4 i 5 preglednog dijagrama Consul (Dijagram 1).
- Naš Consul poslužitelj generira Consul token s dopuštenjima u skladu s našim određenim pravilima metode autorizacije (koja smo definirali) u vezi s identitetom podnositelja zahtjeva. Zatim će poslati taj token natrag. Ovo odgovara koraku 6 Consul dijagrama (Dijagram 1).
- Naš klijent Consul prosljeđuje token aplikaciji ili usluzi koja zahtijeva.
Naša aplikacija ili usluga sada može koristiti ovaj Consul token za komunikaciju s našim Consul podacima, kako je određeno povlasticama tokena.
Čarolija je otkrivena!
Za one od vas koji nisu zadovoljni samo zecom iz šešira i žele znati kako to funkcionira... dopustite mi da vam "pokažem koliko duboko zečja rupa".
Kao što je ranije spomenuto, naš "čarobni" korak (Slika 2: Korak 4) je mjesto gdje Consul poslužitelj provjerava autentičnost zahtjeva, prikuplja informacije o zahtjevu i uspoređuje ih sa svim povezanim unaprijed definiranim pravilima. Ovaj korak odgovara koracima 3, 4 i 5 preglednog dijagrama Consul (Dijagram 1). Ispod je dijagram (Dijagram 3), čija je svrha jasno pokazati što se zapravo događa ispod haube specifična Kubernetes metoda autorizacije.
Dijagram 3: Magija je otkrivena!
- Kao početnu točku, naš klijent Consul prosljeđuje zahtjev za prijavu našem poslužitelju Consul s tokenom Kubernetes računa i specifičnim nazivom instance metode autorizacije koja je ranije stvorena. Ovaj korak odgovara koraku 3 u prethodnom objašnjenju kruga.
- Sada Consul server (ili voditelj) treba provjeriti autentičnost primljenog tokena. Stoga će konzultirati Kubernetes klaster (putem Consul klijenta) i uz odgovarajuće dozvole saznat ćemo je li token originalan i kome pripada.
- Potvrđeni zahtjev se zatim vraća voditelju Consula, a Consul poslužitelj traži instancu metode autorizacije s navedenim imenom iz zahtjeva za prijavu (i vrste Kubernetes).
- Vođa konzula utvrđuje navedenu instancu metode autorizacije (ako je pronađena) i čita skup obvezujućih pravila koja su joj priložena. Zatim čita ta pravila i uspoređuje ih s potvrđenim atributima identiteta.
- TA-da! Prijeđimo na korak 5 u prethodnom objašnjenju kruga.
Pokrenite Consul-poslužitelj na običnom virtualnom računalu
Od sada ću uglavnom davati upute o tome kako izraditi ovaj POC, često u točkama, bez potpunih objašnjenja rečenice. Također, kao što je ranije navedeno, koristit ću GCP za stvaranje cijele infrastrukture, ali istu infrastrukturu možete stvoriti bilo gdje drugdje.
- Pokrenite virtualni stroj (instanca/poslužitelj).
- Napravite pravilo za vatrozid (sigurnosna grupa u AWS-u):
- Volim dodijeliti isto ime stroja i pravilu i mrežnoj oznaci, u ovom slučaju "skywiz-consul-server-poc".
- Pronađite IP adresu svog lokalnog računala i dodajte je na popis izvornih IP adresa kako bismo mogli pristupiti korisničkom sučelju (UI).
- Otvorite priključak 8500 za korisničko sučelje. Pritisnite Stvori. Uskoro ćemo ponovo promijeniti ovaj vatrozid [].
- Instanci dodajte pravilo vatrozida. Vratite se na VM nadzornu ploču na Consul Serveru i dodajte “skywiz-consul-server-poc” u polje mrežnih oznaka. Pritisnite Spremi.
- Instalirajte Consul na virtualni stroj, provjerite ovdje. Ne zaboravite da vam je potrebna Consul verzija ≥ 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 Consula i postavljanju klastera od 3 čvora, pogledajte .
- Napravite datoteku /etc/consul.d/agent.json na sljedeći način []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Pokrenite naš Consul poslužitelj:
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 hrpu izlaza i završiti s "... ažuriranje blokirano ACL-ovima."
- Pronađite vanjsku IP adresu Consul poslužitelja i otvorite preglednik s ovom IP adresom na portu 8500. Provjerite otvara li se korisničko sučelje.
- Pokušajte dodati par ključ/vrijednost. Mora da postoji greška. To je zato što smo učitali Consul poslužitelj s ACL-om i onemogućili sva pravila.
- Vratite se u svoju ljusku na Consul poslužitelju i pokrenite proces u pozadini ili na neki drugi način da ga pokrenete i unesite 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 mapi custom-ns!”
Pokretanje Kubernetes klastera za našu aplikaciju s Consul klijentom kao Daemonsetom
- Napravite K8s (Kubernetes) klaster. Stvorit ćemo ga u istoj zoni kao i poslužitelj radi bržeg pristupa i tako možemo koristiti istu podmrežu za jednostavno povezivanje s internim IP adresama. Nazvat ćemo ga "skywiz-aplikacija-s-konzulom-klijent-poc".
- Kao usputna napomena, ovdje je dobar vodič na koji sam naišao dok sam postavljao POC Consul klaster s Consul Connectom.
- Također ćemo koristiti Hashicorp helm chart s proširenom datotekom vrijednosti.
- Instalirajte i konfigurirajte Helm. Konfiguracijski koraci:
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- karta kormila:
- 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- Primijeni dijagram kormila:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kada se pokuša pokrenuti, trebat će mu dozvole za Consul poslužitelj, pa ih dodamo.
- Obratite pažnju na "Pod Address Range" koji se nalazi na nadzornoj ploči klastera i pogledajte naše pravilo vatrozida "skywiz-consul-server-poc".
- Dodajte raspon adresa za modul na popis IP adresa i otvorite portove 8301 i 8300.
- Idite na Consul UI i nakon nekoliko minuta vidjet ćete da se naš klaster pojavljuje na kartici čvorova.
Konfiguriranje metode autorizacije integracijom Consula s Kubernetesom
- Vratite se na ljusku poslužitelja Consul i izvezite token koji ste ranije spremili:
export CONSUL_HTTP_TOKEN=<SecretID>- Trebat će nam informacije iz našeg Kubernetes klastera za stvaranje instance auth metode:
- kubernetes-domaćin
kubectl get endpoints | grep kubernetes- kubernetes-uslužni-račun-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 base64 kodiran, pa ga dešifrirajte koristeći svoj omiljeni alat []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Uzmite certifikat “ca.crt” (nakon base64 dekodiranja) i zapišite ga u datoteku “ca.crt”.
- Sada instancirajte metodu autentifikacije, zamjenjujući rezervirana 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 stvoriti pravilo i priložiti ga novoj ulozi. Za ovaj dio možete koristiti Consul UI, ali mi ćemo koristiti naredbeni redak.
- Napiši 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 stvorili iz izlaza.
- Stvorite 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 auth metode. Imajte na umu da oznaka "selektor" određuje hoće li naš zahtjev za prijavu dobiti ovu ulogu. Ovdje provjerite ostale mogućnosti odabira:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Na kraju konfiguracije
Prava pristupa
- Stvorite prava pristupa. Moramo dati konzulu dopuštenje za provjeru i identifikaciju identiteta tokena računa usluge K8s.
- Zapiš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 s Consul klijentom
- Kao što je navedeno Postoji nekoliko opcija za povezivanje s daemonsetom, ali prijeći ćemo na sljedeće jednostavno rješenje:
- Primijenite sljedeću datoteku [].
### 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 upotrijebite sljedeću ugrađenu naredbu za stvaranje configmapa []. Imajte na umu da se pozivamo na naziv naše usluge, zamijenite 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 autentifikacije
Sada da vidimo magiju na djelu!
- Stvorite još nekoliko ključnih mapa s istim ključem najviše razine (tj. /sample_key) i vrijednost po vašem izboru. Stvorite odgovarajuće politike i uloge za nove ključne staze. Poslije ćemo napraviti uvezivanje.
Test prilagođenog prostora imena:
- Kreirajmo vlastiti prostor imena:
kubectl create namespace custom-ns- Kreirajmo pod u našem novom prostoru imena. 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- Izradi pod:
kubectl create -f poc-ubuntu-custom-ns.yaml- Nakon što se spremnik 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 Consulu koristeći metodu autorizacije koju smo kreirali ranije [].
- Za pregled unesenog tokena s vašeg računa usluge:
cat /run/secrets/kubernetes.io/serviceaccount/token- Napišite sljedeće u datoteku unutar spremnika:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Prijaviti se!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Da biste izvršili gore navedene korake u jednom retku (budući da ć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- Djela! Barem bi trebalo. Sada uzmite SecretID i pokušajte pristupiti ključu/vrijednosti kojem bismo trebali 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 base64 dekodirati "Vrijednost" i vidjeti da odgovara vrijednosti u custom-ns/test_key u korisničkom sučelju. Ako ste koristili istu vrijednost iznad u ovom vodiču, vaša kodirana vrijednost bi bila IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Test računa korisničke usluge:
- Stvorite prilagođeni ServiceAccount pomoću sljedeće naredbe [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Stvorite novu konfiguracijsku datoteku za pod. Imajte na umu da sam uključio instalaciju kovrča 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 spremnika.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Prijaviti 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- Dopuštenje odbijeno. Oh, zaboravili smo dodati nova pravila obvezujuća s odgovarajućim dopuštenjima, učinimo to sada.
Ponovite prethodne korake iznad:
a) Napravite identičnu Politiku za prefiks “custom-sa/”.
b) Stvorite ulogu, nazovite je "custom-sa-role"
c) Priložite Politiku ulozi.
- Napravite povezivanje pravila (moguće samo iz cli/api). Obratite pažnju na različito značenje zastavice za odabir.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Ponovno se prijavite iz spremnika "poc-ubuntu-custom-sa". Uspjeh!
- Provjerite naš pristup custom-sa/ ključnom putu.
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 dopušta pristup kv u "custom-ns/". Samo ponovite gornju naredbu nakon što ste "custom-sa" zamijenili prefiksom "custom-ns".
Dopuštenje odbijeno.
Primjer preklapanja:
- Vrijedno je napomenuti da će sva preslikavanja koja obvezuju pravila biti dodana tokenu s ovim pravima.
- Naš spremnik "poc-ubuntu-custom-sa" nalazi se u zadanom prostoru imena - pa ga upotrijebimo za drugačije vezanje pravila.
- Ponovite prethodne korake:
a) Napravite identična pravila za prefiks ključa "default/".
b) Napravite ulogu, nazovite je "default-ns-role"
c) Priložite Politiku ulozi. - Stvaranje povezivanja 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š spremnik "poc-ubuntu-custom-sa" i pokušajte pristupiti kv stazi "default/".
- Dopuštenje odbijeno.
Navedene vjerodajnice za svaki token možete vidjeti u korisničkom sučelju pod ACL > Tokeni. Kao što vidite, naš trenutni token ima samo jednu "prilagođenu-sa-ulogu" pridruženu sebi. Token koji trenutačno koristimo generiran je kad smo se prijavili i postojalo je samo jedno vezanje pravila koje je tada odgovaralo. Moramo se ponovno prijaviti i koristiti novi token. - Provjerite možete li čitati s kv staza "custom-sa/" i "default/".
Uspjeh!
To je zato što naš "poc-ubuntu-custom-sa" odgovara vezivanju pravila "custom-sa" i "default-ns".
Zaključak
Upravljanje TTL tokenom?
U vrijeme pisanja ovog teksta ne postoji integrirani način za određivanje TTL-a za tokene generirane ovom metodom autorizacije. Bila bi to fantastična prilika za sigurnu automatizaciju konzulske autorizacije.
Postoji opcija za ručno stvaranje tokena s TTL-om:
Vrijeme isteka - vrijeme u kojem će ovaj token biti opozvan. (Izborno; dodano u Consul 1.5.0)- Postoji samo za ručno kreiranje/ažuriranje
Nadamo se da ćemo u bliskoj budućnosti moći kontrolirati kako se tokeni generiraju (po pravilu ili metodi autorizacije) i dodati TTL.
Do tada se predlaže da u svojoj logici koristite krajnju točku odjave.
Također pročitajte ostale članke na našem blogu:
Izvor: www.habr.com