Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support Custom Secret Targets #32571
This adds support for custom secret target paths lifting the restriction of limiting secrets to
@ehazlett: I'd suggest this borrow the code from configs in #32336. That stores the config under the full target path, so there isn't a risk of collisions from targets that share the same basename. Also, it would be good for the config and secret implementations to stay consistent.
Let me know if it would be helpful for me to carry this PR.
Force-pushed to rebase and change the "local" storage paths to use the full target path instead of just the basename (which could collide).
When I have a chance (either later today or early next week), I'll expand the automated tests to check that the files actually exist inside the container in the right places, with the right content, using both relative and absolute paths. I'll also improve the tests to cover invalid targets and referencing the same secret twice under different targets.
I've updated the vendoring, as the upstream swarmkit PR was merged.
I added test coverage for the following:
I also added corresponding tests to the configs PR (#32336).
Couple of questions:
- Should we even support secret creation with targets that have potential OS separators?
- Should we list all secrets in
/var/run/secretseven if the target is outside of base secrets dir? Would have the advantage that a
ls /var/run/secrets/always returns all the secrets available.
- Should we allow someone to add a target into
/var/run/secrets/? In particular concerned that the validation of multiple targets being set somehow doesn't handle this new way of adding targets and the behavior will be unknown or the task unschedulable.
- Are there any files/paths we want to reject outright from being overwritten? (like anything in
Thanks for carrying this PR @aaronlehmann
Thanks @aaronlehmann! I could not think of any issues allowing a secret to escape
I don't think users should be providing traversals from
Thinking about it more, it may be nice if we could prevent path traversals at all on
LGTM on green.
added a commit
this pull request
May 9, 2017
This seems to happen with any secret target right now.
And I end up with leaked mounts: