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

Защита сервисов при помощи 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

  • Чтобы заставить самоподписанный сертификат пересоздаваться при каждом запуске плейбука, установите соответствующий параметр регенерации в true. Например, если вы уже запустили плейбук 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, ключи и сертификаты CA. Получение сертификатов от доверенного центра сертификации выходит за рамки этого документа, но раздел Управление сертификатами в 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"

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

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

Для развертывания сертификатов с помощью 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 для внутреннего виртуального IP (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