Replies: 1 comment
-
Dagger currently supports a secure implementation for secrets but we are working on a new interface for all inputs. As for packages being an attack vector imagine if I write a series of components that claim to do something, and perhaps they actually do, but they also siphon arbitrary (potentially sensitive files) from your Dagger host and send them back to me without you realizing. I could write a component that connects to your local docker daemon and uses it to launch crypto mining software, or to be a node in a distributed DoS or credential stuffing attack. These are just some of the things we want to protect against in order to help ensure the highest quality code in the Dagger ecosystem. |
Beta Was this translation helpful? Give feedback.
-
I noticed in the Dagger documentation it explains that input values need to be provided at runtime because the "package system could be a source of attacks."
https://docs.dagger.io/1003/get-started/#define-input-values-per-environment
Could I get a bit more detail on how/why the package system is an attack vector, perhaps with some examples? Is this a Dagger issue or is this a general CUE issue?
Some more background - for small parts of our existing CD system we allow developers to express their secrets in sops-encrypted CUE files. These are then decrypted and
export
ed from CUE at deploy-time. We would like to integrate this system with Dagger without needing to re-implement everything.Beta Was this translation helpful? Give feedback.
All reactions