feat(proposal): container outputs and dynamic environments for Docker runtime #988
Conversation
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
|
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? |
|
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. |
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. |
| Say the user in the above example does not own or contribute to the `vela/my-plugin` plugin. Further, the plugin does not support `cred_path: <path>`; instead, it expects a token provided as `$PLUGIN_TOKEN`. How can we accommodate this in Vela today? | ||
|
|
||
| ```yaml | ||
| steps: | ||
| - name: generate credentials | ||
| image: alpine | ||
| commands: | ||
| - ./fetch-credentials.sh | ||
| - echo $FETCHED_CREDENTIALS > /vela/creds.txt | ||
|
|
||
| - name: plugin to use auth | ||
| image: vela/my-plugin:latest | ||
| entrypoint: | ||
| - /bin/sh | ||
| - -c | ||
| - export PLUGIN_TOKEN=$(cat /vela/creds.txt); /bin/my-plugin | ||
| ``` |
There was a problem hiding this comment.
to drive the point home, i wouldn't mind seeing an example of the after version with the outputs container in play. wherever it makes the most sense. either that, or leading with that with "this is how one might expect it" but "this is actually the mess you have to go through to make it work today" part.
No description provided.