Ensure Secrets are not stored in Cloud Functions environment variables by using Secret Manager

From Google Cloud Console

To enable Secret Manager API for your Project

1. Within the project you wish to enable, navigate to APIs & Services , then select Enabled APIs & Services in the menu that opens up
2. Click the button + Enable APIS and Services
3. In the Search bar, search for Secret Manager API and select it
4. Click the blue box that says Enable

Reviewing environment variables that should be migrated to Secret Manager

1. Go to Cloud Functions
2. Click on a function name from the list
3. Click on EDIT and look under Runtime environment variables for variables that should be secrets. Leave this list open for the next step

Migrating environment variables to Secrets within the Secret Manager

1. Go to the Secret Manager page
2. On the Secret Manager page, click Create Secret
3. On the Create secret page, under Name, enter the name of the Environment Variable you are replacing. This will then be the Secret Variable you will reference in your code.
4. You will also need to add a version. This is the actual value of the variable that will be referenced from the code. To add a secret version when creating the initial secret, in the Secret value field, enter the value from the Environment Variable you are replacing
5. Leave the Regions section unchanged
6. Click the Create secret button
7. Repeat for all Environment Variables

Granting your runtime's Service Account access to Secrets

1. Navigate to Secret Manager with an account that has the roles/secretmanager.secretAccessor permission
2. Click the name of a secret listed in this screen
3. If it is not already open, click Show Info Panel in this screen to open the panel
4. In the info panel, click Add principal
5. In the New principals field, enter the service account your function uses for its identity. (If you need help locating or updating your runtime's service account, please see the 'docs/securing/function-identity#runtime_service_account' reference.)
6. In the Select a role dropdown, choose Secret Manager and then Secret Manager Secret Accessor

Modify your code to use the Secrets in Secret Manager

Please see the '/docs/creating-and-accessing-secrets#access' reference for language specific instructions

Deleting the insecure Environment Variables

1. Navigate to Secret Manager under Security
2. Click the name of a function. Click EDIT
3. Click Runtime, build and connections settings to expand the advanced configuration options
4. Click Security. Hover over the secret you want to remove, then click Delete
5. Click Next. Click Deploy. The latest version of the runtime will now reference the secrets in Secret Manager

Using Google Cloud CLI

To enable Secret Manager API for your Project

Within the project you wish to enable the API in, run the following command:

gcloud services enable secretmanager.googleapis.com

Reviewing environment variables that should be migrated to Secret Manager

1. To view a list of your cloud functions run the following command:

gcloud functions list

1. For each cloud function run the following command:

gcloud functions describe <functionName>

1. Review the settings of the buildEnvironmentVariables and environmentVariables. Keep this information for the next step

Migrating environment variables to Secrets within the Secret Manager

1. Run the following command with the Environment Variable name you are replacing in the <secretID>. It is most secure to point this command to a file with the Environment Variable value located in it, as if you entered it via command line it would show up in your shell's command history

gcloud secrets create <secretID> --data-file="/path/to/file.txt"

Granting your runtime's Service Account access to Secrets

As of the time of writing, using Google CLI to list Runtime variables is only in beta

Modify your code to use the Secrets in Secret Manager

Please see the '/docs/creating-and-accessing-secrets#access' reference for language specific instructions

Deleting the insecure Environment Variables

gcloud functions deploy <functionName> --remove-env-vars <envVars>

If you need to find the environment variables to remove, you can find them in the output of the command gcloud functions describe <functionName>

Default value

By default, Secret Manager is not enabled.

References

1. https://cloud.google.com/functions/docs/configuring/env-var#managing_secrets
2. https://cloud.google.com/secret-manager/docs/overview

Additional information

There are slight additional costs to using the Secret Manager API. Review the documentation to determine your organizations' needs.

Multiple Remediation Paths

Google Cloud

SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.

gcloud org-policies set-policy policy.yaml

ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.

PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.

References for Service-Wide Patterns

• GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
• GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
• gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

• Google Cloud: apply organization policy constraints at org/folder scope.

gcloud org-policies set-policy policy.yaml

2. Remediate Existing Affected Assets

• Execute the control-specific Console/CLI steps documented above for each flagged resource.
• Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

• Re-scan after each remediation batch.
• Track exceptions with owner and expiry date.
• Add preventive checks in IaC/CI pipelines.