Understanding regional secret manager

[rseng]

Hi all,

this is my first question here, happy to be part of this community 🙂

NOTE: it seems like there is no specific board for asking secret manager questions, so I just chose this one

I am trying to understand what "regional" actually means when it comes to  regional secrets in secret manager. In theory it's simple, instead of creating global secrets, I can specify in which region I want to create a secret and it's only accessible via the regional secret manager API endpoint.

The documentation states that the secrets will reside in this location at-rest, in-use and in-transit. This makes sense and is useful in case you have legal/compliance requirements.

However, I can still access regional secrets from all locations around the world. If I create a secret in let's say europe-west4, I can:

- still access it from my local machine via gcloud/REST etc.
- access it from workloads running in different regions (e.g. from a VM in europe-west1)

I would have expected (reading the docs) that if I use regional secrets, I can only access it from workloads running in the exact same location. Otherwise it's not true that the secret data never leaves the location in which the secret was created.

Am I missing something here or am I misunderstanding what regional secrets actually mean ? Happy to gain more insights 🙂

[jamespatrickm · Accepted solution]

Hi @rseng,

Welcome to Google Cloud Community!

Regional secrets can only be accessed by applications or services running within the same location. Also please take note of the Regional endpoint availability for Europe. Europe-west1 and europe-west4 are not available for storing Secret Manager resources. 

To learn more about how Regional Secrets works please see:

• Enforce data residency using regional secrets
• Regional endpoints for Secret Manager

Was this helpful? If so, please accept this answer as “Solution”. If you need additional assistance, reply here within 2 business days and I’ll be happy to help.

[trondhjem]

 @jamespatrickm  statement that regional secrets can only be accessed from within the same location seems to contradict @rseng finding that they can be accessed from elsewhere too.

@jamespatrickm as I also verified that I can make a CURL to the API endpoint from a VM in  another location and still access the secret even if it's not stored in the same location as the VM, can you please clarify your statement?

Thanks!