🥇Sissejuhatus Hashicorp Consuli Kubernetes'e autoriseerimisse

Täpselt, pärast väljalaskmist Hashicorp Consul 1.5.0 2019. aasta mai alguses on Consulis võimalik rakenduste ja teenuste autentimist, mis käivitatakse Kuberneteses, natiivselt.

Selles juhendis loome samm-sammult POC (Kontseptsiooni tõestus (Proof of concept, PoC) — kontseptsiooni teostatavuse tõestamine — tõlkija märkus), demonstreerides seda uut funktsiooni. Oodatakse, et teil oleks algteadmised Kubernetesest ja Hashicorp’s Consulist. Kuigi võite kasutada mis tahes pilveteenust või kohalikku keskkonda, kasutame selles juhendis Google Cloud Platformi.

Ülevaade

Kui liigume Consul dokumentatsiooni autoriseerimise meetodi kohta, saame lühiülevaate selle eesmärgist ja kasutusmudelist, samuti mõned tehnilised üksikasjad ja ülevaate loogikast. Soovitan tungivalt seda lugeda vähemalt korra enne jätkamist, kuna ma hakkan seda kõik selgitama ja arutama.

Schema 1: Consul autoriseerimise meetodi ametlik ülevaade

Vaatame dokumentatsiooni spetsiifilise Kubernetes autoriseerimise meetodi kohta.

Loomulikult on seal kasulikku teavet, kuid puudub juhend selle kohta, kuidas seda tegelikult kasutada. Seetõttu, nagu iga mõistlik inimene, sirvite internetis juhendite otsimisel. Ja siis... Tekkivad takistused. Nii juhtub. Parandame selle.

Enne kui liigume edasi meie POC loomise juurde, vaatame uuesti Consuli autoriseerimismeetodite üle (Schema 1) ja täpsustame seda Kubernetes'i kontekstis.

Arhitektuur

Selles juhendis loome Consuli serveri eraldi masinas, mis suhtleb Kubernetes'i klastriga, kus on installitud Consuli klient. Seejärel loome oma näidisrakenduse pods ja kasutame meie konfigureeritud autoriseerimismeetodit, et lugeda meie Consuli võtme/väärtuse hoidlast.

Allolev skeem näitab üksikasjalikult arhitektuuri, mida selles juhendis loome, ning autoriseerimismeetodi loogikat, mis seletatakse hiljem.

Schema 2: Autoriseerimismeetodi ülevaade Kubernetes'is

Väike märk: Consuli server ei pea elama Kubernetes'i klastrist väljaspool, et see toimiks. Kuid jah, ta saab olla nii-öelda ja naa.

Seega, kui võtame Consul'i ülevaateskeemi (skeem 1) ja rakendame sellele Kubernetes'i, saame ülaltoodud skeemi (skeem 2), ja loogika on järgmine:

