Proposal: decompose --privileged into individual --security-opt options #47663
Labels
area/security
kind/feature
Functionality or other elements that the project doesn't currently have. Features are new and shiny
status/0-triage
Description
These two pull requests have (re-)surfaced recently, and are motivated by the the want to make
--privileged
less blunt/all-encompassing, in order to enable new use-cases that only require some of its features.--privileged
#47500Today there is a lot that only
--privileged
can do, and the semantics of combining it with existing--security-opt
are unclear, even to maintainers. A partially correct/semi-out-of-date list is here:To try and solve this in a way that lets us move forward and doesn't incur more technical debt, blow up the combinatorial matrix in a way that is hard to understand, or introduce even more confusion for users, I'd like to propose eliminating
--privileged
entirely.Instead,
--privileged
could be clientside sugar that decomposes into a (new) set of--security-opt
flags that poke all the holes in the container we create today, but in a composable fashion. This would also enable us to solve the 'how to combine' problem above, by empowering the user to express exactly the semantics they desire; we can make--privileged
and--security-opt
an error, and print a suggested command line that specifies each option granularity instead (or alternatively, lists all the knobs but doesn't enumerate those left at default values).While this isn't quite a full entitlements system (#32801), I think it does help with other use-cases, like moby/swarmkit#3072 as well (allowing for something more granular would solve most of the objections the SwarmKit maintainers have historically had), and would align nicely with recent work in SwarmKit:
The text was updated successfully, but these errors were encountered: