Support new Kubernetes PodSecurityStandards #972
Comments
|
I think we should enforce the As for namespace-wide config we have a desire to add some namespace or global config to kpack builds which could help with namespaced policies. |
|
Enforcing the restricted standard generally makes sense but I am concerned with buildpacks out there that do insecure stuff, e.g. running as root. After enforcing the restricted security, those buildpacks would start failing. That is why I suggested some sort of an emergency setting that users could override, however they must realise that doing so carries security implications. |
kieron-dev
pushed a commit
to cloudfoundry/korifi
that referenced
this issue
Jun 28, 2022
The mutating webhook sets a security policy in the kpack build pods' containers that matches the `restricted` pod security enforced by the workload namespace The webhook is a workaround to kpack issue buildpacks-community/kpack#972. Once the issue is resolved and a fix is adopted, we should probably revert the commit and adopt the kpack fix. Issue: #1220 Co-authored-by: Danail Branekov <danailster@gmail.com> nearly working Co-authored-by: Danail Branekov <danailster@gmail.com> It works Co-authored-by: Danail Branekov <danailster@gmail.com>
kieron-dev
pushed a commit
to cloudfoundry/korifi
that referenced
this issue
Jun 28, 2022
The mutating webhook sets a security policy in the kpack build pods' containers that matches the `restricted` pod security enforced by the workload namespace The webhook is a workaround to kpack issue buildpacks-community/kpack#972. Once the issue is resolved and a fix is adopted, we should probably revert the commit and adopt the kpack fix. Issue: #1220 Co-authored-by: Danail Branekov <danailster@gmail.com> nearly working Co-authored-by: Danail Branekov <danailster@gmail.com> It works Co-authored-by: Danail Branekov <danailster@gmail.com>
danail-branekov
added a commit
to cloudfoundry/korifi
that referenced
this issue
Jun 29, 2022
The mutating webhook sets a security policy in the kpack build pods' containers that matches the `restricted` pod security enforced by the workload namespace The webhook is a workaround to kpack issue buildpacks-community/kpack#972. Once the issue is resolved and a fix is adopted, we should probably revert the commit and adopt the kpack fix. Issue: #1220 Co-authored-by: Danail Branekov <danailster@gmail.com> nearly working Co-authored-by: Danail Branekov <danailster@gmail.com> It works Co-authored-by: Danail Branekov <danailster@gmail.com>
kieron-dev
pushed a commit
to cloudfoundry/korifi
that referenced
this issue
Jun 29, 2022
The mutating webhook sets a security policy in the kpack build pods' containers that matches the `restricted` pod security enforced by the workload namespace The webhook is a workaround to kpack issue buildpacks-community/kpack#972. Once the issue is resolved and a fix is adopted, we should probably revert the commit and adopt the kpack fix. Issue: #1220 Co-authored-by: Danail Branekov <danailster@gmail.com>
danail-branekov
added a commit
to cloudfoundry/korifi
that referenced
this issue
Jun 29, 2022
The mutating webhook sets a security policy in the kpack build pods' containers that matches the `restricted` pod security enforced by the workload namespace The webhook is a workaround to kpack issue buildpacks-community/kpack#972. Once the issue is resolved and a fix is adopted, we should probably revert the commit and adopt the kpack fix. Issue: #1220 Co-authored-by: Danail Branekov <danailster@gmail.com>
|
All Cloud Native Buildpack Builds should work with the restricted pod security standard. I don't think there is a need for modifying the pods based on the namespace's pod security standards. |
gcapizzi
added a commit
to cloudfoundry/korifi
that referenced
this issue
Jan 9, 2023
We used to need that webhook to change the security context of the kpack build pods so that they can run in a namespace with `restricted` pod security standard. As of kpack 0.7 buildpods have their security context configured accordingly and therefore our webhook is no longer needed See buildpacks-community/kpack#972 and buildpacks-community/kpack#1030. Co-authored-by: Giuseppe Capizzi <gcapizzi@vmware.com>
danail-branekov
added a commit
to cloudfoundry/korifi
that referenced
this issue
Jan 9, 2023
We used to need that webhook to change the security context of the kpack build pods so that they can run in a namespace with `restricted` pod security standard. As of kpack 0.7 buildpods have their security context configured accordingly and therefore our webhook is no longer needed See buildpacks-community/kpack#972 and buildpacks-community/kpack#1030. Co-authored-by: Giuseppe Capizzi <gcapizzi@vmware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi kpack,
Korifi here. As of Kubernetes 1.21 pod security policies are deprecated and are going to be removed in 1.25. They are going to be replaced by the Pod security admission controller and pod security standards. This means that pod security is going to be configured per namespace rather than per pod.
In a scenario where a namespace has been configured to enforce the
restrictedpod security standard, kpack build pod that runs in that namespace would fail because its security context does not comply with therestrictedstandard. We had an explore spike to figure out how to address that and came up with a change that makes kpack build pods work in such a namespace.With this issue we would like ot start a discussion on supporting the pod security standard. Some preliminary input from our side:
restrictedpod security standard is not ideal because there might be buildpacks that do not work in such an environmentpod-securitylabels and configure the build pods according to the namespace security standardThe text was updated successfully, but these errors were encountered: