Programmatic secret management
Looking at API reference - is there any way to programmatically add/update a service's secrets?
So far I've been able to update project envs with the API
9 Replies
it has a weird historical naming, but these should be the endpoints https://api.app-prg1.zerops.io/api/rest/public/swagger/#/PublicUserData
@Aleš thank you ! also - im reading docs about referencing env vars.
If i want to use a secret in my code, is it best to create an env variable that references the secret?
or do all my secrets automatically become available in process.env... ?
nvm figured it out
Hi @nicolas-angelo , secret variables are available the same as the ones from
zerops.yaml. The only difference is that you can edit them without changing zerops.yaml. So it is the ideal place for various external tokens and passwords.
It is probably safest to keep the secret variables on one stack and if you need them elsewhere, reference them via zerops.yaml.
That is, if you have a secret variable on service a
STRIPE_TOKEN
and you need its value in another service, I make it in zerops.yaml
MYTOKEN=$a_STRIPE_TOKEN
this explicit referencing will ensure that the token is not accidentally available in another service. This code can be stored in the repository and the value is added in zerops.
Otherwise, of course, the secret variable itself is available in the given service just like the variables from zerops.yaml.
It is also possible to set the service to see all variables across the project, which is controlled by envIsolation, per project.
https://docs.zerops.io/features/env-variables#environment-variable-isolationperfect thank you
would it also be fine to hoist a shared secret up to the project level? I'm assuming then I can access it by prefixing with PROJECT_<..>
All project variables are available in all services. If you do not override them with another value on the service level.
That's why it is not an ideal place for secret variables, because by default they will be visible everywhere.
I'm assuming then I can access it by prefixing with PROJECT_<..>Just an FYI, for now they also exist under
PROJECT_ prefix, but this is deprecated and will be removed, so I would not rely on this functionality.
As Jan said, project variables are automatically merged with service variables (if service already contains variable with same name, it's not overwritten), so my_env in project envs will be visible as my_env under any service.@Michal Saloň ahh cool. so to clarify, in the future, PROJECT_ prefixes will be deprecated...
but any variables created on a project level would function as "global" vars that automatically are accessible by all resources associated with that project, correct?
Yes, they already work that way, just the extra,
PROJECT_ prefixed, variables will disappear in the future.makes sense. thank you