Should apparmor always view unconfined as complaint? about gatekeeper-library HOT 4 CLOSED

Hi @fseldow! - Not specific to unconfined, but for backwards compatibility we want to preserve the templates existing behavior. So any potentially breaking change would probably need to be gated with a new parameter, for which the default would maintain the template's current behavior.

from gatekeeper-library.

Hi @apeabody thx for discussion.
In my draft pr: https://github.com/open-policy-agent/gatekeeper-library/pull/476/files#diff-12f0a346e8a71d42c3220276be2c51872b8195d0838c33ec2a24d09657c74937

The result change will happen only when input parameter does not include unconfined but the container is set as unconfined. We used to view it as non-complaint. After the change it will become complaint.
In other word, the parameter allowedProfile will by default include unconfined then

Will it also be viewed as breaking change? because from my side, it will not suddenly casue complaint resources to be non-complaint or deny the curd of pods

from gatekeeper-library.

Thanks for raising this @fseldow!
After looking at the docs, if this annotation is set to unconfined for a specific container, it means that the container will not be subject to any AppArmor profile restrictions. This configuration effectively disables AppArmor protection for the container, allowing it to run with the default permissions and capabilities granted by the Kubernetes cluster and the underlying operating system.

+1 to adding a new parameter in the policy to enable this behavior to allow compliance for unconfined, while ensuring the default behavior when the new parameter is no set is non compliant.

from gatekeeper-library.

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

from gatekeeper-library.