Human Access Policies

By default, Wayfinder does not give static permissions to users. Instead, users begin with least privilege and can request access to specific roles to carry out a task for a period of time. Users request this escalation by using wf access cluster or wf assume. After the access period ends, these permissions expire and the user's access rolls back to least privilege again. For more information, see Human Roles.

User access policies put constraints on how human users are permitted to assume roles. Similar user access policies apply to roles that are assigned to access tokens. Access policies determine the constraints (see below) of who, how, when, where a role may be assumed by a user or assigned to an access token.

Access policy constraints

Wayfinder's access policies provide a number of constraints for controlling how users assume roles. For any role, the policy constraints are:

• Max expiration—how long the user is permitted to assume the role
• User groups—which user group can assume the role, for example, the workspace admin
• Clusters—which clusters users are allowed to assume the role in based on cloud providers, stages, and labels
• Source networks—the networks from which the user is allowed access
• Days of week—which days of the week users can assume the role
• Time of day—what time of day users can assume the role

This allows the construction of policies, or combination of policies, that provide constraints such as:

• Developers work Monday to Friday from the office, but require on-call to work outside of working days or network.
• There is a seven-hour expiry for an assumption for those coming from the office network, but external users can only have one hour.

If Wayfinder doesn't support the policy constraint you require out of the box, you can create your own constraints with some knowledge of OPA.

Examples of roles humans can assume

Here are some typical roles human users can assume:

• cluster.viewer - gives a user read-only access to all namespaces in the workspace clusters, but does not provide access to sensitive data held in secrets
• namespace.admin - gives a user administrative permissions within a specific namespace
• cluster.admin - gives a user unrestricted access to a cluster

To see details of these roles run wf get accessrole ROLE-NAME -o yaml.

As a workspace administrator, you can create your own assumable roles if needed. A role is represented as a Kubernetes custom resource definition of kind PolicyPlan—see PolicyPlan in the API Reference. For more information see:

• Create a role (UI)
• Creating Roles (CLI/yaml)

Examples of access policies for human roles

Wayfinder provides some default access policies for human roles, such as:

• assume.admin—lets workspace admins assume these roles for their workspace clusters:
  • cluster.viewer
  • namespace.admin
  • cluster.admin
• assume.members—lets workspace members assume these roles for their workspace clusters:
  • cluster.viewer
  • namespace.admin

To see details of these policies, run wf get accesspolicy POLICY-NAME -o yaml. See also View all policies below.

Create a user access policy for humans

To create a user access policy:

1. Select Settings in the Wayfinder's web interface, and then navigate to Isolation & Boundaries > Workspace RBAC > Access Policies

   The default user access/assumption policies are listed on this page.

2. Click Create policy, and then enter a name and description for this policy.

3. In the Policy constraints section, enter or select the policy constraints.

   • See Available policy constraints for a description of these.
   • In the Clusters section, you can constrain the policy to allow/deny specific cloud providers and stages. Optionally, you can click Advanced mode to match cluster labels. You can enter the exact label key/value pairs, or match expressions to find labels with matching values.

4. Click Save.

   The new policy is listed. Click the down arrow beside the policy to see its details.

View all policies

You can list or see details of policies, including assumption policies. To identify the policies associated with users' assumed roles, look for assume within the name of the policy.

To list policies or view policy details:

1. To list all Wayfinder policies, run wf get accesspolicy.

   The response is something like the one below. This includes default Wayfinder policies, policies created by assignment or assume policies, or other custom policies:

     NAME                              ROLE                ENABLED     STATUS     AGE
   assignment.members                 -                     true       Success    70d
   assume.admin                       -                     true       Success    70d
   assume.members                     -                     true       Success    70d
   cluster.admin-assume-tjh2d         cluster.admin         true       Success    155m  cluster.deployment-assign-fkbdl    cluster.deployment    true       Success    7m22s
   cluster.deployment-assign-m5vlh    cluster.deployment    true       Success    4m40s
   cluster.ingress.v1                 -                     false      Success    28d
   cluster.networkpolicies.v1         -                     true       Success    28d
   cluster.serviceaccounts.v1         -                     true       Success    28d
   cluster.services.v1                -                     true       Success    28d
   default.clusters-release           default.clusters      true       Success    28d
   default.members-release            default.members       true       Success    28d
   default.robots-release             default.robots        true       Success    28d

2. To view the details of any policy, run wf get accesspolicy POLICY-NAME -o yaml.

   The kubernetes resource definition for the policy is displayed.

Edit an access policy

To edit an access policy:

1. Select a workspace in the UI, and then navigate to User access > User access policies.
2. Find the policy you want to edit, click the down arrow to expand its details, and then click Edit policy.
3. Edit the policy, and then click Save.

Disable or delete an access policy

To disable a policy:

1. Select a workspace in the UI, and then navigate to User access > User access policies.

2. Find the policy you want to disable, and then click Disable.

   The policy is disabled, and an Enable button appears. You can re-enable the policy later by clicking this button.

CLI:

wf get accesspolicy
wf disable accesspolicy POLICY-NAME

To delete a policy:

caution

This cannot be undone.

1. Select a workspace in the UI, and then navigate to User access > User access policies.
2. Find the policy you want to delete, click the down arrow to expand its details, and then click Delete policy.
3. Confirm that you want to delete the policy.

Revoke user access

See Revoking Access.