Работа с сертификатами в Consul

Опубликовано: 22.02.2023

Используемые термины: Consul, Linux.

В сервер consul встроен центр сертификации, на основе которого он создает ключи для сервиса connect или при запуске веб-сервиса на https. Однако, системой предусмотрена процедура замены данного сертификата на свой. В данной инструкции рассмотрим данную возможность и рассмотрим дополнительно настройку работы веб UI по HTTPS. Работать будем на Linux.

Готовим систему к работе
Отображение информации о сертификатах
Используем свой сертификат
Настройка https для UI
Дополнительная информация

Подготовка к работе

Предполагается, что мы будем работать в каталоге /etc/ssl/consul. Создадим его и перейдем в данную папку:

mkdir /etc/ssl/consul

cd /etc/ssl/consul

Работа с центром сертификации ведется посредством API запросов, которые мы выполняем с помощью утилиты curl. Также, ответы, которые мы получает имеют формат json. В консоли данный формат смотрится некрасиво и неудобно. Чтобы улучшить ситуацию, можно использовать приложение jq.

Итого, нам нужно установить пакеты curl и jq. В зависимости от типа Linux, команды будут немного отличаться.

а) на DEB (Debian / Ubuntu / Astra Linux):

apt install curl jq

б) на RPM (Rocky Linux / CentOS / РЕД ОС):

yum install curl jq

Получение информации

Список корневых сертификатов, загруженных в consul:

curl http://localhost:8500/v1/connect/ca/roots | jq

Команда вернет массив корневых сертификатов. Из них активный только один — для его ключа Active должно быть указано значение true. С помощью утилиты jq мы можем отобразить только активный ключ:

curl http://localhost:8500/v1/connect/ca/roots | jq .Roots | jq '.[] | select(.Active==true)'

Также можно сохранить значение RootCert в формат pem:

И уже посмотреть подробную информацию о сертификате:

openssl x509 -text -in consul.pem

Командой ниже мы можем увидеть настройки для ca:

curl --header "Authorization: Bearer <Consul Token>" http://127.0.0.1:8500/v1/connect/ca/configuration | jq

* header Authorization можно упустить, если наш сервер consul не использует ACL.

Команда позволит нам увидеть закрытый ca ключ и некоторые настройки.

Загрузка собственного сертификата

Для начала, у нас должен быть сертификат. Есть много способов его получить:

Купить.
Получить бесплатно от Let's Encrypt.
Сгенерировать самоподписанный сертификат.
Запросить у собственного центра сертификации.

Некоторые из данных способов описаны на сайте. Ссылки приведены в конце инструкции.

Для наших тестовых целей достаточно самоподписанного сертификата. Сгенерируем его командой:

openssl req -new -x509 -days 3670 -nodes -out ca.pem -keyout ca.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=consul.dmosk.ru"

* в данном примере мы сгенерируем открытый и закрытый ключи ca.pem и ca.key; срок действия ключа 10 лет.

Для загрузки последовательности, нам нужно убрать из нее все переносы строк. Это можно сделать в любом текстовом редакторе вручную или командами:

cat ca.pem | tr '\n' '~' | sed 's/~/\\n/g' && echo " "

cat ca.key | tr '\n' '~' | sed 's/~/\\n/g' && echo " "

Полученные результаты фиксируем. Они нам понадобятся на следующем шаге.

Создаем файл:

vi payload.json

{
"Provider": "consul",
"Config": {
"LeafCertTTL": "72h",
"PrivateKey": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDgfAFPOZdMxqCs\nfBHFQvGUCjk+CpzXYtAMs4bCk/jtFCjA+VtMw5KwfMSyx9Es2JZx7u1NqL1bBh9T\ni3qdDMgpVldjSu82er7jVCE455pACcS8wX+b6rWPymut0DzpWQdC+MowFuBw2t9B\nf8rBDd4DIU7L0/KYMMrrtHzMZuKUjFCXmHSFuYoKVBXGJ7aRy5zrOh2IByARzpEc\nUlyb0XCKSGIQ31MHMznX2sdeFxGBYuA21Q689AUchkM052VQBkta4Eo7NLaUAXA3\nCGTHm6UqWJ3XnYPT2H+96dWvz9rIyaYS9duuhu2i8KWj3Z3KQrmwAjVtX6XoXsYe\nnAmqCSqxAgMBAAECggEBAIesSrpQK1Japdc5cSAQsqLvfuMxVNOUQ/u5MRQ+jG71\nBSCEVJrThL+n2NXYkGKTUHHxnniWKENwMtSyctuiUwMwzMYVDviVPPN18FJNH9ve\nS4ptRCu+shcClwvI1FeP2CSw6rofyWxLzCzxCGCfefPYWKA2K+OxcaL9RYPgFscB\n2PvWQ2prXXT3ceUU/rIarVGUIFBUby6fdY9JjN8x6fS0rX/LB9yAbdUIvimeQlvc\nzHF60eIIinSsPJ4C5CUl05bubvtE8MzMoo5VRAxbrbqJCMg8Cdk8egJ+EWIxSx5n\nvpqCYEnc7n2YsAIKK+e7Xo/jXDigoG4V3EwiZea7ElUCgYEA9qRv+ONQdPll4hUx\nwBHLxnkwxPXmBbEOsvvppj2ZM1rhwunO6uXWcWdWLg/5nxP34ZzcH87PvEI1mzSr\nl/cWX+OeAPjQzvtH8mFpbgN4WMsCgYEA6QBato+ufbwy6AlPFrnxinMwJ07NijW3\nWgWAl0a1iMJTG0Z+LwFbCnvK6Ly/w3KlUFidyhNIarULqVa/yP2cI/5gIkoBsdaZ\nyL+fcxV8l3NYnKeMBq+FGhAGM9W48lGi6MoJtoVVRgFBYw2A2RgHuNgfYmBSnyuP\ndBCOJVDEZvMCgYBT7nVkPwa8J7qyCwAmq3E+ER+2ObO5DQdz6Vnv06sZmeShGUDJ\nYynY4nvipPUA4ZCTlbIzoYC9hh9GRlH88pFjww4DmKJkQXJ9GhjSx5eA0GaPS71s\nVjZ5dO7w0eLibYsnLZgDAv/SUr2nSW8zUZQ9oVm9fu6f4QcExn14QJoNrQKBgF59\n6Ev1RRx0wGhdrhdXXV96i2LFkJGmay804At5f5FwzWdYVUAW2qcLwSRVt6c5zVUi\nOwuCenHb7ljEd465WyM1vCLrxHgswb0qCS4Q3rBE9QDC6gSkFeSV7w4CdLjA5sJl\nfT7qH8T+KVhUV5azKh6Kd1/cFGW8sratKBh2AtCFAoGBAMDZuOK5u+PQl/DXewVp\n55fKyhOrOXckNPgByz4f1OnFXvLVzWEZ+ReUrNRqnFkcNYtu+u9lebzxDU4DMN1q\nixej72JftUsrSiFttB0IH4W9P1Lz9r7jlyymSLoJHVLto7hlegy9l/zdx9lwkcaD\n29NBST9cKbsUvMmmDZaeHJs6\n-----END PRIVATE KEY-----\n",
"RootCert": "-----BEGIN CERTIFICATE-----\nMIIDxzCCAq+gAwIBAgIJALpP+Yz7TqVMMA0GCSqGSIb3DQEBCwUAMHoxCzAJBgNV\nBAYTAlJVMQwwCgYDVQQIDANTUGIxDDAKBgNVBAcMA1NQYjEYMBYGA1UECgwPR2xv\nYmFsIFNlY3VyaXR5MRYwFAYDVQQLDA1JVCBEZXBhcnRtZW50MR0wGwYDVQQDDBRj\nb25zdWwubHV4bXMuc3BiLmNvbTAeFw0yMzAyMjExNDIzNThaFw0zMzAzMTAxNDIz\nNThaMHoxCzAJBgNVBAYTAlJVMQwwCgYDVQQIDANTUGIxDDAKBgNVBAcMA1NQYjEY\nMBYGA1UECgwPR2xvYmFsIFNlY3VyaXR5MRYwFAYDVQQLDA1JVCBEZXBhcnRtZW50\nMR0wGwYDVQQDDBRjb25zdWwubHV4bXMuc3BiLmNvbTCCASIwDQYJKoZIhvcNAQEB\nBQADggEPADCCAQoCggEBAOB8AU85l0zGoKx8EcVC8ZQKOT4KnNdi0AyzhsKT+O0U\nxLzBf5vqtY/Ka63QPOlZB0L4yjAW4HDa30F/ysEN3gMhTsvT8pgwyuu0fMxm4pSM\nUJeYdIW5igpUFcYntpHLnOs6HYgHIBHOkRxSXJvRcIpIYhDfUwczOdfax14XEYFi\n4DbVDrz0BRyGQzTnZVAGS1rgSjs0tpQBcDcIZMebpSpYndedg9PYf73p1a/P2sjJ\nphL1266G7aLwpaPdncpCubACNW1fpehexh6cCaoJKrECAwEAAaNQME4wHQYDVR0O\nBBYEFHc2q6aLWmhbx9SFBZ80KRZGphhpMB8GA1UdIwQYMBaAFHc2q6aLWmhbx9SF\nBZ80KRZGphhpMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBADeQ9sdx\nsV+fq2nysmk1OYot6GNm1fFNjQHrXBlTgpXpktOKozM4cAfG3EDco+29RKXCs4Xg\n8eya0cH/r1ZUAXLCkMWtkRmMEhP1WtgQwO9wAyAtLYjftLrniqab09EvjWGLU46F\nU7jrtiOFzAItJF1c50QTrmKBrUCs/Yx0/YEM2FPgsvZonLGWPGHSm+AUKg77PvIT\nYBatlNpl+2zBq7Q460duycZE9swKZCc2W3QtJJRYQV7FHRtOhHAp17AcyijS2tJ6\n9h/oBPdahLiUIabxIMYon1FTKurOb1TH8r/FFnmJPabnyVkOruvOa2CuGRhimYdf\nKdsOVeygf6HRcQ4=\n-----END CERTIFICATE-----\n",
"IntermediateCertTTL": "8760h"
},
"ForceWithoutCrossSigning": false
}

* где:

LeafCertTTL — максимальный срок действия клиентского сертификата, который выдан сервером. Речь идет о сертификатах, которые создаются автоматически, например, для службы connect.
PrivateKey — последовательность для закрытого ключа.
RootCert — последовательность для открытого ключа.
IntermediateCertTTL — срок действия для промежуточных сертификатов, которые подписаны корневым.
ForceWithoutCrossSigning — если указан true, то consul не поддерживает сертификаты, выданные предыдущим корнем. Это приведет к тому, что после смены сертификата все службы перестанут работать, пока не обновлять сертификат. Как заявляет разработчик, это происходит в течение нескольких секунд.

Применяем созданный файл — загружаем данные в консул:

curl --header "Authorization: Bearer <Consul Token>" --request PUT --data @payload.json http://127.0.0.1:8500/v1/connect/ca/configuration

Смотрим на список сертификатов:

curl http://localhost:8500/v1/connect/ca/roots | jq

Должно стать больше на один.

Также давайте теперь посмотрим на активный сертификат:

curl http://localhost:8500/v1/connect/ca/roots | jq .Roots | jq '.[] | select(.Active==true)'

Это должны быть новые последовательности.

Мы можем еще раз выгрузить последовательность в формат pem:

И убедиться, что consul пользуется созданным нами сертификатом:

openssl x509 -text -in consul.pem

Работа веб-интерфейса по SSL

Дополнительно, рассмотрим настройку веб-интерфейса consul по протоколу https. Подразумевается, что мы находимся в каталоге /etc/ssl/consul.

Для начала, создадим сертификат сервера. Для этого есть встроенная команда consul tls cert create:

consul tls cert create -server -ca=ca.pem -key=ca.key

* в данном примере мы создаем запрос на создание сертификата для сервера; в качестве ca используем ранее созданные ключи.

Мы должны увидеть что-то на подобие:

==> WARNING: Server Certificates grants authority to become a
server and access all state in the cluster including root keys
and all ACL tokens. Do not distribute them to production hosts
that are not server nodes. Store them as securely as CA keys.
==> Using ca.pem and ca.key
==> Saved dc1-server-consul-0.pem
==> Saved dc1-server-consul-0-key.pem

* были созданы файлы dc1-server-consul-0.pem и dc1-server-consul-0-key.pem. Это открытый и закрытый ключи для сервера.

Открываем конфигурационный файл консула:

vi /etc/consul.d/config.json

Добавим в конец:

...,
"ports": {
"http": 8500,
"https": 8501
},
"ca_file": "/etc/ssl/consul/ca.pem",
"cert_file": "/etc/ssl/consul/dc1-server-consul-0.pem",
"key_file": "/etc/ssl/consul/dc1-server-consul-0-key.pem"
}

* где:

ports — указываем, на каких портах должен запускаться UI консула.
ca_file — открытая последовательность удостоверяющего центра (то есть, нашего сертификата, который мы создали в начале инструкции).
cert_file — открытый сертификат сервера.
key_file — закрытый сертификат сервера.

Если мы хотим запретить консулу работать на небезопасном порту, указываем для http значение:

"http": -1,

Проверяем корректность настройки:

consul validate /etc/consul.d/

Перезагружаем консул:

systemctl restart consul

Работа с сертификатами в Consul

Подготовка к работе

Получение информации

Загрузка собственного сертификата

Работа веб-интерфейса по SSL

Читайте также