PodSecurity Admission

[kadel]

/kind user-story

User Story

As an odo user, I want to be able to run my application with standard Devfile even if the cluster that I'm using enforces security policies using PodSecurity Admission controller.

Acceptance Criteria

• odo should generate PodSpec that complies with the PodSecurity policies set on the clutester
  • odo dev (fixed by Patch Pods to pass pod security admission #6602)
  • odo deploy (with Exec command) (blocked by Add DevfileOptions to GetPodTemplateSpec devfile/library#167)
  • PodSecurity Admission: Display duplicate warnings only once #6699

Details:

• what should odo do
  • For now we will focus only on enforce policy. Other policies audit and warn should not effect the ability to run the container that doesn't meet the set policies.
  • The mechanism for checking what policies are in effect should be done by checking labels on the current namespace.
  • if there is no pod-security.kubernetes.io/enforce label
    • do nothing special
  • if pod-security.kubernetes.io/enforce is set
    • check what policy is set to be enforced
    • Pod Security Standards are hardcoded in the admission plugin. Changes to the standards are tied to the Kubernetes version that they were introduced in. Odo needs to support multiple versions of Pod Security Standards. There is a ../enforce-version label that indicates what version is being used. If not set odo should assume the latest version it knows.

https://kubernetes.io/docs/concepts/security/pod-security-admission/
https://kubernetes.io/docs/concepts/security/pod-security-standards/

/kind user-story

[rm3l]

Grooming (2023-01-19)

• Check if there is some library
  • Might be good to add this in the Devfile library (later)
• The point here (automatic way) is to have a Pod which is guaranteed to be created
  • Enable this behavior via a flag (only when requested)

=> TODO for Sprint 231 (3 days): More research with concrete examples

[feloy]

On IBM Cloud, PodSecurity feature gate is active on Kubernetes clusters >= 1.25 (ref: https://cloud.ibm.com/docs/containers?topic=containers-service-settings#feature-gates)

[kadel]

On IBM Cloud, PodSecurity feature gate is active on Kubernetes clusters >= 1.25 (ref: https://cloud.ibm.com/docs/containers?topic=containers-service-settings#feature-gates)

Do you know if anything is set to enforce by default?

[feloy]

Do we want to mutate the Pod before or after pod/container-overrides?

for example, if the user sets securityContext.privileged=true using container-override, do we want to set it back to undefined or false?

[feloy]

The use of k8s.io/pod-security-admission library (https://github.com/kubernetes/pod-security-admission) can help to detect which policies are not respected by a Pod for a given namespace.

PoC: https://github.com/feloy/podsecurity-admission-test

[feloy]

On IBM Cloud, PodSecurity feature gate is active on Kubernetes clusters >= 1.25 (ref: https://cloud.ibm.com/docs/containers?topic=containers-service-settings#feature-gates)

Do you know if anything is set to enforce by default?

On IBM Cloud:

• On Kubernetes v1.25, no annotations are added to namespaces.
• On OpenShift v4.11 (based on Kubernetes v1.24), these annotations are automatically added by default:

  pod-security.kubernetes.io/audit: restricted
  pod-security.kubernetes.io/audit-version: v1.24
  pod-security.kubernetes.io/warn: restricted
  pod-security.kubernetes.io/warn-version: v1.24
  

So, no enforce added by default in any cluster

[kadel]

Do we want to mutate the Pod before or after pod/container-overrides?

for example, if the user sets securityContext.privileged=true using container-override, do we want to set it back to undefined or false?

before, users should have the ability to override it in devfile.

[kadel]

valaparthvi moved this from In Progress 🚧 to Done ✅ in odo Project last week

@valaparthvi Why was this moved to done?

[valaparthvi]

IIRC, the work on the issue for that particular sprint was done, so it was marked as Done. We should be able to set it back to To Do once we move it to a new sprint.

[feloy]

As discussed during the devfile cabal, this feature can be implemented in the devfile library, passing the policy we want to enforce when calling ParseDevfileAndValidate

[feloy]

I realize that it won't be easy to patch the pod for security admission before container-overrides, without changing the way the container-overrides are handled for the moment.

As a matter of fact, the containers are overridden when generator.GetContainers() is called, then pod is overriden when generator.GetDeployment() is called.

Pod Security Admission rules are defined for pods, not at the container level, and so they don't really make sense at the time of calling generator.GetContainers()

[rm3l]

/status blocked

Marking this as waiting for devfile/library#167

[rm3l]

Closing this issue as implemented by #6679.

The new issue added will be handled separately in #6699

/close

[openshift-ci]

@rm3l: Closing this issue.

In response to this:

Closing this issue as implemented by #6679

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.