Role-Based Access and Security Tiers

Altinity.Cloud hierarchy and role-based access.

Introduction

Access to ClickHouse® data hosted in Altinity.Cloud is controlled through a combination of security tiers and account roles. This allows companies to tailor access to data in a way that maximizes security while still allowing ease of access.

Account Roles

The actions that can be taken by Altinity.Cloud accounts are based on the role they are assigned. Here are the roles and their permissions based on the security tier:

Figure 1 - An overview of roles and permissions

Role Descriptions

  • orgadmin manages the Organization, including all user accounts and Environment settings, and has full access to any Cluster. An orgadmin is the only role that can create or delete an Environment.
  • envadmin is a member of an Organization, can read and edit specified Environments, and has full access to any Cluster in those environments.
  • envuser is a member of an Organization, can read specified Environments, and has full access to specified Clusters.
  • envsupport is a member of an Organization and has read access to specified Environments as well as read and edit access to specified Clusters.
  • grafanauser is a member of an Organization and has read access to specified Environments.
  • billing can access the billing page only. From there they can view invoices and update payment details.

Managing roles

Altinity.Cloud accounts with the role orgadmin are able to create and modify roles through the Altinity Cloud Manager. Click the Accounts tab on the left to see the Accounts page:

Figure 2 - The accounts page

Clicking in the upper right takes you to the list of roles:

Figure 3 - The list of roles in this environment

NOTE: Roles with a icon cannot be modified.

You can click the button to add a new role, or you can click the icon next to a role in the list and select Edit from the menu to edit a role. Either way, you’ll see the Account Role Details dialog:

Figure 4 - The Account Role Details dialog

If you’re creating a new role, give it a name in the entry field at the top of the dialog; if you’re editing an existing role, the role name is read-only. (Again, if the role has the icon, everything is read-only.)

There are hundreds of settings, giving you fine-grained control over what each role is allowed to do. You can allow or deny all permissions in a category by selecting the * item, then define individual exceptions as needed. In Figure 4 above, the envsupport role has full permissions for cluster-related actions, with the exception of actionAltinityAccessCredentials, actionBackupCreate, and actionBackupRestore. In other words, this role cannot access credentials stored in the environment, create a backup, or restore from a backup.

When you’ve defined permissions the way you want, click SAVE to save the role.

Security Tiers

Altinity.Cloud groups a set of clusters together in ways that allow companies to give accounts access only to the clusters or groups of clusters that they need. Altinity.Cloud groups clusters into the following security tiers:

Security Tiers

Figure 5 - Security tier showing the relationship between an organization, environment, cluster, and ClickHouse database nodes.

Hierarchy

  • Organizations contain one or more environments.
  • Environments contain one or more clusters.
  • Clusters contain ClickHouse databases and manage access.
  • ClickHouse databases live inside clusters.

Security Tier

Account access is controlled by assigning an account a single role and a security tier depending on their role.
A single account can be assigned to:

  • A single Organization
  • One or multiple Environments
  • One or multiple Clusters within an Environment

Organization Example

The following example shows an Organization called HappyDragon that shows how Accounts and Role assignments are configured. Role names are also shown in Figure 1. The account roles are tied into the security tiers and allow an account to access multiple environments and clusters depending on what tier they are assigned to.

Account Title Role Organization Accounts Billing Environments Clusters
mary Administrator orgadmin HappyDragon all all Access to all Environments all
jessica Operations envadmin HappyDragon n/a n/a HappyDragon_Prod
HappyDragon_Dev		 all
peter Developer envadmin HappyDragon n/a n/a HappyDragon_Dev all
paul Marketing envuser HappyDragon marketing n/a HappyDragon_Prod marketing

Account and Roles

Mary (Administrator, Role: orgadmin)

Mary has the orgadmin role, which has the highest level of access in this example.

  • Has full access to the organization account
  • Can create and manage accounts for other users
  • Can create and manage new environments
  • Can create and manage new clusters

Jessica (Operations, Role: envadmin)

  • Has read and edit access (but not write or delete access) to both Dev and Prod environments
  • Has full access to create, read, write and delete clusters in both environments

Peter (Developer, Role: envadmin)

  • Has read and edit access (but not write or delete access) to the Dev environment only
  • Has full access to create, read, write and delete any cluster in the Dev environment only

Paul (Marketing user, Role: envuser)

  • Has create, read, edit and delete access to the cluster marketing in the environment HappyDragon_Prod