Enhancing Cloud Run Security with Binary Authorization in GCP Single Project

Note

This post translated By AI and the original content was written in Traditional Chinese.

Scenario

• Use the Binary Authorization feature in CloudRun to enhance security control
• Using Binary Authorization policy can check if the revision complies with policy requirements before each CloudRun service deployment
• If you want to force deployment in non-compliant situations, you can bypass it using the breakglass feature
• Policy does not retroactively apply to already deployed and running CloudRun services

Enable API

Projects using CloudRun or GKE need to access this, click here to enable Binary Authorization API

Click NEXT

Click Enable

(Optional) Confirm org settings

You can click here to check the project or org application status and settings

Enter “Allowed Binary Authorization Policies (Cloud Run)” as the filter condition to view. If adjustments are needed, follow the instructions to configure

As shown in the image below, the project inherits organizational rules

Set Disallow All Images Policy

Click here to set policy

Set default rules

• Use default block all images and exempt image
• If you want to enable Dry-run mode, you can check and enable it here
• For Exempt image settings, refer to this article
  • You can specify a single image, such as: gcr.io/example-project/helloworld
    • Specify tag: gcr.io/example-project/helloworld:latest
    • Specify all versions gcr.io/example-project/helloworld:*
  • Specify a project gcr.io/example-project/*
    • Including subfolders under the project gcr.io/example-project/**
• Save after completion

Enable Binary Authorization on new CloudRun service

Use Policy-compliant image

Create CloudRun service

Use exempt image

Check to use binary authorization and then create

Service can be created normally

Use non-Policy-compliant image

Same as the previous steps, but choose a different image

A message appears indicating inability to deploy, you can click BREAKGLASS

Enter the reason, then click BREAKGLASS again

After BREAKGLASS, it can operate normally

Audit log information

Default disallow using non-allowed image

You can go to Log Explorer to query, enter the following filter conditions to view records

resource.type="cloud_run_revision"
logName:"cloudaudit.googleapis.com%2Fsystem_event"
protoPayload.response.status.conditions.reason="ContainerImageUnauthorized"

The following record will appear

Using Dry run audit log

resource.type="cloud_run_revision"
logName:"cloudaudit.googleapis.com%2Fsystem_event"
"dry run"

Breakglass audit log

For breakglass records, you can use the following filter conditions to search

protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
"run.googleapis.com/binary-authorization-breakglass"

The red box shows the reason entered

SCC integration

Currently, SCC supports the following events, but it’s still in the Preview stage

Data source

Data source

Set Attestations Policy

Since using attestations requires preliminary steps to create attestor and PKIX key, this case uses KMS to create PKIX, and finally sign the image with attestations.

The creation process is as follows:

1. Create KMS Key in GCP
2. Set up attestor
3. Set binary authorization policy
4. Use attestations

Set up KMS

Enable KMS API

First-time use requires enabling the KMS API

Enter in the search bar

Cloud Key Management Service (KMS) API

Click to enter

Enable

Create Key

Create Key Rings

Perform the following actions as needed

1. Name
2. Region
3. Create

After completion, create Key, enter name, select software for protection level, choose Asymmetric sign for purpose, and select Elliptic Curve P-256 - SHA256 Digest for algorithm

After completion, click create

After creation, click to enter

Copy the Key resource name for later use

Set up Attestor

Enable Attestor API

As with the steps to enable the KMS API, search for containeranalysis.googleapis.com and enable the API

Enable binaryauthorization.googleapis.com API

Add Attestor

1. Create name
2. Expand
3. Paste the Key resource name copied earlier
4. Complete

After pasting, SUBMIT

1. Click DONE
2. Confirm that Automatically generate a Container Analysis note is checked
3. Click CREATE

Set Binary Authorization Policy

Add the recently created Attestor

1. Choose Require attestations
2. Add attestor
3. Save settings

Add attestors

1. Select name
2. Add

Using Attestation

Attest image

Currently, only gcloud commands are supported for implementation

Set the following environment variables and execute

ATTESTOR_PROJECT_ID="YOUR_PROJECT_ID"
ATTESTATION_PROJECT_ID="YOUR_PROJECT_ID"
ATTESTOR_NAME="demo-attstor"
IMAGE_PATH="asia-east1-docker.pkg.dev/YOUR_PROJECT_ID/allow-repo/nginx"
IMAGE_DIGEST="sha256:YOUR_IMG_DIGEST"
IMAGE_TO_ATTEST="${IMAGE_PATH}@${IMAGE_DIGEST}"
KMS_KEY_PROJECT_ID="YOUR_PROJECT_ID"
KMS_KEY_LOCATION="global"
KMS_KEYRING_NAME="image-keys"
KMS_KEY_NAME="binary-auth-key"
KMS_KEY_VERSION=1

gcloud beta container binauthz attestations sign-and-create \
    --project="${ATTESTATION_PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${ATTESTOR_PROJECT_ID}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

Confirm if the execution was successful, list existing Attestations

gcloud container binauthz attestations list \
  --attestor-project=${ATTESTOR_PROJECT_ID} \
  --attestor=${ATTESTOR_NAME}

Expected result

---
attestation:
  serializedPayload: xxxxxxxxx
  signatures:
  - publicKeyId: //cloudkms.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/keyRings/image-keys/cryptoKeys/binary-auth-key/cryptoKeyVersions/1
    signature: MEUCIDdfSyE-2SNAXVxzh4FzfEtwgnBEFs9sY4BFAqH3fZLdAiEAmfk6Ov-TUGwyx2qWVQTIni_fYvWi-ye6ObmCVr6i4AU=
createTime: '2023-07-27T06:21:02.953969Z'
kind: ATTESTATION
name: projects/YOUR_PROJECT_ID/occurrences/32524935-0c65-4d7e-b9e6-2c7b1fceadcd
noteName: projects/YOUR_PROJECT_ID/notes/demo-attstor-note
resourceUri: asia-east1-docker.pkg.dev/YOUR_PROJECT_ID/allow-repo/nginx@sha256:YOUR_IMG_DIGEST
updateTime: '2023-07-27T06:21:02.953969Z'

Test Policy

The testing method is the same as Enable Binary Authorization on new CloudRun service, but this method mainly judges the sha value of the image. After testing, if two images are in different repos but have the same sha, they can still be deployed normally.

Delete attestation

List existing Attestations

gcloud container binauthz attestations list \
  --attestor-project=${ATTESTOR_PROJECT_ID} \
  --attestor=${ATTESTOR_NAME}

Copy the id after occurrences

---
...
kind: ATTESTATION
name: projects/YOUR_PROJECT_ID/occurrences/32524935-xxxx-xxxx-xxxx-2c7b1fceadcd
...

Enter the following command to delete

OCCURRENCE_ID="32524935-xxxx-xxxx-xxxx-2c7b1fceadcd"
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -X DELETE https://containeranalysis.googleapis.com/v1beta1/projects/${ATTESTATION_PROJECT_ID}/occurrences/${OCCURRENCE_ID}