Version: 0.7

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 system robot accounts (also known as service accounts). The access for both of these subjects is controlled by the policies applied.

The policy engine allows three layers of control:

  • Access controls decide how subjects (users or robots) can access Kore and the clusters it manages. These controls can be based on time, connection method, network range, or other things.
  • Policies govern how subjects are permitted to:
    • Assume permissions—use a set of permissions temporarily to human users
    • Assign permissions—grant a set of permissions permanently to a robot/service account
  • Policy plans (often bundled in a Compliance Module) enforce team behaviour or resource utilization. They provide the set of templates for roles that can be assumed by, or assigned to, subjects.

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 policy plans, 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.

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 you 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 Control 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 account. 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 robot accounts, and who may assign them. See Control 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.

What are policy plans?#

Policy plans (also known as roles) provide a means to template a set of policies to be assumed as a role or assigned to a robot. Policy plans contain:

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

Policy plans 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 policy plan 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 policy plans and Kore administrators can control, remove or extend these defaults, or apply alternative Compliance Packages. These provide pre-packaged sets of policy plans and policies to teams. See Manage Compliance Packages to understand how team administrators can use and extend the built-in defaults.

View policy plans#

  • To list the available policy plans and see which are assumeable, run:

    kore get policyplans

  • To see the details of a specific policy plan, run:

    kore get policyplan POLICYPLAN-NAME -o yaml

What are policies?#

A policy is a specific grant of a set of operations, against specific resources, to specific subjects (users or robots). When a policy plan 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 policy plan (also known as a role). See Control 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 policy plan to a robot. See Control Role Assignment to understand how team administrators can control assignment policies.

View current applied policies#

  • To list the current applied policies, run:

    kore get policies

  • To see the 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.