No warning displayed on kubectl apply with enforcementAction warn

[globalundo]

What steps did you take and what happened:

• OPA Gatekeeper is installed in the k8s cluster
• A constraint has been created
• On enforcementAction: deny, resource admission is denied on constraint violation, with a proper message on kubectl apply
• On enforcementAction: warn, no warning message is displayed on kubectl apply, even if resources violates the constraint/

What did you expect to happen:
A warning message would be printed according to the Warn enforcement action.

Anything else you would like to add:

• Gatekeeper has been deployed via gatekeeper.yaml
• A proper message is printed when enforcementAction is set to deny
• If --log-denies is set, a constrain violation get logged correctly on both warn and deny.
• Based of kubectl --v=9 and Gatekeeper’s --logdenies, a constrain violation gets logged in stderr of the gatekeeper’s pod but kubectl does not get a HTTP 299 response but 201 instead
• Any debugging tips or requests for an additional information are welcome

Environment:

• Gatekeeper version: 3.13.0
• Kubernetes version:

Client Version: v1.27.11
Kustomize Version: v5.0.1
Server Version: v1.27.9

[ritazh]

@globalundo can you please share your ConstraintTemplate, constraint, and request that should have returned a warning?
For constraints using warn enforcementAction, gatekeeper should be returning a 299 status code:

gatekeeper/pkg/webhook/policy.go

Line 69 in 45e4552

const httpStatusWarning = 299

[globalundo]

@ritazh while preparing a minimal set of ConstraintTemplate, constraint, and request to reproduce the issue, I have managed to locate an exact issue:

• in all our constants we have a multi-line violation message.
• a violation is printed correctly when enforcementAction is deny
• no message is printed if enforcementAction is warn

Here's a minimal example:

---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AlwaysDeny
metadata:
  name: deny-all-requests-in-namespace
spec:
  enforcementAction: deny
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "default"
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AlwaysDenyMultiline
metadata:
  name: deny-all-requests-in-namespace-multiline
spec:
  enforcementAction: deny
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "default"
---
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: alwaysdenymultiline
spec:
  crd:
    spec:
      names:
        kind: AlwaysDenyMultiline
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package alwaysdeny

        violation[{"msg": "All requests are denied by this policy \n multiline message"}] {
          true
        }
---
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: alwaysdeny
spec:
  crd:
    spec:
      names:
        kind: AlwaysDeny
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package alwaysdeny

        violation[{"msg": "All requests are denied by this policy."}] {
          true
        }

Now, with enforcementAction:deny

$ kubectl run -i --rm --tty podinfo -n default --image=stefanprodan/podinfo  --restart=Never 
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [deny-all-requests-in-namespace-multiline] All requests are denied by this policy 
 multiline message
[deny-all-requests-in-namespace] All requests are denied by this policy.

However, with enforcementAction:warn only a single line violation message is present:

$ kubectl run -i --rm --tty podinfo -n default --image=stefanprodan/podinfo  --restart=Never 
Warning: [deny-all-requests-in-namespace] All requests are denied by this policy.

The multi-line warning message did work in previous OPA Gatekeeper version, but I can not pinpoint at after what version this has stopped working.

[maxsmythe]

I don't think Gatekeeper has changed any of its violation-reporting-via-webhook logic recently. Is this perhaps related to a Kubernetes or kubectl version change?