Sounds like we need an explicit audit enforcementAction. Today audit is always enabled by default for each constraint. To ensure backward compatibility, do we need to make it opt-out instead of opt-in like all the other enforcement actions?

Opt out would make the most sense to me. If audit is enabled I would expect it to be enabled for all constraints by default.

On a related note, can a constraint only be checked during audit? An enforcement action of warn or deny will check in real-time which we may not want to reduce load/response time but having it run in the background may still be desirable to have warnings bubble up. Dryrun also still processes the constraint in real-time but takes no action.

For example, what if my constraint requires resources to be synced because it's referential, it might require a lot of resources to do so.. perhaps I only want to have these audited so we don't need to enable cache or slow down api calls. I assume there would still be some benefit to having an enforcementAction other than dry-run to entirely skip processing of these constraints in the webhook. To cover this (if it isn't already possible) perhaps we also need an option to disable the enforcementAction all together?

Example:
enforcementAction: [warn, deny, dryrun, none]
auditEnforcementAction: [warn, dryrun, none]

If auditEnforcementAction is not specified, default to enforcementAction (deny treated as warn).

We don't currently scope which constraints get evaluated where, but it's def. a good idea.

This is similar to my request

With the addition of the external data provider, audit can cause calls to other applications, that could result in external calls to cloud APIs.

I think we need a similar way to scope processes as we do in config resource

    - excludedNamespaces: ["kube-*", "my-namespace"]
      processes: ["webhook", "audit"]

      # this doesn't exist yet
    - namespaceSelector: 
         matchExpression:
          - key: audit-me
       processes: [audit]

IMO this is tied in with enforcementAction and enforcement points, not just per-process.

E.g. there may be different enforcement actions available, and taking different actions may make sense, depending on whether a violation is caught shift-left via gator test vs. at webhook time vs. in audit.

Because we probably don't want to couple infrastructure with policy implementation, we should have some means of letting enforcement points self-identify (e.g. webhook.gatekeeper.sh, gator.gatekeeper.sh, etc. -- though maybe we could be a bit less literal and more intent-based), along with a default enforcement action.

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 is there a current enforcement action that would disable Audit or is that what you are proposing?

@jimmyraywv There's no mechanism to disable audit selectively per constraint today (it can only be disabled as a whole or on a namespace level). There's a design doc that we are discussing various options: https://docs.google.com/document/d/1QIABjZN9B8oBZF5mm1hz5IhpTGulm1jTNn20nYIF-Hc/edit

Hello!
Are there any updates regarding the subject? Is there any chance to see the discussed functionality in upcoming releases?
Thanks!

Up

Am I right that there are no plans regarding the topic?

@ikusomr This is the design doc that we are discussing various options: https://docs.google.com/document/d/1QIABjZN9B8oBZF5mm1hz5IhpTGulm1jTNn20nYIF-Hc/edit
Feel free to review and give feedback.

@ritazh yep, I've seen it, thank you. I mean, no decision has been made on this, right?

no decision yet

@salaxander this might be a good one for you to drive