Skip to main content
Version: 1.6

RBAC and Policy Overview

Wayfinder provides a detailed, highly configurable, policy-based engine to permit access to Wayfinder and to the clusters it manages.

Role-based Access Controls (RBAC)

Wayfinder uses the RBAC framework in Kubernetes to control access for two types of subjects that can access managed clusters or Wayfinder itself:

  • Human users
  • Robots (service accounts)

The access for both of these subjects is controlled by the RBAC policies applied. A workspace administrator can configure appropriate policies for the workspace members, and the Wayfinder administrator can apply global policies to all workspaces.

Custom security policies

In addition to RBAC policies, administrators can create any type of custom security policy by defining it as a Kubernetes resource.

Where to find information

This section...Contains...
Human RolesHow workspace members get permissions by assuming roles
Robot RolesHow users create and assign roles to robots/service accounts
User AccessHow workspace admins control access and policies
Custom Security PoliciesHow Wayfinder or workspace admins can write other types of security or access policies, and some common examples

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 accessing a role on a specific resource such as a cluster or namespace. This access can be by humans or robots/service accounts. Users never have permanent access to anything. Instead, they are given a limited subset of permissions. When they need additional permissions, they 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 that 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:

This table describes the RBAC terms and Wayfinder concepts that work together to control user access.

PermissionThe ability to create, modify, delete, or perform other operations on a resource (such as a cluster, namespace, ingress, etc.)
RoleA group of generic 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 for a limited time. Robots are assigned roles permanently. Roles are often bundled in a compliance package.
Access policyWhile a role provides generic permissions, an access policy constrains those permissions to specific resources and conditions. Access policies are a set of rules about what a specific subject (human or robot) can do to specific infrastructure. For example, the Wayfinder deployment role lets a robot deploy to a cluster and namespace. When Robot A is created and assigned that role, the access policy assigned constrains Robot A to deploy to a specific cluster and namespace, and only during working hours.
Compliance packageA collection of roles and policies. In Wayfinder, compliance packages are associated with an infrastructure stage (like prod or nonprod). The 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.
GroupsA group of users. Groups facilitate creating and adjusting roles and policies for a group of users who share the same set of permissions.
Live sessionsWayfinder shows you who currently has access to resources. This lets you revoke those sessions if needed.
WorkspacesA way of putting related users, teams, projects, etc., and their associated infrastructure together in once space. All user access permissions are bound to the scope of a workspace. So, the roles and access policies in a workspace are limited to accessing the infrastructure in that workspace.
StagesUsed to separarate production environments from non-production, and any other stage you optionally define. Access policies are scoped to a specific stage by default.

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.

About roles


The roles discussed here are different from the workspace user types (workspace roles) such as workspace member or admin. For information on Wayfinder workspace roles and privileges, see Users and privileges.

Roles provide a means to template a set of policies to be assumed as a role or assigned to a robot. Roles contain:

  • A number of optional inputs
  • A set of templated criteria for what the role permits against which resources
  • A set of templated criteria for who is allowed to perform the permitted operations

Roles can target:

  • Wayfinder itself—allowing operations against Wayfinder such as creating and managing clusters, workspace members, etc.
  • Workspace clusters—allowing operations such as deploying, managing, viewing or operating Kubernetes applications

If a role definition has the Assumable flag set, it becomes a role that a workspace member can request using the either the wf access cluster CLI command, provided there is an access policy allowing the workspace member to do so.

Wayfinder ships with a default set of roles. Wayfinder administrators can control, remove or extend these defaults, or apply alternative Compliance Packages. These provide pre-packaged sets of roles and policies to workspaces. Workspace administrators can also create new roles. For more information, see Custom Roles and Policies.

Assuming a role

By default, access to clusters managed by Wayfinder is ephemeral, with no permissions statically assigned. Human users must assume a role to perform privileged operations. For details, see Human Roles.

Assuming a role is time-limited and can have other policy constraints applied, such as location, authentication methods, and times of the day or week at which that role can be assumed. Workspace administrators can configure a set of policies that define these constraints. See Manage access policies.

Assigning a role to a robot

Robots cannot assume roles. Instead, you can statically assign a role to a robot/service account. This lets you use the robot in a continuous integration/deployment scenario. See Robot Roles to understand the process. Workspace administrators can configure a set of policies that describe what permissions may be statically assigned to robots, and who may assign them. See Manage access policies.

View roles

  • To list the available roles, run:

    wf get accessrole

    Roles that users can assume are listed with role in the category column. Roles that can be assigned to robots are listed with deployment as the category.

  • To see the details of a specific role, run:

    wf get accessrole NAME -o yaml

View live sessions

You can see which users currently have permissions to access clusters.

  • To view live sessions, run wf sessions --all.

For more information, see Revoking Access.

View current applied policies

  • To list all current applied policies, run:

    wf get accesspolicy

  • To see details of a specific policy, run:

    wf get accesspolicy POLICY-NAME -o yaml

    The response looks almost identical to standard Kubernetes RBAC, which is what Wayfinder translates the policy into.

  • To list policies that apply to you or another user, run:

    wf get accesspolicy --subject USERNAME

RBAC defaults

Wayfinder comes with some default user groups, roles, and policies. For details, see Default Groups, Roles, and Policies.