Настройка TLS

В KeyStack TLS настраивается на нескольких уровнях:

  • TLS на VIP — шифрует соединение между клиентом OpenStack и HAProxy. Без этой опции API-эндпоинты доступны по HTTP.

  • TLS во внутренней сети (backend TLS) — шифрует соединение между HAProxy и серверными сервисами API.

Для компонентов LCM TLS включён по умолчанию — самоподписанные сертификаты генерируются при установке.

Значения параметров TLS по умолчанию заданы в релизе KeyStack и загружаются поверх стандартных значений kolla-ansible. При необходимости их можно переопределить в файле globals.d/REGION.yml в репозитории региона. Значения по умолчанию:

kolla_enable_tls_external: "yes"        # TLS между клиентом OpenStack и HAProxy на внешнем VIP
kolla_enable_tls_internal: "yes"        # TLS между клиентом OpenStack и HAProxy на внутреннем VIP
kolla_enable_tls_backend: "yes"         # TLS между HAProxy и серверными сервисами API
kolla_copy_ca_into_containers: "yes"    # Копирование CA-сертификата внутрь контейнеров сервисов
database_enable_tls_backend: "no"       # TLS между ProxySQL и MariaDB
database_enable_tls_internal: "no"      # TLS между сервисами OpenStack и ProxySQL
nova_qemu_vnc_tls: "yes"                # TLS для трафика между клиентом и прокси-сервером noVNC
libvirt_tls: "yes"                      # mTLS для API Libvirt
rabbitmq_enable_tls: "yes"              # TLS для RabbitMQ
kolla_enable_mtls_backend: "no"         # mTLS между HAProxy и серверными сервисами
kolla_enable_mtls_external: "no"        # mTLS на внешнем VIP

Включение и отключение параметров TLS

Для изменения параметров TLS:

  1. Войдите в GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.

  2. Откройте файл globals.d/REGION.yml и измените в нём значения необходимых переменных.

  3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  4. Запустите пайплайн: New pipeline.

  5. Запустите задачу deploy в созданном пайплайне.

  6. Дождитесь завершения выполнения задачи.

Использование собственных сертификатов для настройки TLS на VIP

Параметры kolla_enable_tls_internal и kolla_enable_tls_external управляют TLS для каждого VIP независимо. Чтобы использовать отдельные сертификаты, добавьте в globals.d/REGION.yml параметры kolla_internal_fqdn_cert и kolla_external_fqdn_cert, в котором укажите пути до файлов сертификатов:

kolla_internal_fqdn_cert: "<путь к файлу сертификата внутреннего VIP>"
kolla_external_fqdn_cert: "<путь к файлу сертификата внешнего VIP>"

После внесения изменений создайте и запустите пайплайн.

Настройка TLS для noVNC

Для noVNC шифрование обеспечивается на двух участках: между клиентом и прокси-сервером (управляется параметром nova_qemu_vnc_tls) и между прокси-сервером и Libvirt (управляется параметром libvirt_tls). Для полной защиты соединения оба параметра должны быть включены.

Если в процессе настройки параметров TLS меняется только значение параметра nova_qemu_vnc_tls, при создании пайплайна добавьте переменную KOLLA_ARGS со значением -t nova, чтобы развёртывание выполнилось только для компонентов Nova.

Сертификаты OpenStack в Vault

Сертификаты для сервисов OpenStack хранятся в Vault по пути secret_v2 / deployments / <LCM FQDN> / <имя региона> / ssl_certificates и генерируются автоматически при запуске пайплайна. Набор ключей зависит от включённых параметров TLS:

  • haproxy_pem генерируется при включённом kolla_enable_tls_external;

  • haproxy_internal_pem — при включённом kolla_enable_tls_internal;

  • backend_pem, backend_key_pem — при включённом kolla_enable_tls_backend или rabbitmq_enable_tls;

  • libvirt_cacert, libvirt_cakey, libvirt_serverkey, libvirt_clientkey и libvirt_inventory_hash — при включённом libvirt_tls или nova_qemu_vnc_tls. В режиме отдельных сертификатов на гипервизор (см. ниже) вместо libvirt_serverkey/libvirt_clientkey сохраняются ключи libvirt_ph_<hostname>_key и libvirt_ph_<hostname>_crt для каждого compute-узла.

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

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

