Проверяем RBAC в Kubernetes

Одно дело обезопасить кластер Kubernetes, а вот поддерживать защиту — задачка та еще. Впрочем, в Kubernetes добавилось новых средств: теперь выполнять и то, и другое намного проще.

В Kubernetes (начиная с версии 1.6) ввели концепт контроля доступа на основе ролей (RBAC), который позволяет администраторам определять политики ограничения для пользователей кластера. То есть создаете пользователя с ограниченным доступом: лимитируете доступ пользователя к ресурсам вроде секретов или к определенным неймспейсам.

В этом посте мы не станем разбираться, как реализовать RBAC. Приличных источников, где эта тема разобрана от и до, хватает:

• https://medium.com/containerum/configuring-permissions-in-kubernetes-with-rbac-a456a9717d5d ^[1]
• https://www.cncf.io/blog/2018/08/01/demystifying-rbac-in-kubernetes/ ^[2]
• https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/ ^[3]
• https://kubernetes.io/docs/reference/access-authn-authz/rbac/ ^[4]

Лучше сосредоточимся на том, как сделать так, чтобы выполнялись требования вашего бизнеса, и проследим, нуждаются ли запущенные объекты 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 ^[5].

Ниже — пример запуска теста. Он проверяет работу правил 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

Источник ^[6]