20.7. Роли в распределённой системе #
20.7.1. Управление пользователями и ролями #
Пользователи и роли в кластере Postgres Pro Shardman — это обычные локальные пользователи и роли PostgreSQL и глобальные пользователи и роли, вводимые и управляемые Postgres Pro Shardman. Управлять ими можно отдельно на каждом сервере или глобально.
В Postgres Pro Shardman также используются понятия глобальных пользователей и глобальных ролей. Только глобальные пользователи (или роли) могут создавать другие объекты Postgres Pro Shardman (например, сегментированные или глобальные таблицы) и владеть ими на уровне кластера. Действие глобальных ролей распространяется на весь распределённый кластер. Однако, несмотря на то, что роль является глобальной, предоставленные ей права могут быть ограничены определённым объектом.
Операции глобальных пользователей всегда выполняются одновременно на всех группах репликации. Например, когда глобальная роль включается в какую-то другую роль или удаляется, эта операция выполнится для всех групп репликации.
Можно создать глобального пользователя, используя оператор CREATE USER ... IN ROLE global, например:
CREATE USER someuser ENCRYPTED PASSWORD 'somepass' IN ROLE global;
При создании глобального пользователя Postgres Pro Shardman автоматически создаёт сопоставление пользователя во всех группах репликации и предоставляет этому пользователю доступ ко всем сторонним серверам, входящим в существующие группы репликации. Поэтому при создании глобального пользователя нужно либо задать незашифрованный пароль, чтобы его можно было сохранить в пользовательском сопоставлении, либо вообще не задавать пароль. Глобальные роли и пользователи, для которых не задан пароль, не могут получить доступ к сторонним серверам. Однако глобальной роли можно выдать нужный набор разрешений, чтобы затем предоставлять их пользователям, включая их в эту роль. Кроме того, можно задать пароль для глобального пользователя позже.
Глобальных пользователей может создавать только пользователь с разрешением CREATEROLE на всех узлах кластера.
Операторы ALTER и DROP для глобальных пользователей транслируются всем группам репликации. Когда роль предоставляется глобальному пользователю, эта операция также транслируется. Переименование глобального пользователя не поддерживается, поскольку это делает недействительными пароли md5/scram-sha-256, хранящиеся в сопоставлениях пользователей.
Список глобальных пользователей хранится в таблице shardman.users.
Роль, заданная в PgSuUsername (обычно postgres), также создаётся как глобальная во время инициализации кластера. Однако роль, заданная в PgReplUsername, создаётся как локальная в каждой группе репликации.
Роль global зарезервирована и не может напрямую использоваться в кластере Shardman. Обратите внимание, что «global» является не фактически заданной ролью, а просто зарезервированным словом.
20.7.2. Управление разрешениями для сегментированных таблиц #
В Postgres Pro Shardman сегментированная таблица — это по сути секционированная таблица, где секции представляют собой либо локальные сегменты, либо сторонние таблицы, ссылающиеся на сегменты в других группах репликации.
Разрешения, установленные для сегментированной таблицы, транслируются для всех групп репликации и всех секций таблицы.
Когда в кластер добавляется новая группа репликации, shardmanctl копирует схему из случайной существующей группы репликации в новую. Он также создаёт сторонний сервер для новой группы репликации во всех существующих группах репликации и пересоздаёт сторонние серверы в новых группах репликации. Разрешения для созданных сторонних серверов и сопоставления пользователей копируются со случайного стороннего сервера в существующей группе репликации. В новой группе репликации для каждой секции сегментированной таблицы shardmanctl создаёт стороннюю таблицу, ссылающуюся на существующий сегмент, и заменяет секцию этой сторонней таблицей. Позже некоторые из этих сторонних таблиц могут быть заменены на реальные таблицы. Это происходит на этапе перебалансировки команды shardmanctl nodes add, если перебалансировка включена. Данные для этих секций переносятся с существующих узлов с использованием логической репликации. Когда shardmanctl создаёт таблицы (или сторонние таблицы), он копирует разрешения из родительской таблицы. В родительской таблице уже должны быть правильные разрешения, поскольку они были скопированы из существующей группы репликации.
20.7. Roles in Distributed System #
20.7.1. Managing Users and Roles #
Users and roles in a Postgres Pro Shardman cluster are usual local PostgreSQL users and roles, and global users and roles introduced and managed by Postgres Pro Shardman. You can manage them separately on each server or globally.
Postgres Pro Shardman also uses concepts of global users and global roles. And only the global users (or roles) can create and own other Postgres Pro Shardman cluster-wide objects, such as sharded or global tables. Global roles are applied for the entire distributed cluster. However, even if roles are global, the privileges granted to a role can be specific to an object.
Operations on global users are always performed on all replication groups simultaneously. For example, when you include a global role in some other role or drop it, this operation will be performed on all replication groups.
You can create a global user with a CREATE USER ... IN ROLE global statement, for example:
CREATE USER someuser ENCRYPTED PASSWORD 'somepass' IN ROLE global;
When a global user is created, Postgres Pro Shardman automatically creates user mappings on all replication groups and grants this user with access to all foreign servers corresponding to existing replication groups. Therefore, when you create a global user, you need to specify either a cleartext password, so that it can be saved in a user mapping, or no password at all. A passwordless global user or role is unable to access foreign servers, but you can use such a role to accumulate some permissions and grant it to different users. You can also set a password for a passwordless global user later.
Global users can be created only by user with CREATEROLE permission on all cluster nodes.
ALTER and DROP statements for global users are broadcasted to all replication groups. When a role is granted to a global user, this operation is also broadcasted. Renaming a global user is not supported since this invalidates md5/scram-sha-256 passwords stored in user mappings.
The list of global users is stored in the shardman.users table.
The role specified in PgSuUsername (usually, postgres) is also created as global user during cluster initialization. However, the role specified in PgReplUsername is created as local user on each replication group.
The role global is reserved and cannot be used directly in a Shardman cluster. Note that 'global' is not a really defined role but just a reserved word.
20.7.2. Managing Permissions for Sharded Tables #
In Postgres Pro Shardman, a sharded table is basically a partitioned table where partitions are either local shards or foreign tables referencing shards in other replication groups.
Permissions granted on a sharded table are broadcasted to all replication groups and to all partitions of the table.
When a new replication group is added to a cluster, shardmanctl copies the schema from a random existing replication group to the new one. It also creates a foreign server for the new replication group on all existing replication groups and recreates foreign servers on new replication groups. Permissions for the created foreign servers and user mappings are copied from a random foreign server in an existing replication group. In the new replication group, for each partition of the sharded table shardmanctl creates a foreign table referencing the existing shard and replaces the partition with this foreign table. Later some of these foreign tables can be replaced by real tables. This happens during the shardmanctl nodes add rebalance stage when rebalance is enabled. Data for these partitions is transferred from existing nodes using logical replication. When shardmanctl creates tables (or foreign tables), it copies permissions from the parent table. The parent table must already have correct permissions since they were copied from an existing replication group.
