Защита цепочки поставок и секретов

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

• Скомпрометированные базовые образы или зависимости.
• Изменённые образы в реестре.
• Вредоносные этапы конвейера непрерывной интеграции и доставки.

Образы часто поставляются с пакетами, для которых известны уязвимости. Сканирование выявляет их до развёртывания.

• Старые базовые образы накапливают известные уязвимости.
• Раздутые образы расширяют поверхность атаки.
• Встроенные секреты в слоях образа раскрывают учётные данные.

Уменьшайте поверхность атаки, начиная с небольшого проверенного образа.

• Используйте образы без дистрибутива или минимальные базовые образы (без оболочки и менеджера пакетов).
• Закрепляйте базовые образы по дайджесту, а не по изменяемым тегам.
• Отдавайте предпочтение официальным или проверенным внутри организации базовым образам.

Меньший образ означает меньше уязвимостей и меньше инструментов, которыми атакующий сможет злоупотребить после компрометации.

Подпись доказывает, что образ создан вашим конвейером и не подвергался изменению. Сведения о происхождении (SLSA) фиксируют способ его сборки.

• Cosign подписывает образы и проверяет их подписи.
• Создавайте SBOM, чтобы отслеживать каждый компонент.
• Добавляйте подтверждения происхождения сборки.

Обеспечьте запуск только подписанных и проверенных сканированием образов. Контроллер допуска отклоняет неподписанные или уязвимые образы во время развёртывания.

Сама система непрерывной интеграции и доставки представляет большую ценность для атакующего: она хранит учётные данные и может отправлять изменения в рабочую среду.

• Ограничивайте область действия учётных данных конвейера принципом минимальных привилегий и устанавливайте короткие сроки действия.
• Закрепляйте версии и проверяйте сторонние действия и плагины конвейера.
• Изолируйте исполнители сборки; не используйте их повторно между уровнями доверия.
• Защищайте реестр с помощью аутентификации и неизменяемости.

Секреты Kubernetes по умолчанию закодированы в base64, но не зашифрованы. Любой, кто может прочитать их или получить доступ к etcd, увидит данные в открытом виде.

Защитите содержимое etcd, чтобы украденная резервная копия или доступ к etcd не привели к утечке всех данных.

• Включите шифрование в состоянии покоя с помощью EncryptionConfiguration.
• Подключите поставщика облачного KMS для конвертного шифрования.
• Ограничивайте прямой доступ к etcd и проводите его аудит.

Самый надёжный подход — вообще не хранить секреты в хранилище кластера.

• HashiCorp Vault или облачные менеджеры секретов хранят источник истины.
• Оператор внешних секретов или драйвер CSI внедряет их во время выполнения.
• Используйте идентификацию рабочей нагрузки, чтобы поды получали секреты с помощью краткоживущих облачных токенов, а не статических ключей.

Рабочие практики снижают риск раскрытия секретов.

• Никогда не встраивайте секреты в образы и не добавляйте их в систему контроля версий.
• Проверяйте репозитории и образы на наличие утёкших учётных данных.
• Регулярно меняйте секреты и делайте это при подозрении на раскрытие.
• Ограничивайте в RBAC разрешения get/list secrets необходимым минимумом.

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

Сообщайте о каждом недостатке и указывайте конкретный механизм, который его устраняет (политика подписей, шифрование с помощью KMS, внешний менеджер).

Вы усилили защиту цепочки поставок образов и работу с секретами.

• Сканируйте образы, используйте минимальные образы с закреплёнными версиями и подписывайте их с помощью Cosign.
• При допуске применяйте требования к подписанным и проверенным сканированием образам и доверенным реестрам.
• Секреты Kubernetes используют только кодировку base64; включите шифрование в состоянии покоя с помощью KMS.
• Отдавайте предпочтение внешним менеджерам секретов и идентификации рабочих нагрузок; соблюдайте правила безопасного обращения с секретами.

На этом завершаются курс по безопасности Kubernetes и этот набор уроков.