Разрешения и учетные записи пользователей

RethinkDB управляет доступом к кластерам с помощью системы, основанной на пользователях, разрешениях и областях действия. Вместе они позволяют задавать точный контроль за чтением, записью и административным доступом до уровня отдельных таблиц.

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

Пользователь в RethinkDB похож на пользователей в большинстве других систем баз данных; у администратора базы данных может быть учетная запись пользователя, а клиентским приложениям могут быть предоставлены учетные записи пользователей. Эти учетные записи не связаны с учетными записями пользователей, которые могут быть реализованы внутри приложения.

Пользователи создаются путём вставки документов в users системную таблицу. Каждый пользователь имеет имя учетной записи в поле id, и необязательный пароль.

r.db('rethinkdb').table('users').insert({id: 'bob', password: 'secret'})

Если вы прочитаете этот документ снова, то получите следующее:

{
    "id": "bob",
    "password": true
}

Поле password просто содержит булево значение, указывающее, установлен ли пароль или нет. Нет возможности прочитать пароль из базы данных.

Вы можете обновить пароль на новое значение или удалить его, установив его значение в false.

r.db('rethinkdb').table('users').get('bob').update({password: false})

Изменить имя пользователя после его создания нельзя. Однако вы можете удалить пользователей из таблицы.

Итерации хеширования паролей

По умолчанию RethinkDB будет использовать 4096 итераций для хеширования паролей во время процесса установления соединения между драйверами клиентов и сервером. Есть возможность задать количество итераций для каждой учетной записи, задав пароли в виде объекта следующего формата: {password: "password", iterations: 4096}. Если вы хотите использовать только 1024 итерации, вы можете задать пароль следующим образом:

r.db('rethinkdb').table('users').insert({id: 'bob', password: {password: 'secret', iterations: 1024}})

Обратите внимание, что вы не сможете прочитать значение iterations для учетной записи; так как оно хранится в поле пароля, оно остается только для чтения.

Значение для iterations представляет собой компромисс между производительностью и защитой от атак методом грубой силы. Если соединения медленные, рассмотрите возможность уменьшения числа итераций. Увеличение числа итераций затруднит применение атак методом грубой силы, но увеличит использование ЦП клиентами при установлении соединения.

Пользователь администратор

Новый кластер RethinkDB всегда имеет одного пользователя с именем admin; этот пользователь всегда имеет все разрешения на глобальном уровне, и пользователя нельзя удалить. По умолчанию у пользователя admin нет пароля. Вы можете изменить это, обновив документ пользователя admin или указав параметр командной строки --initial-password при запуске.

Веб-интерфейс администрирования всегда подключается как пользователь admin, и пропускает процесс аутентификации (т. е. пароль не используется для этого соединения). Хотя веб-интерфейс нельзя защитить паролем, вы можете ограничить адреса, с которых он будет принимать подключения, используя параметр командной строки --bind-http. Для получения более подробной информации ознакомьтесь со статьёй Защитите свой кластер.

Если вы забудете пароль администратора, его можно изменить в Data Explorer, используя update как описано выше.

Разрешения

Существует четыре разных разрешения, которые могут быть предоставлены пользователю:

• read позволяет читать данные в таблицах.
• write позволяет изменять данные, включая вставку, замену/обновление и удаление.
• connect позволяет пользователю открывать HTTP-соединения с помощью команды http. Ограничение этого позволяет защититься от использования эксплойта в вашем коде для обхода ограничений брандмауэра.
• config предоставляет пользователям различные возможности, в зависимости от области действия:
  • область действия таблицы позволяет создавать и удалять вторичные индексы в таблице, а также изменять конфигурацию кластера таблицы (такие команды как reconfigure и rebalance).
  • область действия базы данных позволяет создавать и удалять таблицы, помимо вышеперечисленного.
  • глобальная область действия позволяет создавать и удалять базы данных, помимо вышеперечисленного. (Однако, пользователь должен иметь разрешение config для таблиц внутри базы данных, чтобы удалить их, что может не быть так, если их разрешение config переопределено на уровне таблицы; см. Области действия ниже.)

Разрешения хранятся в permissions системной таблице. Хотя вы можете изменить разрешения, изменив документы в этой таблице, намного удобнее использовать команду grant; см. ниже.

Области действия

Разрешения read, write и config могут быть заданы в трёх областях действия, от наиболее точной до наименее:

• таблица (только для одной таблицы)
• база данных (для базы данных и таблиц внутри неё)
• глобальная (для всех баз данных и таблиц внутри них)

Разрешения, заданные на более низком уровне, будут переопределять разрешения, заданные на более высоком уровне: пользователю могут быть предоставлены права чтения и записи для базы данных field_notes, но отказано в праве записи для таблицы calendar и правах чтения или записи для таблицы supervisor_only.

User: notesapp
    database "field_notes" { read: true, write: true, config: false }
        table "calendar" { write: false }
        table "supervisor_only" { read: false, write: false }

Таблица calendar наследует разрешения read: true с уровня базы данных, но указывает разрешение write: false для того, чтобы таблица стала только для чтения для notesapp. Таблица supervisor_only переопределяет как разрешения на чтение, так и на запись. Учетная запись notesapp имеет права чтения и записи для всех остальных таблиц в базе данных field_notes, но не может создавать и удалять индексы или изменять конфигурацию кластера любой таблицы.

Команда grant

Команда ReQL grant используется для предоставления и отзыва разрешений для пользователей. Область действия выбирается цепочкой grant после db (для области действия базы данных), table (для области действия таблицы) или вызовом её напрямую (для глобальной области действия).

r.grant("user", {permissions}) → object
table.grant("user", {permissions}) → object
db.grant("user", {permissions}) → object

Чтобы задать описанные выше разрешения для пользователя Bob, вы должны выполнить следующие команды ReQL:

// set database scope
r.db('field_notes').grant('bob', {read: true, write: true, config: false});

// set table scopes
r.db('field_notes').table('calendar').grant('bob', {write: false});
r.db('field_notes').table('supervisor_only').grant('bob', {read: false, write: false});

Дополнительная информация

Документация API для grant:

• JavaScript
• Python
• Ruby
• Java

Также ознакомьтесь с:

• Системные таблицы
• Защита вашего кластера