Включение SSL-шифрования

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

Для тестовых целей вы можете использовать самоподписанные сертификаты, создание которых описано в разделе Создание самоподписанных SSL-сертификатов.

Если SSL включен, все сервисы кластера ADPG будут использовать шифрование SSL и протокол HTTPS вместо HTTP.

ВАЖНО
  • Настоятельно рекомендуется сохранять файлы сертификатов и ключей вне каталога данных ADPG (путь по умолчанию — /pg_data1/adpg16), поскольку имя каталога данных меняется во время мажорного обновления.

  • Необходимо генерировать сертификаты SSL с опцией SAN (Subject Alternative Names). Короткие имена хостов и полные доменные имена (FQDN) должны присутствовать в секции alt_names конфигурационного файла SSL-сертификата.

  • Использование ключей, защищенных паролем, не поддерживается.

  • При обновлении ADPG с версии v16.3.3 с включенным SSL рекомендуется отключить SSL, затем выполнить обновление до ADPG v16.3.4 и использовать кластерное действие Manage SSL для включения SSL.

Настройка SSL через ADCM

Чтобы включить SSL, выполните следующие действия:

  1. Откройте страницу Clusters и выполните действие Manage SSL.

    Выполнение действия Manage SSL
    Выполнение действия "Manage SSL"
  2. В открывшемся окне активируйте переключатель Enable SSL.

    Окно Run an action: Manage SSL
    Окно "Run an action: Manage SSL"

    Настройки SSL отобразятся под переключателем Enable SSL. Параметры, выделенные красным, являются обязательными.

    Параметры SSL
    Параметры SSL
  3. Укажите настройки SSL в соответствии с вашим окружением. К сертификатам и ключам должны быть указаны абсолютные пути. Не рекомендуется сохранять файлы сертификатов и ключей в каталоге данных ADPG (путь по умолчанию: /pg_data1/adpg16), так как при обновлении мажорной версии имя каталога данных будет изменено.  

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

    Параметр Описание Расположение файла

    ADPG generic certificate

    Путь к общему сертификату ADPG, соответствующему требованиям всех сервисов ADPG

    На каждом хосте кластера, где установлены сервисы ADPG, Balancer, Etcd или Monitoring

    ADPG generic certificate key

    Путь к ключу общего сертификата ADPG, который соответствует требованиям всех сервисов ADPG. Права доступа к файлу ключа общего сертификата ADPG должны быть равны 0644 — владелец файла имеет право на чтение и запись, а группа и остальные пользователи могут только читать его. Если используется сервис Balancer (HAProxy), имя файла должно заканчиваться следующим расширением: .crt.key, например, generic.crt.key

    На каждом хосте кластера, где установлены сервисы ADPG, Balancer, Etcd или Monitoring

    Arenadata PostgreSQL certificate

    Путь к отдельному сертификату со специальными правами для сервиса ADPG (PostgreSQL). Эквивалент параметра ssl_cert_file из файла postgresql.conf. Пользователь postgres должен иметь права владельца на файл сертификата

    На каждом хосте кластера, где установлен сервис ADPG

    Arenadata PostgreSQL certificate key

    Путь к ключу отдельного сертификата со специальными правами для сервиса ADPG (PostgreSQL). Эквивалент параметра ssl_key_file из файла postgresql.conf. Права доступа к файлу ключа сертификата PostgreSQL должны быть равны 0600 — владелец файла имеет право на чтение и запись, а группа и остальные пользователи не имеют никаких прав. Пользователь postgres должен иметь права владельца на файл ключа сертификата

    На каждом хосте кластера, где установлен сервис ADPG

    CA file

    Указывает имя файла, содержащего сертификаты центров сертификации (ЦС) для проверки входящих соединений

    На каждом хосте кластера, где установлены сервисы ADPG, Balancer, Etcd или Monitoring

    S3 backup CA file

    Указывает имя файла, содержащего сертификаты центров сертификации (ЦС) для S3-хранилища. Этот параметр следует указывать если включено создание бэкапов и значение параметра Repo type установлено в s3

    На каждом хосте кластера, где установлен сервис ADPG

  4. После указания параметров SSL нажмите Next.

    Окно Run an action: Manage SSL с настройками SSL
    Окно "Run an action: Manage SSL" с настройками SSL
  5. На вкладке Confirmation нажмите Run, чтобы выполнить действие Manage SSL.

    Вкладка Confirmation
    Вкладка "Confirmation"

    После выполнения действия Manage SSL настройки SSL добавляются в раздел SSL configuration конфигурации сервиса ADPG. Этот раздел содержит следующие поля:

    • Enable SSL — поле, доступное только для чтения, имеет значение true, если включен SSL.

    • postgresql.conf — поле, доступное только для чтения, которое содержит настройки SSL.

    • PG_HBA — поле для указания правил для SSL-соединений.

  6. После завершения действия Manage SSL необходимо разрешить SSL-соединения для сервера ADPG. Для этого откройте вкладку Primary configuration сервиса ADPG, разверните раздел SSL configuration в дереве Configuration и кликните поле PG_HBA.

    Секция SSL configuration
    Секция "SSL configuration"

    Добавьте строку, которая разрешает SSL-соединения, в поле PG_HBA раздела SSL configuration. Например:

    hostssl     all     all     0.0.0.0/0     cert
    Поле PG_HBA
    Поле "PG_HBA"

    Эта запись позволяет всем пользователям (all) использовать SSL-соединения (hostssl) со всеми базами данных (all) со всех адресов IPv4 (0.0.0.0/0). Аутентификация осуществляется с использованием клиентских сертификатов SSL (cert). За дополнительной информацией обратитесь к статье Обзор конфигурации PG_HBA.

  7. Сохраните изменения и запустите действие Reconfigure & Restart, чтобы применить изменения.

ПРИМЕЧАНИЕ

Действие Manage SSL переопределяет параметры SSL, указанные в разделах postgresql.conf и Custom postgresql.conf дерева Configuration сервиса ADPG. Обратите внимание, что при отключении SSL через действие Manage SSL снова будут применены настройки SSL из этих разделов. Во избежание неоднозначных ситуаций рекомендуется удалить настройки SSL из этих разделов перед включением SSL, управляемого через действие кластера Manage SSL.

Использование клиентских сертификатов

Для записи секции PG_HBA с типом соединения hostssl можно выбрать вариант аутентификации clientcert=verify-ca или clientcert=verify-full.

Если указано clientcert=verify-ca, сервер проверяет, что сертификат клиента подписан одним из доверенных центров сертификации. Если используется clientcert=verify-full, сервер не только проверяет цепочку сертификатов, но также проверяет, соответствует ли имя пользователя или его сопоставление cn (Common Name) предоставленного сертификата. Обратите внимание, что при использовании метода аутентификации cert всегда обеспечивается проверка цепочки сертификатов.

Промежуточные сертификаты, которые связаны с существующими корневыми сертификатами, также могут быть включены в файл, указанный в параметре CA file, если вы хотите избежать их хранения на клиентах. Списки отзыва сертификатов (Certificate Revocation List, CRL) также проверяются, если параметры ssl_crl_file, ssl_crl_dir установлены через ADCM в поле postgresql.conf.

Опция аутентификации clientcert доступна для всех методов аутентификации в записях PG_HBA, указанных как hostssl. Если clientcert не указан, сервер проверяет сертификат клиента по своему списку ЦС, только если сертификат предоставлен и этот список определен.

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

  • Использование метода аутентификации cert для записей hostssl в PG_HBA. Сертификат будет использоваться как для аутентификации, так и для защиты SSL-соединения. См. Certificate authentication. (При использовании метода аутентификации cert нет необходимости явно указывать какие-либо параметры clientcert). В этом случае параметр cn (Common Name), указанный в сертификате, сверяется с именем пользователя или применяемым сопоставлением.

  • Использование любого метода аутентификации для записей hostssl с проверкой клиентских сертификатов через установку для параметра аутентификации clientcert значения verify-ca или verify-full. Первое значение только гарантирует, что сертификат действителен, а второе также гарантирует, что cn (Common Name) в сертификате соответствует имени пользователя или применимому сопоставлению.

