Cluster Access Management: Overview
Overview of the updated cluster access management, introduced with Orka 3.0
Quick navigation
Jump to: Terminology | Role-based access matrix| Workflow overview
Starting with Orka 3.0, Orka relies on Single-Sign On (SSO) and the Kubernetes concept of role-based access control (RBAC) for user management.
Users log in to their cluster with their MacStadium Customer Portal credentials. Based on the role bindings configured for the respective user, they can access one or more namespaces.
Terminology
| Domain | Term | Definition |
|---|---|---|
| Customer Portal | Account | The account managing one or more Orka clusters in the MacStadium Customer Portal. Every account has a unique ID in the Customer Portal. One account might have multiple account users in various account roles. If one Customer Portal account manages multiple Orka clusters, all account users are shared between the clusters. |
| Customer Portal | Account user | A user belonging to the managing account in the MacStadium Customer Portal. One Customer Portal account user can assume only one account role at a time. If one Customer Portal account manages multiple Orka clusters, all account users are shared between the clusters. Any account user can log in to the Orka cluster belonging to the account. Only Admin and Tech users can work with the cluster. |
| Customer Portal | Account role | An account user can assume only one of the following account roles at a time: Admin, Billing, or Tech. Account users with the Admin role are also administrators for the Orka cluster. Account users with the Tech role are considered developers and have non-administrative access to the Orka cluster. Account users with the Billing role can only log in to the cluster but cannot perform any actions. |
| Orka cluster | Cluster user | A Customer Portal account user logged in to the Orka cluster. Based on their account role, they belong to the Administrator or the Technical role.If one Customer Portal account manages multiple Orka clusters, all account users are shared between the clusters. |
| Orka cluster | Service account | A special type of Orka cluster account intended for use with the available Orka CI/CD integrations. A service account is not related to a Customer Portal account and cannot be shared across clusters. |
| Orka cluster | Namespace | A namespace is a way to isolate resources and dedicate them to a specific user, group of users, or service account(s). For a user or a service account to be able to access the namespace, they must be added as a subject to the respective role binding. Role bindings are created automatically, but administrators need to add subjects manually. |
| Orka cluster | Role | A Kubernetes RBAC role for your Orka cluster. The two default roles: Administrator and Technical correspond directly to the Admin and Tech account roles.When an administrator creates a new namespace, Orka automatically creates a predefined role for the namespace. You can control which cluster users and service accounts can access the namespace by adding or removing subjects to the respective role binding. |
| Orka cluster | Role bindings and subjects | A way to indicate which cluster users have access to which namespaces. By default, all Administrator and Tech users can access the orka-default namespace. All Administrators can access all custom orka- namespaces. Tech users have access to a custom namespace when they are added as a subject to the respective role binding. |
Role-based access matrix
The Admin account role maps to the Administrator group role in the Orka cluster.
The Tech account role maps to the Technical group role in the Orka cluster.
The Billing account role does not map to any role in the Orka cluster.
Cluster service accounts don't map to any account roles.
Within the Customer Portal, the Admin, Tech, and Billing roles have the following capabilities:
Within the Orka cluster, the Admin, Tech, and Billing roles have the following capabilities:
| Operation | Admin | Tech | Billing | Admin SA (Orka Small Teams-only) | Regular SA |
|---|---|---|---|---|---|
| Log in with CP credentials | β | β | β | β | β |
| Log in with authentication token | β | β | β | β | β |
| Log out | β | β | β | β | β |
| Manage users | β | β | β | β | β |
| Manage service accounts, including token generation | β | β | β | β | β |
| Print authentication token | β | β | β | β | β |
| Manage namespaces | β | β | β | β | β |
| Manage role bindings | β | β | β | β | β |
| List nodes | β | β | β | β | β |
| Manage nodes | β | β | β | β | β |
Access and work in the orka-default namespace | β | By default, yes. An administrator can revoke access to orka-default. | β | β | Yes, if created in the orka-defaultnamespace. Otherwise, based on role bindings. |
Access and work in custom orka- namespaces | β | Based on role bindings. | β | β | Yes, if created in the respective namespace. Otherwise, based on role bindings. |
| View information about all VMs in the namespace | β | β | β | β | β |
| Deploy VMs in the namespace | β | β | β | β | β |
| Manage the VM state of all VMs in the namespace | β | β | β | β | β |
| Delete own VMs in the namespace | β | β | β | β | β |
| Delete other subjects' VMs in the namespace | β | β | β | β | β |
| Manage VM configs (except deleting) | β | β | β | β | β |
| Delete own VM configs | β | β | β | β | β |
| Delete other owners' VMs | β | β | β | β | β |
| Manage images | β | β | β | β | β |
| List and pull remote images | β | β | β | β | β |
| Manage ISOs | β | β | β | β | β |
| List and pull remote ISOs | β | β | β | β | β |
Workflow overview
The following workflow outlines how to add users to the cluster.
- In the MacStadium Customer Portal, an account administrator invites the account users who need to be able to access the Orka cluster and sets their roles.
- The invited account users accept the invite and update their temporary credentials in the MacStadium Customer Portal.
- The account users log in to the Orka cluster with their Customer Portal credentials.
The following workflow outlines how to add service accounts to the cluster.
- In the Orka cluster, an administrator creates the service account to target a specific namespace.
- If needed, the cluster administrator provides additional namespace access to the service account.
Next, administrators can choose to isolate and dedicate resources to specific users and service accounts. This way, administrators can structure their clusters around teams and/or workflows.
- The cluster administrator creates a namespace.
- The cluster administrator assigns nodes to the namespace. (Nodes cannot be shared across namespaces and clusters.)
- The cluster administrator adds subjects to the respective role binding for the namespace. Any service accounts need to already exist. Any users need to already be part of the Customer Portal account.
If needed, an administrator can change the details or role of a user, or revoke the access of a user or a service account to the cluster.
- In the MacStadium Customer Portal, an account administrator edits or disables users.
- In the Orka cluster, a cluster administrator deletes service accounts.
If needed, an administrator can move unused resources (nodes) across namespaces.
If needed, an administrator can revoke the access to a namespace or provide additional namespace access to existing users and service accounts.
- In the Orka cluster, an administrator adds or removes subjects to the respective role bindings.
See also
Updated 5 months ago