I am confused by the secrets API:
- I can create or modify a secret with
setSecret - I can lookup a secret by ID with
secret - But I can't lookup a secret by name? In other words, no
getSecret? Is this an oversight? If not, why?
#No GetSecret() ?
blissful yacht
near patio
probably @red urchin and/or @magic fern have context about this. I recall Tanguy during a some work on this interface.
magic fern
Don't remember it being a conscious choice but I think most API dicussions around it happened before me. Seems like it would be trivial to add.
blissful yacht
Yeah I was heavily involved in the underlying design, just not the last mile of bikeshedding actual field names etc
Certainly there's no reason to have it in the underlying design. Unless a security consideration appeared in the last mile
red urchin
I think there was just a single focus and limited scope (to improve later) at the time to make secrets safer. Adding the setSecret was enough to deprecate the old methods. A GetSecret was actually added in core as well and is used by the API (by Secret.plaintext), just not directly exposed.
A Query.getSecret hasn’t been necessary for most users that have all their pipeline in the same process, i.e., they set a secret instance and pass it around in code. Even using different client sessions with dagger query users have been saving the SecretID and passing that to the next query. I don’t remember anyone requesting to get a secret by name.
There's more need for it now in current Zenith since modules run in different processes, but even if not it's trivial to add (just needs to be exposed) and makes the API more complete so 👍 for adding it now.
blissful yacht
I think there was just a single focus and limited scope (to improve later) at th...
Thanks for the context. I'm just wondering if it's safe to allow a module to get the value of a secret set by its caller? In theory wouldn't that allow a module to access secrets it's not meant to access, by guessing secret keys?
red urchin
Yes, that's on my mind. I'm wondering the same thing.
Feels safer for a module to return a Secret and another to receive it in input. I'm trying to think of cases where you can't pass the SecretID around.
I also can't think of a case where you use a module (as a dependency) that sets a secret and you shouldn't have access to it (by name).