За информацией о том, как настроить сертификаты на клиенте, обратитесь к статье SSL Support.

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

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

Генерация сертификатов для кластера ADPG

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

Хост IP FQDN Сервис

eek-host-1

10.92.41.39

eek-host-1.ru-central1.internal

ADPG

eek-host-2

10.92.40.233

eek-host-2.ru-central1.internal

Etcd

eek-host-3

10.92.41.52

eek-host-3.ru-central1.internal

Balancer

В данном примере сертификаты создаются на хосте eek-host-1 c сервисом ADPG.

Для кластера ADPG необходимо генерировать сертификаты SSL с опцией SAN (Subject Alternative Names). Для этого создайте временный конфигурационный файл с секцией alt_names, соответствующей топологии кластера, его можно разместить по следующему пути: /tmp/san.cnf. Для рассматриваемого кластера ADPG файл выглядит следующим образом:

[req]
default_bits = 4096
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = RU
L = Moscow
O = Arenadata
CN = Common Name

[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names

[alt_names]
IP.1 = 127.0.0.1
IP.2 = 10.92.41.39
IP.3 = 10.92.40.233
IP.4 = 10.92.41.52
DNS.1 = localhost
DNS.2 = eek-host-1.ru-central1.internal
DNS.3 = eek-host-2.ru-central1.internal
DNS.4 = eek-host-3.ru-central1.internal
DNS.5 = eek-host-1
DNS.6 = eek-host-2
DNS.7 = eek-host-3

Чтобы сгенерировать SSL-сертификаты, выполните следующие действия:

  1. Создайте каталог, в котором вы хотите генерировать сертификаты, предоставьте к нему полные права доступа и перейдите в него. Например:

    $ sudo mkdir /etc/certificates
    $ sudo chmod 777 /etc/certificates
    $ cd /etc/certificates
  2. Чтобы создать сертификат сервера, который смогут проверить клиенты, создайте запрос сертификата (Certificate Signing Request, CSR) и файлы открытого/закрытого ключей. Замените <root.yourdomain.com> на желаемое значение, например, CN=eek-host-1. Также необходимо установить разрешения:

    $ openssl req -new -nodes -text -out root.csr -keyout root.crt.key -subj "/CN=<root.yourdomain.com>"
    $ chmod 600 root.crt.key
  3. Подпишите запрос ключом, чтобы создать корневой центр сертификации. Обратите внимание, что путь к файлу openssl.cnf (/etc/ssl/openssl.cnf) может отличаться в вашем окружении:

    $ openssl x509 -req -in root.csr -text -days 3650 \
      -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
      -signkey root.crt.key -out root.crt

    Установите необходимые разрешения:

    $ chmod 644 root.crt

    В результате следующие файлы будут созданы: root.crt, root.csr и root.crt.key.

  4. Создайте сертификат ADPG generic, подписанный новым корневым центром сертификации, и установите необходимые права:

    $ openssl req -new -nodes -text -out generic_1.csr -keyout generic_1.crt.key -subj "/CN=$(hostname)" -config /tmp/san.cnf
    $ chmod 644 generic_1.crt.key
    $ openssl x509 -req -in generic_1.csr -text -days 365 -CA root.crt -CAkey root.crt.key -CAcreateserial -out generic_1.crt -extfile /tmp/san.cnf -extensions v3_req

    Следующие файлы будут созданы: generic_1.csr, generic_1.crt и generic_1.crt.key.

  5. Создайте сертификат Arenadata PostgreSQL, подписанный новым корневым центром сертификации:

    $ openssl req -new -nodes -text -out postgres_1.csr -keyout postgres_1.crt.key -subj "/CN=$(hostname)" -config /tmp/san.cnf
    $ openssl x509 -req -in postgres_1.csr -text -days 365 -CA root.crt -CAkey root.crt.key -CAcreateserial -out postgres_1.crt

    Следующие файлы будут созданы: postgres_1.csr, postgres_1.crt и postgres_1.crt.key.

  6. Проверьте сертификаты. Команды ниже должны вернуть OK:

     $ openssl verify -CAfile root.crt generic_1.crt
     $ openssl verify -CAfile root.crt postgres_1.crt
  7. Измените разрешения для сертификата Arenadata PostgreSQL и его ключа:

    $ sudo chown postgres:postgres /etc/certificates/postgres_1.*
  8. Скопируйте сертификаты CA в стандартный каталог для хранения корневых сертификатов удостоверяющих центров (по умолчанию этот каталог — /usr/local/share/ca-certificates/) и выполните команду update-ca-certificates, чтобы обновить кеш доверенных сертификатов. Этот шаг необходимо выполнить на всех хостах с сервисом ADPG после того, как вы скопируете на них сертификаты.

    $ sudo cp generic_1.crt /usr/local/share/ca-certificates/
    $ sudo cp postgres_1.crt /usr/local/share/ca-certificates/
    $ sudo cp root.crt /usr/local/share/ca-certificates/
    $ sudo update-ca-certificates
  9. Скопируйте файлы generic_1.crt и generic_1.crt.key на другие хосты кластера, используя тот же путь (в этом примере — /etc/certificates) и установите права для generic_1.crt.key:

    $ sudo chmod 644 generic_1.crt.key

    Пути к этим файлам необходимо указать в параметрах ADPG generic certificate key и ADPG generic certificate действия Manage SSL.

  10. Скопируйте файлы postgres_1.crt и postgres_1.crt.key на все хосты кластера с сервисом ADPG, используя тот же путь (в этом примере — /etc/certificates), и установите права для файлов:

    $ sudo chown postgres:postgres /etc/certificates/postgres_1.*

    Пути к этим файлам необходимо указать в параметрах Arenadata PostgreSQL certificate и Arenadata PostgreSQL certificate key действия Manage SSL.

  11. Скопируйте файл root.crt на другие хосты кластера, используя тот же путь (в этом примере — /etc/certificates), и установите права для root.crt:

    $ chmod 644 root.crt

    Путь к файлу root.crt необходимо указать в параметре CA file действия Manage SSL.

  12. Выполните шаг 5 на всех хостах с сервисом ADPG.

Генерация SSL-сертификата для клиентов PostgreSQL

Создайте запрос сертификата (CSR), где CN — имя пользователя базы данных:

$ openssl req -new -nodes -subj "/CN=<имя_пользователя_базы_данных>" -keyout client.key -out client.csr

Например:

$ openssl req -new -nodes -subj "/CN=postgres" -keyout client.key -out client.csr

Установите следующие разрешения для client.key:

$ chmod 600 client.key

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

$ openssl x509 -days 3650 -req -CAcreateserial -in client.csr -CA root.crt -CAkey root.key -out client.crt

Удалите файл CSR:

$ rm client.csr

Файлы client.crt и client.key должны храниться на клиенте. См. SSL client file usage.

После создания сертификатов и размещения их на хостах кластера укажите необходимые параметры сервиса ADPG через пользовательский интерфейс ADCM:

  1. Добавьте запись, разрешающую SSL-соединения, в поле PG_HBA раздела SSL Configuration. Например:

    hostssl all all 0.0.0.0/0 cert clientcert=1
  2. Установите параметр ssl_ca_file в поле postgresql.conf раздела ADPG Configurations. Для этого примера значение будет следующим:

    ssl_ca_file='/etc/certificates/root.crt'
  3. Выполните действие Reconfigure & Restart сервиса ADPG.

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней