Configuring a policy using the Console

This page provides instructions for configuring a Binary Authorization policy using Google Cloud Console. As an alternative, you can perform these tasks using gcloud commands at the command line or using the REST API. This step is part of setting up Binary Authorization.

A policy is a set of rules that govern the deployment of one or more container images.

Before you begin

  1. Enable Binary Authorization.
  2. Create a cluster.
  3. If you intend to use attestations, we recommend that you create attestors before configuring the policy. You can create attestors using the Cloud Console or through a command-line tool.
  4. Select the project ID for the project in which you enabled Binary Authorization.

Set the default rule

A rule is the part of a policy that defines constraints that images must satisfy before they can be deployed. The default rule defines constraints that apply to all non-exempt container images that don't have their own cluster-specific rules. Every policy has a default rule.

To set the default rule:

  1. In the Cloud Console, go to the Binary Authorization page.

    Go to the Binary Authorization page

  2. Click the Policy tab.

  3. Click Edit Policy.

  4. Set the evaluation mode for the default rule.

    The evaluation mode specifies the type of constraint that Binary Authorization enforces at deploy time. To set the evaluation mode, select one of the following options:

    • Allow all images: allows all images to be deployed.
    • Deny all images: disallows all images from being deployed.
    • Allow only images that have been approved by the following attestors: allows an image to be deployed if the image has an associated attestation that can be verified by one of the attestors you add to this rule. To learn about creating attestors, see Creating attestors.

    If you selected Allow only images that have been approved by the following attestors:

    1. Get the name or resource ID of your attestor.

      In the Google Cloud Console, on the Attestors page, you can view your existing attestors, or create a new one.

      Go to the Binary Authorization Attestors page

    2. Click Add Attestors.

    3. Select one of the following options:

      • Add by project and attestor name

        The project refers to the project ID of the project that stores your attestors. An example of an attestor name is build-qa.

      • Add by attestor resource ID

        A resource ID has the format:

        projects/PROJECT_ID/attestors/ATTESTOR_NAME
        
    4. Under Attestors, enter appropriate value(s) for the option you selected.

    5. Click Add Another Attestor if you want to add additional attestors.

    6. Click Add Attestor(s) to save the rule.

  1. If you want to enable dry run mode, select Dry Run Mode.

  2. Click Save Policy.

Set cluster-specific rules (optional)

A policy might also have one or more cluster-specific rules. This type of rule applies to container images that are to be deployed to specific Google Kubernetes Engine (GKE) clusters only. Cluster-specific rules are an optional part of a policy.

Add a cluster-specific rules (GKE)

To add a cluster-specific rule for a GKE cluster, do the following:

  1. In the Cloud Console, go to the Binary Authorization page.

    Go to the Binary Authorization page

  2. Click the Policy tab.

  3. Click Edit Policy.

  4. Under Cluster-specific rules, expand the Rules section.

  5. Click Add Rule.

  6. In the Cluster resource ID field, enter the resource ID for the cluster.

    The resource ID for the cluster has the format LOCATION.NAME, for example, us-central1-a.test-cluster.

  7. Set the evaluation mode for the default rule.

    The evaluation mode specifies the type of constraint that Binary Authorization enforces at deploy time. To set the evaluation mode, select one of the following options:

    • Allow all images: allows all images to be deployed.
    • Deny all images: disallows all images from being deployed.
    • Allow only images that have been approved by the following attestors: allows an image to be deployed if the image has an associated attestation that can be verified by one of the attestors you add to this rule. To learn about creating attestors, see Creating attestors.

    If you selected Allow only images that have been approved by the following attestors:

    1. Get the name or resource ID of your attestor.

      In the Google Cloud Console, on the Attestors page, you can view your existing attestors, or create a new one.

      Go to the Binary Authorization Attestors page

    2. Click Add Attestors.

    3. Select one of the following options:

      • Add by project and attestor name

        The project refers to the project ID of the project that stores your attestors. An example of an attestor name is build-qa.

      • Add by attestor resource ID

        A resource ID has the format:

        projects/PROJECT_ID/attestors/ATTESTOR_NAME
        
    4. Under Attestors, enter appropriate value(s) for the option you selected.

    5. Click Add Another Attestor if you want to add additional attestors.

    6. Click Add Attestor(s) to save the rule.

  8. Click Add to add the cluster-specific rule.

    You might see a message that reads, "It looks like this cluster doesn't exist. This rule will still take effect if this cluster becomes available in GKE in the future." If so, click Add again to save the rule.

  9. If you want to enable dry run mode, select Dry Run Mode.

  10. Click Save Policy.

Add a cluster-specific rule (Anthos clusters on VMware)

To add a cluster-specific rule for a Anthos clusters on VMware cluster, do the following:

  1. In the Cloud Console, go to the Binary Authorization page.

    Go to the Binary Authorization page

  2. Click the Policy tab.

  3. Click Edit Policy.

  4. Under Cluster-specific rules, expand the Rules section.

  5. Click Add Rule.

  6. In the Cluster resource ID field, enter the resource ID for the cluster.

    The resource ID has the format: global.CLUSTER_ID. Learn how to get the cluster resource ID for a cluster on Anthos clusters on VMware.

  7. Set the evaluation mode for the default rule.

    The evaluation mode specifies the type of constraint that Binary Authorization enforces at deploy time. To set the evaluation mode, select one of the following options:

    • Allow all images: allows all images to be deployed.
    • Deny all images: disallows all images from being deployed.
    • Allow only images that have been approved by the following attestors: allows an image to be deployed if the image has an associated attestation that can be verified by one of the attestors you add to this rule. To learn about creating attestors, see Creating attestors.

    If you selected Allow only images that have been approved by the following attestors:

    1. Get the name or resource ID of your attestor.

      In the Google Cloud Console, on the Attestors page, you can view your existing attestors, or create a new one.

      Go to the Binary Authorization Attestors page

    2. Click Add Attestors.

    3. Select one of the following options:

      • Add by project and attestor name

        The project refers to the project ID of the project that stores your attestors. An example of an attestor name is build-qa.

      • Add by attestor resource ID

        A resource ID has the format:

        projects/PROJECT_ID/attestors/ATTESTOR_NAME
        
    4. Under Attestors, enter appropriate value(s) for the option you selected.

    5. Click Add Another Attestor if you want to add additional attestors.

    6. Click Add Attestor(s) to save the rule.

  8. Click Add to save the rule.

    You might see a message that reads "It looks like this cluster doesn't exist. This rule still takes effect if the specified cluster becomes available in GKE in the future." In this case, click Add again to save the rule.

  9. If you want to enable dry run mode, select Dry Run Mode.

  10. Click Save Policy.

Add specific rules (Anthos Service Mesh)

Anthos Service Mesh users can create rules that are scoped to either a mesh service identity, a Kubernetes service account, or a Kubernetes namespace. You can add or modify a specific rule as follows:

  1. In the Cloud Console, go to the Binary Authorization page.

    Go to the Binary Authorization page

  2. Click the Policy tab.

  3. Click Edit Policy.

  4. If no specific rule type is set, click Create Specific Rules.

    1. Click Specific Rule Type to select the rule type.

    2. Click Change to update the rule type.

  5. If the specific rule type exists, you can change the rule type by clicking Edit Type.

  6. To add a specific rule, click Add Specific Rule. Depending on the rule type you choose, you enter an ID, as follows:

    • ASM Service Identity: Enter your ASM service identity ID. Example format: PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT
    • Kubernetes Service Account: Enter your Kubernetes service account ID. Example format: NAMESPACE:SERVICE_ACCOUNT.
    • Kubernetes Namespace: Enter your Kubernetes namespace ID. Example format: NAMESPACE

    Replace the following, as required, depending on the rule type:

    • PROJECT_ID: the project ID in which you define your Kubernetes resources.
    • NAMESPACE: the Kubernetes namespace.
    • SERVICE_ACCOUNT: the service account.
  7. Set the evaluation mode for the default rule.

    The evaluation mode specifies the type of constraint that Binary Authorization enforces at deploy time. To set the evaluation mode, select one of the following options:

    • Allow all images: allows all images to be deployed.
    • Deny all images: disallows all images from being deployed.
    • Allow only images that have been approved by the following attestors: allows an image to be deployed if the image has an associated attestation that can be verified by one of the attestors you add to this rule. To learn about creating attestors, see Creating attestors.

    If you selected Allow only images that have been approved by the following attestors:

    1. Get the name or resource ID of your attestor.

      In the Google Cloud Console, on the Attestors page, you can view your existing attestors, or create a new one.

      Go to the Binary Authorization Attestors page

    2. Click Add Attestors.

    3. Select one of the following options:

      • Add by project and attestor name

        The project refers to the project ID of the project that stores your attestors. An example of an attestor name is build-qa.

      • Add by attestor resource ID

        A resource ID has the format:

        projects/PROJECT_ID/attestors/ATTESTOR_NAME
        
    4. Under Attestors, enter appropriate value(s) for the option you selected.

    5. Click Add Another Attestor if you want to add additional attestors.

    6. Click Add Attestor(s) to save the rule.

  8. Click Dry run mode to enable dry run mode.

  9. Click Add to save the specific rule.

  10. Click Save Policy.

Manage exempt images

An exempt image is an image that is exempt from policy rules. Binary Authorization always allows exempt images to be deployed.

Each policy can have an allowlist of exempt images specified by their registry path. This path can be a location either in Container Registry or another container image registry.

Enable the system policy

Trust all Google-maintained system images is a policy setting that enables the Binary Authorization system policy. When this setting is enabled at deploy time, Binary Authorization exempts a list of Google-maintained system images that are required by GKE from further policy evaluation. The system policy is evaluated before any of your other policy settings.

To enable the system policy, do the following:

  1. Go to the Binary Authorization page in Cloud Console.

    Go to the Binary Authorization page

  2. Click Edit Policy.

  3. Select Trust All Google-Provided System Images in the Images Exempt from Deployment Rules section.

  4. To manually specify additional exempt images, expand the Images Paths section.

    Then, click Add Image Path and enter the registry path to any additional image you want to exempt.

  5. Click Save Policy.

What's next