Dit is reg, na die vrystelling aan die begin van Mei 2019 kan Consul toepassings en dienste wat in Kubernetes loop, van nature magtig.
In hierdie tutoriaal sal ons stap vir stap skep (Proof of concept, PoC) wat hierdie nuwe kenmerk demonstreer. Daar word van jou verwag om basiese kennis van Kubernetes en Hashicorp se Consul te hê. En terwyl jy enige wolkplatform of plaaslike omgewing kan gebruik, sal ons in hierdie tutoriaal Google se Wolkplatform gebruik.
Hersien
As ons gaan na , sal ons 'n kort oorsig kry van die doel en gebruiksgeval daarvan, sowel as 'n paar tegniese besonderhede en 'n algemene oorsig van die logika. Ek beveel sterk aan om dit ten minste een keer te lees voordat ek verder gaan, want ek sal dit nou verduidelik en opkou.
Skema 1: Amptelike oorsig van die Konsul-magtigingsmetode
Kom ons kyk na .
Natuurlik is daar nuttige inligting daar, maar daar is geen gids oor hoe om dit alles werklik te gebruik nie. So, soos enige gesonde persoon, soek jy die internet vir leiding. En dan... Word verslaan. Dit gebeur. Kom ons maak dit reg.
Voordat ons voortgaan met die skep van ons POC, kom ons gaan terug na die Consul-magtigingsmetodes-oorsig (Diagram 1) en verfyn dit in die konteks van Kubernetes.
Argitektuur
In hierdie tutoriaal sal ons 'n Consul-bediener op 'n aparte masjien skep wat met 'n Kubernetes-kluster met die Consul-kliënt geïnstalleer is. Ons sal dan ons dummy-toepassing in die pod skep en ons gekonfigureerde magtigingsmetode gebruik om uit ons Consul-sleutel-/waardewinkel te lees.
Die diagram hieronder toon in detail die argitektuur wat ons in hierdie tutoriaal skep, sowel as die magtigingsmetode-logika, wat later verduidelik sal word.
Diagram 2: Kubernetes Magtigingsmetode-oorsig
'n Vinnige nota: die Consul-bediener hoef nie buite die Kubernetes-groepering te woon om dit te laat werk nie. Maar ja, hy kan enige manier.
Dus, deur die Consul-oorsigskema (Skema 1) te neem en Kubernetes daarop toe te pas, kry ons die skema hierbo (Skema 2), en hier sal die logika soos volg wees:
- Elke peul sal 'n diensrekening daaraan gekoppel hê, wat 'n JWT-token bevat wat deur Kubernetes gegenereer en bekend is. Hierdie teken word ook by verstek in die peul ingevoeg.
- Ons toepassing of diens binne 'n pod sal 'n aanmeldopdrag na ons Consul-kliënt begin. Die aanmeldversoek sal ook ons teken en naam insluit spesiaal geskep magtigingsmetode (soos Kubernetes). Hierdie stap #2 stem ooreen met stap 1 van die Consul-kring (Diagram 1).
- Ons Consul-kliënt sal dan hierdie versoek aan ons Consul-bediener stuur.
- TOWERKUNS! Dit is waar die Consul-bediener die versoek staaf, die identiteit van die versoek insamel en dit vergelyk met enige geassosieerde voorafbepaalde reëls. Hieronder is nog 'n diagram om dit te illustreer. Hierdie stap stem ooreen met stappe 3, 4 en 5 van die Consul-oorsigdiagram (Diagram 1).
- Ons Consul-bediener genereer 'n Consul-token met toestemmings volgens die magtigingsmetodereëls wat ons gespesifiseer het (wat ons gedefinieer het) met betrekking tot die identiteit van die versoeker. Dit sal dan daardie teken terugstuur. Dit stem ooreen met stap 6 van die Konsulskema (Diagram 1).
- Ons Consul-kliënt stuur die teken aan na die aansoek of diens wat versoek.
Ons toepassing of diens kan nou hierdie Consul-token gebruik om met ons Consul-data te kommunikeer, soos gedefinieer deur die token se voorregte.
Die magie word geopenbaar!
Vir die van julle wat nie tevrede is met net 'n hasie uit 'n hoed nie en wil weet hoe dit werk...laat ek jou wys hoe diep Konyn gat".
Soos vroeër genoem, is ons "magic" stap (Skema 2: Stap 4) vir die Consul-bediener om die versoek te verifieer, inligting oor die versoek in te samel en dit te vergelyk met enige geassosieerde voorafbepaalde reëls. Hierdie stap stem ooreen met stappe 3, 4 en 5 van die Consul-oorsigdiagram (Diagram 1). Hieronder is 'n diagram (Skema 3), waarvan die doel is om duidelik te wys wat werklik gebeur onder die enjinkap spesifieke Kubernetes-magtigingsmetode.
Diagram 3: Die magie word geopenbaar!
- As 'n beginpunt stuur ons Consul-kliënt die aanmeldversoek aan ons Consul-bediener met die Kubernetes-rekeningtoken en die spesifieke instansienaam van die magtigingsmetode wat ons vroeër geskep het. Hierdie stap stem ooreen met stap 3 in die vorige diagramverduideliking.
- Nou moet die Consul-bediener (of leier) die egtheid van die ontvangde token verifieer. Daarom sal dit met die Kubernetes-groepering konsulteer (via die Consul-kliënt) en, met die toepaslike toestemmings, sal ons uitvind of die token eg is en wie dit besit.
- Die gevalideerde versoek word dan teruggestuur na die Consul-leier, en die Consul-bediener word gesoek vir 'n magtigingsmetode-instansie met die gespesifiseerde naam van die aanmeldversoek (en Kubernetes-tipe).
- Die Konsulleier bepaal die gespesifiseerde magtigingsmetode-instansie (indien gevind) en lees die stel bindende reëls wat daaraan gekoppel is. Dit lees dan daardie reëls en vergelyk dit met die geverifieerde identiteitskenmerke.
- TA-daah! Gaan na stap 5 in die vorige stroombaan verduideliking.
Begin Consul-bediener in 'n normale virtuele masjien
Van nou af sal ek hoofsaaklik instruksies gee vir die skep van hierdie POC, dikwels in paragrawe, sonder verklarende heelsinne. Soos vroeër genoem, sal ek GCP gebruik om die hele infrastruktuur te skep, maar jy kan dieselfde infrastruktuur op enige ander plek skep.
- Begin die virtuele masjien (instansie / bediener).
- Skep 'n firewall-reël ('n sekuriteitsgroep in AWS):
- Ek hou daarvan om dieselfde masjiennaam aan die reël en die netwerkmerker toe te ken, in hierdie geval "skywiz-consul-server-poc".
- Vind die IP-adres van jou plaaslike rekenaar en voeg dit by die lys van bron-IP-adresse sodat ons toegang tot die gebruikerskoppelvlak (UI) kan kry.
- Maak poort 8500 oop vir UI. Klik Skep. Ons sal binnekort weer hierdie firewall verander [].
- Voeg 'n firewall-reël by die instansie. Gaan terug na die VM-kontroleskerm op die Consul-bediener en voeg "skywiz-consul-server-poc" by die netwerketikette-veld. Klik Stoor.
- Installeer Consul op 'n virtuele masjien, kyk hier. Onthou jy benodig Consul weergawe ≥ 1.5 [skakel]
- Kom ons skep 'n enkele nodus Consul - die konfigurasie is soos volg.
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- Vir 'n meer gedetailleerde gids oor die installering van Consul en die opstel van 'n 3-node-kluster, sien .
- Skep lêer /etc/consul.d/agent.json soos hierdie []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Begin ons Consul-bediener:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Jy behoort 'n klomp uitset te sien en uiteindelik "... opdatering geblokkeer deur ACL's".
- Vind die eksterne IP-adres van die Consul-bediener en maak 'n blaaier oop met daardie IP-adres op poort 8500. Maak seker dat die UI oopmaak.
- Probeer om 'n sleutel/waarde-paar by te voeg. Daar moet 'n fout wees. Dit is omdat ons die Consul-bediener met 'n ACL gelaai het en alle reëls geweier het.
- Gaan terug na jou dop op die Consul-bediener en begin die proses in die agtergrond of op 'n ander manier om dit te laat werk en tik die volgende:
consul acl bootstrap- Vind die "SecretID" waarde en keer terug na die UI. Op die ACL-oortjie, voer die geheime token-ID in wat jy sopas gekopieer het. Kopieer die SecretID iewers anders, ons sal dit later nodig hê.
- Voeg nou 'n sleutel/waarde-paar by. Vir hierdie POC, voeg die volgende by: sleutel: "custom-ns/test_key", waarde: "Ek is in die persoonlike-ns-lêergids!"
Begin 'n Kubernetes-kluster vir ons toepassing met die Consul-kliënt as 'n Daemonset
- Skep 'n K8s (Kubernetes)-kluster. Ons sal dit in dieselfde sone as die bediener skep vir vinniger toegang en dus kan ons dieselfde subnet gebruik om maklik met interne IP's te koppel. Ons sal dit "skywiz-app-met-konsul-kliënt-poc" noem.
- As 'n kantaantekening, hier is 'n goeie gids wat ek teëgekom het toe ek 'n Consul POC-kluster met Consul Connect opgestel het.
- Ons sal ook die Hashicorp-helmkaart met 'n uitgebreide waardelêer gebruik.
- Installeer en konfigureer Helm. Konfigurasie stappe:
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- stuurkaart:
- Gebruik die volgende waardes-lêer (let wel dat ek die meeste gedeaktiveer het):
### 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- Pas stuurkaart toe:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Wanneer dit probeer loop, sal dit toestemmings vir die Consul-bediener nodig hê, so kom ons voeg dit by.
- Let op die "Pod-adresreeks" wat op die groepkontroleskerm geleë is en gaan terug na ons "skywiz-consul-server-poc" firewall-reël.
- Voeg die adresreeks vir die pod by die lys van IP-adresse en maak poorte 8301 en 8300 oop.
- Gaan na Consul UI en binne 'n paar minute sal jy sien dat ons groep in die nodes-oortjie verskyn.
Pas die magtigingsmetode aan deur Consul met Kubernetes te integreer
- Keer terug na die Consul-bedienerdop en voer die token uit wat jy vroeër gestoor het:
export CONSUL_HTTP_TOKEN=<SecretID>- Ons het inligting van ons Kubernetes-groepering nodig om die autoriseringsmetode te instansieer:
- kubernetes gasheer
kubectl get endpoints | grep kubernetes- kubernetes-diens-rekening-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:- Die teken is base64-geënkodeer, so dekripteer dit met jou gunsteling instrument []
- kubernetes-ca-sert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Neem die “ca.crt”-sertifikaat (na base64-dekodering) en plaas dit in die “ca.crt”-lêer.
- Instansieer nou die bekragtigingsmetode en vervang die plekhouers met die waardes wat jy sopas ontvang het.
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>"- Vervolgens moet ons 'n reël skep en dit aan die nuwe rol koppel. Vir hierdie deel kan u Consul UI gebruik, maar ons sal die opdragreël gebruik.
- Skryf 'n reël
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Pas die reël toe
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- Vind die ID van die reël wat jy sopas geskep het uit die uitvoer.
- Skep 'n rol met 'n nuwe reël.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Ons sal nou ons nuwe rol assosieer met die instansie van die bekragtigingsmetode. Let daarop dat die "keurder" vlag bepaal of ons aanmeldversoek hierdie rol sal ontvang. Kyk hier vir ander kieseropsies:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Konfigurasies op die ou end
Toegangsregte
- Skep toestemmings. Ons moet toestemming aan Consul gee om die identiteit van die K8s-diensrekeningtoken te verifieer en te identifiseer.
- Skryf die volgende aan die lêer :
###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- Kom ons skep toegangsregte
kubectl create -f skywiz-poc-consul-server_rbac.yamlKoppel aan Consul Client
- Soos genoem , daar is verskeie opsies om aan die daemonset te koppel, maar ons gaan na die volgende eenvoudige oplossing:
- Pas die volgende lêer toe [].
### 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- Gebruik dan die volgende ingeboude opdrag om 'n configmap te skep []. Let daarop dat ons na die naam van ons diens verwys, verander dit indien nodig.
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}')"]}
EOFToets die outoriteit metode
Kom ons kyk nou na die magie in aksie!
- Skep nog 'n paar sleutelvouers met dieselfde topvlaksleutel (d.w.s. /voorbeeld_sleutel) en 'n waarde van jou keuse. Skep die toepaslike beleide en rolle vir die nuwe sleutelpaaie. Ons sal later die bindings doen.
Pasgemaakte naamruimtetoets:
- Kom ons skep ons eie naamruimte:
kubectl create namespace custom-ns- Kom ons skep 'n peul in ons nuwe naamruimte. Skryf die konfigurasie vir die peul.
###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- Skep onder:
kubectl create -f poc-ubuntu-custom-ns.yaml- Sodra die houer aan die gang is, gaan daarheen en installeer krul.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Ons sal nou 'n aanmeldversoek aan Consul stuur met die magtigingsmetode wat ons vroeër geskep het [].
- Om die ingevoerde teken vanaf jou diensrekening te sien:
cat /run/secrets/kubernetes.io/serviceaccount/token- Skryf die volgende na 'n lêer in die houer:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Teken aan!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Om die bogenoemde stappe in een reël uit te voer (aangesien ons verskeie toetse gaan uitvoer), kan jy die volgende doen:
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- Werk! Moet ten minste. Neem nou die SecretID en probeer toegang kry tot die sleutel/waarde waartoe ons toegang moet hê.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Jy kan "Value" base64 dekodeer en sien dat dit ooreenstem met die waarde in custom-ns/test_key in die UI. As jy dieselfde waarde gebruik het wat vroeër in hierdie gids gegee is, sal jou geënkodeerde waarde IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi wees.
Gebruikersdiensrekeningtoets:
- Skep 'n pasgemaakte diensrekening met die volgende opdrag [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Skep 'n nuwe konfigurasielêer vir die pod. Neem asseblief kennis dat ek die krul-installasie ingesluit het om arbeid te bespaar :)
###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- Begin daarna 'n dop in die houer.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Teken aan!
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- Toestemming geweier. O, ons het vergeet om 'n nuwe reël wat met die toepaslike toestemmings bind by te voeg, kom ons doen dit nou.
Herhaal die vorige stappe hierbo:
a) Skep 'n identiese Beleid vir die "custom-sa/" voorvoegsel.
b) Skep 'n rol, noem dit "custom-sa-role"
c) Heg die Beleid aan die Rol.
- Skep 'n reël-binding (slegs moontlik vanaf cli/api). Let op die verskillende waarde van die kieservlag.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Probeer weer aanmeld vanaf die "poc-ubuntu-custom-sa"-houer. Sukses!
- Gaan ons toegang tot die pasgemaakte-sa/sleutelpad na.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Jy kan ook seker maak dat hierdie teken nie toegang tot kv in "custom-ns/" verleen nie. Herhaal net die bogenoemde opdrag nadat jy "custom-sa" vervang het met "custom-ns" voorvoegsel.
Toestemming geweier.
Oorleg voorbeeld:
- Dit is opmerklik dat alle reël-bindende passings by die teken gevoeg sal word met hierdie regte.
- Ons "poc-ubuntu-custom-sa"-houer is in die verstek naamruimte - so kom ons gebruik dit vir 'n ander reël-binding.
- Herhaal vorige stappe:
a) Skep 'n identiese beleid vir die "verstek/" sleutelvoorvoegsel.
b) Skep 'n rol, noem dit "default-ns-role"
c) Heg die Beleid aan die Rol. - Skep 'n reëlbinding (slegs moontlik vanaf 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"'- Gaan terug na ons "poc-ubuntu-custom-sa" houer en probeer om toegang tot die "default/" kv pad te kry.
- Toestemming geweier.
U kan die gespesifiseerde geloofsbriewe vir elke teken in die UI onder ACL > Tokens bekyk. Soos jy kan sien, is daar net een "custom-sa-role" verbonde aan ons huidige token. Die teken wat ons tans gebruik, is gegenereer toe ons aangemeld het en daar was net een reël-binding toe wat ooreenstem. Ons moet weer aanmeld en die nuwe teken gebruik. - Maak seker dat jy beide "custom-sa/" en "default/" kv paaie kan lees.
Sukses!
Dit is omdat ons "poc-ubuntu-custom-sa" ooreenstem met die "custom-sa" en "default-ns" reëlbindings.
Gevolgtrekking
TTL-token beheer?
Ten tyde van hierdie skrywe is daar geen geïntegreerde manier om die TTL te bepaal vir tokens wat deur hierdie magtigingsmetode gegenereer word nie. Dit sal 'n fantastiese geleentheid wees om veilige magtigingsoutomatisering vir Consul te verskaf.
Daar is 'n opsie om handmatig 'n teken met TTL te skep:
Vervaltyd - Die tyd wat hierdie teken herroep sal word. (Opsioneel; bygevoeg in Consul 1.5.0)- Bestaan slegs vir handmatige skepping/opdatering
Hopelik sal ons binnekort in staat wees om te beheer hoe tokens gegenereer word (vir elke reël of magtigingsmetode) en TTL by te voeg.
Tot dan word voorgestel dat u die uitteken-eindpunt in u logika gebruik.
Lees ook ander artikels op ons blog:
Bron: will.com