Garden supports disabling privileged containers, and some users have configured it (see Discord message) - should we support that for the containerd runtime too?
That looks sooo much like something one would do via OPA, e.g., in kubernetes:
package kubernetes.admission
deny[message] {
input.request.kind.kind == "Pod"
container := input.request.object.spec.containers[_]
container.securityContext.privileged
message := sprintf("Container %v in privileged mode.", [container.name])
}
https://dzone.com/articles/kubernetes-pod-security-policies-with-open-policy
(OPA rfc: https://github.com/concourse/rfcs/pull/41 @evanchaoli )
I was looking at this with Tom (who raised it on Discord) and we felt like it would be preferable if the container runtime itself also wouldn't allow privileged workloads. OPA can be used for a slightly more front-door approach and has better UX (well, if this gets merged) but it is nice to be able to define it right down at the runtime level. For Garden this is pretty easy as it has a flag/config option you can pass to gdn but for containerd it is all defined within Concourse itself (privileged just means no user namespace). At that point, since both are in "managed" Concourse code, you could definitely make an argument for just using OPA I guess.
Just like to second @andy-paine's comment above, that if I were running a multi-tenant Concourse (I know, it's designed for trusted tenants currently) then I'd strongly like to have multiple means of preventing privileged workloads running. Defence in depth, and all that.
Most helpful comment
Just like to second @andy-paine's comment above, that if I were running a multi-tenant Concourse (I know, it's designed for trusted tenants currently) then I'd strongly like to have multiple means of preventing privileged workloads running. Defence in depth, and all that.