Skip to content
Merged
Show file tree
Hide file tree
Changes from 12 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 36 additions & 21 deletions docs/_snippets/_users-and-roles-common.md
Original file line number Diff line number Diff line change
Expand Up @@ -120,49 +120,51 @@ With this set of examples:

Roles are used to define groups of users for certain privileges instead of managing each user separately.

1. Create a role to restrict users of this role to only see `column1` in database `db1` and `table1`:
<VerticalStepper headerLevel="h5">

##### Create a role to restrict users of this role to only see `column1` in database `db1` and `table1`: {#create-column-role}

```sql
CREATE ROLE column1_users;
```

2. Set privileges to allow view on `column1`
##### Set privileges to allow view on `column1` {#set-column-privileges}

```sql
GRANT SELECT(id, column1) ON db1.table1 TO column1_users;
```

3. Add the `column_user` user to the `column1_users` role
##### Add the `column_user` user to the `column1_users` role {#add-column-user-to-role}

```sql
GRANT column1_users TO column_user;
```

4. Create a role to restrict users of this role to only see selected rows, in this case, only rows containing `A` in `column1`
##### Create a role to restrict users of this role to only see selected rows, in this case, only rows containing `A` in `column1` {#create-row-role}

```sql
CREATE ROLE A_rows_users;
```

5. Add the `row_user` to the `A_rows_users` role
##### Add the `row_user` to the `A_rows_users` role {#add-row-user-to-role}

```sql
GRANT A_rows_users TO row_user;
```

6. Create a policy to allow view on only where `column1` has the values of `A`
##### Create a policy to allow view on only where `column1` has the values of `A` {#create-row-policy}

```sql
CREATE ROW POLICY A_row_filter ON db1.table1 FOR SELECT USING column1 = 'A' TO A_rows_users;
```

7. Set privileges to the database and table
##### Set privileges to the database and table {#set-db-table-privileges}

```sql
GRANT SELECT(id, column1, column2) ON db1.table1 TO A_rows_users;
```

8. grant explicit permissions for other roles to still have access to all rows
##### Grant explicit permissions for other roles to still have access to all rows {#grant-other-roles-access}

```sql
CREATE ROW POLICY allow_other_users_filter
Expand All @@ -173,17 +175,21 @@ Roles are used to define groups of users for certain privileges instead of manag
When attaching a policy to a table, the system will apply that policy, and only those users and roles defined will be able to do operations on the table, all others will be denied any operations. In order to not have the restrictive row policy applied to other users, another policy must be defined to allow other users and roles to have regular or other types of access.
:::

</VerticalStepper>

## Verification {#verification}

### Testing role privileges with column restricted user {#testing-role-privileges-with-column-restricted-user}

1. Log into the clickhouse client using the `clickhouse_admin` user
<VerticalStepper headerLevel="h5">

##### Log into the clickhouse client using the `clickhouse_admin` user {#login-admin-user}

```bash
clickhouse-client --user clickhouse_admin --password password
```

2. Verify access to database, table and all rows with the admin user.
##### Verify access to database, table and all rows with the admin user. {#verify-admin-access}

```sql
SELECT *
Expand All @@ -201,13 +207,13 @@ Roles are used to define groups of users for certain privileges instead of manag
└────┴─────────┴─────────┘
```

3. Log into the ClickHouse client using the `column_user` user
##### Log into the ClickHouse client using the `column_user` user {#login-column-user}

```bash
clickhouse-client --user column_user --password password
```

4. Test `SELECT` using all columns
##### Test `SELECT` using all columns {#test-select-all-columns}

```sql
SELECT *
Expand All @@ -230,7 +236,7 @@ Roles are used to define groups of users for certain privileges instead of manag
Access is denied since all columns were specified and the user only has access to `id` and `column1`
:::

5. Verify `SELECT` query with only columns specified and allowed:
##### Verify `SELECT` query with only columns specified and allowed: {#verify-allowed-columns}

```sql
SELECT
Expand All @@ -250,15 +256,19 @@ Roles are used to define groups of users for certain privileges instead of manag
└────┴─────────┘
```

</VerticalStepper>

### Testing role privileges with row restricted user {#testing-role-privileges-with-row-restricted-user}

1. Log into the ClickHouse client using `row_user`
<VerticalStepper headerLevel="h5">

##### Log into the ClickHouse client using `row_user` {#login-row-user}

```bash
clickhouse-client --user row_user --password password
```

2. View rows available
##### View rows available {#view-available-rows}

```sql
SELECT *
Expand All @@ -278,37 +288,41 @@ Roles are used to define groups of users for certain privileges instead of manag
Verify that only the above two rows are returned, rows with the value `B` in `column1` should be excluded.
:::

</VerticalStepper>

## Modifying users and roles {#modifying-users-and-roles}

Users can be assigned multiple roles for a combination of privileges needed. When using multiple roles, the system will combine the roles to determine privileges, the net effect will be that the role permissions will be cumulative.

For example, if one `role1` allows for only select on `column1` and `role2` allows for select on `column1` and `column2` then the user will have access to both columns.

1. Using the admin account, create new user to restrict by both row and column with default roles
<VerticalStepper headerLevel="h5">

##### Using the admin account, create new user to restrict by both row and column with default roles {#create-restricted-user}

```sql
CREATE USER row_and_column_user IDENTIFIED BY 'password' DEFAULT ROLE A_rows_users;
```

2. Remove prior privileges for `A_rows_users` role
##### Remove prior privileges for `A_rows_users` role {#remove-prior-privileges}

```sql
REVOKE SELECT(id, column1, column2) ON db1.table1 FROM A_rows_users;
```

3. Allow `A_row_users` role to only select from `column1`
##### Allow `A_row_users` role to only select from `column1` {#allow-column1-select}

```sql
GRANT SELECT(id, column1) ON db1.table1 TO A_rows_users;
```

4. Log into the ClickHouse client using `row_and_column_user`
##### Log into the ClickHouse client using `row_and_column_user` {#login-restricted-user}

```bash
clickhouse-client --user row_and_column_user --password password;
```

5. Test with all columns:
##### Test with all columns: {#test-all-columns-restricted}

```sql
SELECT *
Expand All @@ -327,7 +341,7 @@ For example, if one `role1` allows for only select on `column1` and `role2` allo
SELECT(id, column1, column2) ON db1.table1. (ACCESS_DENIED)
```

6. Test with limited allowed columns:
##### Test with limited allowed columns: {#test-limited-columns}

```sql
SELECT
Expand All @@ -344,6 +358,7 @@ For example, if one `role1` allows for only select on `column1` and `role2` allo
│ 2 │ A │
└────┴─────────┘
```
</VerticalStepper>

## Troubleshooting {#troubleshooting}

Expand Down
19 changes: 11 additions & 8 deletions docs/cloud/_snippets/_security_table_of_contents.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,11 @@
| Page | Description |
|---------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------|
| [Shared Responsibility Model](/cloud/security/shared-responsibility-model) | Understand how security responsibilities are divided between ClickHouse Cloud and your organization for different service types. |
| [Cloud Access Management](/cloud/security/cloud-access-management) | Manage user access with authentication, single sign-on (SSO), role-based permissions, and team invitations. |
| [Connectivity](/cloud/security/connectivity) | Configure secure network access including IP allow-lists, private networking, S3 data access, and Cloud IP address management. |
| [Enhanced Encryption](/cloud/security/cmek) | Learn about default AES 256 encryption and how to enable Transparent Data Encryption (TDE) for additional data protection at rest. |
| [Audit Logging](/cloud/security/audit-logging) | Set up and use audit logging to track and monitor activities in your ClickHouse Cloud environment. |
| [Privacy and Compliance](/cloud/security/privacy-compliance-overview) | Review security certifications, compliance standards, and learn how to manage your personal information and data rights. |
| Page | Description |
|------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [ClickHouse Cloud Security Features](/cloud/security) | Details the security options and best practices available for ClickHouse organization and service protection. |
| [Cloud access management guides](/cloud/security/cloud_access_management) | This section contains step-by-step guides for managing access in ClickHouse Cloud. |
| [Setting IP filters](/cloud/security/setting-ip-filters) | A guide on how to create or modify an IP access list. |
| [Private networking](/cloud/security/connectivity/private-networking) | ClickHouse Cloud provides the ability to connect your services to your cloud virtual network. Refer to these guides for set up steps for your provider |
| [Data masking](/cloud/guides/data-masking) | Learn how you can mask data in ClickHouse. |
| [Data encryption](/cloud/security/cmek) | Learn how to enable Transparent Data Encryption as well as Customer Managed Encryption Keys. |
| [Audit logging](/cloud/security/audit_logging) | Guides on how to access and review audited events in the ClickHouse Cloud console, as well as sample logs and queries customers can use in developing their BYOC security program |
| [HIPAA onboarding](/cloud/security/compliance/hipaa-onboarding) | This page describes the process for enabling deployment of HIPAA compliant services in ClickHouse Cloud. |
| [PCI onboarding](/cloud/security/compliance/pci-onboarding) | This page describes the process for enabling deployment of PCI compliant services in ClickHouse Cloud. |
2 changes: 1 addition & 1 deletion docs/cloud/features/01_cloud_tiers.md
Original file line number Diff line number Diff line change
Expand Up @@ -173,7 +173,7 @@ You can upgrade to the Scale or Enterprise tier to scale their services.
Designed for workloads requiring enhanced SLAs (2+ replica deployments), scalability, and advanced security.

- Offers support for features such as:
- [Private networking support](/cloud/security/private-link-overview).
- [Private networking support](/cloud/security/connectivity/private-networking).
- [Compute-compute separation](../reference/warehouses#what-is-compute-compute-separation).
- [Flexible scaling](/manage/scaling) options (scale up/down, in/out).
- [Configurable backups](/cloud/manage/backups/configurable-backups)
Expand Down
39 changes: 39 additions & 0 deletions docs/cloud/features/04_infrastructure/deployment-options.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
title: 'Deployment Options'
slug: /infrastructure/deployment-options
description: 'Deployment options available for ClickHouse customers'
keywords: ['bring yor own cloud', 'byoc', 'private', 'government', 'self-deployed']
doc_type: 'reference'
---

# ClickHouse Deployment Options

ClickHouse provides a range of deployment options to cater to diverse customer requirements, offering varying degrees of control, compliance, and operational overhead.
This document outlines the distinct deployment types available, enabling users to select the optimal solution that aligns with their specific architectural preferences, regulatory obligations, and resource management strategies.

## ClickHouse Cloud {#clickhouse-cloud}

ClickHouse Cloud is a fully managed, cloud-native service that delivers the power and speed of ClickHouse without the operational complexities of self-management.
This option is ideal for users who prioritize rapid deployment, scalability, and minimal administrative overhead.
ClickHouse Cloud handles all aspects of infrastructure provisioning, scaling, maintenance, and updates, allowing users to focus entirely on data analysis and application development.
It offers consumption-based pricing, and automatic scaling, ensuring reliable and cost-effective performance for analytical workloads. It is available across AWS, GCP and Azure, with direct marketplace billing options.

Learn more about [ClickHouse Cloud](/getting-started/quick-start/cloud).

## Bring Your Own Cloud {#byoc}

ClickHouse Bring Your Own Cloud (BYOC) allows organizations to deploy and manage ClickHouse within their own cloud environment while leveraging a managed service layer. This option bridges the gap between the fully managed experience of ClickHouse Cloud and the complete control of self-managed deployments. With ClickHouse BYOC, users retain control over their data, infrastructure, and security policies, meeting specific compliance and regulatory requirements, while offloading operational tasks like patching, monitoring, and scaling to the ClickHouse. This model offers the flexibility of a private cloud deployment with the benefits of a managed service, making it suitable for large-scale deployments at enterprises with stringent security, governance, and data residency needs.

Learn more about [Bring Your Own Cloud](/cloud/reference/byoc).

## ClickHouse Private {#clickhouse-private}

ClickHouse Private is a self-deployed version of ClickHouse, leveraging the same proprietary technology that powers ClickHouse Cloud. This option delivers the highest degree of control, making it ideal for organizations with stringent compliance, networking, and security requirements, as well as for teams that possess the operational expertise to manage their own infrastructure. It benefits from regular updates and upgrades that are thoroughly tested in the ClickHouse Cloud environment, a feature-rich roadmap, and is backed by our expert support team.

Learn more about [ClickHouse Private](/cloud/infrastructure/clickhouse-private).

## ClickHouse Government {#clickhouse-government}

ClickHouse Government is a self-deployed version of ClickHouse designed to meet the unique and rigorous demands of government agencies and public sector organizations that need isolated and accredited environments. This deployment option provides a highly secure, compliant, and isolated environment, focusing on FIPS 140-3 compliance utilizing OpenSSL, additional system hardening, and vulnerability management. It leverages the robust capabilities of ClickHouse Cloud while integrating specialized features and configurations to address the specific operational and security requirements of governmental entities. With ClickHouse Government, agencies can achieve high-performance analytics on sensitive data within a controlled and accredited infrastructure, backed by expert support tailored to public sector needs.

Learn more about [ClickHouse Government](/cloud/infrastructure/clickhouse-government).
2 changes: 1 addition & 1 deletion docs/cloud/features/05_admin_features/api/openapi.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ This document covers the ClickHouse Cloud API. For database API endpoints, pleas
3. To create an API key, specify the key name, permissions for the key, and expiration time, then click `Generate API Key`.
<br/>
:::note
Permissions align with ClickHouse Cloud [predefined roles](/cloud/security/cloud-access-management/overview#console-users-and-roles). The developer role has read-only permissions for assigned services and the admin role has full read and write permissions.
Permissions align with ClickHouse Cloud [predefined roles](/cloud/security/console-roles). The developer role has read-only permissions for assigned services and the admin role has full read and write permissions.
:::

<Image img={image_03} size="md" alt="Create API key form" border/>
Expand Down
Loading
Loading