Support passing Apollo Key/GraphRef via Config File

[lleadbet]

Is your feature request related to a problem? Please describe.

The router currently requires that I pass an APOLLO_KEY and APOLLO_GRAPH_REF environment variable to start, however in some situations I would like to pass it as a static value within a configuration or another environment variable name, or as passing from a file's contents. Currently this isn't supported, however.

The YAML implementation supports both passing values by environment variable and passing file contents directly, which would address my concerns.

Describe the solution you'd like

A new configuration option to pass the APOLLO_KEY/GRAPH_REF, such as:

supergraph:
  apollo_key: 1234
  apollo_graph_ref: my-supergraph@prod

Which would default to:

supergraph:
  apollo_key: ${env.APOLLO_KEY}
  apollo_graph_ref: ${env.APOLLO_GRAPH_REF}

To make it a non-breaking change.

Describe alternatives you've considered

• Using the existing environment variables and populating them via a prelaunch script (e.g. sourcing a .env file)

Additional context

While this feature would be relatively uncommon, it would be helpful for some organizations.

[abernix]

One of the reasons we consciously imposed this limitation initially was to actively prevent folks from checking in static secrets, particularly since we think the configuration files themselves might at some point live in GraphOS.

I'm very sympathetic to supporting reading from a file. Also very sympathetic to reading from another environment variable, though the "defaulting" pattern ${var-:default} (or whatever it is, I can't remember at the moment 😭 ), makes it still possible that someone could leverage that to put a secret in-line.

I know you're literally asking for static values to be in the file, but ... what if we just didn't do that and just started with supporting reading a value from an external file? 😆

[lleadbet]

Supporting a file could be nice as a stopgap, however agree re: inline secrets.

[smyrick]

If we could support loading a .env file that would also help: https://crates.io/crates/dotenv

[smyrick]

Updating here as another customer is asking for this support. They have an environment that has strict requirements and nothing can be saved as a env var so everything must be read from file, not even temporarily doing a cat into the env var at boot up time. They can manage all the other secrets but right now the APOLLO_KEY is one secret that does not even have the ability to be read from file.

If we added support to set the key in the config we could use variaible expansion ${file.apollo-key.txt}, but I agree to Jesse's point, to maybe defer anyone from even accidentally saving the raw value into the file we bypass that and just add another way to load the Apollo key is from a file and the Router does that for you

[lleadbet]

I'm very sympathetic to supporting reading from a file. Also very sympathetic to reading from another environment variable, though the "defaulting" pattern ${var-:default} (or whatever it is, I can't remember at the moment 😭 ), makes it still possible that someone could leverage that to put a secret in-line.

I would also like to add that we have plenty of other places this can happen- OTLP setup is a great example.

I agree we should probably try to avoid footguns, but there's a point where we can only prevent so much for the user without affecting the UX.

[gbarsky]

Hello. I am wondering what is the status of this issue? I am also interested to know if there is a support to provide these variables within config file as static values rather than env variables. Please advise

[smyrick]

This request can slightly be updated to only load the graph ref from file as loading the key is a supported feature via APOLLO_KEY_PATH: https://www.apollographql.com/docs/graphos/routing/configuration/envvars#apollo_key_path