🥇Uvod u Hashicorp Consulovu Kubernetes autorizaciju

Sve je točno, nakon objave Hashicorp Consul 1.5.0 početkom svibnja 2019. godine u Consulu je moguće izvršiti autorizaciju aplikacija i servisa pokrenutih na Kubernetesu, nativno.

U ovom vodiču ćemo korak po korak izraditi POC (Provjera koncepta (Proof of concept, PoC — dokaz [izvedivosti] koncepta — napomena prev.), demonstrirajući ovu novu funkcionalnost. Očekuju se osnovna znanja o Kubernetesu i Hashicorpovom Consulu. Iako možete koristiti bilo koju cloud platformu ili lokalno okruženje, u ovom vodiču ćemo koristiti Googleovu Cloud Platformu.

Pregled

Ako pređemo na dokumentaciju Consula o njegovoj metodi autorizacije, dobit ćemo kratak pregled svog namjena i načina korištenja, kao i neke tehničke detalje i opći pregled logike. Toplo preporučujem da je pročitate barem jednom prije nego nastavite, jer ću sve to objašnjavati i razrađivati.

Shema 1: Službeni pregled metode autorizacije Consula

Pogledajmo u dokumentaciju za specifičnu metodu autorizacije Kubernetes.

Naravno, postoje korisne informacije, ali nema vodiča o tome kako točno sve to koristiti. Zato, kao svaka razumna osoba, pretražujete Internet u potrazi za vodičem. A onda… doživite neuspjeh. Tako to ide. Ispravimo to.

Prije nego što pređemo na izradu našeg POC-a, vratimo se na pregled metoda autorizacije Consula (Shema 1) i prilagodimo ga u kontekstu Kubernetes.

Arhitektura

U ovom vodiču ćemo izraditi Consul server na zasebnom računalu koje će komunicirati s Kubernetes klasterom s instaliranim Consul klijentom. Zatim ćemo stvoriti našu lažnu aplikaciju u podu i koristiti naš podešeni metod autorizacije za čitanje iz naše Consul key/value pohrane.

Shema u nastavku detaljno prikazuje arhitekturu koju stvaramo u ovom vodiču, kao i logiku metode autorizacije koja će biti objašnjena kasnije.

Shema 2: Pregled metode autorizacije u Kubernetesu

Mala napomena: Consul server ne mora živjeti izvan Kubernetes klastera da bi to funkcioniralo. Ali da, može i ovako i onako.

Dakle, uzimajući preglednu shemu Consula (Shema 1) i primjenjujući je na Kubernetes, dobivamo shemu iznad (Shema 2), a logika će biti sljedeća:

Svakom podu bit će dodan servisni račun s JWT tokenom koji je generiran i poznat Kubernetesu. Ovaj token također se ubacuje u pod prema zadanim postavkama.
Naša aplikacija ili servis unutar poda pokreće komandni poziv našim Consul klijentom. U zahtjevu za prijavu također će biti naveden naš token i ime posebno stvorene metode autorizacije (tipa Kubernetes). Ovaj korak br. 2 odgovara koraku 1 u Consul shemi (Shema 1).
Naš Consul klijent tada usmjerava ovaj zahtjev našem Consul serveru.
MAGIJA! Ovdje Consul server provjerava autentičnost zahtjeva, prikupljajući informacije o identitetu zahtjeva i uspoređujući ih s bilo kojim pripadajućim predodređenim pravilima. Ispod je još jedna shema koja to ilustrira. Ovaj korak odgovara koracima 3, 4 i 5 u pregledu Consul sheme (Shema 1).
Naš Consul server generira Consul token s dopuštenjima u skladu s pravilima autorizacijske metode (koje smo definirali) za identitet koji je zatražio. Zatim se taj token vraća. To odgovara koraku 6 u Consul shemi (Shema 1).
Naš Consul klijent preusmjerava token zatražujućoj aplikaciji ili servisu.

Naša aplikacija ili servis sada mogu koristiti ovaj Consul token za komunikaciju s našim Consul podacima, kako je određeno privilegijama tokena.

Magija otkrivena!

Za one od vas koji nisu zadovoljni samo zekom iz šešira i žele znati kako to funkcionira… dopustite mi da vam pokažem koliko je duboka zečina rupa».

Kao što je ranije spomenuto, naš 'čarobni' korak (Shema 2: Korak 4) je da Consul server provjerava autentičnost zahtjeva, prikuplja informacije o zahtjevu i uspoređuje ih s bilo kojim pripadajućim predodređenim pravilima. Ovaj korak odgovara koracima 3, 4 i 5 u pregledu Consul sheme (Shema 1). Ispod je shema (Shema 3) čija je svrha prikazati što se zapravo događa ispod haube određene metode autorizacije Kubernetes.

Shema 3: Magija otkrivena!

Kao točka polazišta, naš Consul klijent preusmjerava zahtjev za prijavu na naš Consul server s Kubernetes računom tokenom i specifičnim imenom instance autorizacijske metode koja je ranije stvorena. Ovaj korak odgovara koraku 3 u prethodnom objašnjenju sheme.
Sada Consul poslužitelju (ili vođi) treba provjeriti autentičnost primljenog tokena. Stoga će se konzultirati s Kubernetes klasterom (putem Consul klijenta) i, ako postoje odgovarajuće dozvole, utvrditi je li token autentičan i kome pripada.
Zatim se provjereni zahtjev vraća vođi Consul-a, a na Consul poslužitelju se pretražuje instanca metode autorizacije s navedenim imenom iz zahtjeva za prijavu (i tipa Kubernetes).
Vođa Consul-a određuje navedenu instancu metode autorizacije (ako je pronađena) i čita skup pravila povezivanja koja su mu priložena. Zatim čita ta pravila i uspoređuje ih s provjerenim atributima identiteta.
Evo! Idemo na korak 5 u prethodnom objašnjenju dijagrama.

Pokrenite Consul poslužitelj na običnoj virtualnoj mašini.

Od ovog trenutka dalje, uglavnom ću davati upute za izradu ovog POC-a, često u stavcima, bez objašnjivih cijelih rečenica. Također, kao što je navedeno ranije, koristit ću GCP za izradu cijele infrastrukture, ali možete izraditi istu infrastrukturu bilo gdje drugdje.

Pokrenite virtualnu mašinu (instancu / poslužitelj).

Stvorite pravilo za vatrozid (grupa sigurnosti u AWS-u):
Sviđa mi se dodijeliti isto ime stroju pravilu i mrežnoj oznaci, u ovom slučaju to je «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 port 8500 za UI. Kliknite Create (Stvori). Uskoro ćemo ponovno promijeniti ovaj vatrozid [link].
Dodajte pravilo za vatrozid instanci. Vratite se na nadzornu ploču VM-a na Consul poslužitelju i dodajte «skywiz-consul-server-poc» u polje mrežnih oznaka. Kliknite Save (Spremi).

Instalirajte Consul na virtualnu mašinu, provjerite ovdje. Zapamtite da vam je potrebna verzija Consul ≥ 1.5 [link]
Stvorimo single node 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

Detajniji vodič za instalaciju Consul-a i postavljanje klastera od 3 nodova sm. ovdje.
Stvorite datoteku /etc/consul.d/agent.json na sljedeći način [link]:

### /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 izlaznih podataka i na kraju ćete naići na „… update blocked by ACLs”.
Pronađite javnu IP adresu Consul servera i otvorite preglednik s tom IP adresom na portu 8500. Provjerite da se UI otvara.
Pokušajte dodati nekoliko ključ/vrijednost. Trebala bi se pojaviti pogreška. To se događa jer smo učitali Consul server s ACL-om i zabranili sve pravila.
Vratite se u svoju ljusku na Consul serveru i pokrenite proces u pozadini ili bilo koji drugi način da radi, a zatim unesite sljedeće:

consul acl bootstrap

Pronađite vrijednost „SecretID” i vratite se u UI. Na kartici „ACL” unesite tajni identifikator tokena koji ste upravo kopirali. Kopirajte SecretID negdje drugdje, trebat će nam kasnije.
Sada dodajte nekoliko ključ/vrijednost. Za ovaj POC dodajmo sljedeće: ključ: „custom-ns/test_key”, vrijednost: „Ja sam u custom-ns direktoriju!”

Pokretanje Kubernetes klastera za našu aplikaciju s Consul klijentom kao Daemonset.

Stvorite K8s (Kubernetes) klaster. Stvorit ćemo ga u istoj zoni kao i server za brži pristup i kako bismo mogli koristiti istu podmrežu za jednostavno povezivanje s unutarnjim IP adresama. Nazvat ćemo ga „skywiz-app-with-consul-client-poc”.

Kao napomena, evo dobrog vodiča s kojim sam naišao prilikom postavljanja POC Consul klastera s Consul Connect.
Također ćemo koristiti Hashicorp helm chart s proširenim 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

helm chart: https://www.consul.io/docs/platform/k8s/helm.html
Koristite sljedeću datoteku vrijednosti (primijetite da sam većinu onemogućen):

### 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 helm chart:

.\/helm install -f poc-helm-consul-values.yaml .\/consul-helm - name skywiz-app-with-consul-client-poc

Prilikom pokušaja pokretanja, trebat će mu dozvole za Consul server, pa dodajmo te dozvole.
Obratite pozornost na „raspon adresa Pod” koji se nalazi na upravljačkoj ploči klastera i vratite se našem pravilu za vatrozid „skywiz-consul-server-poc”.
Dodajte raspon adresa za pod na listu IP adresa i otvorite portove 8301 i 8300.

Idite na Consul UI, a nakon nekoliko minuta vidjet ćete da se naš klaster pojavljuje na kartici čvorova.

Postavite metodu autorizacije integrirajući Consul s Kubernetesom.

Vratite se u ljusku Consul servera i izvezite token koji ste prethodno pohranili:

export CONSUL_HTTP_TOKEN=

Treba nam informacija iz našeg Kubernetes klastera kako bismo stvorili instancu metoda auth:
kubernetes-host

kubectl get endpoints | grep kubernetes

kubernetes-service-account-jwt

kubectl get sa -consul-client -o yaml | grep "- name:" 
kubectl get secret  -o yaml | grep token:

Token je kodiran u base64, stoga ga dešifrirajte pomoću svog omiljenog alata [link]
kubernetes-ca-cert

kubectl get secret  -o yaml | grep ca.crt:

Zapošljite certifikat "ca.crt" (nakon dekodiranja sa base64) i upišite ga u datoteku "ca.crt".
Sada stvorite instancu metoda auth, zamjenjujući placeholder-e s vrijednostima koje ste upravo dobili.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "Ovo je auth metoda koja koristi kubernetes za klaster skywiz-app-with-consul-client-poc" 
-kubernetes-host "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

Dalje moramo stvoriti pravilo i povezati ga s novom ulogom. Ovu dio možete koristiti Consul UI, ali ćemo koristiti naredbeni redak.
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 "Ovo je primjer pravila za kv na custom-ns/" 
-rules @kv-custom-ns-policy.hcl

Pronađite identifikator pravila koje ste upravo stvorili iz izlaznih podataka.
Stvorite ulogu s novim pravilom.

consul acl role create 
-name "custom-ns-role" 
-description "Ovo je primjer uloge za custom-ns namespace" 
-policy-id

Sada ćemo povezati našu novu ulogu s instancom metoda auth. Imajte na umu da zastavica „selector“ određuje hoće li naš zahtjev za pristup dobiti ovu ulogu. Provjerite ovdje druge opcije selektora: https://www.consul.io/docs/acl/auth-methods/kubernetes.html#trusted-identity-attributes

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 za kraj

Prava pristupa

Stvorite prava pristupa. Moramo dati dopuštenje Consulu da provjeri i identificira vjerodajnice tokena računa usluge K8s.
Zapišite u datoteku sljedeće [link]:

###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

Stvorimo prava pristupa

kubectl create -f skywiz-poc-consul-server_rbac.yaml

Povezivanje s Consul Client

Kao što je spomenuto ovdje, postoji nekoliko opcija za povezivanje s daemonset-om, ali ćemo preći na sljedeće jednostavno rješenje:
Primijenite sljedeću datoteku [link].

### 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 primijenite sljedeću ugrađenu naredbu za stvaranje configmap [link]. Imajte na umu da se pozivamo na naziv naše usluge, zamijenite ga po potrebi.

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}')"]}
EOF

