Skip to main content
Version: 1.3

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
Getting PermissionsHow workspace members get permissions by assuming roles or assigning them to robots
Administering RBACHow workspace admins control role assumption and assignment policies, and other RBAC policy-related information
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 role assumption. 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:

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.

About roles

Note

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 CLI command wf assume provided there is an assumption 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 Assuming 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. For more information, see Assumption 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 Assigning 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. For more information, see Assignment Policies.

View roles

  • To list the available roles, run:

    wf get role

    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 role 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.

About policies

A policy is a specific grant of a set of operations, against specific resources, to specific subjects (users or robots). When a role is used through an assume or an assign, Wayfinder creates a set of policies that implement the required access. In the case of assume, the access is short-lived. Workspace administrators can also create custom policies. For more information, see Custom Roles and Policies.

There are also two special classes of policy that Wayfinder uses in order to allow subjects to escalate their privileges via assume and assign:

  • Assumption policy

    This is the mechanism that permits a subject to use wf assume to escalate their own privileges to a specific assumable role. For more information, see Creating Assumption Policies.

  • Assignment policy

    This is the mechanism that permits a subject to statically assign a role to a robot. For more information, see Creating Assignment Policies.

View current applied policies

  • To list all current applied policies, run:

    wf get policies

  • To see details of a specific policy, run:

    wf get policy 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 policy --subject USERNAME