Hologres:Grant permissions using SPM

Etapa 1: Ative a extensão SPM

Antes de ativar o SPM, execute o comando abaixo para habilitar a invocação da função:

CREATE EXTENSION spm;

Etapa 2: Ative o SPM para o banco de dados de destino

Conecte-se ao banco de dados de destino e execute:

CALL spm_enable();

O SPM vem desativado por padrão. Para detalhes sobre esta função, consulte spm_enable.

Etapa 3: Migre objetos existentes (se aplicável)

Ignore esta etapa se o banco de dados for recém-criado e não contiver objetos.

Se o banco de dados utilizar o modelo de autorização padrão do PostgreSQL e contiver tabelas, visualizações ou tabelas externas, migre esses objetos para o SPM antes de prosseguir. Sem a migração, as permissões das tabelas existentes serão perdidas, o que pode interromper cargas de trabalho em execução.

CALL spm_migrate();

Este comando altera o proprietário de todos os objetos existentes para o grupo developer. Como a migração executa ALTER ... OWNER TO em cada objeto, ela está sujeita ao limite max_locks_per_transaction do PostgreSQL por execução. Execute spm_migrate() várias vezes até migrar todos os objetos. Para mais detalhes, consulte spm_migrate.

Etapa 4: Crie um usuário

Ignore esta etapa se o usuário já existir na instância.

Contas Alibaba Cloud e usuários RAM

Use spm_create_user para criar um usuário. Opcionalmente, adicione-o a um grupo na mesma chamada:

-- Create a user only
CALL spm_create_user('<account-id-or-email-or-ram-user>');

-- Create a user and add to a group in one step
CALL spm_create_user('<account-id-or-email-or-ram-user>', '<dbname>_[admin|developer|writer|viewer]');

Substitua <dbname> pelo nome do banco de dados de destino.

Exemplo: adicione o usuário RAM xxx.onaliyun.com ao grupo developer do banco testdb:

CALL spm_create_user('xxx.onaliyun.com', 'testdb_developer');

Usuários personalizados

CREATE USER "BASIC$<user_name>" WITH PASSWORD '<password>';

Para usuários RAM, adicione o prefixo p4_ ao UID da conta ao chamar spm_create_user . Por exemplo: p4_564306222995xxx .

Nomes de usuários personalizados não podem terminar com admin , developer , writer , viewer ou all_users .

Etapa 5: Adicione o usuário a um grupo de usuários

Se você já adicionou o usuário a um grupo durante a criação, ignore esta etapa.

Execute spm_grant para adicionar um usuário a um grupo. Depois disso, o usuário poderá se conectar ao banco de dados com uma ferramenta de desenvolvimento e operar dentro do escopo permitido pelo grupo.

CALL spm_grant('<dbname>_[admin|developer|writer|viewer]', '<account-id-or-email-or-ram-user>');

Para detalhes sobre esta função, consulte spm_grant. Para informações sobre grupos de usuários, veja Grupos de usuários.

Exemplos

Todos os exemplos abaixo usam mydb como nome do banco de dados. Substitua-o pelo nome real do seu banco.

-- Add a RAM user to the admin group
CALL spm_grant('mydb_admin', 'p4_564306222995xxx');

-- Add an Alibaba Cloud account to the admin group
CALL spm_grant('mydb_admin', '197006222995xxx');

-- Add an Alibaba Cloud account (email format) to the admin group
CALL spm_grant('mydb_admin', 'ALIYUN$xxx');

-- Add a RAM user to the developer group
CALL spm_grant('mydb_developer', 'p4_564306222995xxx');

-- Add an Alibaba Cloud account to the developer group
CALL spm_grant('mydb_developer', '197006222995xxx');

-- Add a RAM sub-user to the developer group
CALL spm_grant('mydb_developer', 'RAM$mainaccount:subuser');

-- Add a RAM user to the viewer group of a case-sensitive database name "MYDB"
CALL spm_grant('"MYDB_viewer"', 'p4_564306222995xxx');

-- Add an Alibaba Cloud account to the viewer group of a case-sensitive database name "MYDB"
CALL spm_grant('"MYDB_viewer"', '197006222995xxx');

-- Add an account (email format) to the viewer group
CALL spm_grant('mydb_viewer', '"xxx@aliyun.com"');

CALL spm_revoke('<dbname>_[admin|developer|writer|viewer]', '<account-id-or-email-or-ram-user>');

-- Remove a RAM user from the admin group
CALL spm_revoke('dbname_admin', 'p4_564306222995xxx');

-- Remove an Alibaba Cloud account from the admin group
CALL spm_revoke('dbname_admin', '197006222995xxx');

-- Remove an account (email format) from the admin group
CALL spm_revoke('dbname_admin', 'xxx@aliyun.com');

-- Remove a RAM sub-user from the developer group
CALL spm_revoke('mydb_developer', 'RAM$mainaccount:subuser');

-- Remove a RAM user from the developer group
CALL spm_revoke('mydb_developer', 'p4_564306222995xxx');

-- Remove a RAM user from the viewer group of a case-sensitive database name "MYDB"
CALL spm_revoke('"MYDB_viewer"', 'p4_564306222995xxx');

DROP ROLE "<account-id-or-email-or-ram-user>";

Etapa 1: Desative o SPM

Execute o seguinte comando no banco de dados de destino:

CALL spm_disable();

Após a desativação, os quatro grupos de usuários (admin, developer, writer, viewer) não são excluídos automaticamente. Para detalhes sobre o que acontece com as permissões após a desativação, consulte Funções do SPM.

Etapa 2: Limpe os grupos de usuários (opcional)

Após desativar o SPM, limpe os grupos de usuários com spm_cleanup se necessário. Manter os grupos não causa problemas; deixe-os intactos caso planeje reativar o SPM posteriormente.

Cenário 1: Excluir grupos de usuários, mas manter o banco de dados

Execute o seguinte como Superuser no banco de dados de destino:

CALL spm_cleanup('<dbname>');

Como a limpeza executa ALTER ... OWNER TO nas tabelas de negócios, ela está sujeita ao limite max_locks_per_transaction por execução. Execute spm_cleanup várias vezes até migrar todos os objetos e excluir os quatro grupos de usuários. Para mais detalhes, consulte spm_cleanup.

Cenário 2: Banco de dados já excluído, mas grupos de usuários restantes

Se o banco de dados original foi excluído antes da limpeza dos grupos de usuários, execute o seguinte a partir de outro banco de dados (por exemplo, postgres) como Superuser:

CALL spm_cleanup('mydb');

Permissões após desativar o SPM

Após a desativação do SPM, aplicam-se as seguintes permissões:

Permissões da função pública

Permissões dos grupos de usuários

Todos os quatro grupos (admin, developer, writer, viewer) mantêm suas permissões nos objetos existentes. Essas permissões não se estendem a novos objetos de banco de dados criados após a desativação do SPM.

CALL spm_enable('t');   -- Re-enable SPM for the current database
CALL spm_migrate();     -- Transfer ownership of existing objects to the developer group