Resource Access Management
Testkube provides a flexible access-control mechanism to help you enforce how members of an Organization have access to Environments and their Resources (Workflows, Workflow Templates, Triggers and Webhooks).
Testkube enforces resource access described in this document in the Control Plane, meaning that it is possible to bypass these controls by directly interacting with Testkube resources in your cluster(s) using kubectl or similar tooling.
More rigorous RBAC functionality enforced across the entire Testkube stack is on the roadmap.
Organization Members and Teams
There are four roles for organization members - Read More. For the sake of this document:
Owner
/Admin
- Always have access to all resources in all environments.Member
- Resource access is controlled at the Environment and Resource Group level.Biller
- No Resource access.
To furthermore simplify access management for a group of members, Testkube has the concept of Teams, which provides convenient grouping of members. Whenever you can specify a Member for access control in Testkube, you can also specify a Team.
There are currently two "levels" of providing access to Testkube Resources:
- Environment Access
- Resource Groups
Environment Access
To have access to resources in a Testkube Environment, organization Members and Teams must be added to an Environment with a specific role - Read More. The given role applies to all Resources in that Environment.
If a member has access to an Environment via multiple Teams and/or as a direct Member, Testkube will enforce the most permissive role for a given Resource (unless that Resource is in a Resource Group - see below).
For example, if Organization Member A has the write
Role in Env B, but is also a member of Team C which has the
read
role in that Environment, Testkube will enforce the write
role as it is the more permissive of the two roles.