Контроль доступу на основі ролей

Огляд

Автентифікація була додана в etcd 2.1. API v3 etcd трохи змінив API функції автентифікації та інтерфейс користувача, щоб краще відповідати новій моделі даних. Цей посібник призначений для допомоги користувачам у налаштуванні базової автентифікації та контролю доступу на основі ролей в etcd v3.

Спеціальні користувачі та ролі

Існує один спеціальний користувач, root, і одна спеціальна роль, root.

Користувач root

Користувач root, який має повний доступ до etcd, повинен бути створений перед активацією автентифікації. Ідея користувача root полягає в адміністративних цілях: управління ролями та звичайними користувачами. Користувач root повинен мати роль root і має право змінювати будь-що всередині etcd.

Роль root

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

Робота з користувачами

Підкоманда user для etcdctl обробляє всі питання, повʼязані з обліковими записами користувачів.

Список користувачів можна знайти за допомогою:

$ etcdctl user list

Створення користувача так само просто, як

$ etcdctl user add myusername

Під час створення нового користувача буде запропоновано ввести новий пароль. Пароль можна ввести зі стандартного вводу, якщо вказано опцію --interactive=false. Також можна використовувати --new-user-password для введення пароля.

Ролі можуть бути надані та відкликані для користувача за допомогою:

$ 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 в алфавітному порядку.

Доступ може бути наданий як для читання, запису або обох, як у наступних прикладах:

# Надати доступ на читання до ключа /foo
$ etcdctl role grant-permission myrolename read /foo

# Надати доступ на читання до ключів з префіксом /foo/. Префікс дорівнює діапазону [/foo/, /foo0)
$ etcdctl role grant-permission myrolename --prefix=true read /foo/

# Надати доступ тільки на запис до ключа /foo/bar
$ etcdctl role grant-permission myrolename write /foo/bar

# Надати повний доступ до ключів у діапазоні [key1, key5)
$ etcdctl role grant-permission myrolename readwrite key1 key5

# Надати повний доступ до ключів з префіксом /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 для автентифікації

etcdctl підтримує подібний прапор до curl для автентифікації.

$ etcdctl --user user:password get foo

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

$ etcdctl --user user get foo

Пароль також можна ввести за допомогою прапорця командного рядка --password:

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

Створення користувача, який не може бути автентифікований за допомогою пароля, також можливо, як показано нижче:

$ etcdctl user add myusername --no-password

Такий користувач може бути автентифікований лише за допомогою TLS Common Name.

Інакше всі команди etcdctl залишаються такими ж. Користувачі та ролі все ще можуть бути створені та змінені, але вимагають автентифікації користувачем з роллю root.

Використання TLS Common Name

Починаючи з версії v3.2, якщо сервер etcd запускається з опцією --client-cert-auth=true, поле Common Name (CN) у TLS сертифікаті клієнта буде використовуватися як користувач etcd. У цьому випадку загальне імʼя автентифікує користувача, і клієнту не потрібен пароль. Зверніть увагу, що якщо одночасно виконуються 1. передано --client-cert-auth=true і клієнт надає CN, і 2. клієнт надає імʼя користувача та пароль, пріоритет надається автентифікації на основі імені користувача та пароля. Зверніть увагу, що ця функція не може бути використана з gRPC-proxy та gRPC-gateway. Це тому, що gRPC-proxy завершує TLS зʼєднання від свого клієнта, тому всі клієнти використовують сертифікат проксі. gRPC-gateway використовує TLS зʼєднання внутрішньо для перетворення HTTP запиту в gRPC запит, тому має ті ж обмеження. Тому клієнти не можуть правильно надати свій CN серверу. gRPC-proxy викличе помилку і зупиниться, якщо наданий сертифікат має непорожній CN. gRPC-proxy повертає помилку, яка вказує на те, що клієнт має непорожній CN у своєму сертифікаті.

Примітки щодо міцності пароля

etcdctl та API etcd не вимагають конкретної довжини пароля під час створення користувача або операцій оновлення пароля користувача. Відповідальність за дотримання цих вимог лежить на адміністраторові. Для уникнення ризиків безпеки, повʼязаних з міцністю пароля, можна використовувати автентифікацію на основі TLS Common Name та користувачів, створених з опцією --no-password.