Human 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 access cluster. This 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 owners and Wayfinder administrators.

Workspace owners can set constraints on how, when or where users can assume roles by creating access policies. For more information, see Understanding roles and access policies.

note

Access Tokens 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:

Shortcut: wf access cluster CLUSTER-NAME [NAMESPACE-NAME] --ROLE-NAME

1. Use wf access cluster to get the privileges you need and prepare kubectl to access the cluster.

   Using wf access cluster is equivalent to using wf assume and wf kubeconfig. It will prompt you to select a cluster and 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

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

1. Use kubectl to access your cluster as normal. For example:

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

For more information on accessing clusters, see Selve-Serve Kubernetes Clusters in Wayfinder.

View permissions provided by a role

You can see role permissions either in the UI or using the CLI.

To see role permissions the Wayfinder web interface:

1. Select Admin, and then navigate to Access > Roles

To see role permissions with the CLI:

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

➜  ~ wf get accessrole cluster.admin -o yaml
    apiVersion: policydelivery.appvia.io/v1alpha1
    kind: AccessRole
    metadata:
      name: cluster.admin
      namespace: ws-app
    spec:
      clusterScope: true
      description: Full cluster administration
      rules:
      - apiGroups:
        - '*'
        - '*/*'
        resources:
        - '*'
        verbs:
        - '*'

List all roles that are assumable

1. Run wf get accessroles. Example:

➜  ~ wf get accessroles
NAME                           DESCRIPTION                                                                                     STATUS     ENABLED    AGE
cluster.admin                  Full cluster administration                                                                     Success    Unknown    7d4h
cluster.deployment             Provision standard resources for access token deployments to any namespace in a cluster         Success    Unknown    7d4h                                                                                     Unknown    7d4h
cluster.deployment-readonly    Cluster-wide read access to resources required for namespace deployments using access tokens    Success    Unknown    7d4h
cluster.view                   Read-only access to standard resources, excluding secrets                                       Success    Unknown    7d4h
namespace.admin                Full namespace administration                                                                   Success    Unknown    7d4h
namespace.daemonset            Provisioning of daemonsets to a namespace for deployments using access tokens                   Success    Unknown    7d4h
namespace.deployment           Provisioning standard resources to a namespace for access token deployments                     Success    Unknown    7d4h
namespace.edit                 Full access to standard resources, excluding secrets read                                       Success    Unknown    7d4h
namespace.troubleshooting      Retrieve logs and exec into pods                                                                Success    Unknown    7d4h
namespace.view                 Read-only access to standard resources, excluding secrets                                       Success    Unknown    7d4h
secrets.view                   View secrets                                                                                    Success    Unknown    7d4h
➜  ~

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.

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.