Hologres:Usando o modelo de permissão no nível de schema

Pré-requisitos

Antes de começar, certifique-se de ter:

• Acesso de superusuário à instância do Hologres

• Uma ferramenta de desenvolvimento conectada à instância (por exemplo, HoloWeb ou psql)

Ative o SLPM para um banco de dados

1. Instale a extensão SLPM. Execute esta etapa uma única vez por banco de dados.

   create extension slpm;

2. Ative o SLPM. Certifique-se de que nenhuma instrução SQL esteja em execução no banco de dados ao rodar este comando.

   call slpm_enable ();

3. (Opcional) Migre do modelo de permissão padrão do PostgreSQL. Se o banco de dados já possuir tabelas, views ou tabelas externas gerenciadas sob o modelo padrão do PostgreSQL, migre a propriedade dos objetos existentes para o SLPM com o seguinte comando.

   Para verificar qual modelo de permissão está ativo antes de migrar:

   1. Faça login no console do Hologres. No painel de navegação à esquerda, clique em Go to HoloWeb.

   2. Clique em Security Center. Na página DB Authorization, verifique o modelo de permissão atual.

   A função slpm_migrate processa até 64 usuários por execução (ajustável). Se o banco de dados tiver mais usuários, execute a função várias vezes até que todas as permissões sejam migradas. Para detalhes sobre os parâmetros, consulte slpm_migrate .

   -- Transfer ownership of existing objects to the developer group for SLPM management.
   call slpm_migrate ();

Etapa 1: Crie o usuário

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

-- Create a user.
call slpm_create_user('<ACCOUNT>');

-- Create a user and add them to a group in one step.
call slpm_create_user('<ACCOUNT>', '{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]');

Substitua <ACCOUNT> por um dos seguintes formatos:

Para usar o UID de usuário RAM, adicione o prefixo p4_ . Obtenha o UID na página Usuários do console RAM. Para mais informações sobre formatos de conta, consulte Account system .

Etapa 2: Adicione o usuário a um grupo

call slpm_grant('{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]', '<ACCOUNT>');

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

Exemplos:

O exemplo a seguir adiciona uma conta Alibaba Cloud ao grupo admin de mydb.

call slpm_grant('mydb.admin', '197006222995xxx');
call slpm_grant('mydb.admin', 'ALIYUN$xxx');

Este exemplo adiciona usuários ao grupo developer do schema public em mydb.

call slpm_grant('mydb.public.developer', '197006222995xxx');
call slpm_grant('mydb.public.developer', 'RAM$mainaccount:subuser');

O exemplo abaixo adiciona um usuário ao grupo viewer do schema lisa em MYDB (nome de banco de dados sensível a maiúsculas e minúsculas).

call slpm_grant('"MYDB.lisa.viewer"', '197006222995xxx');
call slpm_grant('mydb.lisa.viewer', '"xxx@aliyun.com"');

call slpm_revoke('{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]', '<ACCOUNT>');

call slpm_revoke('dbname.admin', 'p4_564306222995xxx');
call slpm_revoke('dbname.admin', '197006222995xxx');
call slpm_revoke('dbname.admin', '"xxx@aliyun.com"');

call slpm_revoke('mydb.lisa.developer', 'RAM$mainaccount:subuser');
call slpm_revoke('mydb.public.developer', 'p4_564306222995xxx');

call slpm_revoke('"MYDB.SCHEMA1.viewer"', 'p4_564306222995xxx');

DROP ROLE "<ACCOUNT>";

Etapa 1: Desative o modelo

Somente um superusuário pode desativar o SLPM.

call slpm_disable ();

Após a desativação:

• Os quatro grupos de usuários ({db}.admin, {db}.{schemaname}.developer, {db}.{schemaname}.writer, {db}.{schemaname}.viewer) mantêm suas permissões nos objetos existentes. As permissões não se estendem a novos objetos.

• O PUBLIC recebe as seguintes concessões: USAGE e CREATE no schema public; CONNECT e TEMPORARY no banco de dados; EXECUTE em funções e procedimentos; USAGE em linguagens e tipos de dados (incluindo domínios).