Управление сертификатами Libvirt

Источник сертификатов Libvirt (mTLS для живой миграции и noVNC) выбирается параметром libvirt_cert_source. По умолчанию используется selfsigned с режимом «сертификат на гипервизор» (libvirt_cert_per_host: true) — KeyStack сам управляет жизненным циклом сертификатов; для отката к прежнему поведению явно укажите legacy.

Важно

Изменение поведения при обновлении до текущей версии по умолчанию действовал legacy (генерация через kolla-ansible certificates). Теперь по умолчанию — selfsigned + per-host: при первом же развёртывании существующего региона сертификаты Libvirt перевыпускаются как отдельные сертификаты на каждый compute-узел (CA переиспользуется, если его ключ libvirt_cakey сохранён в секрете; иначе CA однократно ротируется). Это штатная миграция, но она затрагивает все compute-узлы региона за одно развёртывание. Также источнику selfsigned требуется коллекция community.crypto на узле развёртывания. Чтобы сохранить прежнее поведение без изменений, задайте libvirt_cert_source: legacy для региона.

Автоматическое управление жизненным циклом (источники selfsigned и vault, отслеживание изменения состава compute-узлов и перевыпуск, per-host) недоступно для регионов, которые продолжают использовать режим legacy — в нём сертификат Libvirt не перевыпускается при изменении состава compute-узлов (подробнее — в предупреждении для режима legacy ниже).

Поведением управляют параметры в globals.d/REGION.yml (указаны значения по умолчанию):

libvirt_cert_source: "selfsigned"   # legacy | selfsigned | vault
libvirt_cert_per_host: true         # false — один общий сертификат со SAN всех гипервизоров (для selfsigned/vault; legacy всегда общий)
libvirt_ca_valid_days: 3650         # срок действия CA (~10 лет; только для selfsigned)
libvirt_cert_valid_days: 825        # срок действия листового сертификата (только для selfsigned)
renew_before_percent: 33            # порог обновления по сроку действия, %

Значения libvirt_cert_source:

  • legacy (путь отката). Генерация через kolla-ansible certificates с перевыпуском только при отсутствии сертификата — без учёта изменения инвентаря и срока действия. Прежнее поведение до этой версии; используйте для отката.

    Предупреждение

    В режиме legacy сертификат Libvirt не перевыпускается при изменении состава compute-узлов (изменение состава compute-узлов не отслеживается — перевыпуск происходит только при отсутствии сертификата). Поэтому перед добавлением нового гипервизора удалите текущие сертификаты Libvirt из Vault/SecMan — ключи libvirt_cacert, libvirt_cakey, libvirt_serverkey и libvirt_clientkey в секрете ssl_certificates соответствующего региона. При следующем развёртывании они будут сгенерированы заново с актуальным составом compute-узлов в SAN. Иначе имя нового узла не попадёт в SAN сертификата, и mTLS живой миграции / noVNC на нём завершится ошибкой Failed to verify peer's certificate. Источники selfsigned и vault отслеживают изменение состава compute-узлов и перевыпускают сертификат автоматически — ручное удаление им не требуется.

  • selfsigned (по умолчанию). KeyStack выпускает сертификаты самостоятельно средствами community.crypto — без зависимости от модифицированной сборки kolla-ansible, с полным контролем над сроком действия, SAN и хранением CA. Дополнительные возможности этого источника:

    • Собственный CA. При первом выпуске генерируется самоподписанный CA (libvirt_cacert + libvirt_cakey); он сохраняется в Vault и переиспользуется при последующих перевыпусках — CA остаётся стабильным, перевыпускается только листовой сертификат. Ротация CA по всему кластеру исключается.

    • Перевыпуск при изменении инвентаря. SAN сертификата формируются из группы compute (migration_hostname каждого узла). При изменении состава compute-узлов фиксируется изменение отпечатка libvirt_inventory_hash и сертификат перевыпускается под тем же CA.

    • Обновление по сроку действия. Сертификат и CA обновляются, когда до истечения остаётся менее renew_before_percent % полного срока действия (по умолчанию 33 %, т. е. при остатке ~1/3 срока — по аналогии с cert-manager).

    • Сертификаты на гипервизор (per-host, включено по умолчанию). При libvirt_cert_per_host: true (значение по умолчанию) для каждого compute-узла выпускается отдельный сертификат (каталог config/nova/nova-libvirt/<inventory_hostname>/, SAN = migration_hostname), подписанный общим CA. Добавление или удаление узла затрагивает только его сертификат — перевыпуск и повторное развёртывание сертификатов на остальных узлах не требуется. Это модель, рекомендованная в самом kolla-ansible для промышленной эксплуатации. Значение false возвращает единый общий сертификат со SAN всех гипервизоров (перевыпускается целиком при любом изменении инвентаря).

  • vault. Сертификат выпускается внешним PKI: в режиме vault_secman он запрашивается через SecMan API (SecMan сам управляет продлением), иначе — выпускается напрямую через Vault PKI. Локальный CA при этом не создаётся; CA принадлежит внешнему PKI. Режим per-host поддерживается и здесь (по умолчанию): каждому compute-узлу выпускается собственный сертификат из Vault, узлы, выбывшие из инвентаря, удаляются из секрета; ключ CA не сохраняется (им владеет внешний PKI).

Управление сертификатами Octavia

Amphora-PKI Octavia состоит из двух CA, и, в отличие от Libvirt, контроллер хранит подписывающий CA (server_ca) и сам выпускает сертификаты для amphora во время работы. Поэтому эту PKI нельзя делегировать SecMan/Vault-PKI (они выдают конечные сертификаты, а не подписывающие CA) — значения vault у octavia_cert_source нет.

octavia_cert_source: "legacy"       # legacy | selfsigned

  • legacy (по умолчанию). Генерация через kolla-ansible octavia-certificates. Сертификаты и оба CA сохраняются в Vault и восстанавливаются при каждом развёртывании — состояние стабильно.

  • selfsigned. KeyStack выпускает оба CA (server + client) и клиентский сертификат контроллера средствами community.crypto, без зависимости от kolla-ansible. Оба CA сохраняются в Vault и переиспользуются (по каждому CA отдельно, пока в секрете есть его приватный ключ) — перевыпускается только клиентский сертификат (по умолчанию 365 дней) под тем же client CA; при приближении срока действия он обновляется (renew_before_percent). Ключ server_ca.key.pem шифруется паролем octavia_ca_password (как того требует octavia.conf).

    Примечание

    Переключение существующего региона с legacy на selfsigned не приводит к перевыпуску: при валидных сертификатах перегенерация не запускается, а server CA переиспользуется всегда (legacy тоже сохраняет его ключ octavia_server) — сертификаты amphora остаются валидными. Единственное исключение: ключ client CA в legacy не сохранялся, поэтому если после перехода потребуется перевыпуск клиентского сертификата (по сроку действия), client CA однократно ротируется; далее его ключ сохраняется и client CA стабилен. Server CA при этом не затрагивается.

Маршрутизация сертификатов в режиме vault_secman

В режиме vault_secman сертификаты HAProxy и backend всегда выпускаются через SecMan API. Сертификаты Libvirt проходят через SecMan только при libvirt_cert_source: vault; при legacy или selfsigned они выпускаются локально независимо от SecMan. Сертификаты Octavia всегда выпускаются локально (legacy или selfsigned) независимо от vault_secman — их amphora-PKI самоуправляемая.

Настройка mTLS

Для настройки mTLS между сервисами обратитесь к разделу mTLS в регионе.