Policies allow you to customize admission control and extend Loft. As Loft internally uses Kubernetes resources for anything (including UI requests), you can customize almost everything with policies.
The following use cases are possible with policies:
- Custom validation of users, teams, spaces, clusters and other objects. For example, you can:
- Deny creation, updating or deletion of resources only for specific users or teams
- Deny security critical objects such as privileged pods in clusters
- Ensure unique names, hosts or other properties within a cluster
- Automatic mutation of created or updated resources. For example, you can:
- Add a label or annotation which user or team created an object
- Inject sidecar containers into a pod
- Add groups, cluster account templates etc. automatically to a user
- Automation of certain cluster tasks, such as:
- Automatic creation, update or deletion of users, accounts, spaces etc. on a certain condition
- Sync certain resources within a cluster
- Garbage collection of not needed resources
Policies are based on jsPolicy and you will need to install the jsPolicy app into the cluster if you want to use policies. JsPolicy is a recommended app in Loft and can be installed via the Loft UI.
Alternatively, you can also install jsPolicy with helm.
Policies can be created either through the Loft UI or through directly creating
JsPolicy objects in the cluster. For a more extensive documentation how to write policies, please check the jsPolicy docs.
Go to the Clusters > Policies view and click on 'Add Policy'.
In the metadata section of the policy, you can set the name of the policy, which has to be in domain format (e.g. my-policy.jspolicy.com or any other domain you want), the annotations and labels of the policy object.
In the options section, you can choose from a variety of examples to start from or create your own from scratch. The following options exist:
The type of the policy. For a more extensive explanation check the jsPolicy documentation. The type can be one of:
Validating: Validating policies are executed as part of Kubernetes requests after the execution of mutating policies. The objective of validating policies is to inspect the request and then to either deny or allow it.
Mutating: Mutating policies are executed as part of Kubernetes requests right after the API server performs authentication and authorization (RBAC). The objective of mutating policies is to change the payload (Kubernetes object) provided in a request, e.g. add/remove a label in the
metadata.labelsof a Kubernetes object that is being created.
Controller: Unlike mutating and validating policies, controller policies are not part of the lifecycle of a request to the Kubernetes API server. Controller policies are triggered by the
Eventsthat Kubernetes creates for each change of the cluster state in etcd, e.g. if you create a new
Deploymentor update an
Ingress, Kubernetes creates an
Eventfor this change. The objective of controller policies is to react to changes to your cluster's state.
The scope of the policy. This can be either
Namespaced and refers to the scope of Kubernetes resources. A
Namespaced policy will only match resources that can be created within a namespace, while
Cluster will only match cluster-wide resources such as
The Kubernetes resources this policy should match. You can specify multiple resources here or a wildcard that matches all resources.
Operations are the operations the policy cares about and can be one or more of: CREATE, UPDATE, DELETE, CONNECT or *.
After you have configured the policy, press 'Create' to add it to the cluster.
You can delete a policy either via the Loft UI or kubectl directly.
Go to the Clusters > Policies view and click on 'delete' in the actions column.
If a request was denied by a policy, it will write this violation into its policy log. You can view all policy violations in the Audit > Policy Violations view.
This view shows information about the request that was denied, such as which user was responsible for the violation (if there was any), the action taken, the returned message etc.
This section holds several examples for useful policies within loft. For more examples and explanations checkout the jsPolicy documentation.
You can apply these examples by creating a
policy.yaml and running
kubectl apply -f policy.yaml in the target cluster.
Deny Space Owned By Team
This policy denies spaces that are owned by teams.
Deny Pods of User
This policy will deny pod creation only for a single Loft user called
Deny Resources in default Namespace
This policy will deny all new resources that should be created in the default namespace.
Deny Privileged Pods
This policy will deny privileged pods.
Deny Ingress Classes
This policy will deny all ingress classes except
Allow Space only if Part of Team
This policy will only allow space creation if the user is part of team 'admins'.
Set User as Annotation On New Object
This policy will set the user that has created it on a new kubernetes object.
Inject Sidecar Container
This policy will inject a sidecar container into pods that have an annotation "inject-side-car".
Unique Ingress Hosts
This policy will ensure that ingress hosts are unique in the cluster.
This policy will sync secrets that have the labels
owner-namespace with a parent secret that has the label
sync. On a change to a parent or child secret, the controller policy will evaluate if an update is necessary and update the child secret if it differs from the parent secret.
Why jsPolicy and not OPA / Kyverno?
Loft does not require you to use jsPolicy for policies, and you can always use your own preferred solution. Every policy engine should work fine with Loft. However, if you want to use the policies view in Loft, this currently only works with jsPolicy.
We decided to integrate jsPolicy instead of another policy engine, because jsPolicy is the most flexible one that can cover the most use cases within Loft. Especially with controller policies and mutating webhooks that are not at all or only partly supported in other policy engines, jsPolicy has a huge advantage in terms of flexibility and expressiveness.