Instruct Gatekeeper to bypass policy only if it finds selector deployment-x in namespace-x

[laimison]

Hi,

Is it currently possible to exclude policy by selector and limit this to a namespace in Gatekeeper configuration?

An example: if I want deployment to be excluded from policy, I should create Deployment in namespace-x and also should add deployment-x selector.

Usually people exclude by namespace or possibly in less secure way by selectors (still useful).
Wouldn't be great idea to to merge them both? And why? Any technical limitation how selectors are designed?

If using basic exclusions, it looks like this, but then deployment-x label is excluded in all namespaces:

    enforcementAction: deny
    match:
      excludedNamespaces:
      - namespace-x
      labelSelector:
        matchExpressions:
        - key: app.kubernetes.io/name
          operator: NotIn
          values:
          - deployment-x

Thanks

[maxsmythe]

The inverse of this is "apply this policy only to resources in namespace x with label value deployment-x", which can be expressed simply via the syntax.

Essential match is a set of criteria and-ed together (A AND B AND C must be true) what you're looking for is NOT (A AND B AND C), basically the inversion of that. It might be interesting to allow for negated match criteria to express "apply these policies to all resources but this one" where the excluded resource(s) are selected by a compound statement.

[maxsmythe]

@ritazh @shomron @sozercan @willbeason thoughts?

[willbeason]

I think the design could be tricky - right now we just use the built-in k8s label selector criteria.

Using Existing Features

One way of accomplishing this with the existing infrastructure is recalling De Morgan's Laws. NOT (A AND B AND C) is equivalent to (NOT A) OR (NOT B) OR (NOT C). Thus, you could equivalently do this by defining three Constraints, each with a specific condition.

The requirements for the case above appear to be: "Match all Deployments except those in namespace-x named deployment-x".

In this case, we want two Constraints

• one with a NOT in namespace-x matcher, and
• one with a NOT named deployment-x matcher.

The union of Deployments these cover is everything except the Deployment named deployment-x contained in namespace-x.

Scalability

One problem here is one of scalability - you end up running the Constraint twice on Deployments which are not in namespace-x and are not named deployment-x. However, note that (NOT A) OR (NOT B) is equivalent to (NOT A) OR ((NOT B) AND A). So you could make your two constraints:

• one with a NOT namespace-x Matcher, and
• one with a namespace-x AND NOT deployment-x Matcher

This would ensure exactly one Constraint was executed against any individual Deployment.

Feasibility

This usage isn't intuitive, and I expect people wouldn't like needing to specify multiple Constraints to accomplish this.

Modifying Gatekeeper

We can extend this idea as a function of Gatekeeper by making match accept an array. A single match contains conditions which are AND-ed together, but the set of Matchers are all OR-ed together.

Such a change would either break all existing Matchers, require adding a new field, or require allowing either an array or a single match object. This would need its own design discussion, docs, implementation strategy, etc.

Note that this still doesn't directly allow for a "negative-match" - you need to specify Matchers whose union covers all objects you want to be matched. This is far simpler (in implementation and usage) than constructing fully-featured boolean search of Kubernetes objects on a cluster.

[maxsmythe]

I was wondering if we could add a field (invertMatch or similar) that would effectively throw a NOT in front of the match criteria, turning it from "apply this constraint to all objects who meet all match critera" to "apply this constraint unless the object meets the match critera".

It wouldn't allow for many super-complex statements (nested conditions, for instance), but I'd be wary of making it impossible to index match criteria in the future.

[laimison]

Thanks for the involvement. What @willbeason suggests possibly can be sorted out in Helm templating. It complicates things as we would have larger amount of individual Constraints. One main Constraint + Constraint per excluded namespace. Also some logic in Helm as mentioned. Do I understand it correctly?

This is how I imagine it would work:

# constraint-main
    enforcementAction: deny
    match:
      excludedNamespaces:
      - namespace-a
      - namespace-b

# constraint-namespace-a (this name comes from excludedNamespaces)
    enforcementAction: deny
    match:
      namespaces:
      - namespace-a
      labelSelector:
        matchExpressions:
        - key: app.kubernetes.io/name
          operator: NotIn
          values:
          - deployment-a-1
        - key: app.kubernetes.io/name
          operator: NotIn
          values:
          - deployment-a-2

# constraint-namespace-b (this name comes from excludedNamespaces)
    enforcementAction: deny
    match:
      namespaces:
      - namespace-b
      labelSelector:
        matchExpressions:
        - key: app.kubernetes.io/name
          operator: NotIn
          values:
          - deployment-b-1
        - key: app.kubernetes.io/name
          operator: NotIn
          values:
          - deployment-b-2

If there would be a simplified approach found, that would be still really helpful.

[willbeason]

Yep! That would work for your current use case.