Въведение в разрешението за Kubernetes на Hashicorp Consul

Точно така, след освобождаването Hashicorp Consul 1.5.0 в началото на май 2019 г. Consul може да упълномощи приложения и услуги, работещи в Kubernetes.

В този урок ще създаваме стъпка по стъпка POC (Доказателство за концепция, PoC), демонстриращ тази нова функция. От вас се очаква да имате основни познания за Kubernetes и Consul на Hashicorp. И докато можете да използвате всяка облачна платформа или локална среда, в този урок ние ще използваме облачната платформа на Google.

Преглед

Ако отидем на Консулска документация относно начина му на упълномощаване, ще получим кратък преглед на неговата цел и случай на използване, както и някои технически подробности и общ преглед на логиката. Силно препоръчвам да го прочетете поне веднъж, преди да продължите, тъй като сега ще го обясня и дъвча всичко.

Схема 1: Официален преглед на метода за упълномощаване на консул

Нека да разгледаме документация за конкретен метод за оторизация на Kubernetes.

Разбира се, там има полезна информация, но няма ръководство за това как всъщност да се използва цялата. И така, като всеки здравомислещ човек, вие ровете в интернет за насоки. И тогава... Бъди победен. Случва се. Нека поправим това.

Преди да преминем към създаването на нашия POC, нека се върнем към прегледа на методите за оторизация на Consul (Диаграма 1) и да го прецизираме в контекста на Kubernetes.

архитектура

В този урок ще създадем Consul сървър на отделна машина, която ще взаимодейства с Kubernetes клъстер с инсталиран Consul клиент. След това ще създадем нашето фиктивно приложение в групата и ще използваме нашия конфигуриран метод за оторизация, за да четем от нашето хранилище за ключ/стойност Consul.

Диаграмата по-долу показва в детайли архитектурата, която създаваме в този урок, както и логиката на метода за оторизация, която ще бъде обяснена по-късно.

Диаграма 2: Общ преглед на метода за оторизация на Kubernetes

Кратка бележка: не е необходимо сървърът Consul да живее извън клъстера Kubernetes, за да работи това. Но да, той може и в двата случая.

И така, като вземем схемата за преглед на Consul (схема 1) и приложим Kubernetes към нея, получаваме схемата по-горе (схема 2), а тук логиката ще бъде следната:

1. Всеки pod ще има акаунт за услуга, прикачен към него, съдържащ JWT токен, генериран и известен от Kubernetes. Този токен също се вмъква в групата по подразбиране.
2. Нашето приложение или услуга в под ще инициира команда за влизане към нашия клиент Consul. Заявката за влизане ще включва също нашия токен и име специално създадени метод за оторизация (като Kubernetes). Тази стъпка #2 съответства на стъпка 1 от веригата Consul (Диаграма 1).
3. След това нашият клиент Consul ще препрати тази заявка към нашия сървър Consul.
4. МАГИЯ! Това е мястото, където сървърът Consul удостоверява заявката, събира самоличността на заявката и я сравнява с всички свързани предварително дефинирани правила. По-долу има друга диаграма, която илюстрира това. Тази стъпка съответства на стъпки 3, 4 и 5 от диаграмата за преглед на Consul (Диаграма 1).
5. Нашият Consul сървър генерира Consul токен с разрешения в съответствие с правилата на метода за оторизация, които сме посочили (които сме дефинирали) по отношение на самоличността на заявителя. След това ще изпрати този токен обратно. Това съответства на стъпка 6 от схемата Consul (Диаграма 1).
6. Нашият клиент Consul препраща токена към искащото приложение или услуга.

Нашето приложение или услуга вече може да използва този токен на Consul, за да комуникира с нашите данни на Consul, както е определено от привилегиите на токена.

Магията е разкрита!

За тези от вас, които не са доволни само от зайче от шапка и искат да знаят как работи... нека ви „покажа колко дълбоко заешка дупка".

Както бе споменато по-рано, нашата „магическа“ стъпка (Схема 2: Стъпка 4) е сървърът Consul да удостовери заявката, да събере информация за заявката и да я сравни с всички свързани предварително дефинирани правила. Тази стъпка съответства на стъпки 3, 4 и 5 от диаграмата за преглед на Consul (Диаграма 1). По-долу има диаграма (схема 3), чиято цел е ясно да покаже какво всъщност се случва под капака специфичен метод за оторизация на Kubernetes.

Диаграма 3: Магията е разкрита!

1. Като отправна точка нашият клиент Consul препраща заявката за влизане към нашия сървър Consul с маркера на акаунта Kubernetes и конкретното име на екземпляра на метода за оторизация, който създадохме по-рано. Тази стъпка съответства на стъпка 3 в обяснението на предишната диаграма.
2. Сега сървърът на Consul (или лидерът) трябва да провери автентичността на получения токен. Следователно той ще се консултира с клъстера на Kubernetes (чрез клиента Consul) и с подходящите разрешения ще разберем дали токенът е истински и кой го притежава.
3. След това валидираната заявка се връща на лидера на Consul и сървърът на Consul се търси за екземпляр на метод за оторизация с посоченото име от заявката за влизане (и тип Kubernetes).
4. Лидерът на консула определя конкретния екземпляр на метода за оторизация (ако е намерен) и чете набора от обвързващи правила, които са прикачени към него. След това той чете тези правила и ги сравнява с проверените атрибути за самоличност.
5. ТА-да! Отидете на стъпка 5 в предишното обяснение на веригата.

Стартирайте Consul-сървър в нормална виртуална машина

Отсега нататък основно ще давам инструкции за създаване на този POC, често в параграфи, без обяснителни цели изречения. Освен това, както беше отбелязано по-рано, ще използвам GCP за създаване на цялата инфраструктура, но можете да създадете същата инфраструктура навсякъде другаде.

• Стартирайте виртуалната машина (екземпляр / сървър).

• Създайте правило за защитна стена (група за сигурност в AWS):
• Обичам да присвоявам едно и също име на машина на правилото и мрежовия таг, в този случай "skywiz-consul-server-poc".
• Намерете IP адреса на вашия локален компютър и го добавете към списъка с изходни IP адреси, за да имаме достъп до потребителския интерфейс (UI).
• Отворете порт 8500 за UI. Щракнете върху Създаване. Скоро отново ще променим тази защитна стена [връзка].
• Добавете правило за защитна стена към екземпляра. Върнете се към таблото за управление на VM на сървъра Consul и добавете „skywiz-consul-server-poc“ към полето за мрежови тагове. Щракнете върху Запазване.

• Инсталирайте Consul на виртуална машина, проверете тук. Не забравяйте, че имате нужда от Consul версия ≥ 1.5 [link]
• Нека създадем един възел Consul - конфигурацията е следната.

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

• За по-подробно ръководство за инсталиране на Consul и настройка на клъстер с 3 възела вижте тук.
• Създайте файл /etc/consul.d/agent.json като този [връзка]:

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

• Стартирайте нашия Consul сървър:

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. Уверете се, че потребителският интерфейс се отваря.
• Опитайте да добавите двойка ключ/стойност. Трябва да има грешка. Това е така, защото заредихме сървъра Consul с ACL и отказахме всички правила.
• Върнете се към вашата обвивка на сървъра Consul и стартирайте процеса във фонов режим или по някакъв друг начин, за да работи, и въведете следното:

consul acl bootstrap

• Намерете стойността "SecretID" и се върнете към потребителския интерфейс. В раздела ACL въведете идентификатора на тайния токен, който току-що копирахте. Копирайте SecretID някъде другаде, ще ни трябва по-късно.
• Сега добавете двойка ключ/стойност. За този POC добавете следното: ключ: "custom-ns/test_key", стойност: "Аз съм в папката custom-ns!"

Стартиране на Kubernetes клъстер за нашето приложение с клиента Consul като Daemonset

• Създайте клъстер K8s (Kubernetes). Ще го създадем в същата зона като сървъра за по-бърз достъп и за да можем да използваме същата подмрежа за лесно свързване с вътрешни IP адреси. Ще го кръстим „skywiz-app-with-consul-client-poc“.

• Като странична бележка, ето едно добро ръководство, на което попаднах, когато настройвах Consul POC клъстер с 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

• helmchart: https://www.consul.io/docs/platform/k8s/helm.html
• Използвайте следния файл със стойности (имайте предвид, че съм деактивирал повечето):

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

• Отидете на Consul UI и след няколко минути ще видите нашия клъстер да се появява в раздела с възли.

Персонализиране на метода за оторизация чрез интегриране на Consul с Kubernetes

• Върнете се в обвивката на сървъра Consul и експортирайте токена, който сте запазили по-рано:

export CONSUL_HTTP_TOKEN=<SecretID>

• Имаме нужда от информация от нашия Kubernetes клъстер, за да инстанцираме метода за удостоверяване:
• хост 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-серт

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

