Trusted image cloud workload policies - Trusted image policies ensure the integrity and security of container images and VMs deployed into Kubernetes environments. Using these policies, you can be assured that your images are from a trusted source, are built on approved and validated base images, and are free from unauthorized modifications. - Administrator Guide - Cortex CLOUD

Create an Issue. The image is allowed to run, but a violation is recorded as a posture and/or security issue. For the purposes of this documentation, we refer to this as an issue-only action.

The primary purpose of trusted image policies with the issue-only action is auditing and compliance. These violations are identified by Cortex periodic scans.

The issue-only action assesses trust across a range of assets, including Kubernetes workloads (which are cloud-agnostic, supporting AWS, Azure, GCP, OCI), virtual machines (VMs).

Prevent and Create an Issue. Images created after this policy is enabled will be blocked from running if they don't meet the trust criteria, and a violation will also be recorded as a security issue. For images that were already running—and which don't meet the trust criteria—a posture issue is created.For the purposes of this documentation, we will refer to this as the prevent action.

These issues block deployment in real-time.

The prevent action is cloud-agnostic (supports AWS, Azure, GCP, OCI) and enforced at the Kubernetes cluster level via the admission controller.

All trusted image policies are designed for runtime security enforcement. However, to ensure that policies with the prevent action can successfully block untrusted images, the policy's scope must be on a Kubernetes cluster where the admission controller is enabled.

Utilizing an "OR-based" approach

Cortex utilizes an "OR-based" approach, with no explicit priority or rule order when resolving policy conflicts.

This enables Cortex to prioritize the most permissive result among conflicting policies with prevent actions, while enforcing the most restrictive result between policies with issue-only actions.

Understanding the approach and the logic behind it helps you create policies efficiently.

Recommendations include:

Trusting and allowing images by scope

Trusted image policies provide granular control by ensuring that policies only impact the specific environment (scope) for which they are defined. An image can be trusted in one scope and untrusted in another. For example, a third party image may be trusted in your Development environment but immediately untrusted in your Production environment.

If you have not defined any trusted image policies for a specific scope, the default behavior is that all images within that scope are implicitly trusted However, once a policy is defined for a scope, any image not explicitly trusted by that policy is automatically untrusted.

Policy enforcement is directly tied to the defined scope. When you define the Asset Group scope for a policy (for example, a specific cluster's Test namespace), the policy applies only to the resources within that exact definition. The more narrowly defined your scope, the more targeted the policy's enforcement will be, ensuring the enforcement does not affect unrelated resources.

If multiple policies with prevent actions cover the same scope, the logic is additive (allow-wins). As long as at least one of those policies results in the image being trusted, the image will be allowed to run.

Generating issues

The following points clarify the logic for generating runtime security issues and posture issues based on your defined policies:

Policy evaluation: Handling unknown, missing or partial image data

Situations may arise where insufficient information is available at the time of deployment to conclusively arrive at a trust verdict. This means Cortex cannot confirm an image's trusted or untrusted status. Examples of such situations where there is a lack of complete image metadata include:

Cortex handles these situations differently based on the policy's action:

Policy decision logic for workloads

Situations might arise where within the same workload, multiple images or multiple policies yield conflicting trust results. When these conflicts occur—such as one policy trusting an image while another prevents it, or a single deployment containing both trusted and untrusted images—Cortex relies on the following defined logic to determine the final deployment outcome and what issues, if any, are generated.