Tako je, po izpustitvi v začetku maja 2019 lahko v Consulu avtorizirate aplikacije in storitve, ki se izvorno izvajajo v Kubernetesu.
V tej vadnici bomo ustvarjali korak za korakom (Dokaz koncepta, PoC), ki prikazuje to novo funkcijo. Pričakuje se, da imate osnovno znanje o Kubernetesu in Hashicorpovem Consulu. Čeprav lahko uporabljate katero koli platformo v oblaku ali lokalno okolje, bomo v tej vadnici uporabili Googlovo platformo v oblaku.
Pregled
Če gremo na , bomo dobili hiter pregled njegovega namena in primera uporabe ter nekaj tehničnih podrobnosti in splošen pregled logike. Toplo priporočam, da ga preberete vsaj enkrat, preden nadaljujete, saj bom zdaj vse razložil in prežvečil.
Diagram 1: Uradni pregled metode avtorizacije Consul
Poglejmo noter .
Seveda so tam koristne informacije, vendar ni vodnika, kako vse to dejansko uporabiti. Torej, kot vsaka zdrava oseba, brskate po internetu za nasveti. In potem ... Ne uspeš. Zgodi se. Popravimo to.
Preden nadaljujemo z ustvarjanjem našega POC, se vrnimo k pregledu avtorizacijskih metod družbe Consul (diagram 1) in ga izboljšamo v kontekstu Kubernetesa.
arhitektura
V tej vadnici bomo ustvarili strežnik Consul na ločenem računalniku, ki bo komuniciral z gručo Kubernetes z nameščenim odjemalcem Consul. Nato bomo ustvarili našo lažno aplikacijo v sklopu in uporabili našo konfigurirano avtorizacijsko metodo za branje iz naše shrambe ključev/vrednosti Consul.
Spodnji diagram podrobno prikazuje arhitekturo, ki jo ustvarjamo v tej vadnici, kot tudi logiko za avtorizacijsko metodo, ki bo pojasnjena pozneje.
Diagram 2: Pregled metode avtorizacije Kubernetes
Hitra opomba: strežniku Consul ni treba živeti zunaj gruče Kubernetes, da to deluje. Ampak ja, lahko to naredi tako in tako.
Če torej vzamemo pregledni diagram Consul (diagram 1) in nanj uporabimo Kubernetes, dobimo zgornji diagram (diagram 2), logika tukaj pa je naslednja:
- Vsak pod bo imel pripet servisni račun, ki bo vseboval žeton JWT, ki ga ustvari in pozna Kubernetes. Tudi ta žeton je privzeto vstavljen v pod.
- Naša aplikacija ali storitev znotraj sklopa sproži ukaz za prijavo našemu odjemalcu Consul. Zahteva za prijavo bo vsebovala tudi naš žeton in ime posebej ustvarjen način avtorizacije (tip Kubernetes). Ta korak #2 ustreza koraku 1 Consul diagrama (shema 1).
- Naša stranka Consul bo nato to zahtevo posredovala našemu strežniku Consul.
- ČAROVNIJO! Tukaj strežnik Consul preveri pristnost zahteve, zbere informacije o identiteti zahteve in jih primerja z morebitnimi povezanimi vnaprej določenimi pravili. Spodaj je še en diagram za ponazoritev tega. Ta korak ustreza korakom 3, 4 in 5 diagrama pregleda Consul (diagram 1).
- Naš strežnik Consul ustvari žeton Consul z dovoljenji v skladu z našimi določenimi pravili avtorizacijske metode (ki smo jih definirali) v zvezi z identiteto vlagatelja zahteve. Ta žeton bo nato poslal nazaj. To ustreza 6. koraku konzulovega diagrama (diagram 1).
- Naša stranka Consul posreduje žeton aplikaciji ali storitvi, ki zahteva.
Naša aplikacija ali storitev lahko zdaj uporablja ta žeton Consul za komunikacijo z našimi podatki Consul, kot določajo privilegiji žetona.
Čarovnija je razkrita!
Za tiste, ki niste zadovoljni samo z zajcem iz klobuka in želite vedeti, kako deluje ... naj vam "pokažem, kako globoko zajčja luknja".
Kot smo že omenili, je naš "čarobni" korak (slika 2: korak 4) tisti, v katerem strežnik Consul preveri pristnost zahteve, zbere informacije o zahtevi in jih primerja z morebitnimi povezanimi vnaprej določenimi pravili. Ta korak ustreza korakom 3, 4 in 5 diagrama pregleda Consul (diagram 1). Spodaj je diagram (diagram 3), katerega namen je jasno prikazati, kaj se dejansko dogaja pod pokrovom posebna avtorizacijska metoda Kubernetes.
Diagram 3: Čarovnija je razkrita!
- Kot izhodišče naš odjemalec Consul posreduje zahtevo za prijavo našemu strežniku Consul z žetonom računa Kubernetes in posebnim imenom primerka avtorizacijske metode, ki je bila ustvarjena prej. Ta korak ustreza 3. koraku v prejšnji razlagi vezja.
- Zdaj mora strežnik Consul (ali vodja) preveriti pristnost prejetega žetona. Zato se bo posvetoval z gručo Kubernetes (preko odjemalca Consul) in z ustreznimi dovoljenji bomo ugotovili, ali je žeton pristen in komu pripada.
- Potrjena zahteva se nato vrne vodji Consul, strežnik Consul pa poišče primerek avtorizacijske metode z navedenim imenom iz zahteve za prijavo (in vrste Kubernetes).
- Vodja konzula identificira navedeni primerek avtorizacijske metode (če ga najde) in prebere nabor zavezujočih pravil, ki so mu priložena. Ta pravila nato prebere in jih primerja s preverjenimi atributi identitete.
- TA-da! Pojdimo na 5. korak v prejšnji razlagi vezja.
Zaženite Consul-strežnik na navadnem virtualnem računalniku
Od zdaj naprej bom večinoma dajal navodila o tem, kako ustvariti ta POC, pogosto v točkah, brez popolnih razlag stavkov. Kot že omenjeno, bom uporabil GCP za ustvarjanje vse infrastrukture, vendar lahko isto infrastrukturo ustvarite kjer koli drugje.
- Zaženite virtualni stroj (primerek/strežnik).
- Ustvarite pravilo za požarni zid (varnostna skupina v AWS):
- Pravilu in omrežni oznaki rad dodelim isto ime stroja, v tem primeru "skywiz-consul-server-poc".
- Poiščite naslov IP vašega lokalnega računalnika in ga dodajte na seznam izvornih naslovov IP, da bomo lahko dostopali do uporabniškega vmesnika (UI).
- Odprite vrata 8500 za uporabniški vmesnik. Kliknite Ustvari. Ta požarni zid bomo kmalu spet spremenili [].
- Dodajte pravilo požarnega zidu primerku. Vrnite se na nadzorno ploščo VM na Consul Server in dodajte »skywiz-consul-server-poc« v polje omrežnih oznak. Kliknite Shrani.
- Namestite Consul na virtualni stroj, preverite tukaj. Ne pozabite, da potrebujete različico Consul ≥ 1.5 [povezava]
- Ustvarimo posamezno vozlišče Consul - konfiguracija je naslednja.
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 podrobnejši vodnik o namestitvi Consul in nastavitvi gruče 3 vozlišč glejte .
- Ustvarite datoteko /etc/consul.d/agent.json na naslednji način []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Zaženite naš strežnik Consul:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Morali bi videti kup izpisov in na koncu z "... posodobitev blokirajo ACL-ji."
- Poiščite zunanji naslov IP strežnika Consul in odprite brskalnik s tem naslovom IP na vratih 8500. Prepričajte se, da se odpre uporabniški vmesnik.
- Poskusite dodati par ključ/vrednost. Mora biti napaka. To je zato, ker smo strežnik Consul naložili z ACL in onemogočili vsa pravila.
- Vrnite se v lupino na strežniku Consul in zaženite postopek v ozadju ali na drug način, da ga zaženete, in vnesite naslednje:
consul acl bootstrap- Poiščite vrednost "SecretID" in se vrnite v uporabniški vmesnik. V zavihek ACL vnesite tajni ID žetona, ki ste ga pravkar kopirali. Kopirajte SecretID nekam drugam, potrebovali ga bomo pozneje.
- Zdaj dodajte par ključ/vrednost. Za ta POC dodajte naslednje: ključ: “custom-ns/test_key”, vrednost: “Sem v mapi custom-ns!”
Zagon gruče Kubernetes za našo aplikacijo z odjemalcem Consul kot Daemonset
- Ustvarite gručo K8s (Kubernetes). Ustvarili ga bomo v istem območju kot strežnik za hitrejši dostop in tako bomo lahko uporabili isto podomrežje za enostavno povezovanje z notranjimi naslovi IP. Imenovali jo bomo "aplikacija-skywiz-s-konzulom-odjemalcem-poc".
- Kot stransko opombo je tukaj dobra vadnica, na katero sem naletel med nastavljanjem gruče POC Consul s Consul Connect.
- Uporabili bomo tudi krmilni grafikon Hashicorp z razširjeno datoteko vrednosti.
- Namestite in konfigurirajte Helm. Konfiguracijski koraki:
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- tabela krmila:
- Uporabite naslednjo vrednostno datoteko (upoštevajte, da sem večino onemogočil):
### 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- Uporabi diagram krmila:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Ko se bo poskušal zagnati, bo potreboval dovoljenja za strežnik Consul, zato jih dodajmo.
- Upoštevajte »Razpon naslovov Pod«, ki se nahaja na nadzorni plošči gruče, in se vrnite na naše pravilo požarnega zidu »skywiz-consul-server-poc«.
- Dodajte obseg naslovov za pod na seznam naslovov IP in odprite vrata 8301 in 8300.
- Pojdite na uporabniški vmesnik Consul in po nekaj minutah boste videli našo gručo prikazano na zavihku vozlišč.
Konfiguriranje avtorizacijske metode z integracijo Consula s Kubernetesom
- Vrnite se v lupino strežnika Consul in izvozite žeton, ki ste ga prej shranili:
export CONSUL_HTTP_TOKEN=<SecretID>- Potrebovali bomo informacije iz naše gruče Kubernetes, da ustvarimo primerek metode avtorizacije:
- kubernetes-gostitelj
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:- Žeton je kodiran base64, zato ga dešifrirajte s svojim priljubljenim orodjem []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Vzemite potrdilo “ca.crt” (po dekodiranju base64) in ga zapišite v datoteko “ca.crt”.
- Zdaj ustvarite metodo za preverjanje avtorizacije in zamenjajte ogradne oznake z vrednostmi, ki ste jih pravkar prejeli.
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>"- Nato moramo ustvariti pravilo in ga pripeti novi vlogi. Za ta del lahko uporabite uporabniški vmesnik Consul, mi pa bomo uporabili ukazno vrstico.
- Napišite pravilo
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Uporabite 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- Poiščite ID pravila, ki ste ga pravkar ustvarili iz izhoda.
- Ustvarite vlogo z novim pravilom.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Zdaj bomo našo novo vlogo povezali s primerkom metode auth. Upoštevajte, da zastavica "izbirnik" določa, ali bo naša zahteva za prijavo prejela to vlogo. Tukaj preverite druge izbirne možnosti:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Končno konfiguracije
Pravice dostopa
- Ustvarite pravice dostopa. Konzulu moramo dati dovoljenje za preverjanje in identifikacijo identitete žetona storitvenega računa K8s.
- V datoteko zapišite naslednje :
###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- Ustvarimo pravice dostopa
kubectl create -f skywiz-poc-consul-server_rbac.yamlPovezovanje s stranko Consul
- Kot navedeno Obstaja več možnosti za povezavo z daemonsetom, vendar bomo prešli na naslednjo preprosto rešitev:
- Uporabite naslednjo datoteko [].
### 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- Nato uporabite naslednji vgrajeni ukaz za ustvarjanje configmap []. Upoštevajte, da se sklicujemo na ime naše storitve, po potrebi ga zamenjajte.
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 avtorizacije
Zdaj pa poglejmo čarovnijo v akciji!
- Ustvarite še več ključnih map z istim ključem najvišje ravni (tj. /sample_key) in vrednost po vaši izbiri. Ustvarite ustrezne politike in vloge za nove ključne poti. Vezave bomo naredili kasneje.
Test imenskega prostora po meri:
- Ustvarimo lasten imenski prostor:
kubectl create namespace custom-ns- Ustvarimo pod v našem novem imenskem prostoru. Napišite konfiguracijo 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- Ustvari pod:
kubectl create -f poc-ubuntu-custom-ns.yaml- Ko vsebnik deluje, pojdite tja in namestite curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Zdaj bomo Consulu poslali zahtevo za prijavo z avtorizacijsko metodo, ki smo jo ustvarili prej [].
- Za ogled vnesenega žetona iz vašega storitvenega računa:
cat /run/secrets/kubernetes.io/serviceaccount/token- V datoteko znotraj vsebnika zapišite naslednje:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Vpiši se!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Če želite dokončati zgornje korake v eni vrstici (ker bomo izvajali več testov), lahko storite naslednje:
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- deluje! Vsaj moralo bi. Zdaj vzemite SecretID in poskusite dostopati do ključa/vrednosti, do katerega bi morali imeti dostop.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Lahko dekodirate base64 "Vrednost" in vidite, da se ujema z vrednostjo v custom-ns/test_key v uporabniškem vmesniku. Če ste v tej vadnici uporabili isto vrednost zgoraj, bi bila vaša kodirana vrednost IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Test računa uporabniške storitve:
- Ustvarite ServiceAccount po meri z naslednjim ukazom [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Ustvarite novo konfiguracijsko datoteko za pod. Upoštevajte, da sem vključil namestitev kodrov, da prihranim delo :)
###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- Po tem zaženite lupino znotraj posode.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Vpiši 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- Dovoljenje zavrnjeno. Oh, pozabili smo dodati nova pravila, vezana z ustreznimi dovoljenji, naredimo to zdaj.
Ponovite prejšnje zgornje korake:
a) Ustvarite enako politiko za predpono »custom-sa/«.
b) Ustvarite vlogo, poimenujte jo »custom-sa-role«
c) Vlogi priložite pravilnik.
- Ustvarite vezavo pravil (možno samo iz cli/api). Upoštevajte drugačen pomen izbirne zastavice.
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 vsebnika "poc-ubuntu-custom-sa". uspeh!
- Oglejte si naš dostop do poti custom-sa/key.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Prav tako lahko zagotovite, da ta žeton ne omogoča dostopa do kv v "custom-ns/". Samo ponovite zgornji ukaz, potem ko ste "custom-sa" zamenjali s predpono "custom-ns".
Dovoljenje zavrnjeno.
Primer prekrivanja:
- Omeniti velja, da bodo vse preslikave, ki zavezujejo pravila, dodane žetonu s temi pravicami.
- Naš vsebnik "poc-ubuntu-custom-sa" je v privzetem imenskem prostoru - zato ga uporabimo za drugačno vezavo pravil.
- Ponovi prejšnje korake:
a) Ustvarite enak pravilnik za predpono ključa »default/«.
b) Ustvarite vlogo in jo poimenujte »default-ns-role«
c) Vlogi priložite pravilnik. - Ustvarite vezavo pravil (možno 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"'- Vrnite se v naš vsebnik "poc-ubuntu-custom-sa" in poskusite dostopati do poti kv "default/".
- Dovoljenje zavrnjeno.
Podane poverilnice za vsak žeton si lahko ogledate v uporabniškem vmesniku pod ACL > Žetoni. Kot lahko vidite, ima naš trenutni žeton samo eno »vlogo po meri«. Žeton, ki ga trenutno uporabljamo, je bil ustvarjen, ko smo se prijavili, in takrat se je ujemala le ena vezava pravila. Ponovno se moramo prijaviti in uporabiti nov žeton. - Prepričajte se, da lahko berete s poti kv "custom-sa/" in "default/".
Uspeh!
To je zato, ker se naš »poc-ubuntu-custom-sa« ujema z vezavama pravil »custom-sa« in »default-ns«.
Zaključek
Upravljanje žetonov TTL?
V času tega pisanja ni integriranega načina za določitev TTL za žetone, ustvarjene s to avtorizacijsko metodo. To bi bila fantastična priložnost za zagotavljanje varne avtomatizacije konzularne avtorizacije.
Obstaja možnost ročnega ustvarjanja žetona s TTL:
Čas veljavnosti – čas, ko bo ta žeton preklican. (Izbirno; dodano v Consul 1.5.0)- Obstaja samo za ročno ustvarjanje/posodabljanje
Upajmo, da bomo v bližnji prihodnosti lahko nadzorovali, kako se generirajo žetoni (na pravilo ali metodo avtorizacije) in dodali TTL.
Do takrat je predlagano, da v svoji logiki uporabite končno točko odjave.
Preberite tudi druge članke na našem blogu:
Vir: www.habr.com