From 9e39e77d6e8c7a8bc9ebc0d7ac0354709ec81b42 Mon Sep 17 00:00:00 2001 From: Carlos Polop Date: Wed, 4 Mar 2026 12:21:21 +0100 Subject: [PATCH] f --- .../gcp-kms-post-exploitation.md | 15 ++++++++++++++- .../gcp-security/gcp-services/gcp-kms-enum.md | 13 +++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md index 8cfa1adeb..48f63cf16 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md @@ -82,6 +82,20 @@ gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_ - **Delete the KMS key** - Now only the attacker, who has the original key material could be able to decrypt the encrypted data +#### Cloud Storage + CMEK permission model + +When objects in Cloud Storage are encrypted with CMEK, the decrypt/encrypt calls to KMS are done by the project's **Cloud Storage service agent whose email is service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com)**, not directly by the end user reading the object. + +This means that to read something encrypted by a CMEK: + +- The project's cloud storage service agent must have KMS permissions over the used KMS key (typically `roles/cloudkms.cryptoKeyEncrypterDecrypter`). +- The user only needs object read permissions (for example `storage.objects.get`). He doesn't need permissions over the KMS key. + +Thsi means that to control acces to encrypted data with the KMS key it's needed to add/rmeove KMS permissions to the projects cloud storage service agent. + +Note that there is a project-level binding like `roles/cloudkms.cryptoKeyEncrypterDecrypter` for the Storage service agent will still allow decrypt with the keys in the same project. + + #### Here are the steps to import a new version and disable/delete the older data:
@@ -317,4 +331,3 @@ gcloud kms keys versions enable \ {{#include ../../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum.md b/src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum.md index 7e5bad13f..172edf266 100644 --- a/src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum.md +++ b/src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum.md @@ -35,6 +35,19 @@ The "Programmed for destruction" period is the **time since the user ask for del Each KMS key can have several versions, one of them must be the **default** one, this will be the one used when a **version is not specified when interacting with the KMs key**. +### CMEK permission model + +When objects in Cloud Storage are encrypted with CMEK, the decrypt/encrypt calls to KMS are done by the project's **Cloud Storage service agent whose email is service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com)**, not directly by the end user reading the object. + +This means that to read something encrypted by a CMEK: + +- The project's cloud storage service agent must have KMS permissions over the used KMS key (typically `roles/cloudkms.cryptoKeyEncrypterDecrypter`). +- The user only needs object read permissions (for example `storage.objects.get`). He doesn't need permissions over the KMS key. + +Thsi means that to control acces to encrypted data with the KMS key it's needed to add/rmeove KMS permissions to the projects cloud storage service agent. + +Note that there is a project-level binding like `roles/cloudkms.cryptoKeyEncrypterDecrypter` for the Storage service agent will still allow decrypt with the keys in the same project. + ### Enumeration Having **permissions to list the keys** this is how you can access them: