What is RBAC?
RBAC, or Role-Based Access Control, is like a digital bouncer for your FlexStack environment. It helps manage who can do what within the platform, just like how different people have different access levels in a physical building.
How Does RBAC Work at FlexStack?
Roles: Think of roles as job titles or categories. In FlexStack, users are assigned roles based on their responsibilities. For example, an "Admin" role might have more access than a "Member."
Permissions: Each role comes with a set of permissions, like a list of tasks or actions they can perform. An Admin might have permission to make big changes, while a Member might only be able to list resources.
Assigning Roles: In FlexStack, you decide which role to give to each team member. This determines what they can and cannot do. Organization-level roles can be assigned in the Members dashboard.
How does this help to secure environments?
RBAC at FlexStack helps secure environments in a few important ways:
Control: It lets you control who can access what. So, sensitive data and critical functions are protected.
Reduced Risks: By limiting access, you reduce the chance of mistakes or unauthorized actions. You're less likely to have accidents or data breaches.
Compliance: Many industries have rules about who can access certain data. RBAC helps you follow those rules easily.
Efficiency: RBAC also streamlines work. Each person gets just the access they need, which reduces confusion and makes everything run smoother.
In a nutshell, RBAC is like giving everyone a special key card for their part of the FlexStack building. It's a simple, organized way to make sure the right people have access to the right things, keeping your organization secure and running smoothly.
Unlike native AWS user permissions, which are wide-ranging, difficult to understand, and challenging to assign, FlexStack makes it easy to specify which team members can operate in each environment and service within your organization.
Organization roles
Organization-level roles are assigned in the Members dashboard. There are three roles which are inherited by the rest of the resources in your organization:
Owner: Organization Owners have full read and write to access to all resources in the organization regardless of whatever controls or membership you assign to individual resources, e.g. environments. Owners can also access and update billing information for the organization and are considered a point-of-contact for billing issues.
Admin: Organization Admins have the same rights as Owners, except for billing. That is, they cannot read or write to any billing endpoints. They may invite, update, and revoke team memberships. They can create, update, read, and delete any resource within the organization.
Member: Organization Members can read resources that are not protected by more restrictive permissions (e.g. billing). They may be added as contributors to projects, environments, and components which will allow them to create, update, and delete those respective resources.
Project roles
Project-level roles are assigned in Project settings. Project roles are inherited by all of the environments and components in the project, so choose wisely.
Owner: May create, read, update, and delete all resources within the project. They may also delete or disconnect the project itself. Additionally, they may create, update, and delete members within the project.
Contributor: May create, read, update, and delete all resources within the project including environments and components. They may also read all secret values within the project.
Viewer: May read all non-sensitive resources within the project (i.e. they cannot read secrets).
Organization Owners and Admins inherit the Project Owner role.
Environment roles
Environment-level roles are assigned to specific environments. You can update environment memberships via the Members tab in an environment.
Owner: May create, read, update, and delete all resources within the environment. They may also delete or disconnect the environment itself. Additionally, they may create, update, and delete members within the environment.
Contributor: May create, read, update, and delete all resources within the environment including components. They may also read secret values within the environment.
Viewer: May read all non-sensitive resources within the project (i.e. they cannot read secrets).
Project and Organization Owners and Admins inherit the Environment Owner role. Project and Organization members inherit the Viewer role.