Основы безопасности в Kubernetes: Public Key Infrastructure

От переводчика: в блоге компании Datadog, создателя одноимённой платформы для наблюдаемости и мониторинга облачных приложений, есть достойная серия статей об основах обеспечения безопасности в Kubernetes. Наиболее интересным нам показался материал об инфраструктуре публичных ключей (Public Key Infrastructure, или PKI). Эта тема поднимается не так часто, но в вопросе безопасности кластеров играет далеко не последнюю роль и потому будет полезна начинающим DevOps-специалистам. Перевели текст Rory McCune, Senior Advocate Security & Compliance. Передаём слово автору.

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

Реализация Kubernetes PKI

Итак, зачем мы вообще используем PKI в Kubernetes? С точки зрения безопасности это помогает аутентифицировать соединения между системными компонентами и шифровать передаваемые по этим соединениям данные. Всё это позволяет защититься от сниффинга трафика и атак по типу Adversary-in-the-Middle (AiTM, «злоумышленник посередине»).

Важно разобраться, какие именно соединения нужно защитить. В Kubernetes есть много взаимодействующих компонентов, каждый из которых требует установки TLS-соединений.

В статье мы рассмотрим стандартный кластер, развёрнутый с помощью kubeadm, что позволит сосредоточиться на основных компонентах K8s и типичных конфигурациях. Схема TLS-соединений базовых компонентов кластера выглядит примерно так:

Большинство из них — это аутентифицируемые TLS-соединения, в которых клиент проверяет подлинность сервера, чтобы избежать подключения к «левым» системам. Но есть одно исключение, а именно подключение сервера API к kubelet’у. Соединение можно аутентифицировать, но по умолчанию этого не происходит. В итоге оно оказывается уязвимым для тех самых атак AiTM, о чём прямо говорится в документации Kubernetes.

Центры сертификации и сертификаты

Защита столь большого числа соединений, естественно, ведёт к необходимости управления множеством сертификатов. Дополнительно всё усложняется ещё и тем, что в процессе участвуют различные центры сертификации (Certificate Authority, CA). Как правило, Kubernetes задействует внутренние CA для ключей. Если вы подключитесь к кластеру с помощью инструментов вроде curl или браузера, то получите предупреждение о недоверенных сертификатах.

Все созданные сертификаты можно найти в каталоге /etc/kubernetes/pki/ на узле с управляющим слоем Kubernetes, созданном через kind:

			|-- apiserver-etcd-client.crt
|-- apiserver-etcd-client.key
|-- apiserver-kubelet-client.crt
|-- apiserver-kubelet-client.key
|-- apiserver.crt
|-- apiserver.key
|-- ca.crt
|-- ca.key
|-- etcd
|   |-- ca.crt
|   |-- ca.key
|   |-- healthcheck-client.crt
|   |-- healthcheck-client.key
|   |-- peer.crt
|   |-- peer.key
|   |-- server.crt
|   `-- server.key
|-- front-proxy-ca.crt
|-- front-proxy-ca.key
|-- front-proxy-client.crt
|-- front-proxy-client.key
|-- sa.key
|-- sa.pub
		

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

Основной центр подписывает большинство сертификатов кластера (например, тех, которые kubelet использует для подключения к API-серверу). Сертификаты также можно подписывать самим, используя OpenSSL или аналогичные инструменты, но для этого потребуется интерактивный доступ к хосту управляющего слоя. Кроме того, есть вариант использовать основной центр сертификации Kubernetes для удалённого подписания сертификатов через Certificate Signing Request API.

Помимо основного CA, у нас есть ещё два дополнительных. Первый используется для защиты соединений между etcd и API-сервером. Отдельный центр в этом случае нужен, потому что в той конфигурации, которую использует Kubernetes, etcd предоставляет полный доступ к данным для любого сертификата, подписанного центром, которому она доверяет. Если бы etcd использовало основной CA, то любой атакующий, получивший доступ к действующему клиентскому сертификату, смог бы полностью контролировать хранилище данных кластера.

Наконец, ещё один центр — requestheader-client (файл front-proxy-ca.crt) — отвечает за обработку запросов на агрегацию (когда используются дополнительные API-серверы). Здесь отдельный CA нужен из-за риска конфликтов, которые могут возникнуть при использовании одного и того же центра.

На рабочем узле кластера файлы конфигурации PKI (хранятся по адресу /var/lib/kubelet/pki) нужны kubelet’у. Он использует PEM-файл для подтверждения своей подлинности перед API-сервером, когда выступает в качестве клиента, а файлы crt и key используются kubelet API. В дефолтном развёртывании, проведённом с помощью kubeadm, файл crt содержит самоподписанный сертификат, что делает подключающихся к kubelet’у клиентов (например, API-сервер) уязвимыми для сниффинга и атак AiTM.

			|-- kubelet-client-2025-06-27-08-58-52.pem
|-- kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2025-06-27-08-58-52.pem
|-- kubelet.crt
|-- kubelet.key
		

Суть сертификатов и их назначение подробно описываются в документации Kubernetes.

Защита сертификатов Kubernetes

С точки зрения безопасности в отношении использования PKI и сертификатов в Kubernetes есть два основных момента.

Первый заключается в необходимости обеспечивать безопасность файлов, где хранятся приватные ключи. В частности, это ca.key с ключом для основного центра сертификации Kubernetes. Если атакующий доберётся до этого файла, то без проблем обеспечит себе постоянный доступ на уровне администратора кластера, поскольку сможет с его помощью создавать новые привилегированные учётные записи.

Для защиты файлов ключей важно не размещать их в репозиториях исходного кода. Также важно тщательно контролировать резервные копии этих файлов. Способ решения этой проблемы будет зависеть от используемого дистрибутива Kubernetes. Например, Rancher Kubernetes Engine 1 (RKE1) хранит приватные ключи в ConfigMap. Пользователи с доступом к нему получают и полный доступ к кластеру. Поэтому очень важно быть в курсе всех тонкостей конкретного дистрибутива.

Риски при использовании клиентских сертификатов

В свете обсуждения защиты PKI и Kubernetes также важно затронуть вопросы безопасности, возникающие при использовании клиентских сертификатов для аутентификации. Здесь основная проблема Kubernetes — невозможность отозвать отдельные сертификаты. Дело в том, что K8s не поддерживает списки отозванных сертификатов (Certificate Revocation Lists, CRL) или протоколы вроде Online Certificate Status Protocol (OCSP).

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

Системные компоненты Kubernetes используют PKI для защиты
коммуникаций и аутентификации при использовании API. Важно понимать, как в этом механизме участвуют
разные центры сертификации, и защищать используемые ими чувствительные файлы.