Skip to main content
Version: 0.9

Role Based Access Control (RBAC) in Kore

Kore provides a detailed, highly configurable, policy-based engine to permit access to Kore and to the infrastructure it manages. Within a team, your team administrators can configure appropriate policies for team members, and the Kore administrator can apply global policies to all teams.

There are two subjects who can access Kore and its managed clusters: human users and robots (also known as service accounts). The access for both of these subjects is controlled by the policies applied.

RBAC terms and how they function#

Policies operate on several layers of control:

PermissionThe ability to create, modify, delete, or perform other operations on a resource (such as a cluster, namespace, ingress, etc.)
RoleA group of permissions that can be granted to a subject (human or robot). For example, a Team Admin has permissions to create and delete clusters, create namespaces, etc. Roles provide a set of templates for permissions that can be assumed by, or assigned to, subjects. Human subjects can assume roles. Robots are assigned roles. Roles are often bundled in a compliance package. For more information, see Kore get role.
Policy planA template for a set of policies, some of which are usable as roles.
PolicyA set of rules about what a specific subject (human or robot) can do. They prescribe the optional conditions or rules under which a role can be used, and for which resources. For example, the Kore deployment role is assigned to robot A. Then a policy is assigned to robot A, using the Kore deployment role, which permits the robot to deploy to a specific cluster and namespace, and only during working hours. Another example of a policy is one that defines who can assume or assign a role, and under what conditions. For more information, see kore get policy.
Compliance packageA collection of roles and policies. In Kore, compliance packages are associated with a development stage. The development stage is chosen when creating a cluster. For example, when a Team Admin creates a cluster and chooses whether it’s for production or non-production, the appropriate compliance package is automatically applied. For more information, see Compliance Packages.

These layers of control apply to:

  • Clusters managed by Kore—to view or manage Kubernetes resources in your Kore-managed clusters, at a namespace or cluster-wide level
  • Kore itself—to perform operations against Kore to manage your infrastructure, your team, or Kore's own setup

By administering policies and roles, team and Kore administrators can construct a flexible contract between themselves and team members who request permissions. This lets administrators constrain the how, when, who, and what those members are permitted to do.

About roles#


The roles discussed here are different from the privileges for different types of Kore users, such as Team Member. For information on different Kore user privileges, see Kore users.

Roles provide a means to template a set of policies to be assumed as a role or assigned to a robot. Roles contain:

  • A number of optional inputs
  • A set of templated criteria for what the role permits against which resources
  • A set of templated criteria for who is allowed to perform the permitted operations

Roles can target:

  • Kore itself—allowing operations against Kore such as creating and managing clusters, team members, etc.
  • Team clusters—allowing operations such as deploying, managing, viewing or operating Kubernetes applications

If a role has the Assumable flag set, it becomes a role a team member can request via kore assume, provided there is a policy allowing that team member to do so.

Kore ships with a default set of roles and Kore administrators can control, remove or extend these defaults, or apply alternative Compliance Packages. These provide pre-packaged sets of roles and policies to teams. See Compliance Packages to understand how team administrators can use and extend the built-in defaults.

Assuming a role to access privileged operations#

By default, access to clusters managed by Kore (and, depending on configuration, Kore itself) is ephemeral, with no permissions statically assigned. To perform privileged operations human users must assume a role. See Assume a Role for how to request this.

Assuming a role is time-limited and can have other constraints applied, such as location, authentication methods, and times of the day or week at which that role can be assumed.

If you are a team administrator you can configure a set of policies that provide roles that your users can assume. See Role Assumption for how to manage this in your team.

Assigning a role to a robot / service account#

In addition to assuming roles, you can statically assign a role to a robot. This allows for situations where you cannot use kore assume in a continuous integration/deployment scenario. See Assign a Role to understand the process.

If you are a team administrator you can configure a set of policies that describe what permissions may be statically assigned to robots, and who may assign them. See Role Assignment for how to manage this in your team.

If using the default policies that ship with Kore, you cannot assign roles permanently to a human user—users must use kore assume.

View Roles#

  • To list the available roles, run:

    kore get role

    Roles that users can assume are listed with role in the category column. Roles that can be assigned to robots are listed with deployment as the category.

  • To see the details of a specific role, run:

    kore get role NAME -o yaml

About policies#

A policy is a specific grant of a set of operations, against specific resources, to specific subjects (users or robots). When a role is used through an assume or an assign, Kore creates a set of policies that implement the required access. In the case of assume, the access is short-lived.

There are also two special classes of policy that Kore uses in order to allow subjects to escalate their privileges via assume and assign.

Assumption policy#

This is the mechanism that permits a subject to use kore assume to escalate their own privileges to a specific assumable role. See Role Assumption to understand how team administrators can control assumption policies.

Assignment policy#

This is the mechanism that permits a subject to statically assign a role to a robot. See Control Role Assignment to understand how team administrators can control assignment policies.

View current applied policies#

  • To list all current applied policies, run:

    kore get policies

  • To see details of a specific policy, run:

    kore get policy POLICY-NAME -o yaml

    The response looks almost identical to standard Kubernetes RBAC, which is what Kore translates the policy into.

  • To list policies that apply to you or another user, run:

    kore get policy --subject USERNAME

Last updated on Aug 5, 2021