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.
Policies operate on several layers of control:
|Permission||The ability to create, modify, delete, or perform other operations on a resource (such as a cluster, namespace, ingress, etc.)|
|Role||A 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 |
|Policy plan||A template for a set of policies, some of which are usable as roles.|
|Policy||A 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 |
|Compliance package||A 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.
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.
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.
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
To list the available roles, run:
Roles that users can assume are listed with
categorycolumn. Roles that can be assigned to robots are listed with
To see the details of a specific role, run:
kore get role 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 role 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 role. See Role
Assumption to understand how team administrators can control assumption
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.
To list all current applied policies, run:
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