The clickhouse-rbac
puppet module allows management of ClickHouse resources such as users, grants,
quotas and settings profiles using SQL statements.
clickhouse_user { 'foo':
ensure => 'present',
password_hash => sha256('bar'),
host_ip => [ '::/0' ],
host_names => [],
host_like => [],
host_regexp => [],
profile => 'myprofile',
distributed => false,
}
See:
- https://clickhouse.tech/docs/en/sql-reference/statements/create/user/
- https://clickhouse.tech/docs/en/sql-reference/statements/alter/user/
Defines if the resource should be present or absent.
SHA256 password hash for the user.
ClickHouse supports other types of hashes, but this module only supports SHA256.
Array of allowed user host IPs. (default: ::/0
)
Array of allowed user host names.
Array of allowed user host LIKEs.
Array of allowed user host regular expressions.
Name of the settings profile to associate to the user.
Determine whether to use the ON CLUSTER
statement for queries. (default: true
)
clickhouse_grant { 'foo/mydb.mytable':
ensure => 'present',
user => 'foo',
table => 'mydb.mytable',
privileges => [
'INSERT',
'SELECT',
],
options => 'GRANT',
distributed => false,
This type is highly based on mysql_grant
, so it should work similarly.
The resource name must match <user>/<table>
parameters, otherwise it'll throw an error.
See:
Defines if the resource should be present or absent.
User to apply the grant on.
Table to apply the grant on. Must be in the format <dbname>.<table>
and wildcard for tables can also be used <dbname>.*
.
List of privileges to assign to the grant. Can be specified as Array
or String
.
Determine whether to use the ON CLUSTER
statement for queries. (default: true
)
clickhouse_profile { 'myprofile':
ensure => 'present',
settings => {
'readonly' => 1,
}
distributed => true,
}
See:
- https://clickhouse.tech/docs/en/operations/access-rights/#settings-profiles-management
- https://clickhouse.tech/docs/en/sql-reference/statements/create/settings-profile/
Defines if the resource should be present or absent
Hash containing settings for the profile.
Determine whether to use the ON CLUSTER
statement for queries. (default: true
)
clickhouse_quota { 'myquota':
ensure => 'present',
interval => 'second',
keys => 'user_name',
duration => 3600,
randomized => false,
queries => 0,
errors => 0,
read_rows => 0,
read_bytes => 0,
result_rows => 0,
result_bytes => 0,
execution_time => 0,
user => 'foo',
distributed => true,
}
See:
- https://clickhouse.tech/docs/en/operations/quotas/
- https://clickhouse.tech/docs/en/operations/system-tables/quotas/
Defines if the resource should be present or absent.
User(s) to apply the quota on.
Key specifies how the quota should be shared.
If two connections use the same quota and key, they share the same amounts of resources.
Valid values for this parameter are:
none
All users share the same quota. (default)user_name
Connections with the same user name share the same quota.ip_address
Connections from the same IP share the same quota.client_key
Connections with the same key share the same quota.[ user_name, client_key ]
Connections with the sameclient_key
share the same quota.
If a key isn’t provided by a client, the quota is tracked foruser_name
.[ client_key, ip_address ]
Connections with the sameclient_key
share the same quota.
If a key isn’t provided by a client, the quota is tracked forip_address
.
Type of interval. It can be one of: second
(default), minute
, hour
, day
, week
, month
, quarter
, year
.
Interval duration depending on the specified interval
. (default: 3600
)
Randomize the interval (default: false
)
Max amount of queries.
Max amount of queries that threw an exception.
Max amount of source rows read from tables for running the query on all remote servers.
Max amount of bytes read from tables for running the query on all remote servers.
Max amount of rows given as a result.
Max amount of bytes given as a result.
Max query execution time, in seconds (wall time).
Determine whether to use the ON CLUSTER
statement for queries. (default: true
)
The module provides some useful facts regarding the current ClickHouse node.
Name of the cluster as defined in metrika.xml
.
Current node's shard number.
Current node's replica number.
Current node's ClickHouse server version.
- The password hash for an user is read from the filesystem because, at the current time, there’s no way
to get it by executing SQL statements. There might be some corner cases in which this might not work:
eg. using an SSH tunnel to reach CH from another machine, executing puppet as an unprivileged user
which has no read access to CH
access
directory. - Support for SHA256 password hash only. Should be easy to implement a new hash type.
- There might be some issues when specifying loopback addresses for the
host_*
parameters due to ClickHouse converting internally those addresses to LOCAL. Similar issues might be seen when specifying overlapping addresses/subnets.
- Quotas are recreated on update instead of being ALTERed. This is due to ClickHouse creating multiple rows which are not easy to manage when updating an existent quota with a different interval duration. This has the drawback of assigning a new ID to the quota each time it's changed.
- A workaround is required for ClickHouse/ClickHouse#18231 or at least prevent execution
depending on the server version. This issue could be hit when removing a
SETTINGS PROFILE
which has already been assigned to an user.
Contributions are always welcome!
If you feel there's something that can be improved/implemented, then feel free to submit your changes as PRs.