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

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 представляет собой компромисс между производительностью и защитой от атак с применением грубой силы. Если соединения медленные, рассмотрите возможность уменьшения числа итераций. Увеличение числа итераций затруднит применение атаки с применением грубой силы, но увеличит использование ЦП клиентами при установлении соединения.

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

Новый кластер 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

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

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