Learn about Firebolt organization and account concepts to help you administer and manage your Firebolt account.
A governance model can help manage cloud data warehouse resources by addressing challenges such as data security, cost management, resource isolation, and observability. For example, development, staging, and production environments often require isolation to prevent unintentional changes in development from affecting production or to restrict developers’ access to only their code and data. Similarly, departments may need isolated access to their resources while limiting access to others. Additionally, governance models can support consolidated billing while providing visibility into consumption by department or development environment.
To address these requirements, Firebolt supports concepts of organizations and accounts. You can have different accounts within your organization and additionally benefit from consolidated billing, unified authentication, and efficient account management across all accounts.
Topics
The Firebolt object model is hierarchical and comes with strong containment properties in that parent objects can contain one or more child objects. Child objects are sole children of their parent objects and cannot be shared. Furthermore, there are two classes of objects: global and regional. Global objects are managed globally and can contain objects that are deployed and grouped regionally.
The following Firebolt object model depicts an organization at the highest level, with four layers directly underneath it:
An organization is a fundamental object in Firebolt, providing a logical structure for managing accounts, billing, and authentication. When registering to Firebolt, the organization name you’ll provide is the same as the domain name you use in your email. Organization names are globally unique. No two organizations can have the same name, but organizations can contain multiple accounts. Each account can contain multiple objects including users, roles, databases, tables, views, and engines.
In the Firebolt object model, an organization has the following levels:
When you register for the first time, Firebolt sets up an organization for you. During registration, you’ll set up your first account, with one user. The first user that is added is the account administrator, as shown in the following diagram:
Then, you can add resources and users to this account. The following apply:
Example
In the following example structure, an organization has an account set up for their marketing department and for managers in two different AWS regions:
In the previous diagram, the organization has three separate accounts:
marketing_account
, which has access to resources associated with marketing tasks, and two different users. The user_1
user is associated with a login_1
linked to an email account.manager_account_region_1
, which has access to resources associated with a manager account in one AWS region, and one user_3
that is associated with login_1 linked to the same email account as user_1
in marketing_account.manager_account_region_2
, which has access to resources in a different region than manager_account_region_1
, and one user also associated with login_1
.The manager of the marketing department, user_1
, is associated with login_1
, which is associated with both the marketing account and both manager accounts. These accounts have access to a different set of resources and permissions. The users user_1
, user_3
, and user_4
are all the same person because they have the same login and email. The manager also manages projects across AWS regions and must access those resources in a different account. Another employee, user_2
, works in the marketing department and has access to only the marketing resources designated to marketing_account
using permissions defined by his role.
An account in Firebolt is an object within an organization that encapsulates resources for storing, querying, and managing data. Accounts provide:
Each account in Firebolt exists in a single AWS region, and can have engines and databases associated with it. Initially after registration, an account contains no resources, and only one user that has an account administrator role. An account can contain many users, as shown in the following diagram:
A user must be associated with a role, which grants them permission to access resources. These users can be associated with different roles within a single account. Each user must be associated with either a login for personal access or a service account for programmatic access, as shown in the following diagram:
A login consists of an email address. This login uniquely identifies the user.
Example
In the following example account structure, user_1
has a manager role that grants access to engines and databases associated with human resources tasks, as well as a marketing role that grants them access to everything that their employee has access to. A marketing employee, user_2
, has read-only access to the tables in the database in marketing_account
, but they cannot insert new entries or delete entries from a table.
In Firebolt, each user is associated with either a login, which is an email address, or a service account. Each user must also have a role, as shown in the following diagram:
The role grants the user permission to access resources inside the account that they are associated with. A user can have several roles associated with them at the same time. Firebolt has built-in roles with defined permissions. You can also define a custom role that grants permissions specific to your use case.
Firebolt has the following built-in roles with associated permissions for objects including databases, engines, users, network policies, and accounts:
A public role is associated with a user that can:
A public role has the lowest access privileges of all roles in Firebolt, as shown in the following diagram:
A system administrative role has privileges to manage databases, engines, schemas, and objects within those schemas. A system administrator can:
The previous system administrative privileges are shown in the following diagram:
An account administrative role includes all privileges associated with system administrators and can also manage accounts and users. An account administrator has:
The previous account administrative privileges are shown in the following diagram:
An organizational administrative role has all privileges associated with system administrators and can also manage accounts and users. An organizational administrator has:
An organizational administrative role has the highest access privileges of all roles in Firebolt, as shown in the following diagram:
Firebolt provides billing at the organization level, but gives you billing observability at both organization and account levels. This allows:
Firebolt bills are based on the consumption of resources within each account in your organization. This includes the total amount of data stored and engine usage. Learn how to manage billing.
Learn about authentication methods, role-based access control, network policies, and object ownership in Configure security.
View the AWS regions where you can use Firebolt.