Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Теги: etcd, безопасность, kubernetes, application security

2 В этой статье поговорим о последнем уровне из<a>набора по безопасности</a>Kubernetes. Тут уместно ещё раз вспомнить "первую заповедь" докеровода: "Не храните secrets в докер-файлах". Но даже если мы не храним их в докер-images, мы храним их где-нибудь в Kubernetes, что тоже небезопасно.

3 По умолчанию Kubernetes Secrets не шифруются, они просто кодируются, следовательно, любой человек может их прочитать, забрать себе и получить доступ к базе уже со своего компьютера. Но есть и хорошая новость: начиная с релиза 1.13, в Kubernetes стало поддерживаться шифрование secrets в etcd. Но если у вас есть не только Kubernetes, а какое-то ещё решение/приложение то возникает другая проблема: в etcd оно уже не полезет.

4 Да, у нас есть стандартный инструментetcd, который: - давно на рынке; - безопасен; - поддерживает Dynamic secrets, о которых можно говорить долго.

5 Но есть одно но:дружба Vault с Кубером чисто формальная. Главная проблема - автоматизация доставки Vault Secrets в поды (приходится это делать вручную). В принципе, проблема решаема, для чего существуют два паттерна: 1.Sidecar containers. Создаётся Sidecar-контейнер, запускаемый при инициализации подов. Паттерн не очень удобен тем, что нужно для каждого пода писать команды. 2.Custom resource definitions. Создаётся специальный IP-объект Vault Secret, который уже расшифровывается. Фактически, он динамически получает Secret из Vault’а и записывает его в нужные папки в поде.

6 Вот, в принципе, и всё, осталось предложить вам список ссылок с полезными проектами для интеграции с Vault:

7 Читайте также по этой теме: •<a>Безопасность в Kubernetes. Docker Image Security</a>; •<a>Безопасность в Kubernetes: Host Level Security</a>; •<a>Безопасность в Kubernetes: Container Runtime Security</a>; •<a>Сетевая безопасность в Kubernetes</a>; •<a>Внутренняя безопасность в Kubernetes</a>.