Kubernetes scopes are groups of Kubernetes resources that share a purpose. For example, clusters are Kubernetes resources that qualify for a scope definition. You can use a scope as a filter or to apply an identical security policy across Kubernetes resources.
Grouping Kubernetes resources in scopes provides a foundation for targeted planning of security policies. You can add and edit scopes, and you can delete scopes that are not attached to a Kubernetes policy.
The default scope is a predefined scope that encompasses all clusters and namespaces. The default scope is called Any. The Any scope is always available and cannot be deleted. It is the highest scope in the hierarchy of scopes. The scope resolution process searches for the most precise scope definition into which a Kubernetes resource falls to apply the policy. If no more precise scope is found, the policy that is attached to the default scope is considered.
Scopes for the Build Phase
Build Phase refers to defining the container images or Kubernetes objects for scanning or validating with CLI Client commands. You can integrate the commands in a CI/CD pipeline. You can define a scope for all resources in the build phase, for Kubernetes namespaces, or for a particular build step. The build step is a parameter that the CLI Client uses for performing image scanning. See Setting up CLI Client for Image Scanning and Scanning Images.
Scopes for the Deploy Phase
Deploy Phase refers to a grouping of Kubernetes workloads that are going to be deployed or are already deployed.
Scopes can overlap by hierarchy from the most general to the most specific according to the following order: all clusters, cluster group, cluster, namespace, and workload. For workloads that are part of overlapping scopes, the policy attached to the narrowest scope is applied. In that way, a workload resolves to a single policy.
|A cluster group for all production clusters||Filters or assigns a policy for all clusters in the same tier.|
|One or more Kubernetes clusters||Filter or assigns a policy to different clusters.|
|Application across clusters by choosing a Kubernetes namespace that is defined on many clusters||Filters or assigns policies to a group of resources forming an application regardless of where they are deployed.|
Application scopes include container images in both build phase and deploy phase. The scope reflects the practice of separating the applications in their own Kubernetes namespaces. If a scope is defined as an application scope, the policy assigned to the scope is applied to all container images in the namespace, regardless of the development phase and regardless of the clusters where this namespace is located. This scope ensures the same hardening criteria while building or deploying the application.