AKS ContainerEnforceProbes: Policy text says readiness OR liveness probe is sufficient, but template enforces both

[flaviomeyer]

Details of the scenario you tried and the problem that is occurring

The policy text for the Kubernetes ContainerEnforceProbes sample states that having either a readiness probe OR a liveness (health) probe is sufficient to satisfy the policy. However, in practice the policy requires both probes to be present. Investigation shows that the OR logic described in the policy text is not implemented in the template; instead the template behaves as if an AND is required.

The relevant template is here:
https://store.policy.core.windows.net/kubernetes/container-enforce-probes/v2/template.yaml

Because the template implements an AND instead of the intended OR, the actual enforcement no longer matches the policy description. Resources which should be compliant when they have just one of the two probes (readiness OR liveness) are marked non-compliant, or vice versa depending on the specific rule behavior.

Reproduction (summary):

• Deploy a pod/container with only a readiness probe (no liveness probe).
• The policy evaluates the resource as non-compliant, despite the policy text indicating readiness OR liveness should be sufficient.

Verbose logs showing the problem

N/A — observed behavior described above (policy evaluates as requiring both probes). If needed I can provide sample resource manifests and policy evaluation output showing the non-compliance.

Suggested solution to the issue

Update the template at https://store.policy.core.windows.net/kubernetes/container-enforce-probes/v2/template.yaml so that the probe check uses OR semantics (anyOf) rather than AND/allOf. Concretely:

• Replace the current combined condition with an anyOf-style condition that accepts containers that have either a readinessProbe OR a livenessProbe (or both).
• Validate the updated template against typical pod manifests to confirm the policy text and enforcement match.

Additionally: please confirm who is the owner/maintainer of the file in the policy store (store.policy.core.windows.net) so this fix can be routed to the correct team. Who manages and publishes the template.yaml in the policy store?

If policy is Guest Configuration - details about target node

N/A