Altinity.Cloud provides role based access control. Depending the role granted to an Altinity.Cloud Account, they can assign other Altinity.Cloud accounts roles and grant permissions to access organizations, environments, or clusters.
This is the multi-page printable view of this section. Click here to print.
Access Control
- 1: Role-Based Access and Security Tiers
- 2: Account Management
- 3: Integrating Okta into the Altinity.Cloud login page
- 4: Altinity Access to ClickHouse
1 - Role-Based Access and Security Tiers
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.
Security Tiers
Altinity.Cloud groups a set of clusters together in ways that allow companies to provide Accounts access only to the clusters or groups of clusters that they need.
Altinity.Cloud groups clusters into the following security-related tiers:
Hierarchy
- ClickHouse databases and tables live inside clusters.
- Clusters contain ClickHouse databases and manage access.
- Environments contain one or more clusters.
- Organization is the highest level that houses one or more environments.
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
Account Roles
The actions that can be taken by Altinity.Cloud accounts are based on the role they are assigned.
The following roles and their actions based on the security tier are detailed in Table 1.
Role Descriptions
- orgadmin manages the Organization, including all user accounts and Environment settings, and has full access to any cluster.
- envadmin is a member of an Organization and can edit assigned Environments and has full access to any cluster.
- envuser is a member of an Organization and has full access to specified clusters.
- envsupport is a member of an Organization and has read access to specified environments and 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.
Organization Example
The following example in Table 2 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 type of tier they are assigned to.
Account | Title | Role | Organization | Accounts | Billing | Environments | Clusters |
---|---|---|---|---|---|---|---|
mary | Administrator | orgadmin | HappyDragon | all | all | Access to all Env. | 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 |
Table 2 - Accounts and their roles and security tiers.
Account and Roles
Mary (Administrator, Role: orgadmin)
Mary is the orgadmin role, which has the highest level of access in this example.
- Has full access to the organization account
- Can create and manage access for other users
- Can create and manage new environments
- Can create and manage new clusters
Jessica (Operations, Role: envadmin)
- Has read access (but not write or delete access) to both Dev and Prod environments
- Has full access to read, write and delete clusters in both environments
Peter (Developer, Role: envadmin)
- Has read access (but not write or delete access) to the Dev environment
- Has full access to read, write and delete any cluster in the Dev environment
Paul (Marketing user, Role: envuser)
- Has read, write and delete access to the cluster marketing in the environment HappyDragon_Prod
2 - Account Management
Altinity.Cloud accounts with the role orgadmin are able to create new Altinity.Cloud accounts and associate them with organizations, environments, and one or more clusters depending on their role. For more information on roles, see Role Based Access and Security Tiers.
Account Page
The Account Page displays all accounts assigned to the same Organization and Environments as the logged in account.
For example: the accounts mario
, luigi
, and peach
and todd
are members of the organizations MushroomFactory
and BeanFactory
as follows:
Account | Role | Organization: MushroomFactory | Organization: BeanFactory |
---|---|---|---|
peach | orgadmin | * | |
mario | orgadmin | * | |
luigi | envuser | * | |
todd | envuser | * |
peach
will be able to see their account andtodd
in the Account Page, while accountsmario
andluigi
will be hidden from them.mario
will be able to see their account andluigi
.
Access Accounts
To access the accounts that are assigned to the same Organizations and Environments as the logged in user with the account role orgadmin:
- Login to Altinity.Cloud with an account granted the orgadmin role.
- From the left navigation panel, select Accounts.
- All accounts that are in the same Organizations and Environments as the logged in account will be displayed.
Account Details
Accounts have the following details that can be set by an account with the orgadmin role:
- Common Information:
- Name: The name of the account.
- Email (Required): The email address of the account. This will be used to login, reset passwords, notifications, and other uses. This must be a working email for these functions to work.
- Password: The password for the account. Once a user has authenticated to the account, they can change their password.
- Confirm Password: Confirm the password for the account.
- Role (Required): The role assigned to the account. For more information on roles, see Role Based Access and Security Tiers.
- Organization: The organization assigned to the account. Note that the
orgadmin
can only assign accounts the same organizations that theorgadmin
account also belongs to. - Suspended: When enabled, this prevents the account from logging into Altinity.Cloud.
- Environment Access:
- Select the environments that the account will require access to. Note that the
orgadmin
can only assign accounts the same environments that theorgadmin
account also belongs to.
- Select the environments that the account will require access to. Note that the
- Cluster Access:
- This is only visible if the Role is set to envuser. This allows one or more clusters in the environments the new account was assigned to in Environmental Access to be accessed by them.
- API Access:
- Allows the new account to make API calls from the listed domain names.
Account Actions
Create Account
orgadmin
accounts can create new accounts and assign them to the same organization and environments they are assigned to. For example, continuing the scenario from above, if account peach
is assigned to the organization MushroomFactory
and the environments MushroomProd
and MushroomDev
, they can assign new accounts to the organization MushroomFactory
, and to the environments MushroomProd
or MushroomDev
or both.
To create a new account:
-
Login to Altinity.Cloud with an account granted the orgadmin role.
-
From the left navigation panel, select Accounts.
-
Select Add Account.
-
Set the fields as listed in the Account Details section.
-
Once all settings are completed, select Save. The account will be able to login with the username and password, or if their email address is registered through Google, Auth0.
Edit Account
- Login to Altinity.Cloud with an account granted the orgadmin role.
- From the left navigation panel, select Accounts.
- From the left hand side of the Accounts table, select the menu icon for the account to update and select Edit.
- Update the fields as listed in the Account Details section.
- When finished, select Save.
Suspend Account
Instead of deleting an account, setting an account to Suspended may be more efficient to preserve the accounts name and other settings. A suspended account is unable to login to Altinity.Cloud. This includes directly logging through a browser and API calls made under the account.
To suspend or activate an account:
- Login to Altinity.Cloud with an account granted the orgadmin role.
- From the left navigation panel, select Accounts.
- From the left hand side of the Accounts table, select the menu icon for the account to update and select Edit.
- To suspend an account, toggle Suspended to on.
- To activate a suspended account, toggle Suspended to off.
- When finished, select Save.
Delete Account
Accounts can be deleted which removes all information on the account. Clusters and environments created by account will remain.
To delete an existing account:
- Login to Altinity.Cloud with an account granted the orgadmin role.
- From the left navigation panel, select Accounts.
- From the left hand side of the Accounts table, select the menu icon for the account to update and select Delete.
- Verify the account is to be deleted by selecting OK.
3 - Integrating Okta into the Altinity.Cloud login page
Overview - Okta Integration
Altinity uses Auth0 so that customers who are already logged into other identity providers such as Google or Okta are automatically granted access to Altinity.Cloud.
The following diagram shows the Altinity login process using Auth0, plus adding Okta as discussed on this page.
- Logging in to Altinity.Cloud using a Login Email and Password.
- The Auth0 login link to use a 3rd party authenticator such as Google or Okta. (See Okta/Auth0 Altinity Integration)
- Using Okta allows previously authorized logged-in employees to gain immediate access to Altinity.Cloud.
Figure 1 – Altinity integration of an Okta customer to Auth0.
Set-up Okta Integration
- Go to Okta Dashboard -> Applications -> Create App Integration
- Choose OIDC as Sign-in method and Web Application as Application type, then click Next
- Provide a name, and check all Grant type checkboxes
- Provide https://altinity.auth0.com/login/callback as Sign-in redirect URI
- Choose preferred option for Assignments
- Click Save and leave page open.
Provide Okta Client Details
Contact Altinity to add the Okta domain and Client ID to the Altinity.Cloud access list. Please provide the following:
- The domain you want to sign in on the Okta side, e.g. somemail.com. Note: it should match your organization domain in Altinity.Cloud.
- Okta Domain, e.g. somemail.okta.com
- Okta Client ID
Okta/Auth0 Altinity Integration
These steps are for Altinity technical support to add an Okta connection to Auth0.
Setting up the Auth0 connection
- Go to Auth0 Dashboard -> Authentication -> Enterprise.
- Click Create (plus icon) next to OpenID Connect.
- Provide a name.
- Copy the Okta domain provided by a customer to Issuer URL.
- Copy the Client ID provided by a customer to the Client ID.
- Click Create.
Enabling the connection
- Go to Auth0 Dashboard -> Applications.
- Click the application you wish to use with the connection.
- Go to the Connections tab, find your newly created connection, and switch it on.
Testing the connection
- Go to Auth0 Dashboard -> Authentication -> Enterprise.
- Click OpenID Connect (not the plus sign, the text).
- Find the newly created connection.
- Click the three dots on the right -> Try.
- You should be greeted with an Okta password prompt, or if there is a problem, an error is shown.
- You should be greeted with an Okta password prompt, or if there is a problem, an error is shown.
Enabling the button
- Go to Auth0 Dashboard -> Authentication -> Enterprise.
- Click OpenID Connect (not the plus sign, the text).
- Find the newly created connection and click its name.
- Go to the Login Experience tab.
- Check the Connection button -> Display connection as a button.
- Configure the Button display name and logo URL.
- Click Save.
Testing
- Go to the https://acm.altinity.cloud login page.
- Click Sign in with Auth0.
- A button for the new connection should be shown.
- Upon clicking the button, it should either ask for Okta credentials or log straight into the app.
Altinity blog post
The following Altinity blog post provides an in-depth discussion of adding Okta as an identity provider.
4 - Altinity Access to ClickHouse
Introduction
Altinity Access settings allow Altinity.Cloud users to limit the level of access Altinity personnel have to customer ClickHouse data or administrative operations. Altinity.Cloud provides two types of limits:
- Data Access - Control the ability of Altinity personnel to view or change data in ClickHouse tables.
- Management Access - Control ability to change cluster configuration or perform administrative actions.
If you restrict access to data or management functions you may choose to lift them from time to time to allow Altinity support to diagnose problems or perform operations on your behalf. You can apply the restrictions again afterward.
Viewing and Changing Altinity Access Settings
Access the Cluster Dashboard view of any cluster. You will see the ALTINITY ACCESS button on the upper right-hand side of the dashboard view.
Button Colors
The color indicates the Altinity access level to ClickHouse data.
- Clear (shown) - Altinity personnel have no access to ClickHouse data.
- Green - Altinity personnel have read-only access to system tables.
- Orange - Altinity personnel have read-only access to all tables.
- Red - Altinity personnel have read/write access to all tables.
Access Level Settings
Press the ALTINITY ACCESS button to manage access settings.
You may change settings and press CONFIRM to apply or CANCEL to quit. Changing settings requires an account with EnvUser role or higher.
You may choose any data access level that you please. The following table shows the level of access for each.
Level | Meaning |
---|---|
No Access | Altinity personnel may not use the ACM Query Browser or Schema Browser. They cannot look at data or schema. |
System (Default) | Altinity personnel use the ACM Query browser to query system tables and may look at table definitions in the Schema Browser. This setting provides a good balance between protecting data and providing access required for quick support from Altinity. |
Read Only | In addition to the above, Altinity personnel may use the ACM Query Browser to run SELECT statements that read data from any table. |
Full Access | In addition to the above, Altinity personnel use the ACM Query Browser to run SQL statements that alter data. |
Management Access Settings
You may similarly enable or disable management access. The following sections describe the affected access levels.
Enable Cluster Configuration Management
Checking this box allows Altinity personnel to perform any of the following operations related to configuration.
- Changing cluster configuration settings.
- Changing users or profiles.
- Setting connection configuration.
- Altering backup settings.
- Setting uptime schedules.
- Setting alerts.
The above actions can cause your server to restart, alter user passwords, or change the information that you receive from Altinity.Cloud about your clusters. If the box is unchecked only you can make these changes.
Enable Cluster Actions
Checking this box allows Altinity staff to perform any of the following operations related to cluster administration.
- Creating new clusters.
- Rescaling clusters.
- Upgrading clusters.
- Restarting clusters.
The above actions may cause your server to restart, behave differently for applications, or affect operating costs. If the box is unchecked only you can make these changes.