A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://cloud.google.com/functions/docs/configuring/secrets below:

Configure secrets for services | Cloud Run Documentation

Skip to main content Configure secrets for services

Stay organized with collections Save and categorize content based on your preferences.

Your service might need to have dependencies requiring API keys, passwords, certificates, or other sensitive information. For Cloud Run, Google recommends that you store this type of sensitive information in a secret created in Secret Manager.

You can make a secret available to your containers in either of two ways:

For more information, refer to the Secret Manager best practices document.

How secrets are checked at deployment and runtime

During service deployment, all secrets used, whether as environment variable or mounted as a volume, are checked to ensure the service account used to run the container has access to them. If any check fails, the service deployment fails.

During runtime, when instances start up:

Volume ownership differs by execution environment and deployment type

When you mount a secret volume, the identity owning the files and directories differs depending on the workload's execution environment and on whether the deployment consists of one or multiple containers.

In the first generation execution environment where you are deploying a single container, the secret volume is owned by the identity used for the container. In all other cases, the volume is owned by root. This includes:

Before you begin

  1. Enable the Secret Manager API.

    Enable the API

  2. Use an existing secret or, create a secret in Secret Manager, as described in Create a secret.
Required roles

To get the permissions that you need to configure secrets, ask your administrator to grant you the following IAM roles:

To allow Cloud Run to access the secret, the service identity must have the following role:

For instructions on how to add the service identity principal to the Secret Manager Secret Accessor role, see Manage access to secrets.

For a list of IAM roles and permissions that are associated with Cloud Run, see Cloud Run IAM roles and Cloud Run IAM permissions. If your Cloud Run service interfaces with Google Cloud APIs, such as Cloud Client Libraries, see the service identity configuration guide. For more information about granting roles, see deployment permissions and manage access.

Make a secret accessible to Cloud Run

Any configuration change leads to the creation of a new revision. Subsequent revisions will also automatically get this configuration setting unless you make explicit updates to change it.

You can make a secret accessible to your service using the Google Cloud console, the Google Cloud CLI, or a YAML file when you deploy a new service or update an existing service, and deploy a revision. Click the tab of your choice:

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. Select Services from the menu, and click Deploy container to configure a new service. Fill out the initial service settings page, then click Container(s), Volumes, Networking, Security to expand the service configuration page.

  3. If you are configuring an existing service, click the service, and click Edit and deploy new revision.

  4. Follow the steps to mount the secret as a volume, or expose the secret as an environment variable.

gcloud

To make a secret accessible to your service, enter one of the following commands.

YAML

  1. If you are creating a new service, skip this step. If you are updating an existing service, download its YAML configuration:

    gcloud run services describe SERVICE --format export > service.yaml

  2. For secrets exposed as environment variables, under env, update the ENV_VAR, VERSION, and/or SECRET_NAME as desired. If you have multiple secrets mounted as environment variables, you will have multiples of these attributes.

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      name: REVISION
    spec:
      containers:
      - image: IMAGE_URL
        env:
        - name: ENV_VAR
          valueFrom:
            secretKeyRef:
              key: VERSION
              name: SECRET_NAME

  3. For secrets mounted as file paths, update the MOUNT_PATH, VOLUME_NAME, VERSION, FILENAME, and/or SECRET_NAME as desired. If you have multiple secrets mounted as file paths, you will have multiples of these attributes.

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      name: REVISION
    spec:
      containers:
      - image: IMAGE_URL
        volumeMounts:
        - mountPath: MOUNT_PATH
          name: VOLUME_NAME
      volumes:
      - name: VOLUME_NAME
        secret:
          items:
          - key: VERSION
            path: FILENAME
          secretName: SECRET_NAME

    Note that VOLUME_NAME can be set to any name.

    Replace the following:

  4. Replace the service with its new configuration using the following command:

    gcloud run services replace service.yaml
Terraform

  1. Create a secret and a secret version.

  2. Create a service account and grant it access to the secret:

  3. Secret Manager secrets can be accessed from Cloud Run as mounted file paths or as environment variables.

    1. For secrets mounted as file paths, reference the Secret Manager resource in the volumes parameter. The name corresponds with an entry in the volume_mounts parameter:

    2. For secrets exposed as environment variables, reference the Secret Manager resource in the env parameter:

Reference secrets from other projects

To reference a secret from another project, verify that your project's service account has access to the secret.

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. Select Services from the menu, and click Deploy container to configure a new service. Fill out the initial service settings page, then click Container(s), Volumes, Networking, Security to expand the service configuration page.

  3. If you are configuring an existing service, click the service, and click Edit and deploy new revision.

  4. Follow the steps to mount the secret as a volume, or expose the secret as an environment variable.

gcloud YAML

  1. If you are creating a new service, skip this step. If you are updating an existing service, download its YAML configuration:

    gcloud run services describe SERVICE --format export > service.yaml

Due to constraints around API compatibility, the secret locations must be stored in an annotation.

  1. For secrets exposed as environment variables:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/secrets: SECRET_LOOKUP_NAME:projects/PROJECT_NUMBER/secrets/SECRET_NAME
    spec:
      containers:
      - image: IMAGE_URL
        env:
        - name: ENV_VAR
          valueFrom:
            secretKeyRef:
              key: VERSION
              name: SECRET_LOOKUP_NAME

    Replace the following:

  2. For secrets mounted as file paths:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/secrets: SECRET_LOOKUP_NAME:projects/PROJECT_NUMBER/secrets/SECRET_NAME
    spec:
      containers:
      - image: IMAGE_URL
        volumeMounts:
        - mountPath: MOUNT_PATH
          name: VOLUME_NAME
      volumes:
      - name: VOLUME_NAME
        secret:
          items:
          - key: VERSION
            path: FILENAME
          secretName: SECRET_LOOKUP_NAME

    Replace the following:

Terraform

To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.

Add the following to a google_cloud_run_v2_service resource in your Terraform configuration:

For secrets exposed as environment variables:

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE_NAME"
  location = "REGION"

  template {
    containers {
      image = "IMAGE_URL"
      env {
        name = "SECRET_NAME"
        value_source {
          secret_key_ref {
            secret = "projects/PROJECT_ID/secrets/SECRET_NAME"
            version = "VERSION"
          }
        }
      }
    }
  }
}

Replace the following:

For secrets mounted as file paths:

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE_NAME"
  location = "REGION"

  template {
    containers {
      image = "IMAGE_URL"

      volume_mounts {
        name       = "VOLUME_NAME"
        mount_path = "MOUNT_PATH"
      }
    }

    volumes {
      name = "VOLUME_NAME"
      secret {
        secret = "projects/PROJECT_ID/secrets/SECRET_NAME"
      }
    }
  }
}

Replace the following:

View secrets settings

To view the current secrets settings for your Cloud Run service:

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. Click the service you are interested in to open the Service details page.

  3. Click the Revisions tab.

  4. In the details panel at the right, the secrets setting is listed under the Container tab.

gcloud

  1. Use the following command:

    gcloud run services describe SERVICE

  2. Locate the secrets setting in the returned configuration.

Remove secrets from a service

You can remove secrets from a service using either the Google Cloud console or the gcloud CLI:

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. Select your service from the list, and click Edit and deploy new revision.

  3. Click the Container(s) tab.

  4. To delete secrets mounted as a volume, select the Volume mounts tab, and hold the pointer over the secret you want to remove, then click delete Delete.

  5. To delete secrets exposed as an environment variable, select the Variables and secrets tab, and hold the pointer over the secret you want to remove, then click delete Delete.

  6. Click Deploy.

gcloud

You can remove all secrets from a service or specify one or more secrets to remove:

Use secrets in your code

For examples on accessing secrets in your code as environment variables, refer to the tutorial on end user authentication, particularly the section Handling sensitive configuration with Secret Manager.

Disallowed paths and limitations

Cloud Run does not allow you to mount secrets at /dev, /proc and /sys, or on their subdirectories.

If you are mounting secrets on /tmp and you are using first generation execution environment, refer to the known issue on mounting secrets on /tmp.

Cloud Run does not allow you to mount multiple secrets at the same path because two volume mounts cannot be mounted at the same location.

Overriding a directory

If the secret is mounted as a volume in Cloud Run, and the last directory in the volume mount path already exists, then any files or folders in the existing directory become inaccessible.

For example, if a secret called my-secret is mounted to path /etc/app_data, all the contents inside the app_data directory will be overwritten, and the only visible file is /etc/app_data/my-secret.

To avoid overwriting files in an existing directory, create a new directory for mounting the secret, for example, /etc/app_data/secrets, so that the mount path for the secret is /etc/app_data/secrets/my-secret.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4