search

open-policy-agent / gatekeeper-library

📚 The OPA Gatekeeper policy library
https://open-policy-agent.github.io/gatekeeper-library
Apache License 2.0
647 stars 320 forks source link

Should apparmor always view unconfined as complaint? #475

Closed fseldow closed 4 months ago

fseldow commented 8 months ago

Hi gatekeeper-library, In apparmor constraint template, we setup the rule to block container using apparmor not existed in the parameter allowedProfiles https://github.com/open-policy-agent/gatekeeper-library/blob/master/library/pod-security-policy/apparmor/template.yaml

However, in the apparmor api doc, it is said unconfined to indicate that no profiles will be loaded So will it be reasonable to view unconfined as always complaint even if the allowedProfiles is empty or without unconfined?

apeabody commented 6 months ago

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.

fseldow commented 6 months ago

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

ritazh commented 6 months ago

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.

stale[bot] commented 4 months ago

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.