Одно дело обезопасить кластер Kubernetes, а вот поддерживать защиту — задачка та еще. Впрочем, в Kubernetes добавилось новых средств: теперь выполнять и то, и другое намного проще.
В Kubernetes (начиная с версии 1.6) ввели концепт контроля доступа на основе ролей (RBAC), который позволяет администраторам определять политики ограничения для пользователей кластера. То есть создаете пользователя с ограниченным доступом: лимитируете доступ пользователя к ресурсам вроде секретов или к определенным неймспейсам.
В этом посте мы не станем разбираться, как реализовать RBAC. Приличных источников, где эта тема разобрана от и до, хватает:
- https://medium.com/containerum/configuring-permissions-in-kubernetes-with-rbac-a456a9717d5d
- https://www.cncf.io/blog/2018/08/01/demystifying-rbac-in-kubernetes/
- https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/
- https://kubernetes.io/docs/reference/access-authn-authz/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. Способ проверен на практике: отлавливать изменения, нарушающие политики доступа, получается куда быстрее!
Спасибо, что нашил время прочитать этот пост!
Автор: nAbdullin