Testiranje auth-metode

Sada pogledajmo magiju u akciji!

Izradite još nekoliko ključnih mapa s istim ključem najvišeg nivoa (tj. /sample_key) i vrijednostima po vašem izboru. Izradite odgovarajuće politike i uloge za nove putanje ključeva. Povezat ćemo ih kasnije.

Test korisničkog prostora imena:

Izradimo naš vlastiti prostor imena:

kubectl create namespace custom-ns

Izradimo 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

Izradite pod:

kubectl create -f poc-ubuntu-custom-ns.yaml

Kada se kontejner pokrene, uđite u njega 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 u Consul, koristeći metodu autorizacije koju smo ranije stvorili [link].
Da biste pregledali uneseni token iz svog korisničkog 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>"
}

Prijava!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

Da biste izvršili gornje korake u jednoj liniji (budući da ćemo izvesti nekoliko 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

Radi! Trebalo bi, barem. Sada uzmite SecretID i pokušajte pristupiti ključu/vrijednosti kojoj bismo trebali imati pristup.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: ”

Možete dekodirati "Value" base64 i vidjeti da odgovara vrijednosti u custom-ns/test_key u UI. Ako ste koristili istu vrijednost navedenu iznad u ovom priručniku, vaša kodirana vrijednost bit će IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Test korisničkog računa:

Izradite korisnički ServiceAccount s pomoću sljedeće naredbe [link].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

Izradite novu datoteku konfiguracije za pod. Imajte na umu da sam uključio instalaciju curl radi uštede truda 🙂

###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 ljusku unutar kontejnera.

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

Prijava!

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

Pristup odbijen. Oh, zaboravili smo dodati novu vezu pravila s odgovarajućim dozvolama, hajde da to učinimo sada.

Ponovite prethodne korake iznad:
a) Kreirajte identičnu politiku za prefiks „custom-sa/”.
b) Kreirajte ulogu, nazovite je „custom-sa-role”
c) Povežite politiku s ulogom.

Kreirajte pravilo-vezivanje (moguće samo iz cli / api). Imajte na umu drugu vrijednost oznake 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"'

Ponovite prijavu iz kontejnera „poc-ubuntu-custom-sa”. Uspjeh!
Provjerite naš pristup ključnom putu custom-sa/.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header "X-Consul-Token: "

Također možete provjeriti da ovaj token ne pruža pristup kv u „custom-ns/”. Samo ponovite gornju naredbu nakon što zamijenite „custom-sa” prefiksom „custom-ns”.
Pristup odbijen.

Primjer overlay-a:

Važno je napomenuti da će se sve veze pravila-vezivanja dodati u token s ovim pravima.
Naš kontejner „poc-ubuntu-custom-sa” nalazi se u zadnjem prostoru imena — pa hajde da ga iskoristimo za drugo pravilo-vezivanje.
Ponovite prethodne korake:
a) Kreirajte identičnu politiku za prefiks ključa „default/”.
b) Kreirajte ulogu, nazovite je „default-ns-role”
c) Povežite politiku s ulogom.
Kreirajte pravilo-vezivanje (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šem kontejneru „poc-ubuntu-custom-sa” i pokušajte pristupiti putu „default/” kv.
Pristup odbijen.
Možete pregledati navedene kredencijale za svaku ulogu u UI-u u odjeljku ACL > Tokens. Kao što vidite, našem trenutnom tokenu je dodana samo jedna „custom-sa-role”. Token koji trenutno koristimo bio je generiran kada smo se prijavili, i tada je postoji samo jedno pravilo-vezivanje koje tada odgovara. Trebamo se ponovno prijaviti i koristiti novi token.
Provjerite možete li čitati s puteva „custom-sa/” i „default/” kv.
Uspjeh!
To je zato što naš „poc-ubuntu-custom-sa” odgovara pravilima-vezivanjima „custom-sa” i „default-ns”.

Zaključak

TTL upravljanje tokenima?

U trenutku pisanja ovog članka ne postoji integrirani način za određivanje TTL za tokene generirane ovom metodom autorizacije. To bi bila fantastična mogućnost — omogućiti sigurnu automatizaciju autorizacije Consul.

Postoji mogućnost ručnog stvaranja tokena s TTL-om: