Така е, по ослободувањето на почетокот на мај 2019 година, во Конзул можете да овластувате апликации и услуги кои работат во Кубернетс природно.
Во ова упатство ќе креираме чекор по чекор (Доказ за концепт, PoC) што ја демонстрира оваа нова функција. Од вас се очекува да имате основни познавања за Kubernetes и конзулот на Hashicorp. Иако можете да користите која било платформа за облак или околина во просториите, во ова упатство ќе ја користиме платформата за облак на Google.
Преглед
Ако одиме на , ќе добиеме брз преглед на неговата намена и случај на употреба, како и некои технички детали и општ преглед на логиката. Силно препорачувам да го прочитате барем еднаш пред да продолжите, бидејќи сега ќе го објаснам и џвакам сето тоа.
Дијаграм 1: Официјален преглед на методот за овластување конзул
Ајде да погледнеме внатре .
Секако, таму има корисни информации, но нема водич за тоа како всушност да се користи сето тоа. Така, како и секој здрав човек, вие пребарувате на Интернет за насоки. И тогаш... Не успеваш. Се случува. Ајде да го поправиме ова.
Пред да продолжиме со создавањето на нашиот POC, да се вратиме на прегледот на методите за овластување на конзулот (дијаграм 1) и да го рафинираме во контекст на Kubernetes.
архитектура
Во ова упатство, ќе создадеме сервер Consul на посебна машина што ќе комуницира со кластерот Kubernetes со инсталиран клиент Consul. Потоа ќе ја создадеме нашата лажна апликација во подлогата и ќе го користиме нашиот конфигуриран метод за овластување за читање од нашата продавница за клучеви/вредности конзул.
Дијаграмот подолу ја детализира архитектурата што ја креираме во ова упатство, како и логиката зад методот на авторизација, што ќе биде објаснето подоцна.
Дијаграм 2: Преглед на методот за авторизација на Кубернетс
Брза забелешка: серверот Consul не треба да живее надвор од кластерот Kubernetes за ова да функционира. Но да, тој може да го направи тоа вака и онака.
Значи, земајќи го дијаграмот за преглед на конзулот (дијаграм 1) и применувајќи го Kubernetes на него, го добиваме дијаграмот погоре (дијаграм 2), а логиката овде е следна:
- Секој под ќе има сметка за услуга прикачена на неа која содржи JWT токен генериран и познат од Kubernetes. Овој токен исто така стандардно се вметнува во подлогата.
- Нашата апликација или услуга во подлогата иницира команда за најавување на нашиот клиент конзул. Барањето за најава ќе го вклучи и нашиот токен и име специјално создаден метод на овластување (тип Kubernetes). Овој чекор бр. 2 одговара на чекор 1 од дијаграмот конзул (шема 1).
- Нашиот клиент конзул потоа ќе го проследи ова барање до нашиот сервер за конзул.
- МАГИЈА! Овде серверот конзул ја потврдува автентичноста на барањето, собира информации за идентитетот на барањето и го споредува со сите поврзани претходно дефинирани правила. Подолу е уште еден дијаграм за да се илустрира ова. Овој чекор одговара на чекорите 3, 4 и 5 од дијаграмот за преглед на конзулот (дијаграм 1).
- Нашиот конзулски сервер генерира конзулски токен со дозволи според нашите наведени правила за методот на овластување (што ги дефиниравме) во врска со идентитетот на барателот. Потоа ќе го испрати тој токен назад. Ова одговара на чекор 6 од дијаграмот конзул (дијаграм 1).
- Нашиот клиент конзул го проследува токенот до апликацијата или услугата што бара.
Нашата апликација или услуга сега може да го користи овој конзулски токен за да комуницира со податоците на нашиот конзул, како што е определено со привилегиите на токенот.
Магијата е откриена!
За оние од вас кои не се задоволни со само зајак од капа и сакаат да знаат како функционира... дозволете ми „да ви покажам колку длабоко зајачка дупка".
Како што споменавме порано, нашиот „магичен“ чекор (Слика 2: Чекор 4) е местото каде што серверот на конзулот го автентицира барањето, собира информации за барањето и го споредува со сите поврзани претходно дефинирани правила. Овој чекор одговара на чекорите 3, 4 и 5 од дијаграмот за преглед на конзулот (дијаграм 1). Подолу е дијаграм (дијаграм 3), чија цел е јасно да покаже што всушност се случува под хауба специфичен метод за авторизација на Kubernetes.
Дијаграм 3: Магијата е откриена!
- Како почетна точка, нашиот клиент конзул го проследува барањето за најава до нашиот сервер за конзул со токенот на сметката Kubernetes и конкретното име на примерот на методот за овластување што беше креиран претходно. Овој чекор одговара на чекор 3 во претходното објаснување на колото.
- Сега серверот на конзулот (или лидерот) треба да ја потврди автентичноста на примениот токен. Затоа, ќе се консултира со кластерот Kubernetes (преку клиентот конзул) и, со соодветни дозволи, ќе откриеме дали токенот е оригинален и кому му припаѓа.
- Потврденото барање потоа се враќа кај водачот на конзулот, а серверот на конзулот го бара примерот на методот за овластување со наведеното име од барањето за најава (и типот Kubernetes).
- Водачот на конзулот го идентификува наведениот пример на методот за овластување (ако е пронајден) и го чита збирот на обврзувачки правила што се приложени кон него. Потоа ги чита овие правила и ги споредува со атрибутите на проверениот идентитет.
- ТА-дах! Ајде да преминеме на чекор 5 во претходното објаснување на колото.
Стартувај конзул-сервер на обична виртуелна машина
Отсега натаму, главно ќе давам инструкции како да се создаде овој POC, често во точки, без целосно објаснување на реченицата. Исто така, како што беше забележано претходно, ќе користам GCP за да ја креирам целата инфраструктура, но истата инфраструктура можете да ја креирате на кое било друго место.
- Стартувајте ја виртуелната машина (пример/сервер).
- Создадете правило за заштитниот ѕид (безбедносна група во AWS):
- Сакам да го доделам истото име на машината и на правилото и на мрежната ознака, во овој случај „skywiz-consul-server-poc“.
- Пронајдете ја IP адресата на вашиот локален компјутер и додајте ја на списокот со изворни IP адреси за да можеме да пристапиме до корисничкиот интерфејс (UI).
- Отворете ја портата 8500 за UI. Кликнете на Креирај. Наскоро повторно ќе го промениме овој заштитен ѕид [].
- Додајте правило за заштитен ѕид на примерокот. Вратете се на контролната табла на VM на Consul Server и додадете „skywiz-consul-server-poc“ во полето за мрежните ознаки. Кликнете Зачувај.
- Инсталирајте го конзулот на виртуелна машина, проверете овде. Запомнете дека ви треба верзија на конзул ≥ 1.5 [врска]
- Ајде да создадеме еден јазол Конзул - конфигурацијата е како што следува.
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- За подетален водич за инсталирање на Конзул и поставување кластер од 3 јазли, видете .
- Направете датотека /etc/consul.d/agent.json на следниов начин []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Стартувајте го нашиот конзулски сервер:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Треба да видите еден куп излези и да завршите со „... ажурирањето блокирано од ACL“.
- Пронајдете ја надворешната IP адреса на серверот Consul и отворете прелистувач со оваа IP адреса на портата 8500. Проверете дали се отвора UI.
- Обидете се да додадете пар клучеви/вредности. Мора да има грешка. Ова е затоа што го вчитавме серверот Consul со ACL и ги оневозможивме сите правила.
- Вратете се во вашата школка на серверот Consul и започнете го процесот во заднина или на некој друг начин за да го активирате и внесете го следново:
consul acl bootstrap- Најдете ја вредноста „SecretID“ и вратете се на интерфејсот. Во табулаторот ACL, внесете го тајниот ID на токенот што штотуку го копиравте. Копирај го SecretID на друго место, ќе ни треба подоцна.
- Сега додадете пар клучеви/вредности. За овој POC, додадете го следново: клуч: „custom-ns/test_key“, вредност: „Јас сум во папката custom-ns!“
Лансирање кластер Kubernetes за нашата апликација со клиентот Consul како Daemonset
- Креирајте кластер K8s (Kubernetes). Ќе го создадеме во истата зона како и серверот за побрз пристап, и за да можеме да ја користиме истата подмрежа за лесно поврзување со внатрешни IP адреси. Ќе го наречеме „skywiz-app-with-consul-client-poc“.
- Како споредна забелешка, еве еден добар туторијал на кој наидов додека поставував POC Consul кластер со Consul Connect.
- Исто така, ќе користиме дијаграм на кормилото на Hashicorp со датотека со продолжени вредности.
- Инсталирајте и конфигурирајте Helm. Чекори за конфигурација:
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- шема на кормило:
- Користете ја следнава датотека со вредност (забележете дека најмногу ја оневозможив):
### 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- Применете ја табелата на кормилото:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Кога ќе се обиде да работи, ќе му требаат дозволи за серверот Consul, па ајде да ги додадеме.
- Забележете го „Опсегот на адреси на Pod“ кој се наоѓа на контролната табла на кластерот и обратете се на нашето правило за заштитен ѕид „skywiz-consul-server-poc“.
- Додајте го опсегот на адреси за подлогата во списокот со IP адреси и отворете ги портите 8301 и 8300.
- Одете во корисничкиот интерфејс на конзулот и по неколку минути ќе видите дека нашиот кластер се појавува во јазичето јазли.
Конфигурирање на метод за овластување со интегрирање на конзул со Kubernetes
- Вратете се во школката на серверот Consul и извезете го токенот што сте го зачувале претходно:
export CONSUL_HTTP_TOKEN=<SecretID>- Ќе ни требаат информации од нашиот кластер Kubernetes за да создадеме пример од методот auth:
- kubernetes-домаќин
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:- Токенот е кодиран base64, затоа дешифрирајте го користејќи ја вашата омилена алатка []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Земете го сертификатот „ca.crt“ (по декодирањето на base64) и запишете го во датотеката „ca.crt“.
- Сега инстанцирајте го методот auth, заменувајќи ги поставките со вредностите што штотуку ги добивте.
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>"- Следно, треба да создадеме правило и да го прикачиме на новата улога. За овој дел можете да го користите Consul UI, но ние ќе ја користиме командната линија.
- Напишете правило
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Примени го правилото
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- Најдете го ID на правилото што штотуку го креиравте од излезот.
- Создадете улога со ново правило.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Сега ќе ја поврземе нашата нова улога со примерот на методот auth. Забележете дека знамето „избирач“ одредува дали нашето барање за најава ќе ја добие оваа улога. Проверете овде за други опции на избирачот:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'И на крај конфигурации
Права на пристап
- Создадете права за пристап. Треба да му дадеме дозвола на конзулот да го потврди и идентификува идентитетот на токенот за услугата на K8s.
- Напишете го следново во датотеката :
###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- Ајде да создадеме права за пристап
kubectl create -f skywiz-poc-consul-server_rbac.yamlПоврзување со клиентот конзул
- Како што е забележано Постојат неколку опции за поврзување со daemonset, но ние ќе преминеме на следново едноставно решение:
- Примени ја следнава датотека [].
### 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- Потоа користете ја следнава вградена команда за да креирате конфигурациона мапа []. Ве молиме имајте предвид дека ние се повикуваме на името на нашата услуга, заменете го доколку е потребно.
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
Сега да ја видиме магијата на дело!
- Создадете уште неколку папки со клучеви со истото копче од највисоко ниво (т.е. /sample_key) и вредност по ваш избор. Креирајте соодветни политики и улоги за нови клучни патеки. Подоцна ќе ги извршиме врзувањето.
Тест за прилагоден именски простор:
- Ајде да создадеме сопствен именски простор:
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- Сега ќе испратиме барање за најава до конзулот користејќи го методот за овластување што го создадовме порано [].
- За да го видите внесениот токен од вашата сметка на услугата:
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>”- Можете base64 да го декодирате „Value“ и да видите дека се совпаѓа со вредноста во custom-ns/test_key во интерфејсот. Ако ја користевте истата вредност погоре во ова упатство, вашата кодирана вредност ќе биде IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Тест на сметката за корисничка услуга:
- Креирајте сопствена сметка за услуга користејќи ја следнава команда [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Направете нова конфигурациска датотека за подлогата. Ве молиме имајте предвид дека вклучив инсталација на кадрици за да заштедите труд :)
###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- После тоа, вметнете школка во контејнерот.
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- Барањето е одбиено. О, заборавивме да додадеме нови правила обврзувачки со соодветните дозволи, ајде да го направиме тоа сега.
Повторете ги претходните чекори погоре:
а) Направете идентична политика за префиксот „custom-sa/“.
б) Создадете улога, наречете ја „прилагодена улога“
в) Прикачете ја политиката кон улогата.
- Креирајте Правило за врзување (можно само од cli/api). Забележете го различното значење на знамето на избирачот.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Најавете се повторно од контејнерот „poc-ubuntu-custom-sa“. Успех!
- Проверете го нашиот пристап до клучната патека прилагодено-sa/.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Можете исто така да се осигурате дека овој токен не дава пристап до kv во „custom-ns/“. Само повторете ја горната команда откако ќе го замените „custom-sa“ со префиксот „custom-ns“.
Барањето е одбиено.
Пример за преклопување:
- Вреди да се напомене дека сите мапирања за обврзувачки правила ќе бидат додадени на токенот со овие права.
- Нашиот контејнер „poc-ubuntu-custom-sa“ е во стандардниот именски простор - па ајде да го користиме за различно обврзување на правила.
- Повторете ги претходните чекори:
а) Направете идентична политика за префиксот на копчињата „стандардно/“.
б) Создадете улога, именувајте ја „default-ns-role“
в) Прикачете ја политиката кон улогата. - Создајте обврзувачки правила (можно само од 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"'- Вратете се во нашиот контејнер „poc-ubuntu-custom-sa“ и обидете се да пристапите до патеката „default/“ kv.
- Барањето е одбиено.
Можете да ги прегледате наведените ингеренции за секој токен во UI под ACL > Tokens. Како што можете да видите, нашиот сегашен токен има само една „прилагодена улога“ прикачена на него. Токенот што моментално го користиме беше генериран кога се најавивме и имаше само едно обврзувачки правила што се совпаѓаше тогаш. Треба повторно да се најавиме и да го користиме новиот токен. - Осигурајте се дека можете да читате од двете патеки "custom-sa/" и "default/" kv.
Успех!
Ова е затоа што нашата „poc-ubuntu-custom-sa“ се совпаѓа со обврзувачките за правилата „custom-sa“ и „default-ns“.
Заклучок
TTL токен mgmt?
Во моментот на пишување, не постои интегриран начин да се одреди TTL за токените генерирани со овој метод на авторизација. Тоа би било фантастична можност да се обезбеди сигурна автоматизација на овластувањето од конзулот.
Постои опција за рачно креирање токен со TTL:
Време на истекување - Времето во кое овој токен ќе биде отповикан. (Незадолжително; додадено во Конзул 1.5.0)- Постои само за рачно креирање/ажурирање
Се надеваме дека во блиска иднина ќе можеме да контролираме како се генерираат токените (по правило или метод за авторизација) и да додадеме TTL.
Дотогаш, се предлага да користите крајна точка за одјавување во вашата логика.
Прочитајте и други написи на нашиот блог:
Извор: www.habr.com