Skip to main content
Version: 1.3

Assuming 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. After a set period, these permissions expire and the user's access rolls back to least privilege once more.

The mechanism for users to request escalation is wf assume.

Alternatively, to access a cluster wf access cluster provides a single command to assume a role and configure kubectl to access it. This can provide temporary permissions to both clusters managed by Wayfinder and to Wayfinder itself, depending on the configuration applied by workspace administrators and Wayfinder administrators.

Workspace administrators can set constraints on how, when or where users can assume roles by creating assumption policies. These are also referred to as user access policies in the Wayfinder UI.

note

Robots (service accounts) cannot assume roles.

Assume a role

Example use case: In this example, you're a developer who needs to debug an issue in a deployed application. To do this you must assume a role to access a cluster named eks-dev.

When operating under the default compliance package that ships with Wayfinder, all users with the user role member are permitted to assume the cluster.viewer role in a cluster.

To assume a role without preparing kubectl:

  1. Use wf assume to get the privileges you need:

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

    Name:cluster.viewer
    Owner:dave2

    Provides read-only permissions to all namespaces in the workspace clusters.
    This role does not provide access to sensitive data held in secrets
  2. Choose which of your clusters to access:

    ? Cluster in which you wish to assume cluster viewer:
    ▸ eks-dev
    gke-dev
  3. You now have the requisite access for the specified amount of time. You can use wf kubeconfig to prepare kubectl to access this cluster.

To assume a role and prepare kubectl to access the cluster in a single command:

  1. Use wf access cluster to get the privileges you need and prepare kubectl to access the cluster. It will prompt you to select a role:

    $ wf access cluster
    ? Which role would you like to use?
    cluster.admin
    ▸ cluster.viewer
    namespace.admin

    Name:cluster.viewer
    Owner:devs

    Provides read-only permissions to all namespaces in the workspace clusters.
    This role does not provide access to sensitive data held in secrets
  2. Choose which of your clusters to access:

    ? Cluster in which you wish to assume cluster viewer:
    ▸ eks-dev
    gke-dev

    Depending on the role, other questions may be asked, such as which namespace to use for the namespace.admin role. You can provide all of these in a single line, without any prompts. For example:

    $ wf access cluster eks-dev project-namespace --role cluster.viewer
    ◉ Waiting for role to be applied
    ✔ Access to cluster eks-dev with role cluster.viewer granted until: 30 Apr 21 19:48 BST
    ✔ Current kubectl context set to devs.eks-dev
  3. Use kubectl to access your cluster as normal. For example:

    $ kubectl get pods -n project-namespace
    No resources found in project-namespace namespace.

Using wf access cluster is equivalent to using wf assume and wf kubeconfig.

For more information on accessing clusters, see Provisioning Kubernetes Clusters in Wayfinder.

View permissions provided by a role

Roles that can be assumed are provided by roles marked as assumable.

To see the permissions a role will give you:

  1. Retrieve the role detail, supplying the role name, for example, cluster.admin. Example:

    $ wf get role cluster.admin -o yaml
    apiVersion: policy.org.appvia.io/v1alpha1
    kind: PolicyPlan
    metadata:
    name: cluster.admin
    namespace: mark
    spec:
    description: |
    Provides unstricted access to the cluster assumed in. The role should never be
    allocated out to a robot or statically assigned to a user.
    inputs:
    - apiVersion: clusters.compute.org.appvia.io/v1
    description: |
    Cluster you wish to assume namespace admin
    name: cluster
    required: true
    resource: clusters
    type: single
    templates:
    - name: clusteradmin
    template: |
    policy:
    decision:
    action: allow
    message: User is permitted access to the cluster

    target:
    selector:
    groups:
    - clusters.compute.org.appvia.io
    resources:
    - clusters
    resourceNames:
    - {{ .cluster }}

    selectors:
    - subject:
    scopes:
    - wf:system:user
    - wf:system:robot
    - resource:
    groups:
    - "*"
    resources:
    - "*"
    - "*/*"
    verbs:
    - "*"

To list all roles that are assumable:

  1. Run wf get roles. Example:


    $ wf get roles
    NAME COMPLIANCE ENABLED STATUS AGE
    cluster.admin default true Success 7m40s
    cluster.clusterroles default true Success 7m40s
    cluster.daemonsets default true Success 7m40s
    cluster.deployment default true Success 7m40s
    cluster.registries default true Success 7m40s
    cluster.robots.network default true Success 7m40s
    cluster.viewer default true Success 7m40s
    default.clusters default true Success 7m40s
    default.members default true Success 7m40s
    default.robots default true Success 7m40s
    namespace.admin default true Success 7m40s

View my assumed role sessions

To view your current role assumption sessions:

  1. Run wf sessions.

    The response gives a list of active role assumptions. Example:

    $ wf sessions
    NAME PLAN EXPIRES IN AGE
    cluster.admin-assume-cjqjp cluster.admin 59m 2s
    tip

    Like many commands in wf, if you want to see more detail, add -o yaml to understand the details of a session, such as which cluster it applies to for a cluster-based role, and what permissions are being granted.

UI: Navigate to Access policies > Live sessions

Revoke my assumed role sessions

Sessions expire automatically, however, you can drop assumed privileges after completing a task.

To revoke your active role assumptions:

  1. Run wf sessions --revoke.

    This drops all your current active role assumptions.