Processes selector for excludedNamespaces at the Constraint level

[mccormickt-dd]

When rolling out policies, it is common to have to exempt some namespaces for each policy you want to roll out. Once exempted, however, there isn't a good way to look back at what's been exempted and see if it is still violating the policy, and still needs its exception!

At the config level, we can exempt namespaces from just the webhook, and leave audit to keep auditing workloads. We cannot do this per constraint, from what I can tell, with the given selector fields. I'd like to suggest adding a way to select a specific process to be exempted from at the constraint level, so you can preserve metrics and logs produced by audit for future hardening or analysis of exceptions to policies.

If this is possible today by some other means, I'd love to know!

For a specific policy (not globally) I'm simply looking to:

• Exclude a namespace from admission
• Have this not affect Gatekeeper Audits

Environment:

• Gatekeeper version: N/A
• Kubernetes version: (use kubectl version): N/A

[sozercan]

@mccormickt does enforcement action fulfill your needs? https://open-policy-agent.github.io/gatekeeper/website/docs/violations/#dry-run-enforcement-action

Policy on a constraint level will bypass admission while still being audited. With warn, you can get an immediate message in addition to audit.

[mccormickt-dd]

I actually want the opposite, kind of. I want a specific namespace to not be affected by admission, but everything else to still be. I would also like all namespaces to be audited. I suppose the workaround would be to create another instance of a constraint that is in dryrun with no namespace exceptions?

I more or less would like the below, but at the constraint level instead of globally.

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  match:
    - excludedNamespaces: ["kube-*", "my-namespace"]
      processes: ["Webhook"]  # Exempting only the webhook, but still audits

[maxsmythe]

That workaround works and AFAICT is currently the only way of doing what you're asking.

I'm wondering if we need to start labeling feature requests that touch on more dynamic enforcement actions? IIRC there is at least one other issue that potentially touches on the topic.

[stale[bot]]

This issue 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.

[maxsmythe]

+1, this is a good use case to track

[darey-io]

+1, this use case is indeed required. Perhaps something like this will suffice

   spec:
      scope: Namespaced 
      exemptNamespaces: ["kube-*", "aws-*", flux-*]

[abdennour]

+1, this use case is indeed required. Perhaps something like this will suffice

   spec:
      scope: Namespaced 
      exemptNamespaces: ["kube-*", "aws-*", flux-*]

100% agree & converge

[maxsmythe]

This is coming with scopedEnforcementActions.

Latest PR for this: https://github.com/open-policy-agent/frameworks/pull/403

Note that this particular use case would require implementing 2 constraints (one per enforcement point) to leverage different match criteria.

@JaydipGabani FYI