Is your feature request related to a problem?

Our use case is that we have a central service app, let's call it Core, that other web apps interact with for various core services. To secure this communication, we currently generate an API key that Core and the calling web app both need. Beyond app-specific API keys, there's other secrets that are common to all web apps that use Core.

The Core team wants to own these app-specific API keys and common secrets, revoking them if they want. The calling web apps only get read only access.

Ideally, we would store this secret in one location in Phase. I am struggling to figure out how to implement this.

To handle the app-specific API keys, I am thinking of creating many environments in the "Core" App. Each environment would be tied to some calling web app (Frontend-Prod, Backend-Staging, etc). I believe it's currently possible to create service accounts/tokens such that the Core team owns their App and all environments, and external teams can get access to their specific environment in the Core app. There's some concerns here on access control that my other Issue would address. But at least it's possible.

To handle the common secrets, I was hoping to pull off something where in each App-specific environment within the Core app, I could use the Secret Reference syntax to refer to the common secret at the root.

For example, I create a secret like this. This says I want dev, staging, and prod to have different secrets, but the QA enviroment should reuse the dev secret. Note that people with access to the QA environment don't have access to the Development environment.

I then define a Service Account that has access to this App and to the Staging and QA environments. I then try to export the value:

phase secrets export --app example-app  --env qa SECRET_COOKIE_SIGNATURE_KEY
SECRET_COOKIE_SIGNATURE_KEY="${development.SECRET_COOKIE_SIGNATURE_KEY}"

If I change the Secret Reference to use staging instead (one of the Environments I gave access to), then the value is exported:

phase secrets export --app example-app  --env qa SECRET_COOKIE_SIGNATURE_KEY
SECRET_COOKIE_SIGNATURE_KEY="staging-cookie"

Describe the solution you'd like

I don't know what the correct answer is. It makes sense the account can't read secrets from an environment it doesn't have access to, even if that's enforced during Secret Referencing. But then I have no idea how to implement our use cases in Phase.

So this is a feature request to allow this behavior but if there's another way to solve this use case, I am open to it.

What do you think?

Describe alternatives you've considered

Duplicating the secrets in various locations in Phase, then writing my own custom glue logic so that our maintenance of the secrets is in one place. When I go to manage the lifecycle of this secret, I would make requests to my custom app that then updates it in all the various places in Phase. Obviously, this isn't ideal.