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

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

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

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