Continuous validation overview

Continuous validation (CV) with check-based platform policies is a feature of Binary Authorization that lets you monitor Pods that run on Google Kubernetes Engine (GKE) to ensure that their associated container images continue to conform to Binary Authorization check-based platform policies that you specify.

When CV determines that Pods violate platform policies, it logs the violations to Cloud Logging.

CV with platform policies supersedes legacy continuous validation (deprecated).

Why use CV?

Although Binary Authorization enforcement provides one-time image validations when you deploy container images, CV continuously monitors that images associated with running Pods continue to conform to your policies.

Because of this, when you enable both Binary Authorization enforcement and CV with check-based policies, you can ensure that policy conformance is validated throughout the entire orchestration lifecycle.

CV is useful in the following scenarios:

  • Policy changes: When you update your Binary Authorization project-singleton enforcement policies, Binary Authorization validates only images that are deployed after the update. Pods that are already running aren't affected. They continue to run even if Binary Authorization, using the updated policy, would now block the same image from being deployed.

    Because of this, when you update the Binary Authorization project-singleton policy, we recommend that you also create or update a CV platform policy to match the project-singleton policy. That way CV informs you of running Pods that violate your updated policies.

  • Monitoring image metadata: CV provides specific checks for changes in image metadata, including the following:

    • Attestations: CV logs when the attestations on the Pods' images are no longer valid.
    • Freshness: CV logs when it detects that Pods' images are no longer fresh.
    • Provenance: CV can check that Pods' images were built with a trusted builder, using build configs that reside in a trusted source repository.
    • Sigstore signatures: CV logs when the on the Pods' images lack a valid Sigstore signature.
    • Trusted directory: CV logs when the Pods' images reside in a repository directory that isn't listed in your platform policy.
    • Vulnerabilities: CV logs when vulnerabilities are identified in Pods' images.

  • Dry run monitoring: When you enable dry run, Binary Authorization allows all images to be deployed. By enabling CV with a platform policy that matches your project-singleton policy, CV regularly logs images that violate the platform policy.

  • Breakglass monitoring: When you deploy Pods using breakglass, Binary Authorization bypasses project-singleton policy enforcement and logs a single event to Cloud Audit Logs. By using a matching platform policy, however, CV continues to regularly log policy-violating Pods, including those Pods deployed using breakglass.

How CV works

To use CV, you must enable it on your GKE clusters.

After you deploy images on your cluster, CV monitors the associated Pods to make sure they conform with your check-based platform policy.

CV doesn't support image tags, other than those specified in exempt images.

CV regularly reviews running Pods

To monitor running Pods, CV reviews images associated with each Pod at least every 24 hours. CV also monitors init containers and ephemeral containers.

During each review, CV retrieves a list of images associated with each Pod. CV then verifies that image information satisfies the platform policy.

CV logs violations of platform policies

When CV determines that images violate a platform policy, it logs the violations and other findings to Cloud Logging. A separate log entry is written for each platform policy that is violated, for each Pod.

When CV evaluates a Pod's images using a platform policy, the images might satisfy some checks and violate others. CV produces a log entry whenever any image of a Pod violates any check. The log entry contains only the Pod images that violate the platform policy. If all images satisfy all checks, no log entries are produced.

CV continues to log policy violations until a Pod with non-policy-conformant images terminates. When non-policy-conformant Pods are terminated during the interval between validations, the final CV-generated log entries can appear after termination, during the next CV evaluation.

Non-policy-conformant Pods should be logged at least once, even for short-lived Pods.

CV does not terminate running Pods.

CV uses a feed resource

To retrieve information about Pods running on your GKE cluster, CV creates a feed resource called binauthz-cv-cai-feed.

CV platform policies

To use CV, you first configure platform policies.

Platform policies are different from legacy Binary Authorization policies, also called project-singleton policies. Although the deployment project can have only one legacy project-singleton policy, you can configure multiple platform policies. Each platform policy can reside in one or more projects.

Platform policies work only with CV and don't support Binary Authorization enforcement. Because of this, we recommend that if you want to use both Binary Authorization enforcement and CV monitoring, you create a project-singleton policy for enforcement and a platform policy for monitoring.

For example, suppose that you want to configure Binary Authorization to enforce that your images have an attestation before they are allowed to be deployed, and you also want to ensure that your running Pods conform to the same requirement. To do this, you configure a project-singleton enforcement policy with an attestor. You then create a platform policy with a simple signing attestation check. that has an authenticator based on the same note and public key as the attestor.

Platform policies are platform specific. GKE is the only supported platform.

You can configure checks in platform policies. Checks are grouped into one or more check sets. Each check set can specify one or more checks.

Platform policies can exempt images from evaluation by CV.

Required permissions

To list or describe platform policies, you need the binaryauthorization.policyViewer role. To create, modify, and delete platform policies, you need the binaryauthorization.policyEditor role. For more information, see Manage platform policies.

Policy updates

Updating a platform policy overwrites the existing policy with a policy descriptor that you provide in the YAML file. To add a new check to an existing platform policy, we recommend that you describe the existing policy, saving it to a YAML file, add the new check, and then update the policy using the updated file.

Multiple platform policies

You can create platform policies in the same project as the cluster (a local platform policy) or in any other project.

Because you can configure a number of platform policies, you name each one with a unique resource name. When you run a gcloud CLI command you refer to the local platform policy using its ID. When you refer to a platform policy in another project, you use the resource name, in the following format: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

You can choose which platform policy to associate with each GKE cluster, whether it's a local platform policy or one in a different project.

Multiple checks per platform policy

You can configure multiple checks in each platform policy by adding them to the checks block of the policy. To learn more about specific checks that you can configure, see checks.

When your CV platform policy specifies more than one check, images that are evaluated by one check continue to be evaluated by the other checks.

Binary Authorization evaluates all of the checks that are configured in the platform policy for each image unless the image matches an exempt images allowlist pattern. For more information, see Exempt images.

Single-project setup

You can set up CV in a single project.

In a single-project setup, Binary Authorization automatically sets up its required roles in the Binary Authorization service agent.

If GKE clusters, platform policies bound to the clusters, and the metadata that is required by checks all reside in the same project, no additional Identity and Access Management (IAM) roles are required.

To learn more about configuring a multi-project setup for added security, see Separation of concerns.

Multi-project setup

When you configure a multi-project CV setup with platform policies, the platform policies, the images, the GKE cluster, and other types of CV-dependent resources can each reside in a different project.

In multi-project setup, it's important to know the purpose of each project and the resources that CV needs to access and set up required IAM roles and permissions accordingly.

How to use CV

To use CV, you typically do the following:

  1. Decide which checks you want to use.
  2. Compose one or more platform policies using a policy YAML file. The file specifies which checks you want to use.
  3. Create the platform policy. The policy can be stored in a project of your choice.
  4. Choose whether to enable CV on individual clusters or on a fleet.
  5. Check CV logs in Logging for events.
  6. Review logs and update your build and other processes to produce images that satisfy the checks.

Checks

This section describes the specific checks that CV provides.

Check-based policies have the following canonical format:

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

The displayName field in checks and checkSets is optional. It is used only when CV logs policy violations. It is omitted in some of the examples later in this guide.

Always-deny check

The always-deny check guarantees that all images subject to this check fail evaluation. Each time CV reviews running Pods with this check, it produces a log entry for each of the Pods.

You can combine the always-deny check with allowlists or multiple check sets to ensure that Binary Authorization always produces logs for Pods in certain cases.

To use the always-deny check, add alwaysDeny: true in the checks block, as follows:

gkePolicy: