Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: annotating rule for namespaces/excludedNamespaces #106

Closed
dulltz opened this issue Dec 14, 2020 · 5 comments
Closed

Feature Request: annotating rule for namespaces/excludedNamespaces #106

dulltz opened this issue Dec 14, 2020 · 5 comments

Comments

@dulltz
Copy link
Contributor

dulltz commented Dec 14, 2020

Like #93, I'd like to support annotating rules that generate spec.match.namespaces and spec.match.excludedNamespaces.

Examples

# @namespaces kube-system gatekeeper-system
package foo

import data.lib.core
...

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: Foo
metadata:
  name: foo
spec:
  match:
    namespaces:
      - kube-system
      - gatekeeper-system

# @ excludednamespaces kube-system gatekeeper-system
package foo

import data.lib.core
...

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: Foo
metadata:
  name: foo
spec:
  match:
    excludedNamespaces:
      - kube-system
      - gatekeeper-system
@dulltz dulltz changed the title Feature Request: annotating rule for namespace/excludedNamespaces Feature Request: annotating rule for namespaces/excludedNamespaces Dec 14, 2020
@jalseth
Copy link
Collaborator

jalseth commented Jan 25, 2021

Hi @dulltz, sorry for the delay in response. Looking back, I think I may have moved too quickly when moving forward with #93 as it somewhat goes against Konstraint's original goal of enabling the same policies to be used with Conftest and then deployed in the cluster with Gatekeeper, since these @ tags add the matching metadata to the Gatekeeper resources, but won't have any effect when using Conftest.

I understand that some people may not use Conftest, and may instead test with gvk or similar tools so I'm hoping to find a middle ground. What are your thoughts on adding a lib.matching Rego lib with helpers that would accomplish the same matching that we're adding here, but using Rego rather than the Gatekeeper CRDs to match? This way, there is feature parity either way people decide to use the tool.

@dulltz
Copy link
Contributor Author

dulltz commented Jan 31, 2021

I totally agree with @jalseth 's opinion.

Since users who use the Gatekeeper match field will have to manually edit the generated custom resource,
we should focus on the #56 issue.

@jalseth
Copy link
Collaborator

jalseth commented Jan 31, 2021

In that case, adding a @skip-constraint option in the Rego header may be the best way forward. That way if users want to manually manage the Constraints for a given policy and set matchers, parameters, etc. they can. If that approach is agreeable I can add that in the next couple of days.

@jalseth
Copy link
Collaborator

jalseth commented Feb 13, 2021

@dulltz The tag was added in #130 and will be included in the next release.

@jpreese
Copy link
Collaborator

jpreese commented Mar 7, 2021

@skip-constraint released in v0.12.0

@jpreese jpreese closed this as completed Mar 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants