Как обезопасить Консул с помощью шифрования TLS в Ubuntu 14.04

Вступление

Consul - это инструмент обнаружения сервисов, который можно использовать для простого обнаружения и отслеживания состояния различных сервисов в вашей инфраструктуре. Вы можете использовать консул для управления вашими услугами и поддерживать распределенную систему проверки, чтобы убедиться, что вы можете реагировать, когда приложения или серверы отключаются.

В last guide мы сосредоточились на получении продукции среда уже готова и готова. Это включало создание файлов конфигурации, которые будут считываться при загрузке и запускать сценарии для фактического запуска служб.

Это дало нам большую часть пути к нашей окончательной базовой конфигурации, но мы еще не полностью защитили нашу конфигурацию. Мы внедрили простое секретное решение для совместного использования, которое очень легко шифрует наш протокол сплетен.

Однако на этом этапе связь RPC все еще полностью не зашифрована. Для решения этой проблемы консул изначально поддерживает шифрование TLS, на котором мы сосредоточимся в этом руководстве. Чтобы реализовать это, нам нужно будет создать центр сертификации, а также подписывать и распространять ключи на наши узлы.

Предпосылки и цели

Прежде чем завершить это руководство, у вас должна быть настроена система серверов консула, которую мы оставили в нашем последнем руководстве на https://www.digitalocean.com/community/tutorials/how-to-configure-consul-in-a. -production-environment-on-ubuntu-14-04 [создание готовой к работе инфраструктуры консула].

Серверы, которые мы использовали для этого руководства, имели следующие свойства:

Hostname	IP Address	Role
server1.example.com	192.0.2.1	bootstrap consul server
server2.example.com	192.0.2.2	consul server
server3.example.com	192.0.2.3	consul server
agent1.example.com	192.0.2.50	consul client

Hostname

IP Address

Role

server1.example.com

192.0.2.1

bootstrap consul server

server2.example.com

192.0.2.2

consul server

server3.example.com

192.0.2.3

consul server

agent1.example.com

192.0.2.50

consul client

Это 64-битные серверы Ubuntu 14.04. Обратите внимание, что каждый из этих серверов находится в одном домене. Это будет важно для конфигурации, которую мы реализуем в этом руководстве, потому что мы будем использовать подстановочный сертификат, который будет соответствовать любому из хостов в домене.

В этом руководстве мы сосредоточимся на создании центра сертификации TLS для подписи сертификатов для каждого из наших серверов. Это позволит компонентам консула проверять личности и шифровать трафик. Затем мы немного изменим файлы конфигурации, чтобы заставить наши узлы шифровать трафик.

Создайте структуру SSL

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

Опять же, мы будем выполнять все процедуры в этом руководстве из корневой оболочки. Войдите в систему как root или используйте + sudo -i + как пользователь с привилегиями sudo.

На каждом из членов консула создайте каталог + ssl + внутри каталога + / etc / consul.d +. Здесь мы будем хранить необходимые файлы для шифрования RPC-трафика:

mkdir /etc/consul.d/ssl

На сервере, который вы планируете использовать в качестве центра сертификации, мы создадим в этом каталоге подкаталог для размещения всех файлов, необходимых для создания и подписи сертификатов. Мы можем выбрать любой из наших серверов для размещения центра сертификации, но для наших целей мы будем использовать + server1 +, который также содержит конфигурацию начальной загрузки.

На этом сервере создайте подкаталог с именем + CA + в каталоге, который мы только что создали:

mkdir /etc/consul.d/ssl/CA

Он будет содержать некоторые конфиденциальные данные, к которым мы, вероятно, не хотим, чтобы другие люди имели доступ, поэтому давайте заблокируем разрешения:

chmod 0700 /etc/consul.d/ssl/CA

Переместитесь в этот каталог на сервере CA.

cd /etc/consul.d/ssl/CA

Здесь мы создадим несколько основных файлов, которые должны присутствовать для подписи нашего сертификата. Сначала нам нужно создать файл, который будет увеличиваться со следующим доступным серийным номером для сертификатов. Нам нужно предварительно посеять это со значением.

Чтобы сделать это, введите значение + 000a + в последовательный файл:

echo "000a" > serial

Нам также необходимо предоставить файл, в котором наш центр сертификации может записывать сертификаты, которые он подписывает. Мы назовем этот файл + certindex +:

touch certindex

Создайте самоподписанный корневой сертификат

Чтобы начать работу с нашим центром сертификации, первым шагом нам нужно создать самоподписанный корневой сертификат. Мы можем сделать это с помощью команды + openssl +, которая установлена по умолчанию на компьютерах с Ubuntu.

Команда, которую мы будем использовать для создания сертификата:

openssl req -x509 -newkey rsa:2048 -days 3650 -nodes -out ca.cert

Давайте рассмотрим, что это значит:

* req *: Этот аргумент сообщает openssl, что вы заинтересованы в работе с сертификатом PKCS#10, создавая или обрабатывая запросы.
* -x509 *: этот аргумент указывает на то, что вы хотите самозаверяющий сертификат вместо запроса сертификата. Обычно это делается для сертификатов корневого центра сертификации.
* -newkey rsa: 2048 *: Это говорит openssl сгенерировать новый запрос сертификата и закрытый ключ. Мы передаем ему аргумент, указывающий, что мы хотим получить ключ RSA длиной 2048 бит.
* -days 3650 *: Здесь мы указываем количество дней, в течение которых сертификат считается действительным. Мы используем значение «+ 3650 +», что составляет 10 лет.
* -nodes *: указывает, что сгенерированный закрытый ключ не будет зашифрован с помощью DES, для чего потребуется пароль. Это позволяет избежать этого требования.
* -out ca.cert *: Устанавливает имя файла, которое будет использоваться для сгенерированного файла сертификата.

В процессе создания сертификата вам будет предложено ввести информацию о хосте, который вы сертифицируете. Вы можете заполнить это любой необходимой информацией о сервере:

. . .
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DigitalOcean
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:ConsulCA
Email Address []:[email protected]

Для + Common Name, который будет важен в нашем другом сертификате, вы можете указать все, что захотите.

Когда вы закончите, у вас должен быть файл сертификата + ca.cert +, а также связанный ключ с именем + privkey.pem +.

Создать запрос на подстановочный сертификат

Теперь, когда у нас есть сертификат корневого центра сертификации, мы можем сгенерировать запрос на подпись сертификата для наших клиентских компьютеров.

В этом случае все члены нашего консула являются клиентами, включая сервер, на котором мы сейчас работаем. Вместо того, чтобы генерировать уникальный сертификат для каждого сервера и подписывать его с помощью нашего CA, мы собираемся создать сертификат с подстановочными знаками, который будет действителен для любого хоста в нашем домене.

Общий формат команды будет таким же, с небольшими отличиями:

openssl req -newkey rsa:1024 -nodes -out consul.csr -keyout consul.key

Разница между созданным нами самозаверяющим запросом корневого CA-сертификата и новым запросом на подпись сертификатов, который мы генерируем сейчас:

* no -x509 flag *: Мы удалили флаг + -x509 +, чтобы сгенерировать запрос на подпись сертификата вместо самозаверяющего сертификата.
* -out consul.csr *: Выводимый файл является не самим сертификатом, а запросом на подпись сертификата.
* -keyout consul.key *: Мы указали имя ключа, связанного с запросом на подпись сертификата.

Снова нам будет предложено ответить на запрос подписи сертификата (CSR). Это важнее, чем ответы, которые мы предоставили для самоподписанного корневого сертификата CA. Здесь нам нужно будет использовать подстановочный знак + Common Name, чтобы ваш сертификат был проверен как действительный для каждого из наших хостов:

. . .
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DigitalOcean
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Как вы можете видеть здесь, мы использовали наш домен со звездочкой в качестве хоста, чтобы указать, что сертификат должен считаться действительным для любого хоста в домене. Вы можете безопасно пропустить пароль запроса и дополнительные приглашения названия компании, которые добавляются в конец.

Создайте файл конфигурации центра сертификации

Теперь у нас есть файл самозаверяющего сертификата корневого CA и запрос подписи сертификата с подстановочными знаками, который соответствует всем хостам в нашем домене. Прежде чем мы сможем подписать запрос на подпись нашим сертификатом CA, нам нужно создать файл конфигурации, который будет контролировать, как это происходит.

Мы назовем файл, который мы создаем, + myca.conf +, который будет содержать информацию о нашей CA. Откройте этот файл сейчас:

nano /etc/consul.d/ssl/CA/myca.conf

В этом файле используется формат INI, который разделен на разделы. Первый раздел, который мы определим, это раздел + ca +. Единственное, что мы здесь сделаем, это укажем на наш пользовательский раздел с актуальной информацией CA:

[ ca ]
default_ca = myca

Далее мы создадим раздел, на который мы только что ссылались. Это будет содержать основную часть конфигурации CA.

Мы уточним, что информация, вводимая в сертификаты, не обязательно должна быть уникальной. Затем мы дадим расположение всех созданных нами файлов, необходимых для процесса подписания. Мы скажем + openssl + разместить новые сертификаты в текущем каталоге.

Мы также хотим выбрать некоторые значения по умолчанию, которые будут использоваться, если в командной строке не указаны альтернативы. Мы выберем подписанные сертификаты, чтобы они действовали в течение 10 лет, и будем использовать алгоритм + sha1 +. Наконец, мы укажем на некоторые дополнительные разделы, которые мы будем создавать, чтобы определить дополнительную информацию:

[ myca ]
unique_subject = no
new_certs_dir = .
certificate = ca.cert
database = certindex
private_key = privkey.pem
serial = serial
default_days = 3650
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

Теперь давайте сосредоточимся на первом пользовательском разделе, на который мы только что ссылались, который используется, чтобы решить, какую информацию необходимо предоставить для принятия CSR. Мы собираемся пометить некоторые поля как обязательные, а другие как необязательные. Для обычных подсказок мы сделаем несколько стандартных вариантов:

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = optional

В последнем разделе будут определены расширения x509, которые мы хотим использовать при подписании сертификатов.

Во-первых, мы должны сказать ему, что сертификат, который мы будем подписывать, не является сертификатом CA. Мы будем использовать стандартное значение «хэш» для идентификатора ключа субъекта, поскольку шестнадцатеричные строки (альтернатива) настоятельно не рекомендуется.

Мы установим идентификатор ключа доступа «keyid», чтобы скопировать идентификатор ключа субъекта из родительского сертификата. Мы также уточним, что ключи могут использоваться в качестве подписи или с протоколом, который шифрует ключи. Мы уточним, что расширенное использование ключей может быть использовано для аутентификации сервера и клиента:

