Access Control

This section is about role-based access controls (RBAC) within a Critical Stack cluster. It’s used by Administrators to assign and create permissions.

Currently, Critical Stack has four default cluster roles: admin, audit, cluster-admin and developer.

  • Admin: A namespace-specific admin role with some limitations. Use Admin with a RoleBinding to grant read/write permissions to most resources (e.g create additional roles and RoleBindings within the namespace).

The admin role does not have write permissions to the namespace or resource quotas.

  • Audit: Default access role granting read-only permissions to all resources.
  • Cluster-Admin: Conveys super-user access to perform actions on any resource. Users have full control of all namespaces and cluster resources when used in a ClusterRoleBinding. To limit controls and actions to a specific namespace, use in a RoleBinding. Users will have access to every resource and the namespace itself.
  • Developer: Grants read/write permissions to most resources. Devs do not have write access to Ingress, Resource Quotas, or Limit Ranges.

Before we dive in there are a few things to note about RBAC that may be a bit different from other systems you’ve administered.

  1. A Role or ClusterRole contains a set of rules. The rules define who and where things happens.
  2. Bindings define what happens.
  3. Permissions always add rights. When it comes to clusters, there are no deny rules.
  4. The Access Tab does not list users with access to the UI. It only lists users with permissions in the cluster.

Would you like to know what permissions are currently assigned within your cluster or a specific namespace? Critical Stack makes that easy with an overview of the current permissions in a cluster. These permissions are conveniently listed by subject.

The Access Overview lists the subjects and their bindings. Click each tab (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings) to view access lists by type.

FeatureWhat it Does
1Access Number is the total number of Objects in the cluster (Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings).
2Role Type/Kind states whether the Role applies to a User or a Group.
3Name lists the Subject’s Name.
4Local Account “Yes” means the account is managed with the Critical Stack login provider and a user will need to enter a password. “No” means the account is managed in an external SSO provider and the user will go through that provider’s authentication path.
5Role Count the number of Roles or Cluster Roles bound to a subject.
6Role gives the who, what, and where.

Roles, ClusterRoles, and Bindings, Oh My!

Roles, ClusterRoles, and their respective Bindings seem intimidating or a bit counter-intutitive. The chart below lists the key differences between a Role and a ClusterRole. Use it as a starting point to decide which type of role to create.

RoleClusterRole
Requires a namespaceDoes not require a namespace
Permissions limited to a named spacePermissions are cluster-wide

Creating a Role

Critical Stack makes creating Roles and Bindings simple with a form. The form populates API Groups, Resources, and Verbs from the Cluster. Options change with each selection. For more advanced users Critical Stack provides command line controls to create Roles/ClusterRoles and Bindings, too.

To create a Role, click + Create Role, then give it a name and set the rules in the form: 1. Provide a Name for the Role. 2. Click the drop-down arrow to select an API Group or type an API Group name, if it isn’t listed. 3. Click the drop-down arrow to choose Resource(s). 4. Click the drop-down arrow to see the availabe Verbs and make the appropriate selections. 5. Click the + to add additional Rules and repeat Steps 2-4. 6. Once you’re happy with your selections, click OK to create the Role.

The newly created Role appears in the Roles tab.

Creating a RoleBinding

The twist, you can create a RoleBinding without a specific role. Again, Critical Stack provides a form or command line interface to create Bindings. Create a RoleBinding using the form.

To create a RoleBinding, click + Create RoleBinding, and complete the form: 1. Specify the Kind: Role or ClusterRole. 2. Choose a Role Name: Role Name (You can type a Role Name, if it does not exist). 3. For Subjects, select Kind: User, Group, or ServiceAccount. 4. Choose a Name: This Name matches the User, Group, or ServiceAccount. 5. Click + to add more Subjects. 6. Confirm the RoleBinding Name. The Autofill box is checked by default and a name is generated based on the provided inputs. 7. Click OK to create the RoleBinding.

View the new RoleBinding under the RoleBindings tab.

Creating a ClusterRole

To create a ClusterRole, click + Create ClusterRole, then give it a name and set the rules in the form:: 1. Provide a Name for the ClusterRole. 2. Click the drop-down arrow to select an API Group or type an API Group name, if it isn’t listed. 3. Click the drop-down arrow to choose Resource(s). 4. Click the drop-down arrow to see the availabe Verbs and make the appropriate selections. 5. Click the + to add additional Rules and repeat Steps 2-4. 6. Once you’re happy with your selections, click OK to create the ClusterRole.

The newly created ClusterRole appears in the ClusterRoles tab.

Creating a ClusterRoleBinding

To create a ClusterRole, click + Create ClusterRole, and complete the form: Kind is prepopulated with ClusterRole. 1. Choose a ClusterRole Name: ClusterRole Name (You can type a ClusterRole Name, if it does not exist). 2. For Subjects, select Kind: User, Group, or ServiceAccount. 3. Choose a Name: This Name matches the User, Group, or ServiceAccount. 4. Click + to add more Subjects. 5. Confirm the ClusterRoleBinding Name. The Autofill box is checked by default and a name is generated based on the provided inputs. 6. Click OK to create the ClusterRoleBinding.

View the new ClusterRoleBinding under the ClusterRoleBindings tab.