[Feature] Support `enforcementAction: warn` in Azure Policy for Kubernetes (OPA Gatekeeper)

[jaberchez]

Summary

Azure Policy for Kubernetes currently does not support the Gatekeeper enforcementAction: warn mode. This creates a gap in policy rollout and developer experience, as there is no way to provide non-blocking, real-time feedback at admission time.

---

Problem Statement

Azure Policy for Kubernetes exposes limited enforcement behaviors:

• effect: Deny → maps to enforcementAction: deny
• effect: Audit → maps to enforcementAction: dryrun

However:

• There is no equivalent for enforcementAction: warn
• Developers do not receive admission-time feedback for policy violations unless enforcement is fully set to Deny

Even when manually setting:

spec:
 enforcementAction: warn

Impact

This limitation affects policy adoption and usability:

• No ability to provide immediate feedback to users during kubectl apply
• Violations are only visible through:
  • Constraint status
  • Azure Policy compliance dashboards
• No intermediate stage between:
  • Silent audit (dryrun)
  • Hard enforcement (deny)
• Increased risk when transitioning policies to enforcement due to lack of user awareness

Business Justification

• Aligns Azure Policy capabilities with native Gatekeeper features
• Improves developer experience with real-time feedback
• Enables safer and more controlled policy adoption
• Reduces operational risk when transitioning to enforcement

[JaydipGabani]

@anlandu ptal

[anlandu]

Hi @jaberchez , we support Warn, it's not an effect but rather a boolean in the effectDetails. You can see an example here https://www.azadvertizer.net/azpolicyadvertizer/9a5f4e39-e427-4d5d-ae73-93db00328bec.html thank you!

[kevinhwang-microsoft]

adding on what@anlandu said, if definition is warn=true + enforcement action is Audit, then the enforcement action will be warn

[jaberchez]

Hi @anlandu, @kevinhwang-microsoft,

I’m not letting Azure generate the constraint dynamically; I’m providing it directly in Base64 because I need it for testing with Gator. I'm not sure, but I don’t think it is possible to inject parameters when the constraint is provided in Base64 encoding, so I tried to provide spec.enforcementAction: warn in the constraint itself.

This is my bicep module policy definition:

targetScope = 'subscription'

param policyName string
param policyDisplayName string
param policyDescription string
param effect string
param constraintTemplateBase64 string
param constraintBase64 string

resource opaPolicyDefinition 'Microsoft.Authorization/policyDefinitions@2025-11-01' = {
  name: policyName
  properties: {
    policyType: 'Custom'
    mode: 'Microsoft.Kubernetes.Data'
    displayName: policyDisplayName
    description: policyDescription
    metadata: {
      version: '3.2.0'
      category: 'Kubernetes'
    }
    policyRule: {
      if: {
        field: 'type'
        in: [
          'Microsoft.Kubernetes/connectedClusters'
          'Microsoft.ContainerService/managedClusters'
        ]
      }
      then: {
        effect: effect
        details: {
          // The template and constraint are passed as base64 encoded strings
          templateInfo: {
            sourceType: 'Base64Encoded'
            content: constraintTemplateBase64
          }
          constraintInfo: {
            sourceType: 'Base64Encoded'
            content: constraintBase64
          }
        }
      }
    }
  }
}

output policyId string = opaPolicyDefinition.id
output policyDisplayName string = opaPolicyDefinition.properties.displayName
output policyDescription string = opaPolicyDefinition.properties.description

Thank you!

[kevinhwang-microsoft]

hi @jaberchez, you need warn set to true in then.details - please see L24-L30 in link anlan sent

or you can just do

"then": {
  "details": {
    "apiGroups": [
      ""
    ],
    "warn": true,
    ...
  }
}

[kevinhwang-microsoft]

don't forget enforcement action is only set to warn when

warn=true && enforcement action=audit