You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like us to revisit the decision made here: #164
While I 100% agree that having propagate-environment on by default is somewhat a security issue, I think the point of this plugin is that it makes the 99% case easy mode.
All of the steps I've been writing lately have had both of these options turned on:
steps:
- command: "ruby my-script.rb"
plugins:
- docker#v5.4.0:
image: "ruby:latest"
propagate-environment: true #<-- this
mount-buildkite-agent: true #<-- and this
I think if folks want to go down a "secure docker" route, they have the option to call out to docker directly. But I think we should optimise this plugin for "everything just works" by default.
Are there any other options that we should consider flipping the defaults for?
The text was updated successfully, but these errors were encountered:
My opinion has always been: security by default, that way you would have to (ideally) read the documentation, understand the risks and opt-in to a less secure execution. Realistically, though, I know that most just add options until things work (the equivalent of click through OK without readying the messages) 🤷 .
I believe that the propagate-environment is not that much of an issue as the shared values are not secrets. The mounting of the buildkite agent is definitely not secure as that would share your agent's token to the container by default. I am pretty sure that such a thing is on-par with the arbitrary code execution implications of the options to expand variables (expand-image-vars and expand-volume-vars).
That said, I can think of two alternatives to avoid code repetition:
1- setting BUILDKITE_PLUGIN_DOCKER_PROPAGATE_ENVIRONMENT and BUILDKITE_PLUGIN_DOCKER_MOUNT_BUILDKITE_AGENT as environment variables at the pipeline level
2- YAML anchors and merge tags so that the shared (or base) configuration for the plugin is only specified once and then re-used and shared in all steps
We should probably add some documentation about those alternatives in the meantime while we continue to discuss how to best tackle this.
I'd like us to revisit the decision made here: #164
While I 100% agree that having
propagate-environment
on by default is somewhat a security issue, I think the point of this plugin is that it makes the 99% case easy mode.All of the steps I've been writing lately have had both of these options turned on:
I think if folks want to go down a "secure docker" route, they have the option to call out to docker directly. But I think we should optimise this plugin for "everything just works" by default.
Are there any other options that we should consider flipping the defaults for?
The text was updated successfully, but these errors were encountered: