[Перевод] Проверяем RBAC в Kubernetes
Одно дело обезопасить кластер 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]. Теперь текущий пользователь может проверить, доступно ли ему определенное действие. Поехали:
kubectl auth can-i create pods
Это должно вернуть ответ «yes» или «no» с соответствующим кодом выхода.
Однако при попытке проверить права другого пользователя наткнемся на проблему: пользователь, под которым мы авторизованы в кластере, задан в файле конфига ./kube/config, а иметь отдельные конфиги для тестирования отдельных пользователей — неудобно. К счастью, на помощь снова приходит Kubernetes: он способен имитировать пользователей при помощи меток --as= и --as-group=.
Обновим команду, воспользуемся имитацией другого пользователя:
kubectl auth can-i create pods --as=me
Мы должны увидеть, что с кодом выхода 1 возвращается ответ «no».
И это здорово, потому что у нас теперь есть набор команд, позволяющих проверять, нет ли у пользователя или группы пользователей доступа к какому-либо из ресурсов Kubernetes — от просмотра подов до удаления секретов.
Автоматизация
Впрочем, останавливаться рано: теперь нам под силу реализовать тестовую последовательность, которая опишет перечень требований, и запустить ее как часть конвейера CD. За дело!
Выбирать есть из чего, языков для реализации достаточно: начиная с Ava и Mocha в JavaScript и заканчивая Rspec. В этом случае я реализую чисто bash-евский тестовый фреймворк Bats.
Ниже — пример запуска теста. Он проверяет работу правил RBAC, разрешающих пользователю из группы изменять количество запущенных подов в неймспейсе. Выполняется, если был установлен атрибут «исполняемый». Или — используя bats filename.
#!/usr/bin/env bats
@test "Team namespaces can scale deployments within their own namespace" {
run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns
[ "$status" -eq 0 ]
[ "$output" == "yes" ]
done
}
Команды --as и --as-group требуют использования следующих правил RBAC:
rules:
- apiGroups:
- authorization.k8s.io
resources:
- selfsubjectaccessreviews
- selfsubjectrulesreviews
verbs:
- create
Вот вам простой метод, как реализовать проверки ваших правил RBAC в Kubernetes. Сделав его частью конвейера Kubernetes, мы существенно усилим политику RBAC. Способ проверен на практике: отлавливать изменения, нарушающие политики доступа, получается куда быстрее!
Спасибо, что нашил время прочитать этот пост!