[ myca_extensions ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth

Все вместе файл выглядит примерно так:

[ ca ]
default_ca = myca

[ myca ]
unique_subject = no
new_certs_dir = .
certificate = ca.cert
database = certindex
private_key = privkey.pem
serial = serial
default_days = 3650
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = optional

[ myca_extensions ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth

Сохраните и закройте файл, когда вы закончите. Теперь у нас есть существенный файл конфигурации, который можно использовать для подписания запроса на подпись сертификата, который мы создали ранее.

Подпишите запрос на подпись сертификата для генерации сертификата

Теперь у нас есть все компоненты, необходимые для подписи CSR и создания сертификата. Нам просто нужно сослаться на файл конфигурации, который мы только что создали, и передать сгенерированный CSR.

Команда, которую мы будем использовать:

openssl ca -batch -config myca.conf -notext -in consul.csr -out consul.cert

Варианты, которые мы используем:

* ca *: Использовать функцию управления сертификатами openssl.
* -batch *: указывает, что он должен войти в пакетный режим. Пакетный режим автоматически сертифицирует любые переданные CSR без запроса.
* -config myca.conf *: передать созданный нами файл конфигурации.
* -notext *: Не выводить текстовую форму сертификата.

Остальные параметры определяют входной и выходной файлы.

Это создаст файл с именем + consul.cert + в текущем каталоге. Он также создаст новые версии файлов + serial + и + certindex +, перенеся старые версии в файлы резервных копий. Файл + .pem + также будет создан на основе серийного номера в файле + serial +.

Переместите файлы в правильное местоположение

Теперь у нас есть все необходимые нам компоненты в каталоге + / etc / consul.d / ssl / CA +. Мы хотим скопировать три файла, которые нам нужны, в каталог + / etc / consul.d / ssl +, где мы будем ссылаться на них:

cp ca.cert consul.key consul.cert ..

Наш компьютер + server1 +, который содержит CA, теперь имеет необходимые файлы сертификатов и ключей в правильном расположении.

Чтобы получить их на другие машины в вашей инфраструктуре, + scp + - хороший выбор. Из каталога + / etc / consul.d / ssl + на + server1 + вы можете отправить необходимые файлы на другие серверы, набрав:

cd /etc/consul.d/ssl
scp ca.cert consul.key consul.cert root@:/etc/consul.d/ssl
scp ca.cert consul.key consul.cert root@:/etc/consul.d/ssl
scp ca.cert consul.key consul.cert root@:/etc/consul.d/ssl

Измените IP-адреса для ссылки на каждую машину в вашей инфраструктуре.

Изменить файлы конфигурации Консула

Теперь, когда у нас есть файл корневого сертификата и пара сертификат / ключ для членов нашего консула, мы можем изменить файлы конфигурации нашего консула для ссылки на эти файлы.

Откройте каждый из файлов конфигурации консула на ваших серверах. Для нашего компьютера + server1 + мы начнем с файла конфигурации начальной загрузки:

nano /etc/consul.d/bootstrap/config.json

Файл должен выглядеть следующим образом:

{
   "bootstrap": true,
   "server": true,
   "datacenter": "nyc2",
   "data_dir": "/var/consul",
   "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",
   "log_level": "INFO",
   "enable_syslog": true
}

Первое, что мы должны сделать, это использовать параметры консула, чтобы идентифицировать каждый из наших новых файлов. Параметр + ca_file + ссылается на местоположение файла сертификата CA. Параметры + cert_file + и + key_file + ссылаются на клиентский сертификат и файлы ключей соответственно.

Поскольку это также относится и к шифрованию, мы добавим его ниже параметра + encrypt + для ясности:

{
   "bootstrap": true,
   "server": true,
   "datacenter": "nyc2",
   "data_dir": "/var/consul",
   "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",



   "log_level": "INFO",
   "enable_syslog": true
}

Теперь мы определили расположение этих файлов, но не сказали консулу, что хотим проверить подлинность каждого из хостов, использующих эти файлы. Мы можем сделать это сейчас, сказав консулу, чтобы проверить как входящие, так и исходящие соединения:

{
   "bootstrap": true,
   "server": true,
   "datacenter": "nyc2",
   "data_dir": "/var/consul",
   "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",
   "ca_file": "/etc/consul.d/ssl/ca.cert",
   "cert_file": "/etc/consul.d/ssl/consul.cert",
   "key_file": "/etc/consul.d/ssl/consul.key",


   "log_level": "INFO",
   "enable_syslog": true
}

Сохраните и закройте файл, когда вы закончите.

Сделайте те же самые изменения в каждом из файлов конфигурации, которые используют ваши члены консула.

В + server1 + вы должны внести эти изменения в + / etc / consul.d / bootstrap / config.json и` + / etc / consul.d / server / config.json + `.

На других ваших серверах вам просто нужно изменить + / etc / consul.d / server / config.json +. На вашей клиентской машине вам нужно изменить + / etc / consul.d / client / config.json +.

Перезапуск серверов

Чтобы реализовать наш зашифрованный трафик, вы должны перезапустить сеанс консула на каждом из ваших членов консула по очереди.

На каждой машине в вашей инфраструктуре кратко остановитесь, а затем снова запустите консул:

stop consul && sleep 5 && start consul

Это остановит процесс и перезапустит его на мгновение.

Если вы сделаете это с каждым из ваших членов консула по очереди, они переключатся на использование SSL для шифрования трафика RPC между ними. Когда переключаются только некоторые из них, некоторые проблемы со связью могут ненадолго существовать, так как часть трафика отклоняется из-за отсутствия шифрования.

После перезапуска всех участников трафик RPC должен быть полностью зашифрован.

Заключение

На этом этапе у вас должна быть достаточно безопасная система обнаружения сервисов для вашей инфраструктуры. Мы использовали все собственные системы безопасности, доступные с консулом, чтобы заблокировать доступ и предотвратить подделку наших различных машин.

TOC