Add support for seccomp

[vishh]

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

[vishh]

cc @erictune @kubernetes/rh-platform-management

[bgrant0607]

cc @pmorie @pweil-

[ncdc]

cc @kubernetes/rh-cluster-infra

[rhatdan]

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.

[vishh]

@rhatdan: moby/moby#20082

[erictune]

Do these make sense as requirements for kubernetes support for seccomp filters:

1. we, the project, pre-defines names for certain "canned" seccomp filters with sensible defaults
   • probably the same as Docker's 1.10 default, and unrestricted.
2. cluster admins can define their own custom filters too.
3. it should be possible to define a seccomp filter and a list of allowed capabilities in the same policy object, so that both are set on a pod/container at once, to avoid user confusion about the need to set both.
4. users can select the policy that a pod/container uses by giving the short name of a policy object, rather than inlining the entire seccomp filter text into the pod spec.
5. admins can change the default policy for pods that don't say what to do as regards seccomp.
6. the default default, on a new/upgraded cluster does not change, without some affirmative user action.
7. if a user writes a pod spec that asks for a level of security that is not supported by the node (e.g. they ask for a restrictive seccomp profile, and the node is running docker 1.9) then pod creation fails, rather then the user silently getting no security.

[erictune]

@kubernetes/kube-iam

[erictune]

@pmorie

[eparis]

@erictune my thoughts are here (although disorganized as usual) https://trello.com/c/1pn9IN3m/320-better-seccomp-support But I think you nailed it.

[erictune]

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.