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

> Базовое руководство по аутентификации и управлению доступом на основе ролей

---

Индекс LLMS: [llms.txt](/ru/llms.txt)

---

## Обзор {#overview}

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

## Специальные пользователи и роли {#special-users-and-roles}

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

### Пользователь `root` {#user-root}

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

### Роль `root` {#role-root}

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

## Работа с пользователями {#working-with-users}

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

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

```
$ etcdctl user list
```

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

```
$ etcdctl user add myusername
```

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

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

```
$ etcdctl user add myusername --no-password
```

Такой пользователь может [аутентифицироваться только по Common Name сертификата TLS](#using-tls-common-name).

> [!NOTE]
> etcd не поддерживает аутентификацию с пустым паролем через `--user username:`. Например, пользователь с пустым паролем, созданный командой `etcdctl user add anonymous:''`, не может пройти аутентификацию по имени и паролю, а запросы вида `etcdctl --user anonymous: get foo` завершаются ошибкой `user name is empty`.

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

```
$ 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
```


## Работа с ролями {#working-with-roles}

Подкоманда `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
```

## Включение аутентификации {#enabling-authentication}

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

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

```
$ etcdctl user add root
Password of root:
```

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

```
$ etcdctl auth enable
```

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

```
$ etcdctl --user root:rootpw auth disable
```

## Область защиты аутентификации {#security-scope-of-authentication}

Аутентификация, включённая командой `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` {#using-etcdctl-to-authenticate}

Для аутентификации `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 {#using-tls-common-name}

Начиная с 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 возвращает ошибку и останавливается.

## Примечания о стойкости паролей {#notes-on-password-strength}

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

---

Обратные ссылки:

- [Понижение версии etcd от 3.5 до 3.4](/ru/docs/etcd/downgrades/downgrade_3_5/)