search

go-vela / community

Community Information for Vela (Target's official Pipeline Automation Framework)
https://go-vela.github.io/docs/
Apache License 2.0
23 stars 3 forks source link

feat(proposal): container outputs and dynamic environments for Docker runtime #988

Open ecrupper opened 4 months ago

chrispdriscoll commented 3 months ago

Conceptually, the sidecar container makes me think of a supply chain attack via that container. Will there need to be any validation step-by-step to ensure the output of one is the input for the next?

chrispdriscoll commented 3 months ago

Does this concept better-enable a Restart Steps capability in the future?

Feels like yes because we could enable an output per step to storage. My intent for the question is to ensure we've considered this in the current design so we don't need to revisit when we look to dig into Restart Steps again.

ecrupper commented 3 months ago

Conceptually, the sidecar container makes me think of a supply chain attack via that container. Will there need to be any validation step-by-step to ensure the output of one is the input for the next?

Yeah security is definitely a big consideration with this implementation. I think with how it's currently designed, the outputs container serves as essentially an augmentation of the Docker volume itself. So it should be assumed that whatever a user is "outputting" they should expect to be a part of the environment for other steps. This is an assumption we ask the users to make when they leverage the secret-vault plugin, which writes sensitive values to the shared volume.

Users cannot access the outputs container directly, so there isn't a "back door" so to speak. One outputs container maps directly to one build and is torn down at the end of the build.

I think the additional security we gain from things like secret masking and avoiding file system credentials where possible greatly outway any vulnerabilities. However, I could be missing something for sure.