Все верно, после релиза в начале мая 2019 года в Consul можно делать авторизацию приложений и служб, запущенных в Kubernetes, нативно.
В этом руководстве мы шаг за шагом создадим (Проверка концепции (Proof of concept, PoC — доказательство [осуществимости] концепции — прим. перев.), продемонстрировав эту новую функцию. От вас ожидаются базовые знания о Kubernetes и Hashicorp’s Consul. И хотя вы можете использовать любую облачную платформу или локальную среду, в этом руководстве мы будем использовать Google’s Cloud Platform.
Обзор
Если мы перейдем к , мы получим краткий обзор его назначения и варианта использования, а также некоторые технические детали и общий обзор логики. Я настоятельно рекомендую прочитать ее по крайней мере один раз, прежде чем продолжить, так как сейчас я буду все это объяснять и разжевывать.
Схема 1: Официальный обзор метода авторизации Consul
Давайте посмотрим в .
Конечно, там есть полезная информация, но нет руководства о том, как на самом деле все это использовать. Поэтому, как любой здравомыслящий человек, вы прочесываете Интернет в поисках руководства. А потом… Терпите поражение. Так бывает. Давайте это исправим.
Прежде чем мы перейдем к созданию нашего POC, давайте вернемся к обзору методов авторизации Consul (Схема 1) и уточним его в контексте Kubernetes.
Архитектура
В этом руководстве мы будем создавать Consul-сервер на отдельной машине, которая будет взаимодействовать с кластером Kubernetes с установленным клиентом Consul. Затем мы создадим наше фиктивное приложение в поде и используем наш настроенный метод авторизации для чтения из нашего Consul key/value хранилища.
Схема ниже детально показывает архитектуру, которую мы создаем в этом руководстве, а также логику метода авторизации, которая будет объяснена позже.
Схема 2: Обзор метода авторизации в Kubernetes
Небольшое замечание: Consul-серверу не нужно жить за пределами кластера Kubernetes, чтобы это работало. Но да, он может и так и сяк.
Итак, взяв обзорную схему Consul (Схема 1) и применив к ней Kubernetes, мы получаем схему выше (Схема 2), и тут логика будет следующая:
- К каждому поду будет прикреплена служебная учетная запись, содержащая токен JWT, сгенерированный и известный Kubernetes. Этот токен также вставляется в под по умолчанию.
- Наше приложение или сервис внутри пода инициирует команду входа в наш Consul-клиент. В запросе на вход в систему также будет указан наш токен и указано имя специально созданного метода авторизации (типа Kubernetes). Этот шаг № 2 соответствует шагу 1 схемы Consul (Схема 1).
- Наш Consul-клиент затем направит этот запрос на наш Consul-сервер.
- МАГИЯ! Именно здесь Consul-сервер проверяет подлинность запроса, собирает сведения об идентичности запроса и сравнивает их с какими-нибудь ассоциированными предопределенными правилами. Ниже будет другая схема, чтобы это проиллюстрировать. Этот шаг соответствует шагам 3, 4 и 5 обзорной схемы Consul (Схема 1).
- Наш Consul-сервер генерирует Consul токен с разрешениями в соответствии с указанными нами правилами метода авторизации (которые мы определили) в отношении личности запрашивающего. Затем он отправит этот токен обратно. Это соответствует шагу 6 схемы Consul (Схема 1).
- Наш Consul-клиент перенаправляет токен запрашивающему приложению или сервису.
Наше приложение или сервис теперь могут использовать этот Consul токен для связи с нашими данными Consul, как было определено привилегиями токена.
Волшебство раскрыто!
Для тех из вас, кто не доволен всего лишь кроликом из шляпы и хочет знать, как это работает… позвольте мне «показать вам, насколько глубока кроличья нора».
Как упоминалось ранее, наш «магический» шаг (Схема 2: Шаг 4) заключается в том, что Consul-сервер проверяет подлинность запроса, собирает сведения об запросе и сравнивает их с любыми ассоциированными предопределенными правилами. Этот шаг соответствует шагам 3, 4 и 5 обзорной схемы Consul (Схема 1). Ниже приведена схема (Схема 3), цель которой наглядно показать, что на самом деле происходит под капотом конкретного метода авторизации Kubernetes.
Схема 3: Волшебство раскрыто!
- В качестве отправной точки, наш Consul-клиент перенаправляет запрос на вход на наш Consul-сервер с токеном учетной записи Kubernetes и конкретным именем инстанса метода авторизации, который был создан ранее. Этот шаг соответствует шагу 3 в предыдущем объяснении схемы.
- Теперь Consul-серверу (или лидеру) необходимо проверить подлинность полученного токена. Поэтому он проконсультируется с кластером Kubernetes (через Consul-клиент) и, при наличии соответствующих разрешений, мы выясним, является ли токен подлинным, и кому он принадлежит.
- Затем проверенный запрос возвращается к Consul-лидеру, и на сервере Consul выполняется поиск инстанса метода авторизации с указанным именем из запроса на вход в систему (и типа Kubernetes).
- Consul-лидер определяет указанный инстанс метода авторизации (если он найден) и читает набор правил привязки, которые к нему прикреплены. Затем он читает эти правила и сравнивает их с проверенными атрибутами идентичности.
- Тада! Переходим к шагу 5 в предыдущем объяснении схемы.
Запустите Consul-server на обычной виртуальной машине
С этого момента я в основном буду давать инструкции по созданию этого POC, часто в пунктах, без пояснительных целых предложений. Также, как отмечалось ранее, я буду использовать GCP для создания всей инфраструктуры, но вы можете создать такую же инфраструктуру в любом другом месте.
- Запустите виртуальную машину (инстанс / сервер).
- Создайте правило для firewall (группа безопасности в AWS):
- Мне нравится присваивать одно и то же имя машины правилу и сетевому тегу, в данном случае это «skywiz-consul-server-poc».
- Найдите IP-адрес вашего локального компьютера и добавьте его в список исходных IP-адресов, чтобы мы могли получить доступ к интерфейсу пользователя (UI).
- Откройте порт 8500 для UI. Нажмите Create (Создать). Мы скоро опять изменим этот firewall [].
- Добавьте правило для firewall к инстансу. Вернитесь на панель мониторинга VM на Consul-сервере и добавьте «skywiz-consul-server-poc» в поле сетевых тегов. Нажмите Save (Сохранить).
- Установите Consul на виртуальную машину, проверьте здесь. Помните, что вам нужна версия Consul ≥ 1.5 [ссылка]
- Создадим single node 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- Вы должны увидеть кучу выходных данных и в конечном итоге “… update blocked by ACLs”.
- Найдите внешний IP-адрес Consul-сервера и откройте браузер с этим IP-адресом на порту 8500. Убедитесь, что открывается UI.
- Попробуйте добавить пару ключ/значение. Должна быть ошибка. Это потому, что мы загрузили Consul-сервер с помощью ACL и запретили все правила.
- Вернитесь к своей оболочке на Consul-сервере и запустите процесс в фоновом режиме или каким-либо другим способом, чтобы он работал, и введите следующее:
consul acl bootstrap- Найдите значение «SecretID» и вернитесь к UI. На вкладке «ACL» введите секретный идентификатор токена, который вы только что скопировали. Скопируйте SecretID еще куда-нибудь, он понадобится нам позже.
- Теперь добавьте пару ключ/значение. Для этого POC добавим следующее: ключ: «custom-ns/test_key», значение: «I’m in the custom-ns folder!»
Запуск Kubernetes-кластера для нашего приложения с Consul-клиентом в качестве Daemonset
- Создайте кластер K8s (Kubernetes). Мы создадим его в той же зоне, что и сервер, для более быстрого доступа, и поэтому мы можем использовать ту же подсеть для простого подключения с внутренними IP-адресами. Мы назовем его «skywiz-app-with-consul-client-poc».
- Как примечание, вот хорошее руководство, с которым я столкнулся при настройке POC Consul-кластера с Consul Connect.
- Мы также будем использовать Hashicorp helm chart с расширенным файлом значений.
- Установите и сконфигурируйте 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- helm chart:
- Используйте следующий файл значений (обратите внимание, большинство я отключил):
### 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 chart:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- При попытке запуска, ему понадобятся разрешения для Consul-сервера, так что давайте добавим их.
- Обратите внимание на «диапазон адресов Pod», расположенный на приборной панели кластера, и вернитесь к нашему правилу для firewall «skywiz-consul-server-poc».
- Добавьте диапазон адресов для пода в список IP-адресов и откройте порты 8301 и 8300.
- Перейдите к Consul UI, и через несколько минут вы увидите, что наш кластер появится на вкладке нод.
Настройка метода авторизации путем интеграции Consul с Kubernetes
- Вернитесь в оболочку Consul-сервера и экспортируйте токен, который вы сохранили ранее:
export CONSUL_HTTP_TOKEN=<SecretID>- Нам понадобится информация из нашего Kubernetes-кластера, чтобы создать инстанс метода auth:
- kubernetes-host
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, заменив placeholders на значения, которые вы только что получили.
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>- Теперь мы свяжем нашу новую роль с инстансом метода 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"'Конфигурации напоследок
Права доступа
- Создайте права доступа. Нам нужно дать разрешение 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Тестирование auth-метода
Теперь давайте посмотрим на магию в действии!
- Создайте еще несколько ключевых папок с тем же ключом верхнего уровня (т. е. <new_folder>/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>"
}- Login!
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>”- Вы можете декодировать «Value» base64 и увидеть, что оно соответствует значению в custom-ns/test_key в UI. Если вы использовали то же значение, приведенное выше в этом руководстве, ваше кодированное значение будет IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Тест учетной записи пользовательской службы:
- Создайте пользовательский ServiceAccount с помощью следующей команды [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Создайте новый файл конфигурации для пода. Обратите внимание, что я включил установку curl для экономии труда 🙂
###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- 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- Permission denied. О, мы забыли добавить новую привязку правил с соответствующими разрешениями, давайте сделаем это сейчас.
Повторите предыдущие шаги выше:
а) Создайте идентичную Политику для префикса «custom-sa/».
б) Создайте Role, назовите ее «custom-sa-role»
в) Прикрепите Политику к Role.
- Создайте Rule-Binding (возможно только из 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». Success!
- Проверьте наш доступ к ключевому пути custom-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».
Permission denied.
Пример оверлея:
- Стоит отметить, что все сопоставления rule-binding будут добавлены в токен с этими правами.
- Наш контейнер «poc-ubuntu-custom-sa» находится в пространстве имен по умолчанию — так что давайте использовать его для другой rule-binding.
- Повторите предыдущие шаги:
а) Создайте идентичную Политику для префикса ключа «default/».
б) Создайте Role, назовите ее “default-ns-role”
в) Прикрепите Политику к Role. - Создайте Rule-Binding (возможно только из 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.
- Permission denied.
Вы можете просмотреть указанные учетные данные для каждого токена в UI в разделе ACL > Tokens. Как видите, к нашему текущему токену прикреплена только одна «custom-sa-role». Токен, который мы используем в настоящее время, был сгенерирован, когда мы вошли в систему, и тогда было только одно rule-binding, которое тогда соответствовало. Нам нужно снова войти в систему и использовать новый токен. - Убедитесь, что вы можете читать как из путей «custom-sa/», так и «default/» kv.
Success!
Это связано с тем, что наш «poc-ubuntu-custom-sa» соответствует привязкам правил «custom-sa» и «default-ns».
Заключение
TTL token mgmt?
На момент написания этой статьи не существует интегрированного способа определения TTL для токенов, сгенерированных этим методом авторизации. Это была бы фантастическая возможность — обеспечить безопасную автоматизацию авторизации Consul.
Существует возможность вручную создать токен с TTL:
Expiration Time (Время истечения) — время, когда этот токен будет отозван. (Необязательно; добавлено в Consul 1.5.0)- Существует только для ручного создания / обновления
Надеюсь, в ближайшее время мы сможем контролировать, как генерируются токены (для каждого правила или метода авторизации), и добавлять TTL.
До тех пор предлагается использовать в своей логике конечную точку выхода из системы.
Также читайте другие статьи в нашем блоге:
Источник: habr.com