Управление доступом на основе ролей

Обзор

Аутентификация появилась в etcd 2.1. В API etcd v3 интерфейс API и пользовательский интерфейс аутентификации немного изменены для соответствия новой модели данных. Это руководство поможет настроить базовую аутентификацию и управление доступом на основе ролей в etcd v3.

Специальные пользователи и роли

Существует один специальный пользователь root и одна специальная роль root.

Пользователь root

Пользователя root с полным доступом к etcd необходимо создать до включения аутентификации. Он предназначен для административных задач: управления ролями и обычными пользователями. Пользователь root должен иметь роль root и может изменять любые данные в etcd.

Роль root

Роль root можно назначить любому пользователю, не только пользователю root. Пользователь с этой ролью имеет глобальный доступ на чтение и запись и право изменять конфигурацию аутентификации кластера. Роль root также предоставляет права для общего обслуживания кластера, включая изменение состава, дефрагментацию хранилища и создание снимков.

Работа с пользователями

Подкоманда user утилиты etcdctl выполняет все операции с учётными записями пользователей.

Список пользователей выводится командой:

$ etcdctl user list

Пользователь создаётся командой:

$ etcdctl user add myusername

При создании нового пользователя запрашивается пароль. Если указан параметр --interactive=false, пароль можно передать через стандартный ввод. Его также можно задать параметром --new-user-password.

Пользователя без возможности парольной аутентификации можно создать так:

$ etcdctl user add myusername --no-password

Такой пользователь может аутентифицироваться только по Common Name сертификата TLS .

Роли назначаются и отзываются у пользователя командами:

$ etcdctl user grant-role myusername foo
$ etcdctl user revoke-role myusername bar

Параметры пользователя можно просмотреть командой:

$ etcdctl user get myusername

Пароль пользователя изменяется командой:

$ etcdctl user passwd myusername

При изменении снова запрашивается новый пароль. С параметром --interactive=false его можно передать через стандартный ввод.

Учётная запись удаляется командой:

$ etcdctl user delete myusername

Работа с ролями

Подкоманда role утилиты etcdctl управляет правами доступа отдельных ролей, назначаемых пользователям.

Список ролей выводится командой:

$ etcdctl role list

Новая роль создаётся командой:

$ etcdctl role add myrolename

У роли нет пароля; она лишь определяет набор прав доступа.

Роли предоставляется доступ к одному ключу или диапазону ключей.

Диапазон задаётся интервалом [start-key, end-key), где start-key должен лексикографически предшествовать end-key.

Можно предоставить доступ на чтение, запись или оба вида, как в следующих примерах:

# Give read access to a key /foo
$ etcdctl role grant-permission myrolename read /foo

# Give read access to keys with a prefix /foo/. The prefix is equal to the range [/foo/, /foo0)
$ etcdctl role grant-permission myrolename --prefix=true read /foo/

# Give write-only access to the key at /foo/bar
$ etcdctl role grant-permission myrolename write /foo/bar

# Give full access to keys in a range of [key1, key5)
$ etcdctl role grant-permission myrolename readwrite key1 key5

# Give full access to keys with a prefix /pub/
$ etcdctl role grant-permission myrolename --prefix=true readwrite /pub/

Выданные права можно в любой момент просмотреть у роли:

$ etcdctl role get myrolename

Права отзываются аналогичным образом:

$ etcdctl role revoke-permission myrolename /foo/bar

Роль целиком удаляется командой:

$ etcdctl role delete myrolename

Включение аутентификации

Ниже приведён минимальный порядок включения аутентификации. Администратор может настроить пользователей и роли до или после её включения.

Убедитесь, что пользователь root создан:

$ etcdctl user add root
Password of root:

Включите аутентификацию:

$ etcdctl auth enable

После этого etcd работает с включённой аутентификацией. Для её отключения используйте обратную команду:

$ etcdctl --user root:rootpw auth disable

Область защиты аутентификации

Аутентификация, включённая командой etcdctl auth enable, защищает операции V3 gRPC API (get, put, delete, watch и т. д.).

Конечные точки HTTP /metrics и /health обслуживаются отдельным обработчиком и не защищены аутентификацией V3 RBAC. Поэтому Prometheus и балансировщики нагрузки могут собирать метрики без аутентификации gRPC, тогда как данные ключей и значений остаются защищёнными.

Чтобы защитить эти конечные точки наблюдаемости:

• включите mTLS с --cert-file, --key-file и --client-cert-auth;
• либо привяжите метрики к частному интерфейсу через --listen-metrics-urls;
• либо ограничьте доступ сетевыми политиками или правилами межсетевого экрана.

Аутентификация с помощью etcdctl

Для аутентификации etcdctl поддерживает флаг, аналогичный curl.

$ etcdctl --user user:password get foo

Пароль можно ввести по запросу:

$ etcdctl --user user get foo

Пароль также можно передать флагом командной строки --password:

$ etcdctl --user user --password password get foo

В остальном команды etcdctl не меняются. Пользователей и роли по-прежнему можно создавать и изменять, но для этого требуется аутентификация пользователя с ролью root.

Использование Common Name сертификата TLS

Начиная с v3.2, если сервер etcd запущен с --client-cert-auth=true, поле Common Name (CN) клиентского сертификата TLS используется как пользователь etcd. В этом случае CN аутентифицирует пользователя, и пароль клиенту не нужен. Если одновременно 1. передан --client-cert-auth=true и клиент предоставляет CN и 2. клиент предоставляет имя пользователя и пароль, приоритет имеет аутентификация по имени и паролю. Эту возможность нельзя использовать с gRPC-proxy и gRPC-gateway. gRPC-proxy завершает TLS-соединение клиента, поэтому все клиенты используют сертификат прокси. gRPC-gateway внутренне использует TLS-соединение для преобразования запроса HTTP в запрос gRPC и имеет то же ограничение. Поэтому клиенты не могут правильно передать серверу свой CN. Если предоставленный сертификат содержит непустой CN, gRPC-proxy возвращает ошибку и останавливается.

Примечания о стойкости паролей

etcdctl и API etcd не требуют определённой длины пароля при создании пользователя или обновлении его пароля. Соблюдение таких требований должен обеспечивать администратор. Чтобы избежать рисков, связанных со стойкостью паролей, можно использовать аутентификацию по Common Name сертификата TLS и пользователей, созданных с параметром --no-password.