carmine bison
Hi there! Does Dagger support running code to read files from your local machine, outside of a container? It would be nice if I could use a Function from a Git repository that handled fetching my AWS credentials, but did so by running a command on my local machine.
I know there's a security risk here - I'm coming from Earthly's LOCALLY argument, which offers a --privileged flag to allow remote functions to execute LOCALLY targets. Does Dagger have anything similar?
dawn needle
Hey!
There is no directly equivalent of LOCALLY at the moment, but for your specific use case I think there is a solution using Host Secret Provider
https://docs.dagger.io/api/arguments#host-secret-providers
This allows secrets to be passed as env var, file, and the result of a command (this is close to locally)
Do you think this would work for you?
carmine bison
I mean, it would work, but this is the same issue Earthly ran into. My solution with Earthly was itself a workaround for the fact that secrets had to be passed in from the top level...
So if I knew within an earthly target I wanted to run a job in a specific local AWS target, it would've been great to do something like:
target:
FROM +aws-creds --profile="abcdef"
and that does work if +aws-creds is itself a LOCALLY target, but in any other circumstance it does not. (this code is actually simplified significantly)
The alternative would be for me to pass the information to Earthly or Dagger via the "secrets" support built in, but that requires me to now memorize a command line option like
dagger -c 'github-api cmd://"gh auth token"'
(from your example above)
what would be great would be to do something like
token: dagger.Secret = dagger.secret_cmd("gh auth token")
or something...
though I understand the difficulty of figuring out how that fits into the security model 😁
carmine bison
the core ask here I think is a way to specify the path to the secret (or cmd, or whatever) in the actual "privileged" top-level module code rather than just on the command line... is that possible?
dawn needle
Ah I see, thanks for walking me through that!
If I understand correctly the thing we actually need here is some way to define a "default secret", is that correct?
If so, no this is not possible today but is frequently requested and something we do want to build. This is the kind of thing that leads to folks building a wrapper around dagger which is something we want to avoid.
carmine bison
I guess "default secret" is the right term, if by that you mean a default definition like env://, file://, or cmd:// rather than a "default secret value"
I know it's a balance betweeen flexibility and security, but solving this problem with a "default secret" is one of the less flexible options... if I'm using a cmd:// then it's likely that I have some more complex logic for generating the secret... why not have that logic be a dagger function?
If I wanted to generate e.g. a self-signed SSL certificate that had a service name that was itself derived from a previous dagger function, how would I accomplish something like that with this "default secret" approach?
If I was to rank different approaches from least to most flexible, I'd say the ranking is something like:
dawn needle
This is phenomenal feedback, thanks for taking the time to walk through your thinking.
I think the pre-req for things like #3 and #4 are default secrets
There's an existing design discussion happening here on this topic: https://github.com/dagger/dagger/discussions/10401
