Change:
Seccomp is currently defaulted to on docker: I believe this is for historical reasons, from However, we now have the ability (albeit alpha) to control seccomp profiles, so we should change the default to the more secure option. This profile is carefully curated, and should provide enhanced security without breaking the majority of users. Unfortunately "the majority" is not "everybody", so changing this default would be a breaking change, and care needs to be taken when rolling it out. This may also need to wait for seccomp to be promoted to beta.
fwiw when we launched it with docker i tested all the publically available dockerfiles on github and docker hub with it... so it was not done without much testing, we also only had one issue iirc after the release which was a lot better than i expected.
+1 for attempting to roll out the default docker configuration. Ideally, we want users to use seccomp profiles that is fined tuned for each container. We might have to develop some tooling to make it easy to consume this feature in k8s. The current approach of storing profiles on node's root partition is complicated.
Just want to add my +1 for making this the default.
feature in k8s. The current approach of storing profiles on node's root partition is complicated. Agreed, I consider this alpha-behavior. For both seccomp & apparmor I'd like to add the ability to consume a ConfigMap (or maybe a new resource) as a profile. However, I consider this tangential to the issue discussed here. Adjusting the default is already supported through the PodSecurityPolicy, but we still need to put some thought into how we'd go about rolling this out.
So there are a few ways I can imagine going about this, happy to open a proposal if you if agree with any: to the and maintaining our own default so we can edit easily in the future (i'm happy to do this since I wrote a lot of the docker default) (2) might require making our own "seccomp profile spec" and adding as an api somewhere (idk which group) if we don't want to rely on another runtime's. option to set a different default maybe as a kubelet config option (also might require 3 unless we just default to another runtimes) I am kinda in favor of 2, 3, and 4 so we have the most control.
2,3 sound good to me. I think we can do (2) before fully implementing (3), since it's technically still an "alpha" feature. I think we should use the OCI spec, but I don't know the details on it. (4) is essentially already implemented on the PodSecurityPolicy, via an annotation (should graduate to a field before seccomp support goes to beta): "" (see )
makes sense Should we use theirs as a base and make our own or vendor theirs (ie what happens if they change theirs)
That's a question for but my hunch is that we create our own copy (rather than vendoring), since I don't think we have any other examples of embedding a third party API in ours (unless it's opaque)
cool thats what i was leaning towards :)
I'll open a proposal this afternoon :)
So can we use the default profile to set seccomp as now?
I think we should spec the seccomp format first, refer . or else, other container runtimes couldn't know how to process .
For other runtimes that is why we are using the docker default as a base... not literally docker/default. but yes we can spec it out On Thu, May 25, 2017 at 04:02 Pengfei Ni <: 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
discussion on seccomp format is here :
not sure a docker-specific seccomp name is good as a default
/assign
GitHub didn't allow me to assign the following users: wangzhen127. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Will add runtime/default to addons as the first step to see how it works.
/reopen There is followup work.
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
What's blocking this from happening at this point? cc
long-term-issue (note to self)
Generally, the fact that this a breaking change, and it's very hard to get breaking changes into Kubernetes these days, especially something that is hard to get visibility into. Other issues are that this is still an "alpha" feature, but predates feature gates, so it's an alpha feature that's enabled in every cluster. Before changing the default, we probably need to promote the feature to GA, which includes: the annotation to a pod field the profile management, so that profiles can be written as configmaps or k8s resources, and loaded by the node from there. Kubernetes standard profiles, which can eventually be made the default (can be a copy of the docker default) And possibly: a tool for running seccomp in an "audit only" mode to capture any violations before potentially breaking workloads.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
labels: k8s-app: glbc name: glbc <ins> annotations: seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: containers: - name: default-http-backend

version: v4 annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: priorityClassName: system-cluster-critical tolerations:

version: v1.5.2 annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: priorityClassName: system-cluster-critical containers:

k8s-app: kubernetes-dashboard annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: priorityClassName: system-cluster-critical containers:

k8s-app: kube-dns-autoscaler annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: priorityClassName: system-cluster-critical containers:

metadata: labels: app: metadata-agent <ins> annotations: seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: serviceAccountName: metadata-agent containers:

metadata: labels: app: metadata-agent-cluster-level <ins> annotations: seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: serviceAccountName: metadata-agent containers:

version: v0.2.1 annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </ins> spec: priorityClassName: system-cluster-critical serviceAccountName: metrics-server