f

Author: carlospolop

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:
 
 <details>
@@ -317,4 +331,3 @@ gcloud kms keys versions enable <VERSION_ID> \
 {{#include ../../../banners/hacktricks-training.md}}
 
 
-

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: