dagger: Create secrets from a file without leaking into the cache

Problem

Dagger can create new secrets from the contents of an artifact or container (File { secret }). But the resulting secret is then leaked in the cache. For this reason, File { secret } is currently considered unsafe. The risk can be mitigated, for example by only using this method for secrets that carry an acceptable risk (ie not production credentials), rigorously scoping and rotating them, limiting cache sharing, etc. But unless you are confident that you know what you are doing, this method should not be used.

That is very inconvenient, because at the moment File { secret } is the only available method for creating secrets dynamically.

Solution

  1. Fix the implementation of File { secret }, such that it doesn’t leak secrets in the cache.

  2. Better document the fact that File { secret } is unsafe.

Design considerations

There is probably no easy fix for this. But we don’t know for sure, because we haven’t invested the effort to explore possible solutions.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 16 (16 by maintainers)

Most upvoted comments

It was potentially 😃 My biggest issue was about the security. Less about the API. Keeping the API while making it safe was a way to be good everywhere.

Talking with @vikram-dagger we had some confusion around the 3 way to set secret and how they map with the 2 way to inject secrets. With 1 way to set secret, there is no confusion anymore. It’s more lines of code for the user, but less confusing in the end. That’s good in my book. We’re good.

Just want to double check, is the use case you’re thinking of here where you use pulumi/terraform in a dagger exec and then want to get an output but that output includes a secret? And then there’s currently no to get an output from an exec that doesn’t involve writing it to a file? Or are there other use cases?

Yes. Pulumi supports --show-secrets on pulumi stack output and we can get secrets to stdout; but there’s no way to keep them secure, as documented with other issues.

Makes sense if so. One thing I’m wondering about is if in this use case you ever actually want those sorts of outputs to be cached in the first place. I certainly get there’s a lot of areas where dagger’s caching can benefit execution of pulumi/terraform/etc. but specifically in the step where you retrieve outputs from a stack is there much downside to just always running the command that retrieves the outputs rather than caching it?

I don’t think we do want these cached, though I do need dependent layers to run when the secret has changed.

Perhaps Dagger could provide a directory, like /nocache/ that could be suggested and encouraged for ephemeral secret collection? It could be purged after each session.

^ I was also thinking about this as a quick solution. Having a special ephemeral dir inside each container and raise a warning if you’re trying to create a secret outside that dir that will leak into the cache.