Allow runtime/default seccomp profile in the built-in SCCs #1325
Comments
|
BZ - 2010564 seems to talk about the same issue. |
It seems that built-in SCCs (except `privileged`) don't allow to set the seccomp profile [1]. Until this is fixed in OpenShift, we should leave it to the default (which is already `RuntimeDefault`). [1] openshift/cluster-kube-apiserver-operator#1325 Signed-off-by: Simon Pasquier <[email protected]>
It seems that built-in SCCs (except `privileged`) don't allow to set the seccomp profile [1]. Until this is fixed in OpenShift, we shouldn't try to set `seccompProfile` (the container runtime should already use `RuntimeDefault`). [1] openshift/cluster-kube-apiserver-operator#1325 Signed-off-by: Simon Pasquier <[email protected]>
It seems that built-in SCCs (except `privileged`) don't allow to set the seccomp profile [1]. Until this is fixed in OpenShift, we shouldn't try to set `seccompProfile` (the container runtime should already use `RuntimeDefault`). [1] openshift/cluster-kube-apiserver-operator#1325 Signed-off-by: Simon Pasquier <[email protected]>
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
openshift-ci
bot
removed
the
lifecycle/stale
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
openshift-ci
bot
removed
the
lifecycle/stale
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
@pjbgf Could you please elaborate on how/where was this issue fixed? Thanks. |
|
@nyoxi I don't think the issue was resolved, I closed it due to lack of activity within the year it was opened. |
|
I see. Confusingly GitHub says: |
Currently, all default SCCs (except
privileged) block users from setting seccomp toruntime/default. The current behaviour seems to be a disservice as it blocks workloads to use more restrictive security controls, which may lead to folks simply set a workload SCC toprivilegedin order to "get it to work".This is becoming a larger problem as folks around the OSS community and the private sector start shipping workloads with seccomp set to
runtime/default- which is the recommended setting by CIS Benchmark for a few years now. They are now facing a few options:privileged.The suggested change is to allow all default SCCs to support:
unconfined(current Kubernetes default for backwards compatibility)runtime/default(future Kubernetes default and safer position)I am not entirety sure of the longevity and future plans of SCC. However, making this change will:
Looking forward to hear some thoughts around and understand how receptive the maintainers would be to the above.
cc: @JAORMX @jhrozek @saschagrunert
Upstream Context:
docker/defaultand was later renamed toruntime/default.1.19: Seccomp made GA having profileunconfinedby default.1.22: SeccompDefault feature gate created, enabling users to switch fromunconfinedtoruntime/defaultacross the entire cluster.1.25(planned): SeccompDefault feature gate is enabled by default, meaning that all workloads will have seccomp profileruntime/defaultunless otherwise set on a per workload (pod or container) basis.The text was updated successfully, but these errors were encountered: