mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
f
This commit is contained in:
@@ -82,6 +82,20 @@ gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_
|
|||||||
- **Delete the KMS key**
|
- **Delete the KMS key**
|
||||||
- Now only the attacker, who has the original key material could be able to decrypt the encrypted data
|
- 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:
|
#### Here are the steps to import a new version and disable/delete the older data:
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@@ -317,4 +331,3 @@ gcloud kms keys versions enable <VERSION_ID> \
|
|||||||
{{#include ../../../banners/hacktricks-training.md}}
|
{{#include ../../../banners/hacktricks-training.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**.
|
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
|
### Enumeration
|
||||||
|
|
||||||
Having **permissions to list the keys** this is how you can access them:
|
Having **permissions to list the keys** this is how you can access them:
|
||||||
|
|||||||
Reference in New Issue
Block a user