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

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

Чтобы указать описанные выше разрешения для Боба, вы должны выполнить следующие команды 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

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

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