Protecting functions and data

Exam guide§2.1

You protect a Cloud Run function's data at rest with customer-managed encryption keys (CMEK) created in Cloud KMS. The keys are owned by you, not controlled by Google, and can be held as software keys, in an HSM cluster, or externally. Deploying a function with a CMEK encrypts its data with a key only you can access.

For the general CMEK vs CSEK vs Google-managed-key distinction and Cloud KMS basics, see Encryption & CMEK. This page is the Cloud Run functions-specific setup.

≡FactsWhat a CMEK encrypts on a function

• Function source code uploaded for deployment and stored by Google in Cloud Storage, used in the build process.
• The build results: the container image built from your source code, and each deployed instance of the function.
• The data at rest for internal event transport channels.

⚠GotchaDisabling or destroying the key locks out everyone

If the key is disabled or destroyed, no one - including you - can access the data it protects. This is the point of CMEK, and the operational risk.

Setting up CMEK for a function

#NumbersFour steps, in order

1. Create a single-region encryption key.
2. Create an Artifact Registry repository with CMEK enabled, to store your function images. Use the same key for the repository as the one you enable CMEK with on the function.
3. Grant the Cloud Run functions, Artifact Registry, and Cloud Storage service accounts access to the key.
4. Enable CMEK on the function by deploying it with the key and repository.

Granting access to the key

To use a CMEK, each involved service must act as your key. Add each service agent as a principal of the key and grant it the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter).

≡FactsThe three service agents that need the key

• Cloud Run Functions Service Agent
• Artifact Registry Service Agent
• Cloud Storage Service Agent

CommandsGrant a service agent access to the key

gcloud kms keys add-iam-policy-binding KEY \

--keyring KEY_RING \

--location LOCATION \

--member serviceAccount:SERVICE_AGENT_EMAIL \

--role roles/cloudkms.cryptoKeyEncrypterDecrypter

Enabling CMEK on the function

After the Artifact Registry repository is CMEK-enabled and the service agents have access, enable CMEK by deploying the function with the key and repository (via the Google Cloud console or gcloud).

CommandsDeploy with CMEK

gcloud functions deploy FUNCTION \

--kms-key KEY \

--docker-repository=REPOSITORY

⚠GotchaCMEK uses the primary key version - you can't pin one

Cloud Run functions always uses the primary version of the key for CMEK protection. You cannot specify a particular key version when enabling CMEK on a function.

A CMEK use case: objects in Cloud Storage

CMEKs apply to individual objects in Cloud Storage, or you can configure a bucket default key so every new object is encrypted with it. A function then reacts to those objects through Eventarc and reads them back decrypted. (To use a CMEK on a bucket, the Cloud Storage service agent needs the CryptoKey Encrypter/Decrypter role, same as above.)

An object uploaded to a CMEK-enabled Cloud Storage bucket fires an Eventarc event on create/finalize, which invokes the configured Cloud Run function; the function then reads the object back from the bucket, transparently decrypted with the same key.

You can also run it the other way: implement a function that encrypts individual objects and uploads them to Cloud Storage.

When a key is destroyed or disabled

If the key is destroyed or disabled, or its required permissions are revoked, running work is left alone but new work fails.

≡FactsEffect on function executions

• Active instances of functions protected by the key are not shut down.
• Executions already in progress continue to run.
• New executions fail as long as Cloud Run functions has no access to the key.
• Executions that require new function instances fail.