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

Содержание

Сертификаты TLS#

В процессе развертывания Astra Automation в Kubernetes необходимо настроить использование сертификатов TLS. TLS обеспечивает шифрование трафика между компонентами системы.

Подробнее о поддерживаемых типах сертификатов см. Типы поддерживаемых сертификатов.

../../../_images/day0-topology-green.svg

Контуры доверия TLS#

При развертывании Astra Automation в Kubernetes сертификаты TLS используются в нескольких независимых контурах доверия. Их важно рассматривать отдельно, потому что в каждом контуре сервер предъявляет сертификат, но проверяют его разные клиенты.

Основные контуры:

доверие клиентов к Ingress, через который публикуются графическая консоль, API и сервисы Astra Automation;
доверие Podman на внешних исполняющих узлах к реестру Private Automation Hub, если в топологии используются внешние исполняющие узлы;
доверие containerd на рабочих узлах Kubernetes к реестру Private Automation Hub, если образы сред исполнения (EE) или сред принятия решений (DE) загружаются из Private Automation Hub через Ingress.

Следующая схема представляет взаимодействие компонентов с использованием сертификатов TLS:

Доверие клиентов к Ingress#

Ingress является внешней точкой входа в платформу. Через него пользователи и внешние системы обращаются к Platform Gateway по HTTPS, а внешние исполняющие узлы и рабочие узлы Kubernetes могут загружать образы EE и DE из реестра Private Automation Hub.

Ingress получает серверный сертификат и закрытый ключ из секрета Kubernetes типа kubernetes.io/tls. Укажите название этого секрета в параметре ingress_tls_secret манифеста AstraAutomation. Подготовку секрета см. в документе Секрет для TLS.

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

Сертификат публичного удостоверяющего центра. Дополнительная настройка клиентов обычно не требуется, так как корневой сертификат уже присутствует в доверенных хранилищах операционных систем, браузеров и большинства клиентских приложений.
Сертификат корпоративного удостоверяющего центра. Корневой сертификат корпоративного удостоверяющего центра необходимо распространить на клиентские машины, которые будут обращаться к Ingress. К таким клиентам относятся рабочие станции пользователей и администраторов, внешние сервисы, внешние исполняющие узлы с Podman и рабочие узлы Kubernetes с containerd.
Сертификат собственного удостоверяющего центра. Используйте этот вариант только для тестирования, разработки, лабораторных и изолированных сред. Клиентские машины также должны доверять корневому сертификату этого удостоверяющего центра.

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

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

Доверие Podman на внешних исполняющих узлах#

Внешние исполняющие узлы запускают среды исполнения с помощью Podman. Если такой узел загружает образы EE или DE из Private Automation Hub через Ingress, Podman должен доверять сертификату, который предъявляет Ingress.

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

добавьте корневой сертификат удостоверяющего центра в системное хранилище внешнего исполняющего узла;
настройте отдельный каталог сертификатов Podman для реестра |PAH|.

Системное хранилище доверенных сертификатов#

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

Для настройки выполните следующие действия на внешнем исполняющем узле:

Поместите файл сертификата в каталог /usr/local/share/ca-certificates/:
```
sudo cp <ca.crt> /usr/local/share/ca-certificates/
```
Здесь <ca.crt> – файл корневого сертификата корпоративного или собственного удостоверяющего центра.
Обновите системное хранилище доверенных сертификатов:
```
sudo update-ca-certificates
```

Каталог сертификатов Podman#

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

Для системного режима Podman выполните следующие действия:

Создайте каталог сертификатов для реестра:
```
sudo mkdir -p /etc/containers/certs.d/<ingress_fqdn>
```
Здесь <ingress_fqdn> – доменное имя Ingress, например aa-demo.example.com. Если реестр указан с нестандартным портом, включите порт в название каталога. Например, для реестра aa-demo.example.com:8443 каталог должен называться aa-demo.example.com:8443.
Скопируйте в него корневой сертификат удостоверяющего центра:
```
sudo cp <ca.crt> /etc/containers/certs.d/<ingress_fqdn>/ca.crt
```

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

