Skip to main content
Version: 1.2

Creating Assumption Policies

Assumption Policies are user access policies that put constraints on how users are permitted to assume roles. Robots/service accounts cannot assume roles.

By default, Wayfinder does not give static permissions to users. Instead, users begin with least privilege and can request escalation 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 set period, these permissions expire and the user's access rolls back to least privilege again. For more information, see Assuming Roles.

Available policy constraints

Wayfinder's assumption policies provide a number of constraints for controlling role assumption:

  • Expiration—how long the user is permitted to assume the role
  • Scopes—groups of users/subjects. Currently, there is one scope for role assumption: users
  • Subjects—which users can assume the role
  • Workspace user types—which user type can assume the role, for example, 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.

Assumable roles

The following roles are Wayfinder's default assumable roles:

  • 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 role ROLE-NAME -o yaml. For more information, see wf get role.

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.

Default assumption policies

Wayfinder provides the following default assumption policies, but you can create your own.

  • assume.admin—lets a workspace admin 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, see View all policies.

Create an assumption/user access policy

An assumption policy (CLI) is the same as a user access policy (UI).

UI method

To create a user access policy:

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

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

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

    If you'd rather copy and edit an existing policy, click Duplicate on the policy you want to copy.

  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.

CLI method

To create an assumption policy:

  1. Run the command wf create policy assume command.

    tip

    If you want to see the implementation before applying, run the command with the --dry-run option. This outputs the YAML of the generated policy without applying it.

  2. Respond to the question prompts to form the policy:

    • Which users are you permitting to assume the role: members of a specific workspace, members in a role, all workspace members, etc.
    • Which role are you permitting these users to assume?
    • You are then asked a series of questions allowing you to place constraints on the time, location, authentication method, and other parameters to the role.

Example: Constrain assumption of the namespace.admin role

In this example a developer, katie@yourorg.io, needs to correct an issue in a deployed application. The default assumption policy lets workspace members assume the namespace.admin role, but you want to constrain the ability to assume this role to users from a particular source network, set an expiration time for the role, and limit the assumption to weekdays only.

To create this assumption policy:

  1. Run the following, and select the namespace.admin role:

    $ wf create policy assume
    ? Which role would you like to allow use of?
    cluster.admin
    wf.admin
    wf.viewer
    ▸ namespace.admin

    Name:namespace.admin
    Owner:workspacename

    Provides administrative permissions within a specific namespace
    for a period of time. Note this role is intended to be used by users
    not robot accounts; please use cluster.deployment for deployments.
  1. Select the constraints:

    ✔ Creating role assumption policy for role: "namespace.admin"
    ✔ You have chosen to add a time to live for assuming y
    ✔ The policy will disappear in 1h
    ✔ Policy will apply to member: katie@yourorg.io
    ✔ This role has 2 parameters associated
    ◉ The role has a required value: "cluster" (single)
    ✔ You have selected eks-dev2 as the cluster:
    ◉ The role has a required value: "namespace" (single)
    ✔ You have selected katieapp as the namespace:
    ✔ Choosen to constrain the assume by source network y
    ✔ Select the network range 10.120.0.0/22
    ✔ Choosen to constrain the assume by expiration y
    ✔ What the max time a user can assume e.g. 1h, 30m, 3d: 3h
    ? Would you like to enforce the time of day they can assume? [y/N] y
    ✔ You have selected Mon-Fri as week days
    ✔ You have selected Mon,Tue,Wed,Thu,Fri as the choosen days
    ? Are you sure you want to apply this policy? [y/N] y
    ✔ Policy allowing role assumption created

The developer katie@yourorg.io can now use either of the following commands to assume the role, with the additional constraints you defined above. wf access cluster also configures kubectl to access the cluster:

  • wf access cluster eks-dev katieapp --role namespace.admin
  • wf assume namespace.admin --cluster eks-dev --namespace katieapp

This applies for the next hour.

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

    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 policy POLICY-NAME -o yaml.

    The kubernetes resource definition for the policy is displayed.

Edit an assumption policy

To edit an assumption policy:

  1. Select a workspace in the UI, and then navigate to Access policy > 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 assumption policy

To disable a policy:

  1. Select a workspace in the UI, and then navigate to Access policy > 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 policy
wf disable policy POLICY-NAME

To delete a policy:

caution

This cannot be undone.

  1. Select a workspace in the UI, and then navigate to Access policy > 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.