Specify location on Secret Store for pushing secrets

[blasrodriguez]

Our company is using External Secrets to push secrets from Kubernetes to Google Secret Manager. However, the security team has implemented a GCP organization policy that restricts writing secrets to a global scope. Secrets must be stored in specific authorized zones. Unfortunately, when using PushSecret with External Secrets, it attempts to write the secret to Secret Manager at a global level. Due to the organization policy, this write operation fails, and the secret remains unsaved.

To address this issue, the ideal solution would be to allow specifying the target zone or region within the SecretStore configuration. This would enable PushSecret to write the secret to one of the authorized zones, complying with the security policy and successfully storing the secret.

[Skarlso]

Note, this would be something that we would add to the provider metadata section like here for AWS: https://external-secrets.io/latest/provider/aws-secrets-manager/#additional-metadata-for-pushsecret

The metadata secretPushFormat.

[blasrodriguez]

Yes, something like that would be great!

[Skarlso]

Can you provide information on how to define a region?

Is it just projects/*/locations/*/?

[Skarlso]

So something like projects/%s/locations/%s and after localization comes the region, right?

[blasrodriguez]

It's defined in replication config. Take a look at terraform resource for this kind of secrets:

resource "google_secret_manager_secret" "secret-basic" {
  secret_id = "secret"

  labels = {
    label = "my-label"
  }

  replication {
    user_managed {
      replicas {
        location = "us-central1"
      }
      replicas {
        location = "us-east1"
      }
    }
  }
}

[Skarlso]

@blasrodriguez quick question...

I was thinking about where to put this setting. And I was thinking it should maybe be on the store rather than on a per/push basis? Since if your whole store is location based, it would be a bit redundant to also define it on the push secret?

[blas-rodriguez-edo]

@Skarlso I totally agree with you. The store is the place.

We have another suggestion for pusing secrets not related to the location. Currently, if the secret exists and it's not managed by external secret it's impossible to replace the content. We have a use case that needs to change this behaviour, shall we open another issue?

[Skarlso]

What you are looking for is updatePolicy.

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: pushsecret-example # Customisable
  namespace: default # Same of the SecretStores
spec:
  updatePolicy: Replace # Policy to overwrite existing secrets in the provider on sync
 

But it's not implemented yet for all providers.

[blas-rodriguez-edo]

Great! We need it for GCP provider. Do we need to open an issue or it's already on the roadmap?

[Skarlso]

There is no real roadmap. Things are implemented on a need-to-have basis. Feel free to attempt it though. :) The maintainers are very thin spread with time.

[blas-rodriguez-edo]

I will, thank you very much for your time

[gusfcarvalho]

I was thinking about where to put this setting. And I was thinking it should maybe be on the store rather than on a per/push basis? Since if your whole store is location based, it would be a bit redundant to also define it on the push secret?

Just some valid context here 😄

When PushSecrets was designed, the idea was that each Provider configuration would indeed be a SecretStore configuration. Even if it caused to be more redundant (i.e. creating multiple stores to change 1 or 2 configs), as we thought we should keep the PushSecret the most provider agnostic as possible.

[MiguelMartinho]

I am doing some tests using external-secrets and bumped into the same issue. I agree that the Store should be the place to have this location config (possibly it will be needed for the replication-policy as well - https://cloud.google.com/secret-manager/docs/choosing-replication)

[Skarlso]

Okay, back on this. I'll do this either today, or tomorrow.

[Skarlso]

Would you mind testing out my pr? @blasrodriguez

[blasrodriguez]

@Skarlso I not sure how to test it. Building the docker image and deploying the helm chart is enough?

[Skarlso]

Actually, I think every PR builds and publishes it's own version. Let me check.

[Skarlso]

Should be ghcr.io/external-secrets/external-secrets:v0.9.18-18.ga241cf84 I believe.