Det er rigtigt, efter udgivelsen i begyndelsen af maj 2019 kan du i Consul godkende applikationer og tjenester, der kører i Kubernetes indbygget.
I denne tutorial vil vi oprette trin for trin (Proof of concept, PoC), der demonstrerer denne nye funktion. Du forventes at have grundlæggende viden om Kubernetes og Hashicorps konsul. Selvom du kan bruge enhver cloudplatform eller et lokalt miljø, vil vi i denne vejledning bruge Googles Cloud Platform.
Anmeldelse
Hvis vi går til , får vi et hurtigt overblik over dets formål og brugssituation, samt nogle tekniske detaljer og et generelt overblik over logikken. Jeg anbefaler stærkt at læse den mindst én gang, før jeg fortsætter, da jeg nu vil forklare og tygge på det hele.
Skema 1: Officiel oversigt over Consul-autorisationsmetoden
Lad os se nærmere på .
Selvfølgelig er der nyttig information der, men der er ingen guide til, hvordan man rent faktisk bruger det hele. Så som enhver fornuftig person gennemsøger du internettet for at få vejledning. Og så... Du fejler. Det sker. Lad os ordne dette.
Før vi går videre til at oprette vores POC, lad os gå tilbage til oversigten over Consul-autorisationsmetoder (Diagram 1) og forfine den i forbindelse med Kubernetes.
arkitektur
I denne vejledning vil vi oprette en Consul-server på en separat maskine, der kommunikerer med en Kubernetes-klynge med Consul-klienten installeret. Vi vil derefter oprette vores dummy-applikation i poden og bruge vores konfigurerede godkendelsesmetode til at læse fra vores Consul-nøgle-/værdilager.
Diagrammet nedenfor viser i detaljer den arkitektur, vi opretter i denne vejledning, samt godkendelsesmetodelogikken, som vil blive forklaret senere.
Diagram 2: Oversigt over Kubernetes-godkendelsesmetode
En hurtig note: Consul-serveren behøver ikke at bo uden for Kubernetes-klyngen, for at dette fungerer. Men ja, det kan han begge veje.
Så hvis vi tager Consul-oversigtsskemaet (skema 1) og anvender Kubernetes på det, får vi skemaet ovenfor (skema 2), og her vil logikken være som følger:
- Hver pod vil have en servicekonto knyttet til sig, indeholdende et JWT-token genereret og kendt af Kubernetes. Dette token er også indsat i poden som standard.
- Vores applikation eller service inde i poden starter en login-kommando til vores Consul-klient. Loginanmodningen vil også indeholde vores token og navn specielt skabt autorisationsmetode (Kubernetes-type). Dette trin #2 svarer til trin 1 i Consul-diagrammet (skema 1).
- Vores Consul-klient videresender derefter denne anmodning til vores Consul-server.
- MAGI! Det er her, Consul-serveren autentificerer anmodningen, indsamler identiteten af anmodningen og sammenligner den med eventuelle tilknyttede foruddefinerede regler. Nedenfor er et andet diagram for at illustrere dette. Dette trin svarer til trin 3, 4 og 5 i Consul-oversigtsdiagrammet (Diagram 1).
- Vores Consul-server genererer et Consul-token med tilladelser i henhold til de autorisationsmetoderegler, vi specificerede (som vi definerede) vedrørende anmoderens identitet. Det vil derefter sende det token tilbage. Dette svarer til trin 6 i Consul-diagrammet (Diagram 1).
- Vores Consul-klient videresender tokenet til den anmodende applikation eller tjeneste.
Vores applikation eller service kan nu bruge dette Consul-token til at kommunikere med vores Consul-data, som bestemt af tokenets privilegier.
Magien afsløres!
Til dem af jer, der ikke er tilfredse med bare en kanin ud af en hat og gerne vil vide, hvordan det virker... lad mig "vise jer, hvor dybt kanin hul'.
Som nævnt tidligere er vores "magiske" trin (skema 2: Trin 4) for Consul-serveren at autentificere anmodningen, indsamle information om anmodningen og sammenligne den med eventuelle tilknyttede foruddefinerede regler. Dette trin svarer til trin 3, 4 og 5 i Consul-oversigtsdiagrammet (Diagram 1). Nedenfor er et diagram (skema 3), hvis formål er tydeligt at vise, hvad der rent faktisk sker under kølerhjelmen specifik Kubernetes-godkendelsesmetode.
Diagram 3: Magien afsløres!
- Som udgangspunkt videresender vores Consul-klient login-anmodningen til vores Consul-server med Kubernetes-kontotokenet og det specifikke instansnavn på den autorisationsmetode, vi oprettede tidligere. Dette trin svarer til trin 3 i den foregående kredsløbsforklaring.
- Nu skal Consul-serveren (eller lederen) bekræfte ægtheden af det modtagne token. Derfor vil den rådføre sig med Kubernetes-klyngen (via Consul-klienten), og med de relevante tilladelser finder vi ud af, om tokenet er ægte, og hvem der ejer det.
- Den validerede anmodning returneres derefter til Consul-lederen, og Consul-serveren slår autorisationsmetodeforekomsten op med det angivne navn fra login-anmodningen (og Kubernetes-typen).
- Konsullederen bestemmer den angivne autorisationsmetodeinstans (hvis den findes) og læser det sæt af bindende regler, der er knyttet til den. Den læser derefter disse regler og sammenligner dem med de verificerede identitetsattributter.
- TA-dah! Lad os gå videre til trin 5 i den forrige kredsløbsforklaring.
Kør Consul-server på en almindelig virtuel maskine
Fra nu af vil jeg hovedsagelig give instruktioner til oprettelse af denne POC, ofte i afsnit, uden forklarende hele sætninger. Som tidligere nævnt vil jeg også bruge GCP til at skabe hele infrastrukturen, men du kan oprette den samme infrastruktur andre steder.
- Start den virtuelle maskine (instans/server).
- Opret en firewall-regel (en sikkerhedsgruppe i AWS):
- Jeg kan godt lide at tildele det samme maskinnavn til reglen og netværksmærket, i dette tilfælde "skywiz-consul-server-poc".
- Find IP-adressen på din lokale computer, og tilføj den til listen over kilde-IP-adresser, så vi kan få adgang til brugergrænsefladen (UI).
- Åbn port 8500 for UI. Klik på Opret. Vi vil snart ændre denne firewall igen [].
- Tilføj en firewall-regel til forekomsten. Gå tilbage til VM-dashboardet på Consul-serveren og tilføj "skywiz-consul-server-poc" til netværksmærkefeltet. Klik på Gem.
- Installer Consul på en virtuel maskine, tjek her. Husk at du skal bruge Consul version ≥ 1.5 [link]
- Lad os oprette en enkelt knudekonsul - konfigurationen er som følger.
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- For en mere detaljeret vejledning om installation af Consul og opsætning af en klynge med 3 noder, se .
- Opret fil /etc/consul.d/agent.json som denne []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Start vores Consul-server:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Du skulle se en masse output og til sidst "... opdatering blokeret af ACL'er".
- Find den eksterne IP-adresse på Consul-serveren, og åbn en browser med den IP-adresse på port 8500. Sørg for, at brugergrænsefladen åbner.
- Prøv at tilføje et nøgle/værdi-par. Der må være en fejl. Dette skyldes, at vi indlæste Consul-serveren med en ACL og deaktiverede alle regler.
- Gå tilbage til din shell på Consul-serveren og start processen i baggrunden eller på en anden måde for at få det til at fungere, og skriv følgende:
consul acl bootstrap- Find "SecretID"-værdien og vend tilbage til brugergrænsefladen. På fanen ACL skal du indtaste det hemmelige token-id, du lige har kopieret. Kopier SecretID et andet sted, vi får brug for det senere.
- Tilføj nu et nøgle/værdi-par. Til denne POC skal du tilføje følgende: nøgle: "custom-ns/test_key", værdi: "Jeg er i mappen custom-ns!"
Start af en Kubernetes-klynge til vores applikation med Consul-klienten som en Daemonset
- Opret en K8s (Kubernetes) klynge. Vi vil oprette det i samme zone som serveren for hurtigere adgang, og så vi kan bruge det samme undernet til nemt at forbinde med interne IP'er. Vi kalder den "skywiz-app-with-consul-client-poc".
- Som en sidebemærkning er her en god guide, jeg stødte på, da jeg oprettede en Consul POC-klynge med Consul Connect.
- Vi vil også bruge Hashicorp ror-diagrammet med en udvidet værdi-fil.
- Installer og konfigurer Helm. Konfigurationstrin:
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- styrkort:
- Brug følgende værdifil (bemærk, at jeg har deaktiveret de fleste):
### 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- Anvend rordiagram:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Når den forsøger at køre, skal den have tilladelser til Consul-serveren, så lad os tilføje dem.
- Læg mærke til "Pod address range" placeret på klyngens dashboard og gå tilbage til vores "skywiz-consul-server-poc" firewall-regel.
- Tilføj adresseområdet for poden til listen over IP-adresser, og åbn porte 8301 og 8300.
- Gå til Consul UI, og om et par minutter vil du se vores klynge vises på fanen noder.
Tilpasning af godkendelsesmetoden ved at integrere Consul med Kubernetes
- Vend tilbage til Consul-serverskallen og eksporter det token, du tidligere gemte:
export CONSUL_HTTP_TOKEN=<SecretID>- Vi har brug for oplysninger fra vores Kubernetes-klynge for at instansiere godkendelsesmetoden:
- kubernetes vært
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:- Tokenet er base64-kodet, så dekrypter det med dit yndlingsværktøj []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Tag "ca.crt"-certifikatet (efter base64-afkodning) og læg det i "ca.crt"-filen.
- Instantiér nu godkendelsesmetoden, og udskift pladsholderne med de værdier, du lige har modtaget.
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>"- Dernæst skal vi oprette en regel og knytte den til den nye rolle. Til denne del kan du bruge Consul UI, men vi vil bruge kommandolinjen.
- Skriv en regel
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Anvend reglen
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- Find id'et for den regel, du lige har oprettet fra outputtet.
- Opret en rolle med en ny regel.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Nu vil vi knytte vores nye rolle til godkendelsesmetodeforekomsten. Bemærk, at "vælger"-flaget bestemmer, om vores login-anmodning vil modtage denne rolle. Tjek her for andre valgmuligheder:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Til sidst konfigurationer
Adgangsrettigheder
- Opret adgangsrettigheder. Vi skal give Consul tilladelse til at verificere og identificere identiteten af K8s servicekontotoken.
- Skriv følgende til filen :
###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- Lad os skabe adgangsrettigheder
kubectl create -f skywiz-poc-consul-server_rbac.yamlOpretter forbindelse til Consul Client
- Som nævnt , der er flere muligheder for at oprette forbindelse til daemonset, men vi går videre til den næste enkle løsning:
- Anvend følgende fil [].
### 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- Brug derefter følgende indbyggede kommando til at oprette et configmap []. Bemærk venligst, at vi henviser til navnet på vores tjeneste, udskift det om nødvendigt.
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}')"]}
EOFTest af godkendelsesmetoden
Lad os nu se magien i aktion!
- Opret nogle flere nøglemapper med den samme nøgle på øverste niveau (dvs. /sample_key) og en værdi efter eget valg. Opret de relevante politikker og roller for de nye nøglestier. Vi laver bindingerne senere.
Tilpasset navnerumstest:
- Lad os skabe vores eget navneområde:
kubectl create namespace custom-ns- Lad os oprette en pod i vores nye navneområde. Skriv konfigurationen for poden.
###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- Opret under:
kubectl create -f poc-ubuntu-custom-ns.yaml- Når beholderen kører, skal du gå dertil og installere curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Vi sender nu en login-anmodning til Consul ved hjælp af den autorisationsmetode, vi oprettede tidligere [].
- Sådan får du vist det indtastede token fra din tjenestekonto:
cat /run/secrets/kubernetes.io/serviceaccount/token- Skriv følgende til en fil inde i beholderen:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Log på!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- For at køre ovenstående trin på én linje (da vi vil køre flere test), kan du gøre følgende:
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- Arbejder! Det burde den i hvert fald. Tag nu SecretID'et og prøv at få adgang til den nøgle/værdi, vi skal have adgang til.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Du kan afkode "Value" base64 og se, at den matcher værdien i custom-ns/test_key i brugergrænsefladen. Hvis du brugte den samme værdi som angivet tidligere i denne vejledning, ville din kodede værdi være IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Brugerservicekontotest:
- Opret en brugerdefineret servicekonto med følgende kommando [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Opret en ny konfigurationsfil til poden. Bemærk venligst, at jeg inkluderede krølleinstallationen for at spare arbejdskraft :)
###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- Kør derefter en skal inde i beholderen.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Log på!
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- Adgang nægtet. Åh, vi glemte at tilføje en ny regelbinding med de relevante tilladelser, lad os gøre det nu.
Gentag de foregående trin ovenfor:
a) Opret en identisk politik for præfikset "custom-sa/".
b) Opret en rolle, kald den "custom-sa-rolle"
c) Vedhæft politikken til rollen.
- Opret en regelbinding (kun muligt fra cli/api). Bemærk den forskellige værdi af vælgerflaget.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Prøv igen at logge ind fra "poc-ubuntu-custom-sa"-beholderen. Succes!
- Tjek vores adgang til brugerdefineret-sa/-nøglestien.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Du kan også sikre dig, at denne token ikke giver adgang til kv i "custom-ns/". Bare gentag ovenstående kommando efter at have erstattet "custom-sa" med "custom-ns" præfiks.
Adgang nægtet.
Eksempel på overlejring:
- Det er værd at bemærke, at alle regelbindende tilknytninger vil blive føjet til tokenet med disse rettigheder.
- Vores container "poc-ubuntu-custom-sa" er i standardnavnerummet - så lad os bruge det til en anden regelbinding.
- Gentag de foregående trin:
a) Opret en identisk politik for "default/" nøglepræfikset.
b) Opret en rolle, navngiv den "default-ns-rolle"
c) Vedhæft politikken til rollen. - Opret en regelbinding (kun muligt fra 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"'- Gå tilbage til vores "poc-ubuntu-custom-sa" container og prøv at få adgang til "default/" kv stien.
- Adgang nægtet.
Du kan se de angivne legitimationsoplysninger for hvert token i brugergrænsefladen under ACL > Tokens. Som du kan se, er der kun én "custom-sa-rolle" knyttet til vores nuværende token. Det token, vi bruger i øjeblikket, blev genereret, da vi loggede ind, og der var kun én regelbinding, der matchede. Vi skal logge ind igen og bruge det nye token. - Sørg for, at du kan læse fra både "custom-sa/" og "default/" kv stier.
Succes!
Dette skyldes, at vores "poc-ubuntu-custom-sa" matcher regelbindingerne "custom-sa" og "default-ns".
Konklusion
TTL token håndtering?
På tidspunktet for denne skrivning er der ingen integreret måde at bestemme TTL for tokens genereret af denne godkendelsesmetode. Det ville være en fantastisk mulighed for at give sikker automatisering af Consul-autorisation.
Der er en mulighed for manuelt at oprette et token med TTL:
Udløbstid - Det tidspunkt, hvor dette token vil blive tilbagekaldt. (Valgfrit; tilføjet i Consul 1.5.0)- Eksisterer kun til manuel oprettelse/opdatering
Forhåbentlig vil vi snart være i stand til at kontrollere, hvordan tokens genereres (for hver regel eller godkendelsesmetode) og tilføje TTL.
Indtil da foreslås det at bruge logout-slutpunktet i din logik.
Læs også andre artikler på vores blog:
Kilde: www.habr.com