Организация инфраструктуры PKI в Nova Container Platform
В Kubernetes SSL/TLS сертификаты используются в различных сценариях для решения следующих задач:
-
защита веб-трафика внутри кластера и за его пределами.
-
дополнительная TLS-аутентификация между компонентами Kubernetes.
Следующие операции в среде Kubernetes требуют наличия инфраструктуры PKI:
-
Клиентские сертификаты Kubelet необходимы для взаимодействия с Kubernetes API.
-
Серверные сертификаты Kubelet необходимы Kubernetes API для взаимодействиями с Kubelet на узлах кластера.
-
Серверные сертификаты необходимы для взаимодействия с Kubernetes API.
-
Клиентские сертификаты администраторов кластера необходимы для взаимодействия с Kubernetes API.
-
Клиентские сертификаты Kubernetes API необходимы для взаимодействиями с Kubelet на узлах кластера.
-
Клиентские сертификаты Kubernetes API необходимы для взаимодействиями с хранилищем Etcd.
-
Клиентские сертификаты Controller Manager необходимы для взаимодействиями с Kubernetes API.
-
Клиентские сертификаты Scheduler необходимы для взаимодействиями с Kubernetes API.
-
Клиентские сертификаты необходимы для компонента Kubernetes Front Proxy.
-
Клиентские и серверные сертификаты ресурсов Ingress необходимы для взаимодействия пользователей платформы с опубликованными веб-ресурсами.
В хранилище Etcd также используется механизм взаимной TLS-аутентификации (mTLS) для клиентов и участников кластера.
В Nova Container Platform все необходимые для Kubernetes и компонентов платформы сертификаты создаются автоматически в StarVault и впоследствии могут быть автоматически или принудительно обновлены.
1. Архитектура PKI
Выпуск и управление требуемыми сертификатами осуществляется в StarVault с использованием движка PKI Secrets Engine. Данный движок позволяет не только динамически генерировать X.509 сертификаты, но также и организовывать центры сертификации (CA), обслуживать базы данных сертификатов, управлять процессами отзыва, а также применять политики сертификатов.
1.1. Центры сертификации
Центры сертификации в StarVault делятся на корневые и промежуточные:
-
Корневые СА создаются по принципу Single root CA для каждого глобального блока платформы (Kubernetes, Etcd, Kubernetes Front Proxy и т.п.).
-
Промежуточные СА используются в платформе более гранулярно, разделяя взаимодействие компонентов глобального блока платформы (Kubernetes API, Kubelet, Controller Manager и т.п.).
1.1.1. Корневые центры сертификации
В Nova Container Platform используется следующие корневые центры сертификации:
| Имя | Default CN | TTL | Описание |
|---|---|---|---|
|
|
10 лет |
Корневой СА для хранилища Etcd. |
|
|
10 лет |
Корневой СА для инфраструктуры Kubernetes. |
1.1.2. Промежуточные центры сертификации
В Nova Container Platform используется следующие промежуточные центры сертификации:
| Имя | Default CN | Родительский СА | TTL | Описание |
|---|---|---|---|---|
|
|
|
5 лет |
Промежуточный СА для хранилища Etcd. Применяется для выпуска сертификатов (Etcd Client). |
|
|
|
5 лет |
Промежуточный СА для хранилища Etcd. Применяется для выпуска сертификатов (Etcd Peer). |
|
|
|
5 лет |
Промежуточный СА для инфраструктуры Kubernetes. Применяется для выпуска сертификатов компонентов Kubernetes Control Plane. |
|
|
|
5 лет |
Промежуточный СА для инфраструктуры Kubernetes. Применяется для выпуска сертификатов компонента Kubelet. |
|
|
|
5 лет |
Промежуточный СА для инфраструктуры Kubernetes. Применяется для выпуска сертификатов для ресурсов Ingress. Интегрирован с компонентом CertManager через ресурс ClusterIssuer |
|
|
|
5 лет |
Промежуточный СА для инфраструктуры Kubernetes. Применяется для выпуска сертификатов компонентом Controller Manager при использовании Certificates API. Интегрирован с компонентом CertManager через ресурс ClusterIssuer |
|
|
|
5 лет |
Промежуточный СА для инфраструктуры Kubernetes. Используется в Kubernetes Front Proxy, применяется для выпуска сертификатов компонентов, расширяющих возможности Kubernetes API. |
1.2. Политики выпуска сертификатов
Для обеспечения дополнительной безопасности процесса выпуска сертификатов в StarVault для каждого PKI автоматически настраиваются определенные политики выпуска (роли) сертификатов. Данные роли контролируют различные параметры выпускаемых сертификатов, например:
-
Тип используемого криптографического алгоритма для ключей шифрования
-
Разрешение на выпуск wildcard-сертификатов
-
Правила проверки Common Name
-
TTL
-
Разрешенные домены
-
Разрешение на добавление в сертификаты IP и DNS Sans и их перечень.
-
Правила расширенного использования ключа (Extended Key Usage)
Каждая роль содержит только те параметры, которые требуются тому или иному компоненту согласно лучшим практикам Kubernetes. Таким образом, выпуск сертификата без строгого соответствия данным параметрам невозможен.
Некоторые параметры сертификатов в ролях являются динамическими и различаются в кластерах Nova Container Platform. При установке платформы nova-ctl генерирует данные параметры, используя данные конфигурационного манифеста, а затем выполняет инициализацию StarVault.
1.3. Расположение сертификатов
Корневые и промежуточные центры сертификации, создаваемые в StarVault, не являются экспортируемыми. Это означает, что сгенерированные приватные ключи СА сохраняются в StarVault в зашифрованном виде и впоследствии не могут быть получены.
На узлах кластера Kubernetes находятся выпущенные сертификаты и приватные ключи для компонентов Kubernetes в следующих директориях и файлах:
-
/opt/nova/conf.d/pki/ -
/opt/nova/conf.d/pki/etcd/