[ English | English (United Kingdom) | русский | Deutsch ]

Защита сервисов при помощи SSL сертификатов

Инструкция по безопасности OpenStack рекомендует использовать защищенное соединение между различными сервисами в окружении OpenStack. Проект OpenStack-Ansible в данный момент предоставляет возможность настройки SSL сертификатов для безопасного взаимодействия между сервисами:

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

Во время развертывания с OpenStack-Ansible вы можете либо использовать самоподписанные сертификаты, которые будут сгенерированы во время процесса развертывания, либо предоставить SSL сертификаты, ключи и промежуточные сертификаты для вашего доверенного центра сертификации. Высокозащищенные окружения используют доверенные сертификаты, предоставленные пользователями, для максимально возможного количества сервисов.

Примечание

Выполните все настройки SSL сертификатов в файле /etc/openstack_deploy/user_variables.yml. Не редактируйте роли или плейбуки самостоятельно для этого.

OpenStack-Ansible использует роль ansible ansible_role_pki в качестве общего инструмента для управления и установки самоподписанных и предоставленных пользователями сертификатов.

Примечание

Примеры конфигураций OpenStack-Ansible разработаны как минимальные примеры и в тестовых или разрабатываемых сценариях использования установят external_lb_vip_address на IP-адрес внешней точки доступа HAProxy. Для производственного развертывания рекомендуется установить external_lb_vip_address на полное доменное имя, которое разрешается через DNS в IP внешней точки доступа.

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

Самоподписанные сертификаты позволяют быстро начать работу и шифровать данные при передаче. Однако, они не обеспечивают высокий уровень доверия для публичных точек доступа в высокозащищенных средах. По умолчанию в OpenStack-Ansible используются самоподписанные сертификаты. При использовании самоподписанных сертификатов проверка сертификатов автоматически отключается.

Самоподписанные сертификаты могут играть важную роль в обеспечении безопасности внутренних служб в рамках развертывания OpenStack-Ansible, поскольку они могут быть выпущены только частным CA, связанным с развертыванием. Использование взаимного TLS между внутренними службами, такими как RabbitMQ и MariaDB, с самоподписанными сертификатами и надежной настройкой CA может гарантировать, что только правильно аутентифицированные клиенты смогут подключаться к этим внутренним службам.

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

Самоподписанный центр сертификации создается на хосте развертывания во время первого запуска сценария.

Чтобы повторно сгенерировать центр сертификации, необходимо установить переменную openstack_pki_regen_ca``либо на имя корневого центра сертификации или промежуточного центра сертификации, который вы хотите повторно сгенерировать, либо на ``true, чтобы повторно сгенерировать все самоподписанные центры сертификации.

# openstack-ansible -e "openstack_pki_regen_ca=ExampleCorpIntermediate" certificate-authority.yml

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

Генерация и регенерация самоподписанных сертификатов

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

Чтобы повторно создать новый самоподписанный сертификат для службы, необходимо установить переменную <servicename>_pki_regen_cert в значение true одним из следующих способов:

  • Для принудительного обновления самоподписанного сертификата, вы можете передать переменную openstack-ansible в командной строке:

    # openstack-ansible -e "haproxy_pki_regen_cert=true" haproxy-install.yml

  • Чтобы заставить самоподписанный сертификат регенерироваться при каждом запуске playbook, установите соответствующий параметр регенерации в true. Например, если вы уже запустили playbook haproxy, но хотите регенерировать самоподписанный сертификат, установите переменную haproxy_pki_regen_cert в true в файле /etc/openstack_deploy/user_variables.yml:

    haproxy_pki_regen_cert: true

Генерация и повторная генерация самоподписанных сертификатов пользователей

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

Для генерации пользовательских сертификатов определите переменную с префиксом user_pki_certificates_ в файле /etc/openstack_deploy/user_variables.yml.

Пример

user_pki_certificates_example:
   - name: "example"
     provider: ownca
     cn: "example.com"
     san: "DNS:example.com,IP:x.x.x.x"
     signed_by: "{{ openstack_pki_service_intermediate_cert_name }}"
     key_usage:
       - digitalSignature
       - keyAgreement
     extended_key_usage:
       - serverAuth

Сгенерируйте сертификат с помощью следующей команды:

# openstack-ansible certificate-generate.yml

Чтобы повторно создать новый самоподписанный сертификат для службы, необходимо установить переменную user_pki_regen_cert в значение true одним из следующих способов:

  • Для принудительного обновления самоподписанного сертификата, вы можете передать переменную openstack-ansible в командной строке:

    # openstack-ansible -e "user_pki_regen_cert=true" certificate-generate.yml

  • Чтобы принудительно регенерировать самоподписанный сертификат при каждом запуске сценария, установите для переменной user_pki_regen_cert значение true в файле /etc/openstack_deploy/user_variables.yml:

    user_pki_regen_cert: true

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

Для большего доверия в высоконадежных окружениях, вы можете предоставить собственный SSL сертификат, ключи и промежуточные сертификаты. Получение сертификатов из доверенного центра сертификации находится за пределами данного документа, но раздел Управление Сертификатами Linux Documentation Project объясняет как создать свой собственный центр сертификации и подписывать сертификаты.

Используйте следующий подход для установки собственных SSL сертификатов в OpenStack-Ansible:

  1. Скопируйте ваш SSL сертификат, ключ и промежуточные сертификаты на хост развертывания.

  2. Укажите путь к вашему SSL сертификату, ключу и промежуточным сертификатам в файле /etc/openstack_deploy/user_variables.yml.

  3. Запустите плейбуки для этого сервиса.

Пример HAProxy

Переменные к определению, которые содержат путь к сертификатам на ноде развертывания для настройки HAProxy:

haproxy_user_ssl_cert: /etc/openstack_deploy/ssl/example.com.crt
haproxy_user_ssl_key: /etc/openstack_deploy/ssl/example.com.key
haproxy_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt

Пример RabbitMQ

Для установки определенных пользователем сертификатов на RabbitMQ, скопируйте сертификаты на хост развертывания, отредактируйте файл /etc/openstack_deploy/user_variables.yml и задайте следующие переменные:

rabbitmq_user_ssl_cert:    /etc/openstack_deploy/ssl/example.com.crt
rabbitmq_user_ssl_key:     /etc/openstack_deploy/ssl/example.com.key
rabbitmq_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt

Потом запустите плейбук для применения сертификатов:

# openstack-ansible rabbitmq-install.yml

Плейбук установит предоставленный вами SSL сертификат, ключ и промежуточные сертификаты на каждый контейнер RabbitMQ.

Процесс идентичен для остальных сервисов. Замените префикс rabbitmq в переменной на horizon, haproxy или keystone, а после запустите плейбук для данного сервиса для разливки предоставленного сертификата на данные сервисы.

Сертификаты Certbot

Роль HAProxy ansible поддерживает использование certbot для автоматического развертывания доверенных сертификатов SSL для публичной точки доступа. Каждый сервер HAProxy будет индивидуально запрашивать сертификат SSL с помощью certbot.

По умолчанию Certbot использует Let’s Encrypt в качестве центра сертификации. Другие центры сертификации можно использовать, установив переменную haproxy_ssl_letsencrypt_certbot_server в файле /etc/openstack_deploy/user_variables.yml:

haproxy_ssl_letsencrypt_certbot_server: "https://acme-staging-v02.api.letsencrypt.org/directory"

Запрос типа http-01 используется certbot для развертывания сертификатов, поэтому необходимо, чтобы публичная точка доступа была доступна напрямую центру сертификации.

Развертывание сертификатов с использованием Let’s Encrypt было проверено для Openstack-Ansible с использованием Ubuntu 22.04 (Jammy Jellyfish). Другие дистрибутивы должны работать, но не тестировались.

Чтобы развернуть сертификаты с помощью certbot, добавьте следующее в /etc/openstack_deploy/user_variables.yml, чтобы включить функцию certbot в роли HAProxy ansible, а также создать новую внутреннюю службу с именем certbot для обслуживания запросов http-01.

haproxy_ssl: true
haproxy_ssl_letsencrypt_enable: True
haproxy_ssl_letsencrypt_email: "email.address@example.com"

TLS для внутреннего VIP HAProxy

Помимо балансировки нагрузки публичных точек доступа, HAProxy также используется для балансировки нагрузки внутренних соединений.

По умолчанию OpenStack-Ansible не защищает соединения с внутренним VIP. Чтобы включить это, необходимо задать следующие переменные в файле /etc/openstack_deploy/user_variables.yml:

openstack_service_adminuri_proto: https
openstack_service_internaluri_proto: https

haproxy_ssl_all_vips: true

Запустите все сценарии для настройки служб HAProxy и OpenStack.

При включении HAProxy будет использовать один и тот же сертификат TLS на всех интерфейсах (внутренних и внешних). В настоящее время в OpenStack-Ansible невозможно использовать различные самоподписанные или предоставленные пользователем сертификаты TLS на различных интерфейсах HAProxy.

Единственный способ использовать разные сертификаты TLS на внутреннем и внешнем VIP — это использовать certbot.

Включение TLS на внутреннем VIP для существующих развертываний приведет к некоторому простою, это связано с тем, что HAProxy прослушивает только один известный порт для каждой службы OpenStack, а службы OpenStack настроены на использование http или https. Это означает, что после обновления HAProxy для приема только HTTPS-соединений службы OpenStack перестанут работать, пока они не будут обновлены для использования HTTPS.

Чтобы избежать простоя, рекомендуется включить openstack_service_accept_both_protocols, пока все службы не будут настроены правильно. Это позволяет фронтендам HAProxy прослушивать как HTTP, так и HTTPS.

TLS для бекэндов HAProxy

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

openstack_service_backend_ssl: True

Также есть возможность включить его только для отдельных служб:

keystone_backend_ssl: True
neutron_backend_ssl: True

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

TLS для живых миграций

Живая миграция виртуальных машин с использованием SSH устарела, и OpenStack Nova Docs рекомендует использовать более безопасный собственный метод TLS, поддерживаемый QEMU. Метод живой миграции по умолчанию, используемый OpenStack-Ansible, был обновлен для использования миграций TLS.

Для использования нативного протокола TLS в QEMU требуется, чтобы все вычислительные хосты принимали TCP-подключения на порту 16514 и в диапазоне портов 49152–49261.

Невозможно иметь смешанное состояние, когда некоторые вычислительные узлы используют SSH, а некоторые — TLS для живых миграций, поскольку это помешает живым миграциям между вычислительными узлами.

Нет проблем с включением живой миграции TLS во время обновления OpenStack, пока вам не нужно выполнять ee для инстансов во время обновления. Если же вам нужно ее выполнить во время обновления, включите живую миграцию TLS до или после обновления.

Чтобы принудительно использовать SSH вместо TLS для живых миграций, необходимо установить переменную nova_libvirtd_listen_tls в 0 в файле /etc/openstack_deploy/user_variables.yml:

nova_libvirtd_listen_tls: 0

TLS для VNC

При использовании VNC для доступа к консоли необходимо защитить 3 соединения: клиент к HAProxy, HAProxy к noVNC Proxy и noVNC Proxy к вычислительным узлам. В OpenStack Nova Docs for remote console access безопасность консоли рассматривается гораздо более подробно.

В OpenStack-Ansible TLS для HAProxy настроен в HAProxy, TLS от HAProxy до noVNC в настоящее время не включен, а TLS от nVNC до вычислительных узлов включен по умолчанию.

Изменения не будут применяться к существующим запущенным гостевым ОС на вычислительном узле, поэтому эту настройку следует выполнить до запуска любых инстансов. Для существующих развертываний рекомендуется перенести инстансы с вычислительного узла перед включением.

Чтобы помочь с переходом от незашифрованного VNC к VeNCrypt, изначально схема аутентификации прокси noVNC допускает как зашифрованные, так и незашифрованные сеансы с использованием переменной nova_vencrypt_auth_scheme. Это будет ограничено VeNCrypt только в будущих версиях OpenStack-Ansible.

nova_vencrypt_auth_scheme: "vencrypt,none"

Чтобы не шифровать данные из прокси-сервера noVNC на вычислительные узлы, необходимо установить переменную nova_qemu_vnc_tls в 0 в файле /etc/openstack_deploy/user_variables.yml:

nova_qemu_vnc_tls: 0