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
|Getting Permissions||How workspace members get permissions by assuming roles or assigning them to robots|
|Administering RBAC||How workspace admins control role assumption and assignment policies, and other RBAC policy-related information|
|Custom Security Policies||How 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.
Policies operate on several layers of control:
|Permission||The ability to create, modify, delete, or perform other operations on a resource (such as a cluster, namespace, ingress, etc.)|
|Role||A 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 plan||A template for a set of policies, some of which are usable as roles. Run |
|Policy||A 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 package||A 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.
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.
To list the available roles, run:
Roles that users can assume are listed with
categorycolumn. Roles that can be assigned to robots are listed with
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.
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
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
This is the mechanism that permits a subject to use
wf assumeto escalate their own privileges to a specific assumable role. For more information, see Creating Assumption Policies.
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:
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