Application security: безопасность приложений в Kubernetes

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

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

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

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

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

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