Iga podi külge on kinnitatud teenusekonto, mis sisaldab Kubernetes'i poolt genereeritud ja teadaolevat JWT-janust. See token lisatakse ka podi vaikimisi.
Meie rakendus või teenus podis algatab sisselogimiskäsu meie Consul-klienti. Sisselogimissoovis näidatakse ka meie tokenit ja nime eriti loodud autentimise meetod (Kubernetes'i tüüpi). See samm nr 2 vastab Consul'i skeemi 1 sammule 1.
Meie Consul-klient suunab seejärel selle päringu meie Consul-serverile.
MAAGIA! Just siin Consul-server kontrollib päringu autentsust, kogub päringu identiteedi andmeid ja võrdleb neid mistahes seotud eeldefineeritud reeglitega. Allpool on teine skeem, et seda illustreerida. See samm vastab Consul'i ülevaateskeemi (skeem 1) sammudele 3, 4 ja 5.
Meie Consul-server genereerib Consul-tokeni, millel on õigused vastavalt meie määratud autoriseerimismeetodi reeglitele, mis me oleme määratlenud, seoses päringut esitanud isikuga. Seejärel saadab ta selle tokeni tagasi. See vastab Consul'i skeemi (Skeem 1) sammu 6-le.
Meie Consul-klient suunab tokeni päringu esitanud rakendusele või teenusele.

Meie rakendus või teenus saab nüüd kasutada seda Consul-tokenit suhtlemiseks meie Consul-andmetega, nagu on määratletud tokeni privileegides.

Kärbeste maagia avalikustatud!

Teie, kes te pole rahul vaid kübaraööbikuga ja soovite teada, kuidas see töötab… lubage mul "näidata teile, kui sügavale küüliku urgu».

Kuidas eelnevalt mainitud, on meie "maagiline" samm (Skeem 2: Samm 4) see, et Consul-server valideerib päringu, kogub teavet päringu kohta ja võrdleb seda kõigi seotud eelnevalt määratletud reeglitega. See samm vastab Consuli ülevaateskeemi (Skeem 1) sammudele 3, 4 ja 5. Allpool on skeem (Skeem 3), mille eesmärk on selgelt näidata, mis tegelikult toimub kapoti all konkreetse Kubernetes'i autoriseerimismeetodiga.

Skeem 3: Võlu avatud!

Alguspunktina suunab meie Consul-klient päringu sisendiks meie Consul-serverisse koos Kubernetes'i konto tokeniga ja konkreetse autoriseerimise meetodi instantsi nimega, mis loodi varem. See samm vastab eelmise skeemi selgituse sammule 3.
Nüüd peab Consul-server (või juht) valideerima vastuvõetud tokenit. Seetõttu konsulteerib ta Kubernetes'i klastriga (Consul-klienti kaudu) ja, kui vastavad õigused on olemas, selgitame välja, kas token on autentne ja kellele see kuulub.
Seejärel tagastatakse kontrollitud päring Consul-juhi juurde ja Consul-serveris otsitakse autoriseerimise meetodi instantsi, mille nimi on määratud sisse logimise päringus (ja mis on tüüpi Kubernetes).
Consul-juht määrab kindlaks nimetatud autoriseerimise meetodi instantsi (kui see leitud on) ja loeb selle külge kinnitatud sidumise reeglite kogumi. Seejärel loeb ta neid reegleid ja võrdleb neid kontrollitud identiteedi atribuutidega.
Tada! Liigume järgmise sammuna 5 eelmise skeemi seletuses.

Käivitage Consul-server tavalises virtuaalses masina

Alates nüüd hakkan peamiselt andma juhiseid selle POC-i loomiseks, sageli punktide kaupa, ilma seletavate täisteradeteta. Nagu varem mainitud, kasutan kogu infrastruktuuri loomiseks GCP-d, kuid saate sama infrastruktuuri luua ka mujal.

Käivita virtuaalne masin (instants / server).

Loo tulemüürireegel (AWS-i turgruppe):
Mulle meeldib anda masinale sama nimi, mis on reeglil ja võrgu sildil, antud juhul on see "skywiz-consul-server-poc".
Leia oma kohaliku arvuti IP-aadress ja lisa see lubatud lähtesoovide nimekirja, et saaksime ligipääsu kasutajaliidesele (UI).
Ava port 8500 UI jaoks. Vajuta Loo (Create). Me muudame selle tulemüüri [link].
Lisa reegel tulemüüri instantsile. Mine tagasi Consul-serveri VM-i juhtpaneelile ja lisa "skywiz-consul-server-poc" võrgu siltide väljadele. Vajuta Salvesta (Save).

Paigalda Consul virtuaalsesse masinasse, vaata siit. Pea meeles, et sul on vaja Consul'i versiooni ≥ 1.5 [link]
Loome ühe sõlmega Consuli – 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

Üksikasjalik juhend Consuli installimise ja 3 sõlme klastri seadistamise kohta sm. siit.
Looge fail /etc/consul.d/agent.json järgmiselt [link]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

Käivitage meie Consuli server:

consul agent 
-server 
-ui 
-client 0.0.0.0 
-data-dir=/var/lib/consul 
-bootstrap-expect=1 
-config-dir=/etc/consul.d

Te peaksite nägema hulgaliselt väljundit ja lõpuks “… update blocked by ACLs”.
Leidke Consuli serveri väline IP-aadress ja avage brauser koos selle IP-aadressiga porti 8500. Veenduge, et UI avaneb.
Proovige lisada paar võtme/väärtuse paari. Peab olema viga. See on sellepärast, et laadisime Consuli serveri ACL-iga ja keelasime kõik reeglid.
Minge tagasi oma shelli Consuli serveris ja käivitage protsess taustal või muul viisil, et see töötaks, ja sisestage järgmine:

consul acl bootstrap

Leidke väärtus „SecretID“ ja minge tagasi UI-sse. Vahekaardil „ACL“ sisestage just kopeeritud tokeni salajane identifikaator. Salvestage SecretID kuhugi mujale, meil on seda hiljem vaja.
Nüüd lisage paar võtme/väärtuse paari. Selleks lisame POC-sse järgmise: võti: „custom-ns/test_key“, väärtus: „Olen custom-ns kaustas!“

Kubernetes-klastri käivitamine meie rakenduse jaoks, kus Consul-client on Deemonite komplektina.

Looge K8s (Kubernetes) klaster. Loome selle samas piirkonnas nagu server, et kiiremini juurde pääseda ja seetõttu saame kasutada sama alamvõrku lihtsaks ühendamiseks sisemiste IP-aadressidega. Nimeks anname „skywiz-app-with-consul-client-poc“.

Märkuseks, siin on hea juhend, millega ma kokku puutusin, kui seadistasin POC Consul-klastri koos Consul Connectiga.
Kasutame ka Hashicorp helm chart'i koos täiendatud väärtuste failiga.
Installige ja seadistage Helm. Seadistamise 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

helm chart: https://www.consul.io/docs/platform/k8s/helm.html
Kasutage järgmist väärtuste faili (pange tähele, et ma olen enamus välja lülitanud):

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

Rakendage helm chart:

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

Käivitamisel vajab see lube Consul-serverile, nii et lisame need.
Pöörake tähelepanu klastripaneelis asuvale "Pod adresseerimise vahemikule" ning pöörduge tagasi meie tulemüüri reegli «skywiz-consul-server-poc» juurde.
Lisage Podi adresseerimise vahemik IP-aadresside nimekirja ja avage pordid 8301 ja 8300.

Minge Consul UI-sse ja mõne minuti pärast näete, et meie klaster ilmub node'i vahekaardile.

Seadistage autoriseerimismeetod, integreerides Consuli Kubernetesega.

Tagasi Consul serveri konsooli ja eksportige token, mille te varem salvestasite:

export CONSUL_HTTP_TOKEN=

Me vajame teavet meie Kubernetes klastrist, et luua auth meetodi instants:
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 on base64-kooditud, seega dekodeerige see oma lemmik tööriistaga [link]
kubernetes-ca-cert

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

Võtke sertifikaat "ca.crt" (pärast base64-le dekodeerimist) ja kirjutage see faili "ca.crt".
Nüüd looge auth meetodi instants, asendades kohatäitjad just saadud väärtustega.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "See on auth meetod, mis kasutab kubernetesi klastrit skywiz-app-with-consul-client-poc jaoks" 
-kubernetes-host "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

Järgmisena peame looma reegli ja selle uue rolliga siduma. Selle osa jaoks saate kasutada Consul UI-d, kuid meie kasutame käsurealiidest.
Kirjutage reegel

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

Rakendage reegel

consul acl policy create 
-name kv-custom-ns-policy 
-description "See on näidispoliitika kv jaoks custom-ns/" 
-rules @kv-custom-ns-policy.hcl

Leidke just loodud reegli identifikaator väljunditest.
Looge roll koos uue reegliga.

consul acl role create 
-name "custom-ns-role" 
-description "See on näidisaruanne custom-ns nimete jaoks" 
-policy-id

Nüüd seome meie uue rolli auth meetodi instantsiga. Pange tähele, et "selector" lipp määrab, kas meie sissepääsu päring saab selle rolli. Vaadake siin teisi valikuoptsioone: 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"'

Konfiguratsioonide lõpus

Ligipääs

Looge juurdepääs. Peame andma Consulile loa K8s teenusekonto tokeni autentimise ja tuvastamise kontrollimiseks.
Salvesta faili järgmist [linki]:

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

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

Ühendamine Consul Clientiga

Nagu mainitud siit, on daemonseti ühendamiseks mitmeid võimalusi, kuid liigume edasi järgmise lihtsa lahenduse juurde:
Kohaldage järgmist faili [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

Seejärel rakendage järgmine sisseehitatud käsk configmapi loomiseks [link]. Pange tähele, et viitame meie teenuse nimele, asendage see vajadusel.

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

auth-meetodi testimine

Nüüd vaatame, kuidas maagia töötab!

Looge veel mõned võtme kaustad sama ülemise võtmega (nt /sample_key) ja valige soovitud väärtus. Looge uute võtme tugevatest poliitikatest ja rollidest. Teeme seosed hiljem.

Kohandatud testimise nimeline ruum:

Loome omaenda nimelise ruumi:

kubectl create namespace custom-ns

Создадим под в нашем новом пространстве имен. Напишите конфигурацию для пода.

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

Создайте под:

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

Как только контейнер запустится, зайдите туда и установите curl.

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

Теперь мы отправим запрос на вход в Consul, используя метод авторизации, который мы создали ранее [link].
Чтобы просмотреть введенный токен из своей учетной записи службы:

cat /run/secrets/kubernetes.io/serviceaccount/token

Напишите следующее в файл внутри контейнера:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

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

Чтобы выполнить вышеуказанные шаги в одной строке (поскольку мы будем выполнять несколько тестов), вы можете сделать следующее:

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

Работает! Должно, по крайней мере. Теперь возьмите SecretID и попробуйте получить доступ к ключу/значению, к которому у нас должен быть доступ.

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

Saate dekrüpteerida «Value» base64 ja näha, et see vastab väärtusele custom-ns/test_key kasutajaliideses. Kui kasutasite sama väärtust, mis on eespool selles juhendis, siis teie kodeeritud väärtus on IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Kohandatud teenuse konto test:

Looge kohandatud ServiceAccount järgmise käsuga [link].

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

Looge uus konfiguratsioonifail pods. Pange tähele, et ma lisan curl'i installimise, et töö oleks kergem 🙂

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

Seejärel käivitage konteineri sees koonus.

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

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

Lubamine keelatud. Oi, me unustasime lisada uue reegli sidumise koos vastavate õigustega, teeme seda nüüd.

Korrake ülaltoodud samme:
a) Looge identne poliitika prefiksiga «custom-sa/».
b) Looge roll, nimetage see «custom-sa-role»
c) Siduge poliitika rolliga.

