Advanced use of automatic import/deletion
If you have an advanced use case for automatic import/deletion of Kubernetes workload projects, you can write your own rules. The controller evaluates policy decisions using a policy file written in Rego policy language. Ensure the file is named workload-events.rego.

Provide the policy file to the Snyk controller in a ConfigMap. The policy syntax looks like this:
package snyk
orgs := ["<org-id>"]
default workload_events = false
It is important that the default workload_events is false. If you flip the value to true, it will automatically import or delete everything in the cluster including any workload_events defined in your policy.
Setting the workload_events key to true is not recommended as some workload types like Jobs and Pods can be noisy and generate lots of workload imports in your Snyk organization
Both package snyk and the key workload_events are mandatory by Snyk Controller.

This feature is only available if you are business or enterprise customers
Orgs is a list of organization public IDs. You can add more than one organization to use the auto-import and auto-delete capabilities. You can locate this public ID in the settings page for the organization.
package snyk
orgs := ["<org-id-1>","<org-id-2>"]
default workload_events = false

To define your own rules, set a condition on the workload_events key and by providing your organization public ID. For example, to import workloads from the default namespace and automatically delete them on Snyk side once they are deleted from the cluster, the policy would look like this:
package snyk
orgs := ["19982df2-0ed5-4a16-b355-e6535cfc41ef"]
default workload_events = false
workload_events {
input.metadata.namespace == "default"
}
Here, input refers to the Kubernetes metadata of the workload scanned by the Snyk controller.
You can also create a policy for workload events (creation/deletion) with a specific annotation:
package snyk
orgs := ["19982df2-0ed5-4a16-b355-e6535cfc41ef"]
default workload_events = false
workload_events {
input.metadata.annotations.team == "apollo"
}

As best practice, we recommend excluding specific workload types such as Pods and Jobs from workload events (creation/deletion), as they can be really noisy and can generate lots of workload imports in your Snyk organization. You can do this with the following example policy:
package snyk
orgs := ["19982df2-0ed5-4a16-b355-e6535cfc41ef"]
default workload_events = false
workload_events {
input.kind != "Job"
input.kind != "Pod"
}

kubectl create configmap snyk-monitor-custom-policies \
-n snyk-monitor \
--from-file=workload-events.rego # This name is hardcoded
helm upgrade --install snyk-monitor snyk-charts/snyk-monitor \
--namespace snyk-monitor \
--set clusterName="Production cluster" \
--set workloadPoliciesMap=snyk-monitor-custom-policies
Now you can deploy the Snyk controller, or restart it if it is already running in order to pick up the policy. You will now see new workloads in Snyk.
Export as PDF
Copy link
Edit on GitHub
On this page
Policy syntax
Using more than one org
Defining rules
Excluding workload types
Configure Snyk controller to use the policy