PodSecurityStandards being enforced provide different log information for Deployments and for pods to the user about kubernetes HOT 10 CLOSED

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

from kubernetes.

/sig Policy

from kubernetes.

@cck1860: The label(s) sig/policy cannot be applied, because the repository doesn't have them.

from kubernetes.

/sig Security

from kubernetes.

/sig auth

from kubernetes.

/assign @stlaz

from kubernetes.

Enforcement is actually not run on the pod controllers (such as Deployment), meaning that the enforce label is ignored and only the "warn" label applies for client-side warnings.

On the contrary, the warn-level admission is not run when the enforcement fails.

@liggitt you added this code originally, does running the warn admission on a pod that already failed the enforcement check make sense? Or, perhaps from the other side, should we run enforcement at warn level for pod controllers, and then running the warn admission again?
Are we even able to convey warnings along with errors to the client side?

from kubernetes.

/remove-kind bug
/kind documentation
/close

The reason we only issue warnings at the controller level is because we don't know the pod will be disallowed until a creation is actually attempted and any mutating admission plugins interact with the create attempt.

From https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/2579-psp-replacement#podtemplate-resources

Audit and Warn modes are also checked on resource types that embed a PodTemplate (enumerated below), but enforce mode only applies to actual pod resources.

Since users do not create pods directly in the typical deployment model, the warning mechanism is only effective if it can also warn on templated pod resources. Similarly, for audit it is useful to tie the audited violation back to the requesting user, so audit will also apply to templated pod resources. In the interest of supporting mutating admission controllers, policies will only be enforced on actual pods.

From https://kubernetes.io/docs/concepts/security/pod-security-admission/#workload-resources-and-pod-templates

To help catch violations early, both the audit and warning modes are applied to the workload resources. However, enforce mode is not applied to workload resources, only to the resulting pod objects.

from kubernetes.

@liggitt: Closing this issue.

from kubernetes.

@liggitt you added this code originally, does running the warn admission on a pod that already failed the enforcement check make sense?

Rejecting the pod (enforce) takes precedence over warning.

from kubernetes.