Создайте пользовательский каталог сертификатов для реестра:
```
mkdir -p ~/.config/containers/certs.d/<ingress_fqdn>
```
Скопируйте в него корневой сертификат удостоверяющего центра:
```
cp <ca.crt> ~/.config/containers/certs.d/<ingress_fqdn>/ca.crt
```

Дополнительные сведения о структуре каталога сертификатов см. в описании containers-certs.d.

Доверие containerd на рабочих узлах Kubernetes#

В Kubernetes загрузку образов контейнеров выполняет рабочий узел. Если рабочие узлы используют containerd, проверку TLS для реестра выполняет именно containerd. Это отдельный контур доверия: даже если браузер администратора доверяет сертификату Ingress, рабочие узлы Kubernetes не начнут доверять ему автоматически.

Если Ingress использует сертификат публичного удостоверяющего центра, дополнительная настройка containerd обычно не требуется. При использовании корпоративного или собственного удостоверяющего центра настройте доверие на каждом рабочем узле Kubernetes, который может загружать образы из Private Automation Hub.

Подготовка к изменению конфигурации containerd#

Содержимое файла /etc/containerd/config.toml зависит от версии containerd и от способа установки Kubernetes. Это важно учитывать, потому что containerd 1.x и containerd 2.x используют разные версии формата конфигурации и разные названия секций подключаемых модулей. Если добавить секцию, не поддерживаемую в используемой версии containerd, среда выполнения контейнеров не применит эти параметры к загрузке образов.

Перед настройкой выполните следующие действия на каждом рабочем узле Kubernetes:

Определите версию containerd:
```
containerd --version
```
Сохраните резервную копию текущей конфигурации:
```
sudo cp /etc/containerd/config.toml /etc/containerd/config.toml.bak
```
Проверьте, задан ли в файле параметр config_path для реестров:
```
sudo grep -n "config_path" /etc/containerd/config.toml
```

Результат проверки определяет способ настройки:

если параметр config_path уже задан, используйте настройку через отдельный файл hosts.toml;
если параметр config_path не задан и текущая конфигурация уже содержит секции registry.configs, настройте доверие непосредственно в файле config.toml;
для новых конфигураций предпочтительно использовать hosts.toml, так как containerd больше не рекомендует настраивать реестры через registry.configs и registry.mirrors.

Важно

Не добавляйте настройки registry.configs и registry.mirrors в config.toml, если в этом же файле параметр config_path уже задает каталог с настройками реестров. В таком режиме containerd читает настройки реестров из отдельных файлов hosts.toml и не применяет настройки registry.configs и registry.mirrors из основного файла.

Настройка через hosts.toml#

Используйте этот способ, если файл /etc/containerd/config.toml уже содержит параметр config_path или настраивается новая конфигурация containerd. При таком способе основной файл config.toml содержит только путь к каталогу с настройками реестров. Параметры конкретного реестра задавайте в отдельном файле hosts.toml.

Для настройки через hosts.toml выполните следующие действия:

Убедитесь, что файл /etc/containerd/config.toml содержит корректный номер версии конфигурации и путь к каталогу реестров.

Для containerd 1.x укажите version = 2 и секцию plugins."io.containerd.grpc.v1.cri".registry:
```
version = 2

[plugins."io.containerd.grpc.v1.cri".registry]
  config_path = "/etc/containerd/certs.d"
```
Для containerd 2.x укажите version = 3 и секцию plugins."io.containerd.cri.v1.images".registry:
```
version = 3

[plugins."io.containerd.cri.v1.images".registry]
  config_path = "/etc/containerd/certs.d"
```
Перезапустите containerd для применения изменений:
```
sudo systemctl restart containerd
```
Создайте каталог конфигурации для реестра:
```
sudo mkdir -p /etc/containerd/certs.d/<ingress_fqdn>
```
Скопируйте в него корневой сертификат удостоверяющего центра:
```
sudo cp <ca.crt> /etc/containerd/certs.d/<ingress_fqdn>/ca.crt
```
Создайте файл /etc/containerd/certs.d/<ingress_fqdn>/hosts.toml со следующим содержимым:
```
server = "https://<ingress_fqdn>"

[host."https://<ingress_fqdn>"]
  capabilities = ["pull", "resolve"]
  ca = "/etc/containerd/certs.d/<ingress_fqdn>/ca.crt"
```
Здесь:
- <ingress_fqdn> – доменное имя Ingress, например aa-demo.example.com;
- <ca.crt> – файл корневого сертификата корпоративного или собственного удостоверяющего центра.

