Одно дело обезопасить кластер Kubernetes, а вот поддерживать защиту — задачка та еще. Впрочем, в Kubernetes добавилось новых средств: теперь выполнять и то, и другое намного проще.  В Kubernetes (начиная с версии 1.6) ввели концепт контроля доступа на основе ролей (RBAC), который позволяет администраторам определять политики ограничения для пользователей кластера. То есть создаете пользователя с ограниченным доступом: лимитируете доступ пользователя к ресурсам вроде секретов или к определенным неймспейсам. В этом посте мы не станем разбираться, как реализовать RBAC. Приличных источников, где эта тема разобрана от и до, хватает: Лучше сосредоточимся на том, как сделать так, чтобы выполнялись требования вашего бизнеса, и проследим, нуждаются ли запущенные объекты RBAC в проверке: выполняют ли они свои функции. Некая организация принимает для работы с новым кластером Kubernetes несколько групп. Есть требование: нельзя вмешиваться в развертывания соседней группы, чтобы не случилось непредвиденных межгрупповых проблем или даунтаймов. И вот владелец кластера развернул в кластер RBAC, ограничив тем самым доступ в определенный неймспейс. Первая проверка показала: группы не могут просматривать поды друг у друга в неймспейсах. Прошла неделя. Владелец кластера заметил, что пользователь из изолированного неймспейса читает секреты из другого неймспейса. Как так? Он же применил RBAC! Применить-то применил, но, как и в работе с кодом, систему надо тестировать на соответствие желаемому результату. Хорошо, что инструмент CLI Кубернетес kubectl дает набор средств для проверки конфигурации RBAC. kubectl auth can-i Can I? («можно мне?»)
can-i при помощи API просто проверяет, можно ли выполнить некое действие. Параметры он использует следующие: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]. Теперь текущий пользователь может проверить, доступно ли ему определенное действие. Поехали: Это должно вернуть ответ «yes» или «no» с соответствующим кодом выхода. Однако при попытке проверить права другого пользователя наткнемся на проблему: пользователь, под которым мы авторизованы в кластере, задан в файле конфига ./kube/config, а иметь отдельные конфиги для тестирования отдельных пользователей — неудобно. К счастью, на помощь снова приходит Kubernetes: он способен имитировать пользователей при помощи меток --as= и --as-group=.  Обновим команду, воспользуемся имитацией другого пользователя: Мы должны увидеть, что с кодом выхода 1 возвращается ответ «no». И это здорово, потому что у нас теперь есть набор команд, позволяющих проверять, нет ли у пользователя или группы пользователей доступа к какому-либо из ресурсов Kubernetes — от просмотра подов до удаления секретов. Впрочем, останавливаться рано: теперь нам под силу реализовать тестовую последовательность, которая опишет перечень требований, и запустить ее как часть конвейера CD. За дело! Выбирать есть из чего, языков для реализации достаточно: начиная с Ava и Mocha в JavaScript и заканчивая Rspec. В этом случае я реализую чисто bash-евский тестовый фреймворк Bats. Ниже — пример запуска теста. Он проверяет работу правил RBAC, разрешающих пользователю из группы изменять количество запущенных подов в неймспейсе. Выполняется, если был установлен атрибут «исполняемый». Или — используя bats filename. Команды --as и --as-group требуют использования следующих правил RBAC:  Вот вам простой метод, как реализовать проверки ваших правил RBAC в Kubernetes. Сделав его частью конвейера Kubernetes, мы существенно усилим политику RBAC. Способ проверен на практике: отлавливать изменения, нарушающие политики доступа, получается куда быстрее! Спасибо, что нашли время прочитать этот пост!