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.