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.
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.
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
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.
To list the available policy plans and see which are assumeable, run:
To see the details of a specific policy plan, run:
kore get policyplan POLICYPLAN-NAME -o yaml
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
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
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
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.
To list the current applied policies, run:
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.