Role-Based Access Control (RBAC)
Control which members of your teams have access to infrastructure as well as the level of access. Permissions are first granted at the organization level, and then further access is defined for each stack.
Organization Access
To access anything within your organization in Nullstone, users must first be added as members in your organization. As you add them to your organization, you will determine what type of role they will play. To modify who has access to your organization and their role, navigate to the organization settings page. A link to the organization settings can be found in the bottom left of the sidebar.
Org: Member
The member role is the role with the least privileges. Most members will fall into this category, as they won't need to access much at the organization level. They will be able to see who the other members of the organization are as well as the Nullstone subscription. However, they will not be able to make any changes.
Org: Architect
An organization architect assumes all the permissions of a member but is also granted additional abilities. The architect role is reserved for the members of your organization who are responsible for setting up and granting access to cloud accounts. Architects are also responsible for publishing new custom modules in the Nullstone registry.
Org: Admin
An organization admin can do everything within an organization. They have all the permissions of a member and architect plus the following. Admins have the ability to add and remove members as well as set their roles. They also have the ability to update the Nullstone subscription and manage billing.
Stack Access
A stack in Nullstone is a way of grouping infrastructure that works together and is maintained by a particular team. For smaller systems and companies, you probably only have one stack. However, as your development team grows, typically the team is broken down into smaller teams with responsibility over a specific portion of your overall software system(s). The Nullstone recommended strategy for tackling this is to use the "You build it, you run it" strategy.
Defining roles at the stack level allows you to ensure team members only have access to the infrastructure they need. If a user hasn't been added to a stack, they will not be able to see anything in the stack.
Stack: Software Engineer
The software engineer role is the role with the least privileges in a stack. Granting this role to a user will allow them to create, destroy, and manage applications. They will be able to view all the datastores, domains, and other infrastructure within this stack. However, they will not be able to make changes to anything other than applications.
Stack: Architect
A user with the role of architect for a stack assumes all the privileges of a Software Engineer. In addition, they have privileges to perform some more sensitive actions. They can add, destroy, and maintain datastores, domains, and other infrastructure within the stack. The architect role within a stack is generally reserved for team members who are the leads for their team. Members from your platform team and SREs are usually assigned the architect role within stacks as well.
Stack: Owner
The only thing that an architect isn't responsible for is managing other users' access to the stack. That permission is reserved for the stack owner. The stack owner has full privileges within a stack.