New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for seccomp #20870
Comments
cc @erictune @kubernetes/rh-platform-management |
cc @kubernetes/rh-cluster-infra |
Is the problem here that you are worried about seccomp breaking certain actions? I hate to turn off a key security feature of docker for the masses of users of k8s. |
Do these make sense as requirements for kubernetes support for seccomp filters:
|
@kubernetes/kube-iam |
@erictune my thoughts are here (although disorganized as usual) https://trello.com/c/1pn9IN3m/320-better-seccomp-support But I think you nailed it. |
I didn't realize that only increasingly more restrictive seccomp profiles can be loaded, if I am reading the comments on https://trello.com/c/1pn9IN3m/320-better-seccomp-support correctly. That makes it much less flexible that I had imagined. |
docker only lets us load a single profile, so that part isn't relevant today (I think RH is doing OCI work to make it a list of profiles but who knows if that ever gets plumbed up into docker) If you load 2 profiles they will be executed in order and all of the profiles must 'approve' the syscall. If profile 1 says Then BOTH |
So the profiles themselves do not have to be of increasing restrictivity (restrictivity is a word, right?) but the combination will always be at least as restrictive as either parent. |
What if instead of turning it off completely kubernetes loaded a custom default, w mount and whatever else you all need |
and if the user loads one it would override your default, just like how it works in docker. |
I'd be happy to contribute the patch depending on what syscalls you all need added |
If users have a mechanism to override the default profile, I guess docker's default profile should itself work. |
So is the problem exposing the custom profile in the kubernetes API in a On Monday, April 4, 2016, Vish Kannan notifications@github.com wrote:
Jessie Frazelle |
@erictune are you explicitly referring to Linux capabilities there? One option would be to tie the default Docker seccomp filter to the allowed capabilities so that adding say Getting admins to write seccomp filters is somewhat unpleasant work, the aim with the Docker seccomp support has been to avoid it as much as possible. |
Is this manifesting as a real problem right now? I am wild-guessing that it shows up as containers that fail (syscall blocked) with no remediation (since it didn't make it into our API) ? It seems like an overly large thing to cherry pick, and yet not having it seems bad. Can we maybe have an annotation that we pass through to docker, and add proper profiles and fields in 1.3? |
I tried to add this pull request to docker, but it was closed because docker wants the tighter security I believe that we should attempt to separate different security mechanisms from each other. For example. SELinux can block Capabilities, but I allow all Caps from an SELinux point of view and rely on the Capabilities Subsystem to manage caps, Seccomp did not follow this standard, at least to a few syscalls that are controlled by SYS_ADMIN. We saw these when trying to run systemd in a container. Allowing tools to specify Whitelist or blacklist syscalls would help. It would also help if the syscall table that docker is using was provided externally to the tool, not compiled in. Then the admin or tools could just modify the default json and pass it to docker daemon on on the docker run command to specify the syscalls to be used by the container(s). |
If the default profile is the problem it could easily be fixed by my On Tuesday, April 5, 2016, Daniel J Walsh notifications@github.com wrote:
Jessie Frazelle |
In 1.2 we explicitly disable the seccomp profiles (aka we disable the docker default). So the 'manifestation' today is that kubernetes users cannot make use of this security feature provided by the underlying container backend. The default docker seccomp profile would be great 99% of the time (the exact same % of the time that it would be great for docker). But until we plumb through some way to control the seccomp profile there wasn't a better alternative. This issue requires someone to plumb through the kube API a way to represent seccomp profiles and how to disable them. I think there are a lot of ideas above how to plumb seccomp through the API, some form of which needs to be done before 1.3... |
We can't break existing applications running in existing clusters. Users also expect to be able to delete and re-create their clusters across releases with identical behavior, and we have the official policy that we don't change default behavior of APIs without introducing a new API version. |
@jfrazelle we don't know what calls our users might be doing, so we don't want to change the default and break them. I see that before 1.10 you tested all the official docker images and didn't see any issues. Since then, have there been any user reports of images not working after upgrading to 1.10 due to seccomp? |
You could argue it was an oversight, but it's a stretch. I was hoping On Wed, Apr 20, 2016 at 8:15 AM, Jess Frazelle notifications@github.com
|
don't worry I'll be the pusher for 1.3 😇 |
I'mma hold you to that. On Thu, Apr 21, 2016 at 10:13 AM, Jess Frazelle notifications@github.com
|
👍 |
Automatic merge from submit-queue Seccomp Proposal WIP proposal to address #20870 @kubernetes/kube-api @kubernetes/sig-node <!-- Reviewable:start --> --- This change is [<img src="http://reviewable.k8s.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](http://reviewable.k8s.io/reviews/kubernetes/kubernetes/24602) <!-- Reviewable:end -->
Not yet - we need #26710 to merge first |
Moved this to v1.3 for the proper feature tracking. |
Automatic merge from submit-queue Seccomp Proposal WIP proposal to address kubernetes#20870 @kubernetes/kube-api @kubernetes/sig-node <!-- Reviewable:start --> --- This change is [<img src="http://reviewable.k8s.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](http://reviewable.k8s.io/reviews/kubernetes/kubernetes/24602) <!-- Reviewable:end -->
Feature issue: kubernetes/enhancements#135 |
Closing in favor of kubernetes/enhancements#135 |
Starting from v1.10 docker daemon will run with a restrictive seccomp profile turned on by default.
Users will have to include a custom seccomp profile in addition to capabilities.
Until we figure out a sane way to add support for seccomp, I propose disabling (
unconfined
) seccomp profiles by default.This will allow users to upgrade to docker v1.10 seamlessly.
cc @kubernetes/goog-node @bgrant0607
The text was updated successfully, but these errors were encountered: