Execution environment security

Every function runs on top of a versioned runtime image within the Cloud Run functions secure execution environment. Runtime images contain operating system libraries, language runtimes and other system packages. Google maintains all Cloud Run functions runtime images, releasing security patches and maintenance updates after a period of stability testing.

Runtime images

Each runtime has an associated runtime image (also known as a run image) in a public repository on Artifact Registry. For a of list runtime IDs and their runtime images, see runtimes.

Identify your runtime image

You can identify the runtime image used to create your function by inspecting the build logs for your function.

Within the build logs, search for google.run-image. This gives you the log entry from the build step that describes the version of the runtime image used to build your function. For example, a log entry for a Nodejs function might look like this:

{
  ...
  "textPayload": "Step #2 - \"build\": Adding image label google.run-image:
    us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22:nodejs20_20230924_20_6_1_RC00",
  ...
}

Security update policy

You can choose one of the following security update policies:

  • Automatic updates (default): Updates and security patches to the runtime environment are published in new versions of the runtime image. After a period of testing for stability and reliability, the updated runtime is rolled out to all functions resulting in a zero downtime update. Automatic security updates are available with Cloud Run functions (1st gen) and Cloud Run functions. To take on language-level security fixes, you may need to rebuild functions that use compiled languages such as Go or Java.

  • On deployment updates: Updates and security patches are applied to runtimes only when functions are deployed or redeployed, unless otherwise noted. Updates on deployment are available on both Cloud Run functions (1st gen) and Cloud Run functions.

The runtime update policy can be changed using the --runtime-update-policy flag in your gcloud deploy command.

Set your function's update policy

You can change your function's update policy by including the --runtime-update-policy flag in your gcloud deploy command as shown here:

  gcloud functions deploy FUNCTION_NAME \
    --runtime-update-policy=POLICY ...

Replace:

  • FUNCTION_NAME with the name of your function
  • POLICY with automatic or on-deploy

The default policy for all functions is automatic.

Inspect your function's update policy

You can inspect your function's update policy with the following command:

  gcloud functions describe FUNCTION_NAME \

Where FUNCTION_NAME is the name of your function

  • Functions with automatic security updates enabled will have the key automaticUpdatePolicy
  • Functions that update on deployment will have the key onDeployUpdatePolicy

Identify the runtime image used after an automatic update

When you enable automatic updates, Cloud Run functions swaps your function's runtime image with a newer revision containing additional security patches and updates. This change appears in your function's runtime logs.

Inside the runtime logs the runtime_version label tells you when a new runtime image is being used on your function. A log entry for a Nodejs function that has been automatically updated might look like this:

{
  ...
  "labels:" {
    runtime_version: nodejs20_20230924_20_6_1_RC00
    execution_id: ...
  }
  ...
}

Security scans on Cloud Run functions

Cloud Run functions that have automatic updates enabled are built on top of a scratch image. As a result, the container that represents your function in Artifact Registry won't have a base image and will be considerably smaller than functions using on-deployment updates. The base image is combined with the function image at run time to create a complete function.

You can use security scanners to monitor the Google-managed base images that power your function. You can find the latest base image for your function at REGION-docker.pkg.dev/serverless-runtimes/STACK/runtimes/RUNTIME_ID

Replace:

  • REGION with the preferred region, for example us-central1
  • STACK with the preferred operating system stack, for example google-22-full
  • RUNTIME_ID with the runtime ID used by your function, for example python310

For example, the latest Node.js 20 base image using the google-22-full stack, hosted in us-central1 would be referenced with this URL: us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22

Because your image is now built on top of scratch, the image stored in Artifact Registry won't be directly runnable. If you need a runnable image, use the on-deploy policy.