В тестовой или лабораторной среде можно отключить проверку сертификата TLS для конкретного реестра через файл hosts.toml. Для отключения проверки создайте или измените файл /etc/containerd/certs.d/<ingress_fqdn>/hosts.toml:

server = "https://<ingress_fqdn>"

[host."https://<ingress_fqdn>"]
  capabilities = ["pull", "resolve"]
  skip_verify = true

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

Параметр skip_verify отключает проверку цепочки сертификатов и имени сервера. Используйте его только для разработки и тестирования.

Настройка через основной файл config.toml#

Этот способ используйте для существующих конфигураций, в которых файл /etc/containerd/config.toml не содержит параметр config_path, а параметры реестров уже находятся в основном файле через секции registry.configs. Примеры ниже соответствуют конфигурации containerd 1.x с секцией plugins."io.containerd.grpc.v1.cri". Если файл содержит другой идентификатор подключаемого модуля CRI, сохраните структуру текущего файла и добавьте параметры TLS в соответствующую секцию реестра.

Для настройки доверия к корпоративному или собственному удостоверяющему центру выполните следующие действия на каждом рабочем узле Kubernetes:

Создайте каталог для сертификата удостоверяющего центра:
```
sudo mkdir -p /etc/containerd/certs.d/<ingress_fqdn>
```
Скопируйте корневой сертификат удостоверяющего центра:
```
sudo cp <ca.crt> /etc/containerd/certs.d/<ingress_fqdn>/ca.crt
```
Добавьте в файл /etc/containerd/config.toml блок для доменного имени Ingress:
```
[plugins."io.containerd.grpc.v1.cri".registry.configs."<ingress_fqdn>".tls]
  ca_file = "/etc/containerd/certs.d/<ingress_fqdn>/ca.crt"
```
Здесь:
- <ingress_fqdn> – доменное имя Ingress, например aa-demo.example.com;
- <ca.crt> – файл корневого сертификата корпоративного или собственного удостоверяющего центра.
Перезапустите containerd для применения изменений:
```
sudo systemctl restart containerd
```
Убедитесь, что сервис запущен без ошибок:
```
sudo systemctl status containerd --no-pager
```

В тестовой или лабораторной среде можно отключить проверку сертификата TLS для конкретного реестра через основной файл config.toml. Для отключения проверки выполните следующие действия:

Добавьте в файл /etc/containerd/config.toml блок для доменного имени Ingress:
```
[plugins."io.containerd.grpc.v1.cri".registry.configs."<ingress_fqdn>".tls]
  insecure_skip_verify = true
```
Здесь <ingress_fqdn> – доменное имя Ingress, например aa-demo.example.com.
Перезапустите containerd для применения изменений:
```
sudo systemctl restart containerd
```
Убедитесь, что сервис запущен без ошибок:
```
sudo systemctl status containerd --no-pager
```

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

Параметр insecure_skip_verify отключает проверку цепочки сертификатов и названия сервера. Используйте его только для разработки и тестирования.

Подробное описание способов настройки реестров см. в официальной документации containerd:

Registry Configuration – настройка реестров через hosts.toml, параметры server, capabilities, ca и skip_verify;
CRI Plugin Config Guide – описание конфигурации CRI и версий файла config.toml;
containerd-config.toml(5) – справочник по параметрам файла config.toml.