Skip to main content
Version: 1.1

Role Based Access Control (RBAC)

Wayfinder provides a detailed, highly configurable, policy-based engine to permit access to Wayfinder and to the infrastructure it manages. Within a workspace, your workspace administrators can configure appropriate policies for workspace members, and the Wayfinder administrator can apply global policies to all workspaces.

There are two subjects who can access Wayfinder and its managed clusters: human users and robots (also known as service accounts). The access for both of these subjects is controlled by the policies applied.

What is Wayfinder's user access model?​

Wayfinder leverages the same mechanics and best practice employed within cloud vendors with role assumption.

  • All user access is driven by role assumption; users should never really have permanent access to anything. Instead they are given limited subset of permissions and when requiring additional permissions are prompted to assume, or escalate their permissions via a Role.
  • All sessions have a natural expiration time, so nothing needs to be invalidated.
  • All credentials are rotated on a configurable period.
  • When escalating permissions users are filtered through a series of policies which govern the how, when, what and why a user can assume the role. These policies are multifaceted and can take into account a number of touch points when deciding if the user can gain permissions.

RBAC terminology​

Policies operate on several layers of control:

TermDescription
PermissionThe ability to create, modify, delete, or perform other operations on a resource (such as a cluster, namespace, ingress, etc.)
RoleA group of permissions that can be granted to a subject (human or robot). For example, a Workspace Admin has permissions to create and delete clusters, create namespaces, etc. Roles provide a set of templates for permissions that can be assumed by, or assigned to, subjects. Human subjects can assume roles. Robots are assigned roles. Roles are often bundled in a compliance package. (Note that a role is different from a workspace role like member or admin.)
Policy planA template for a set of policies, some of which are usable as roles. Run wf get compliance to list policy plans and policies in your compliance package.
PolicyA set of rules about what a specific subject (human or robot) can do. They prescribe the optional conditions or rules under which a role can be used, and for which resources. For example, the Wayfinder deployment role is assigned to robot A. Then a policy is assigned to robot A, using the Wayfinder deployment role, which permits the robot to deploy to a specific cluster and namespace, and only during working hours. Another example of a policy is one that defines who can assume or assign a role, and under what conditions.
Compliance packageA collection of roles and policies. In Wayfinder, compliance packages are associated with a development stage. The development stage is chosen when creating a cluster. For example, when a Workspace Admin creates a cluster and chooses whether it’s for production or non-production, the appropriate compliance package is automatically applied.

These layers of control apply to:

  • Clusters managed by Wayfinderβ€”to view or manage Kubernetes resources in your Wayfinder-managed clusters, at a namespace or cluster-wide level
  • Wayfinder itselfβ€”to perform operations against Wayfinder to manage your infrastructure, your workspace, or Wayfinder's own setup

By administering policies and roles, workspace and Wayfinder administrators can construct a flexible contract between themselves and workspace members who request permissions. This lets administrators constrain the how, when, who, and what those members are permitted to do.