Version: 0.7

Assume a Role

By default, Kore does not statically assign permissions to users or robots/service accounts. 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 roll back to least privilege once more.

The mechanism for users to request escalation is the kore assume CLI command. Robots (service accounts) cannot assume roles.

This can provide temporary permissions to both clusters managed by Kore and to Kore itself, depending on the configuration applied by team administrators and Kore administrators. To understand more about what can be assumed, team administrators can refer to Control Role Assumption.

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 Kore, all users with the user role member are permitted to assume the kore.viewer role in a cluster.

To assume the role kore.viewer:

  1. Ensure that you have added the cluster to your kubectl contexts using kore kubeconfig.

    You only need to do this once after a new cluster is built, and it can be done before or after kore assume:

    $ kore kubeconfig
    Imported 2 clusters into your kubeconfig: "~/.kube/config", (format: <team>.<cluster>)
    View the provisioned contexts via: $ kubectl config get-contexts
  2. Use kore assume to get the privileges you need:

    $ kore assume
    ? Which role would you like to assume?
    cluster.admin
    kore.admin
    ▸ kore.viewer
    namespace.admin
    Name:kore.viewer
    Owner:devs
    Provides read only permissions to all namespaces in the kore
    managed cluster. The role doesn't provide access to sensitive
    data held in secrets
  3. Select the role.

  4. Choose which of your clusters to access:

    ? Cluster you wish to assume permissions for:
    ▸ 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:

    $ kore assume kore.viewer --cluster eks-dev --namespace project-namespace
  5. Use kubectl to access your cluster as normal. For example:

    $ kubectl --context teamname.eks-dev get pods -n project-namespace
    No resources found in project-namespace namespace.

    For more information on kore kubeconfig and using kubectl, see Using Kubernetes Clusters with Kore.

View permissions provided by a role#

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

To see the permissions a role will give you:

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

    $ kore get policyplan cluster.admin -o yaml
    apiVersion: policy.kore.appvia.io/v1alpha1
    kind: PolicyPlan
    metadata:
    name: cluster.admin
    namespace: mark
    spec:
    description: |
    Provides unstricted access to the cluster assumed in. The plan should never be
    allocated out to a robot account or statically assigned to a user.
    inputs:
    - apiVersion: clusters.compute.kore.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.kore.appvia.io
    resources:
    - clusters
    resourceNames:
    - {{ .cluster }}
    selectors:
    - subject:
    scopes:
    - kore:system:user
    - kore:system:robot
    - resource:
    groups:
    - "*"
    resources:
    - "*"
    - "*/*"
    verbs:
    - "*"

To list all policy plans that are assumable as roles:

  1. Run kore get policyplans. Example:

    kore get policyplans
    NAME OWNER COMPLIANCE ASSUMABLE ENABLED STATUS AGE
    cluster.admin teamname default Yes true Success 30h
    clusters.defaults teamname default - true Success 30h
    kore.admin teamname default Yes true Success 30h
    kore.build teamname default - true Success 30h
    kore.deployment teamname default - true Success 30h
    kore.viewer teamname default Yes true Success 30h
    member.defaults teamname default - true Success 30h
    namespace.admin teamname default Yes true Success 30h
    robot.defaults teamname default - true Success 30h
    robots.network teamname default - true Success 30h

View assumed role sessions#

To review your current role assumption sessions:

  1. Run kore sessions.

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

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

    Like many commands in kore, 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 assumed role sessions#

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

To revoke your active role assumptions:

  1. Run kore sessions --revoke.

    This drops all your current active role assumptions.