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

https://medium.com/yld-engineering-blog/testing-kubernetes-rbac-5e00dc93af8e
  • Перевод

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


image


В 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. Способ проверен на практике: отлавливать изменения, нарушающие политики доступа, получается куда быстрее!


Спасибо, что нашли время прочитать этот пост!

  • +14
  • 2,5k
  • 3
Southbridge
272,00
Обеспечиваем стабильную работу серверов
Поделиться публикацией

Комментарии 3

    +1

    Если основная суть статьи, что "нужно тестировать rbac настройки", то, извините, ее можно было не писать. Это настолько очевидно, как необходимость тестировать acl в продакшн. Типичные проблемы, с которому встречаются админы: назначили не то, назначили не той персоне. Также тестирование через bats выглядит достаточно сомнительным. Этот фреймворк вообще насколько удобен? Мне кажется, что разумнее начать с mocha.
    Короче — готового решения не увидел, в остальном — вода

      +1
      Да, я не к тому, что «все плохо». Я просто верю и знаю, что Вы можете писать намного лучше ) а еще — и авторские материалы, а не просто переводы.
        +2
        Самая интересная статья, которую я готовил, улетела в жуткие минуса. :)
        Делаем что можем, потихоньку развиваемся.

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое