Controle de acesso e gerenciamento de contas

O ClickHouse oferece suporte ao gerenciamento de controle de acesso com base no modelo RBAC.

Entidades de acesso do ClickHouse:

• Conta de usuário
• Função
• Política de linha
• Perfil de configurações
• Cota

Você pode configurar as entidades de acesso usando:

• Fluxo de trabalho baseado em SQL.

  É preciso habilitar essa funcionalidade.

• Arquivos de configuração do servidor arquivos de configuração users.xml e config.xml.

Recomendamos usar o fluxo de trabalho baseado em SQL. Os dois métodos de configuração funcionam simultaneamente, portanto, se você usar os arquivos de configuração do servidor para gerenciar contas e permissões de acesso, poderá migrar facilmente para o fluxo de trabalho baseado em SQL.

Para ver todos os usuários, funções, perfis etc. e todas as permissões concedidas, use a instrução SHOW ACCESS.

Por padrão, o servidor ClickHouse fornece a conta de usuário default, que não pode usar o controle de acesso e gerenciamento de contas via SQL, mas tem todos os direitos e permissões. A conta de usuário default é usada sempre que o nome de usuário não é definido, por exemplo, ao fazer login pelo cliente ou em consultas distribuídas. No processamento de consultas distribuídas, a conta de usuário padrão é usada se a configuração do servidor ou do cluster não especificar as propriedades de usuário e senha.

Se você começou a usar o ClickHouse agora, considere o seguinte cenário:

1. Ative o controle de acesso e gerenciamento de contas via SQL para o usuário default.
2. Faça login na conta de usuário default e crie todos os usuários necessários. Não se esqueça de criar uma conta de administrador (GRANT ALL ON *.* TO admin_user_account WITH GRANT OPTION).
3. Restrinja as permissões do usuário default e desative para ele o controle de acesso e gerenciamento de contas via SQL.

• Você pode conceder permissões para bancos de dados e tabelas mesmo que eles não existam.
• Se uma tabela for excluída, os privilégios correspondentes a ela não são revogados. Isso significa que, mesmo que você crie uma nova tabela com o mesmo nome mais tarde, todos os privilégios continuarão válidos. Para revogar os privilégios correspondentes à tabela excluída, você precisa executar, por exemplo, a consulta REVOKE ALL PRIVILEGES ON db.table FROM ALL.
• Não há configurações de validade para privilégios.

Uma conta de usuário é uma entidade de acesso que permite autorizar alguém no ClickHouse. Uma conta de usuário contém:

• Informações de identificação.
• Privilégios que definem o escopo das consultas que o usuário pode executar.
• Hosts autorizados a se conectar ao servidor ClickHouse.
• Funções atribuídas e funções padrão.
• Configurações com suas restrições aplicadas por padrão no login do usuário.
• Perfis de configurações atribuídos.

Os privilégios podem ser concedidos a uma conta de usuário pela consulta GRANT ou pela atribuição de funções. Para revogar privilégios de um usuário, o ClickHouse fornece a consulta REVOKE. Para listar os privilégios de um usuário, use a instrução SHOW GRANTS.

Consultas de gerenciamento:

• CREATE USER
• ALTER USER
• DROP USER
• SHOW CREATE USER
• SHOW USERS

As configurações podem ser definidas de diferentes maneiras: para uma conta de usuário, nas funções concedidas a ela e em perfis de configurações. No login do usuário, se uma configuração estiver definida para diferentes entidades de acesso, o valor e as restrições dessa configuração serão aplicados da seguinte forma (da maior para a menor prioridade):

1. Configurações da conta de usuário.
2. As configurações das funções padrão da conta de usuário. Se uma configuração estiver definida em algumas funções, a ordem de aplicação dessa configuração será indefinida.
3. As configurações de perfis de configurações atribuídos a um usuário ou às funções padrão dele. Se uma configuração estiver definida em alguns perfis, a ordem de aplicação dessa configuração será indefinida.
4. Configurações aplicadas a todo o servidor por padrão ou a partir do perfil padrão.

Uma função é um contêiner de entidades de acesso que podem ser atribuídas a uma conta de usuário.

Uma função contém:

• Privilégios
• Configurações e restrições
• Lista de funções atribuídas

Consultas de gerenciamento:

• CREATE ROLE
• ALTER ROLE
• DROP ROLE
• SET ROLE
• SET DEFAULT ROLE
• SHOW CREATE ROLE
• SHOW ROLES

Privilégios podem ser concedidos a uma função por meio da consulta GRANT. Para revogar privilégios de uma função, o ClickHouse fornece a consulta REVOKE.

