Skip to content

Open to offersGoiânia, Brazil or remote

jnogxavier
Back to the Cases

Where the secrets actually live

Configuration and secrets

What should have happened

For each service you can answer which variables it receives, where each value comes from and who can see it.

What actually happened

A service's configuration was spread across three places, variables in the service definition, secrets in a secrets manager and parameters in a parameter store, and none of them showed the other two. Answering “what does this service receive in production” meant opening three consoles and putting it together in your head.

What I did

A single view that reads all three at once through the API and presents them by service, with automatic masking of what is sensitive and a filter by type. The read uses the instance's own identity instead of an access key.

Three placesservice definitionenvironment variablessecrets managersecretsparameter storeparametersread through the API, read-onlysingle viewone screen, per serviceDATABASE_URL••••••••LOG_LEVELinfoAPI_TOKEN••••••••
Masking is what makes the screen usable: you can audit production configuration without the secret value showing up for whoever is investigating.

What This Unlocked

  • Auditing stopped depending on someone with access to three consoles and the patience to cross-check by hand.
  • Masking made it possible to look at production configuration without exposing a secret value on the screen of whoever is investigating.

What I Would Do Differently

If the read comes before the authentication, the tool ends up seeing the configuration of a whole account behind nothing but network access. That is the wrong order: a governance tool without access control is one more surface to govern. Today I would start with login and roles, even if the first release showed less.