• O PUBLIC não recebe permissões em tabelas, views, views materializadas, colunas de tabelas, sequências, wrappers de dados externos, servidores externos ou schemas não públicos. Entre em contato com um superusuário para conceder essas permissões individualmente.

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

Os grupos de usuários não são excluídos automaticamente quando o SLPM é desativado. Para removê-los, chame slpm_cleanup.

Certifique-se de que nenhuma instrução SQL esteja em execução no banco de dados antes de chamar slpm_cleanup . A função slpm_cleanup transfere a propriedade dos objetos em lotes de 64 (ajustável). Execute-a várias vezes se necessário, mas evite mais de cinco execuções. Para detalhes, consulte slpm_cleanup .

Cenário 1: Exclua os grupos de usuários, mas mantenha o banco de dados.

Execute o seguinte comando no banco de dados alvo como superusuário.

call slpm_cleanup('<DBNAME>');

Cenário 2: Exclua os grupos de usuários após a exclusão do banco de dados.

Execute o seguinte comando em outro banco de dados (como postgres) como superusuário.

call slpm_cleanup('mydb');

Quando usar este recurso

Um padrão comum em data warehouse é organizar os dados em schemas em camadas — por exemplo, operation data store (ODS), DWD, data warehouse service (DWS) e ADS — e depois criar views de resumo em uma camada externa que unem tabelas de várias camadas internas.

Considere o seguinte exemplo, onde uma view no schema ads une tabelas de ods e dwd:

DDL da view:

CREATE VIEW ads.customer_total_order_price_view AS
SELECT
    c_name,
    sum(o_totalprice)
FROM
    ods.orders AS o
INNER JOIN dwd.customer AS c
ON o.o_custkey = c.c_custkey
GROUP BY
    1;

Requisitos de permissão

No exemplo acima, para criar ads.customer_total_order_price_view como ads_dev_user:

• Conceda a ads_dev_user a permissão developer em ads.

• Conceda a ads_dev_user a permissão viewer em ods e dwd.

Para permitir que ads_view_user consulte a view, conceda a ads_view_user a permissão viewer em ads.

Após alternar do modelo de permissão simples (SPM) para o SLPM, as views entre schemas existentes tornam-se inacessíveis e as consultas falham com o erro permission denied for table. Execute o seguinte comando como superusuário para ativar o recurso de view entre schemas e, em seguida, recrie as views entre schemas existentes:

call slpm_enable_multi_schema_view();

-- Re-create the cross-schema view
CREATE OR REPLACE VIEW schema_b.cross_schema_view AS
SELECT a.id, a.name, b.value
FROM schema_a.table_a a
JOIN schema_b.table_b b ON a.id = b.id;

Ativar o recurso isoladamente, sem recriar as views, não resolve o erro de permissão.

Ative o recurso de view entre schemas

Execute o seguinte comando como superusuário.

call slpm_enable_multi_schema_view();

Transfira a propriedade da view

Depois que o recurso é ativado, o usuário que cria uma view torna-se seu proprietário. Somente o proprietário pode modificá-la ou excluí-la. Para transferir a propriedade — por exemplo, antes de remover um usuário do banco de dados — execute o seguinte comando. O novo proprietário deve ter permissão developer no schema da view e viewer ou superior em todos os schemas de source.

-- Syntax
call slpm_alter_view_owner('<VIEW_NAME>', '<ACCOUNT>');

-- Example: transfer ownership of ads.customer_total_order_price_view to p4_xxxxx.
call slpm_alter_view_owner('ads.customer_total_order_price_view', 'p4_xxxxx');

Desative o recurso de view entre schemas

-- Disable cross-schema view support.
call slpm_disable_multi_schema_view();
-- Transfer all view ownership back to the developer group of each view's schema.
call slpm_migrate();

Após executar esses comandos, as views existentes que não são entre schemas permanecem consultáveis e o SLPM comporta-se normalmente. As views entre schemas não poderão mais ser consultadas.