• Вземете сертификата „ca.crt“ (след декодиране на base64) и го поставете във файла „ca.crt“.
• Сега инстанцирайте метода за удостоверяване, като замените контейнерите със стойностите, които току-що сте получили.

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

• Намерете идентификатора на правилото, което току-що създадохте, от изхода.
• Създайте роля с ново правило.

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id <policy_id>

• Сега ще свържем нашата нова роля с екземпляра на метода за удостоверяване. Имайте предвид, че флагът "селектор" определя дали нашата заявка за влизане ще получи тази роля. Вижте тук за други опции за избор: 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"'

Конфигурации в крайна сметка

Права за достъп

• Създаване на разрешения. Трябва да дадем разрешение на Consul да провери и идентифицира самоличността на токена на акаунта на услугата 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

Свързване с Consul Client

• Както е споменато тук, има няколко опции за свързване към 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

• След това използвайте следната вградена команда, за да създадете configmap [връзка]. Имайте предвид, че имаме предвид името на нашата услуга, променете го, ако е необходимо.

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

Тестване на метода за удостоверяване

Сега нека видим магията в действие!

• Създайте още няколко ключови папки със същия ключ от най-високо ниво (т.е. /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

• Сега ще изпратим заявка за влизане на Consul, използвайки метода за оторизация, който създадохме по-рано [връзка].
• За да видите въведения токен от вашия сервизен акаунт:

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 и да видите, че съответства на стойността в custom-ns/test_key в потребителския интерфейс. Ако сте използвали същата стойност, дадена по-рано в това ръководство, вашата кодирана стойност ще бъде IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Тест на акаунт за потребителска услуга:

• Създайте персонализиран ServiceAccount със следната команда [връзка].

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

• Разрешението е отказано. О, забравихме да добавим ново правило, обвързващо със съответните разрешения, нека го направим сега.

Повторете предишните стъпки по-горе:
a) Създайте идентична политика за префикса "custom-sa/".
b) Създайте роля, наименувайте я „custom-sa-role“
c) Прикрепете политиката към ролята.

• Създайте обвързване на правило (възможно само от 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". Успех!
• Проверете нашия достъп до custom-sa/ key path.

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" е в пространството на имената по подразбиране - така че нека го използваме за друго обвързване на правила.
• Повторете предишните стъпки:
  a) Създайте идентична политика за префикса на ключа "default/".
  b) Създайте роля, наименувайте я „default-ns-role“
  c) Прикрепете политиката към ролята.
• Създайте обвързване на правило (възможно само от 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" и опитайте да получите достъп до kv пътя "default/".
• Разрешението е отказано.
  Можете да видите посочените идентификационни данни за всеки токен в потребителския интерфейс под ACL > Токени. Както можете да видите, има само една "custom-sa-role", прикрепена към нашия текущ токен. Токенът, който използваме в момента, беше генериран, когато влязохме и имаше само едно обвързване на правило, което съвпадна. Трябва да влезем отново и да използваме новия токен.
• Уверете се, че можете да прочетете както „custom-sa/“, така и „default/“ kv пътища.
  Успех!
  Това е така, защото нашият "poc-ubuntu-custom-sa" съответства на обвързванията на правилата "custom-sa" и "default-ns".

Заключение

Управление на TTL токен?

Към момента на писане няма интегриран начин за определяне на TTL за токени, генерирани от този метод на оторизация. Би било фантастична възможност да се осигури сигурна автоматизация на оторизацията за Consul.

Има опция за ръчно създаване на токен с TTL:

• https://www.consul.io/docs/acl/acl-system.html#acl-tokens
  Време на изтичане - Времето, в което този токен ще бъде отменен. (По избор; добавено в Consul 1.5.0)
• Съществува само за ръчно създаване/актуализиране https://www.consul.io/api/acl/tokens.html#expirationtime

Надяваме се, че скоро ще можем да контролираме как се генерират токени (за всяко правило или метод за оторизация) и да добавим TTL.

Дотогава се препоръчва да използвате крайната точка за излизане във вашата логика.

• https://www.consul.io/api/acl/acl.html#logout-from-auth-method
• https://www.consul.io/docs/acl/acl-auth-methods.html#overall-login-process

Прочетете и други статии в нашия блог:

• До какво доведе миграцията от ClickHouse без авторизация към ClickHouse с авторизация?
• Как да стартирате множество конвейери с GitLab CI/CD
• Три лесни трика за свиване на Docker изображения
• Traefik като входен контролер за K8S
• Архивиране на голям брой разнородни уеб проекти
• Telegram бот за Redmine. Как да направим живота по-лесен за себе си и другите

Източник: www.habr.com