Uma política de linha é um filtro que define quais linhas ficam disponíveis para um usuário ou uma função. Uma política de linha contém filtros para uma tabela específica, bem como uma lista de funções e/ou usuários aos quais essa política de linha deve ser aplicada.

Uma política de linha é aplicada quando os dados da tabela são lidos localmente. Para uma tabela Distributed ou outra tabela que delega a leitura a servidores remotos, defina a política nas tabelas subjacentes de cada servidor: uma política na própria tabela com dados remotos não pode ser aplicada à consulta enviada, e as leituras por meio dela são rejeitadas. Essa política em uma tabela subjacente não é aplicada quando o iniciador envia um plano de leitura já criado; portanto, mantenha serialize_query_plan = 0 para usuários cujas políticas de linha devem ser aplicadas (consulte a issue #112891).

Consultas de gerenciamento:

• CREATE ROW POLICY
• ALTER ROW POLICY
• DROP ROW POLICY
• SHOW CREATE ROW POLICY
• SHOW POLICIES

Um perfil de configurações é um conjunto de configurações. Um perfil de configurações contém configurações e restrições, bem como uma lista de funções e/ou usuários aos quais esse perfil se aplica.

Consultas de gerenciamento:

• CREATE SETTINGS PROFILE
• ALTER SETTINGS PROFILE
• DROP SETTINGS PROFILE
• SHOW CREATE SETTINGS PROFILE
• SHOW PROFILES

Uma cota limita o uso de recursos. Veja Cotas.

Uma cota contém um conjunto de limites para determinados períodos, bem como uma lista de funções e/ou usuários que devem usar essa cota.

Comandos de gerenciamento:

• CREATE QUOTA
• ALTER QUOTA
• DROP QUOTA
• SHOW CREATE QUOTA
• SHOW QUOTA
• SHOW QUOTAS

• Configure um diretório para armazenar as configurações.

  O ClickHouse armazena as configurações das entidades de acesso na pasta definida no parâmetro de configuração do servidor access_control_path.

• Habilite o controle de acesso e o gerenciamento de contas via SQL para pelo menos uma conta de usuário.

  Por padrão, o controle de acesso e o gerenciamento de contas via SQL estão desabilitados para todos os usuários. É necessário configurar pelo menos um usuário no arquivo de configuração users.xml e definir como 1 os valores das configurações access_management, named_collection_control, show_named_collections e show_named_collections_secrets.

Este artigo apresenta os conceitos básicos para definir usuários e funções SQL e aplicar esses privilégios e permissões a bancos de dados, tabelas, linhas e colunas.

1. Habilite o modo de usuário SQL no arquivo users.xml, na seção do usuário <default>:

   <access_management>1</access_management>
   <named_collection_control>1</named_collection_control>
   <show_named_collections>1</show_named_collections>
   <show_named_collections_secrets>1</show_named_collections_secrets>

2. Reinicie os nós para aplicar as alterações.

3. Inicie o cliente do ClickHouse:

   clickhouse-client --user default --password <password>

1. Crie uma conta de administrador SQL:

   CREATE USER clickhouse_admin IDENTIFIED BY 'password';

2. Conceda ao novo usuário permissões administrativas completas

   GRANT ALL ON *.* TO clickhouse_admin WITH GRANT OPTION;

Este artigo tem como objetivo proporcionar uma compreensão melhor de como definir permissões e de como elas funcionam ao usar instruções ALTER para usuários privilegiados.

As instruções ALTER são divididas em várias categorias, algumas das quais são hierárquicas, enquanto outras não são e devem ser definidas explicitamente.

Exemplo de configuração de DB, tabela e usuário

1. Com um usuário administrador, crie um usuário de exemplo

CREATE USER my_user IDENTIFIED BY 'password';

2. Criar um banco de dados de exemplo

CREATE DATABASE my_db;

3. Crie uma tabela de amostragem

CREATE TABLE my_db.my_table (id UInt64, column1 String) ENGINE = MergeTree() ORDER BY id;

4. Crie um usuário administrador de exemplo para conceder/revogar privilégios

CREATE USER my_alter_admin IDENTIFIED BY 'password';

Concessão ou Revogação de Privilégios

A hierarquia de ALTER:

├── ALTER (somente para tabela e view)/
│   ├── ALTER TABLE/
│   │   ├── ALTER UPDATE
│   │   ├── ALTER DELETE
│   │   ├── ALTER COLUMN/
│   │   │   ├── ALTER ADD COLUMN
│   │   │   ├── ALTER DROP COLUMN
│   │   │   ├── ALTER MODIFY COLUMN
│   │   │   ├── ALTER COMMENT COLUMN
│   │   │   ├── ALTER CLEAR COLUMN
│   │   │   └── ALTER RENAME COLUMN
│   │   ├── ALTER INDEX/
│   │   │   ├── ALTER ORDER BY
│   │   │   ├── ALTER SAMPLE BY
│   │   │   ├── ALTER ADD INDEX
│   │   │   ├── ALTER DROP INDEX
│   │   │   ├── ALTER MATERIALIZE INDEX
│   │   │   └── ALTER CLEAR INDEX
│   │   ├── ALTER CONSTRAINT/
│   │   │   ├── ALTER ADD CONSTRAINT
│   │   │   └── ALTER DROP CONSTRAINT
│   │   ├── ALTER TTL/
│   │   │   └── ALTER MATERIALIZE TTL
│   │   ├── ALTER SETTINGS
│   │   ├── ALTER MOVE PARTITION
│   │   ├── ALTER FETCH PARTITION
│   │   └── ALTER FREEZE PARTITION
│   └── ALTER LIVE VIEW/
│       ├── ALTER LIVE VIEW REFRESH
│       └── ALTER LIVE VIEW MODIFY QUERY
├── ALTER DATABASE
├── ALTER USER
├── ALTER ROLE
├── ALTER QUOTA
├── ALTER [ROW] POLICY
└── ALTER [SETTINGS] PROFILE

1. Concedendo privilégios ALTER a um usuário ou função

Usar GRANT ALTER on *.* TO my_user afetará apenas ALTER TABLE e ALTER VIEW no nível superior; outras instruções ALTER devem ser concedidas ou revogadas individualmente.

por exemplo, concedendo o privilégio básico ALTER:

GRANT ALTER ON my_db.my_table TO my_user;

Conjunto de privilégios resultante:

SHOW GRANTS FOR  my_user;

SHOW GRANTS FOR my_user

Query id: 706befbc-525e-4ec1-a1a2-ba2508cc09e3

┌─GRANTS FOR my_user───────────────────────────────────────────┐
│ GRANT ALTER TABLE, ALTER VIEW ON my_db.my_table TO my_user   │
└──────────────────────────────────────────────────────────────┘

Isso concede todas as permissões em ALTER TABLE e ALTER VIEW do exemplo acima; no entanto, não concede algumas outras permissões de ALTER, como ALTER ROW POLICY (volte à hierarquia e você verá que ALTER ROW POLICY não é subordinado a ALTER TABLE nem a ALTER VIEW). Essas permissões devem ser explicitamente concedidas ou revogadas.

Se apenas um subconjunto das permissões de ALTER for necessário, cada uma poderá ser concedida separadamente; se essa permissão tiver subprivilégios, eles também serão concedidos automaticamente.

Por exemplo:

GRANT ALTER COLUMN ON my_db.my_table TO my_user;

As permissões seriam configuradas da seguinte forma:

SHOW GRANTS FOR my_user;

SHOW GRANTS FOR my_user

Query id: 47b3d03f-46ac-4385-91ec-41119010e4e2

┌─GRANTS FOR my_user────────────────────────────────┐
│ GRANT ALTER COLUMN ON default.my_table TO my_user │
└───────────────────────────────────────────────────┘

1 row in set. Elapsed: 0.004 sec.

Isso também concede os seguintes subprivilégios:

ALTER ADD COLUMN
ALTER DROP COLUMN
ALTER MODIFY COLUMN
ALTER COMMENT COLUMN
ALTER CLEAR COLUMN
ALTER RENAME COLUMN

2. Revogar privilégios ALTER de Usuários e funções

O comando REVOKE funciona de maneira semelhante ao comando GRANT.

Se um usuário/role recebeu um subprivilégio, você pode revogar esse subprivilégio diretamente ou revogar o privilégio de nível superior do qual ele é herdado.

Por exemplo, se o usuário recebeu a permissão ALTER ADD COLUMN

GRANT ALTER ADD COLUMN ON my_db.my_table TO my_user;

GRANT ALTER ADD COLUMN ON my_db.my_table TO my_user

Query id: 61fe0fdc-1442-4cd6-b2f3-e8f2a853c739

Ok.

0 rows in set. Elapsed: 0.002 sec.

SHOW GRANTS FOR my_user;

SHOW GRANTS FOR my_user

Query id: 27791226-a18f-46c8-b2b4-a9e64baeb683

┌─GRANTS FOR my_user──────────────────────────────────┐
│ GRANT ALTER ADD COLUMN ON my_db.my_table TO my_user │
└─────────────────────────────────────────────────────┘

Um privilégio pode ser revogado individualmente:

REVOKE ALTER ADD COLUMN ON my_db.my_table FROM my_user;

Ou pode ser revogado de qualquer um dos níveis superiores (revoga todos os subprivilégios de COLUMN):

REVOKE ALTER COLUMN ON my_db.my_table FROM my_user;

REVOKE ALTER COLUMN ON my_db.my_table FROM my_user

Query id: b882ba1b-90fb-45b9-b10f-3cda251e2ccc

Ok.

0 rows in set. Elapsed: 0.002 sec.

SHOW GRANTS FOR my_user;

SHOW GRANTS FOR my_user

Query id: e7d341de-de65-490b-852c-fa8bb8991174

Ok.

0 rows in set. Elapsed: 0.003 sec.

Adicional

Os privilégios devem ser concedidos por um usuário que não apenas possua a opção WITH GRANT OPTION, mas que também possua os próprios privilégios.

1. Para conceder a um usuário Admin um privilégio e também permitir que ele administre um conjunto de privilégios Abaixo está um exemplo:

GRANT SELECT, ALTER COLUMN ON my_db.my_table TO my_alter_admin WITH GRANT OPTION;

Agora o usuário pode conceder ou revogar ALTER COLUMN e todos os subprivilégios.

Testes

1. Conceda o privilégio SELECT

GRANT SELECT ON my_db.my_table TO my_user;

2. Adicione ao usuário o privilégio de adicionar colunas

GRANT ADD COLUMN ON my_db.my_table TO my_user;

3. Faça login com o usuário restrito

clickhouse-client --user my_user --password password --port 9000 --host <your_clickhouse_host>

4. Teste adicionar uma coluna

ALTER TABLE my_db.my_table ADD COLUMN column2 String;

ALTER TABLE my_db.my_table
    ADD COLUMN `column2` String

Query id: d5d6bfa1-b80c-4d9f-8dcd-d13e7bd401a5

Ok.

0 rows in set. Elapsed: 0.010 sec.

DESCRIBE my_db.my_table;

DESCRIBE TABLE my_db.my_table

Query id: ab9cb2d0-5b1a-42e1-bc9c-c7ff351cb272

┌─name────┬─type───┬─default_type─┬─default_expression─┬─comment─┬─codec_expression─┬─ttl_expression─┐
│ id      │ UInt64 │              │                    │         │                  │                │
│ column1 │ String │              │                    │         │                  │                │
│ column2 │ String │              │                    │         │                  │                │
└─────────┴────────┴──────────────┴────────────────────┴─────────┴──────────────────┴────────────────┘

4. Teste a remoção de uma coluna

ALTER TABLE my_db.my_table DROP COLUMN column2;

ALTER TABLE my_db.my_table
    DROP COLUMN column2

Query id: 50ad5f6b-f64b-4c96-8f5f-ace87cea6c47

0 rows in set. Elapsed: 0.004 sec.

Received exception from server (version 22.5.1):
Code: 497. DB::Exception: Received from chnode1.marsnet.local:9440. DB::Exception: my_user: Not enough privileges. To execute this query it's necessary to have grant ALTER DROP COLUMN(column2) ON my_db.my_table. (ACCESS_DENIED)

5. Testando a permissão ALTER ADMIN ao concedê-la

GRANT SELECT, ALTER COLUMN ON my_db.my_table TO my_alter_admin WITH GRANT OPTION;

6. Faça login com o usuário administrador alter

clickhouse-client --user my_alter_admin --password password --port 9000 --host <my_clickhouse_host>

7. Conceda um subprivilégio

GRANT ALTER ADD COLUMN ON my_db.my_table TO my_user;

GRANT ALTER ADD COLUMN ON my_db.my_table TO my_user

Query id: 1c7622fa-9df1-4c54-9fc3-f984c716aeba

Ok.

8. Teste conceder um privilégio que o usuário admin alter não possui e que não seja um subprivilégio das grants do usuário admin.

GRANT ALTER UPDATE ON my_db.my_table TO my_user;

GRANT ALTER UPDATE ON my_db.my_table TO my_user

Query id: 191690dc-55a6-4625-8fee-abc3d14a5545

0 rows in set. Elapsed: 0.004 sec.

Received exception from server (version 22.5.1):
Code: 497. DB::Exception: Received from chnode1.marsnet.local:9440. DB::Exception: my_alter_admin: Not enough privileges. To execute this query it's necessary to have grant ALTER UPDATE ON my_db.my_table WITH GRANT OPTION. (ACCESS_DENIED)

Resumo Os privilégios de ALTER são hierárquicos para ALTER em tabelas e views, mas não para outras instruções ALTER. As permissões podem ser definidas em nível granular ou por agrupamento de permissões e também podem ser revogadas da mesma forma. O usuário que concede ou revoga deve ter WITH GRANT OPTION para definir privilégios para usuários, incluindo para si mesmo como usuário executor, e já deve possuir o privilégio. O usuário executor não pode revogar os próprios privilégios se não tiver o privilégio GRANT OPTION.