Looge reegli sidumine (ainult CLI / API kaudu). Pange tähele teistsugust valiku lipu väärtust.

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-sa-role' 
-selector='serviceaccount.name=="custom-sa"'

Korrake sisselogimist konteinerist «poc-ubuntu-custom-sa». Edu!
Kontrollige meie juurdepääsu võtmeedastusele custom-sa/.

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

Samuti saate veenduda, et see token ei anna juurdepääsu kv-le "custom-ns/". Lihtsalt korrake ülaltoodud käsku, vahetades "custom-sa" prefiksi "custom-ns" vastu.
Luba keelatud.

Overlay näide:

Tuleb märkida, et kõik rule-bindingud lisatakse sellele tokenile nende õigustega.
Meie konteiner "poc-ubuntu-custom-sa" asub vaikimisi nimel — seega kasutame seda teise rule-bindingu jaoks.
Korrake eelnevaid samme:
a) Looge identne poliitika võtme prefiksile "default/".
b) Looge Tegevus (Role), nimetage see “default-ns-role”
c) Siduge poliitika rolliga.
Looge Rule-Binding (ainult cli / api kaudu võimalik)

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 saada juurdepääsu "default/" kv teele.
Luba keelatud.
Saate vaadata iga tokeni jaoks määratud mandaate UI-s sektsioonis ACL > Tokens. Nagu näete, on meie praeguse tokeniga seotud ainult üks „custom-sa-role“. Token, mida me praegu kasutame, genereeriti, kui me süsteemi sisenesime, ja siis oli ainult üks rule-binding, mis vastas sellele. Peame uuesti sisse logima ja kasutama uut tokenit.
Veenduge, et saate lugeda nii teedest „custom-sa/“ kui ka „default/“ kv.
Edu!
See on seotud sellega, et meie „poc-ubuntu-custom-sa“ vastab reeglitel põhinevatele „custom-sa“ ja „default-ns“ sidemetele.

Kokkuvõte

TTL tokeni haldus?

Selle artikli kirjutamise ajal ei ole olemas integreeritud viisi TTL määramiseks selle autoriseerimise meetodi kaudu genereeritud tokenite jaoks. See oleks fantastiline võimalus – tagada Consuli autoriseerimise turvaline automatiseerimine.

On võimalik käsitsi luua TTL-iga token: