gatekeeper: Rego "import future.keywords.in" causes template failure
What steps did you take and what happened:
After using konstraint to create a ConstraintTemplate YAML file, then doing “helm install” to install the file, I got the following error:
Error: admission webhook "validation.gatekeeper.sh" denied the request: 1 error occurred: templates["admission.k8s.gatekeeper.sh"]["VaultSecretPath"]:4: rego_parse_error: unexpected import path, must begin with one of: {data, input}, got: future
import future.keywords.in
What did you expect to happen:
I expected there not to be any errors. https://www.openpolicyagent.org/docs/latest/policy-language/#membership-and-iteration-in documents that Opa uses the notation “import future.keywords” to allow new constructs, in this case, the “in” keyword. That link also shows a sample Rego file that uses the “in” keyword.
Anything else you would like to add: In vendor/github.com/open-policy-agent/opa/ast/parser.go I see code for WithFutureKeywords(), WithAllFutureKeywords(), futureParser(), and “var futureKeywords” so maybe this is just missing documentation, in that there’s a Helm value or a command line arg that enables “import future…”? I’ve searched all the code and the whole Helm chart and if such a flag or option or parameter is there, I can’t find it (maybe because I don’t know exactly what to look for?).
Environment:
- Gatekeeper version: v3.7.0
- Kubernetes version: (use
kubectl version): 1.20.2
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 66 (43 by maintainers)
@maxsmythe Yes - I’m fixing this and moving it to be an option on Driver. Client shouldn’t care about this, and it makes sense as a Driver configuration. There’s never a reason to change this at runtime, so it will be an immutable part of Driver specified via an Arg in the constructor.
💭 Perhaps it would be useful to mention the OPA version used in a GK version more prominently? I’ve thought about using badges before, like
, but these would have to be updated manually, too.
@ritazh https://github.com/open-policy-agent/frameworks/pull/217
GK 3.8.0 pins frameworks to https://github.com/open-policy-agent/frameworks/releases/tag/v0.5.0 while this change was added after that in https://github.com/open-policy-agent/frameworks/commit/370fa375b0a7926f324083bd7bc31dae0ae9ef78
Release v3.9.0-beta.1 cut!
https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.9.0-beta.1
Per community call, we have decided to cut v3.9.0-beta.1 to include this change.
@maxsmythe My tests pass with ffea423. Any chance of getting a 3.8.2 release that includes this fix? If so, roughly how long would that take?
Thanks again, Adam
@maxsmythe @willbeason I did get the same error – but something else I’m working on is making me just a tiny bit suspicious that something with my company’s Docker repo proxy and/or Docker image cache is affecting things. I’ll spend some time today bringing up an instance somewhere not on my company’s network and see if I can reproduce the problem there.
@willbeason Oy! Sorry, yes – I had found that error and fixed it, but not updated my test files. Doh! My apologies for putting you through all the extra work. Tomorrow I’ll fix that and test using rc2 and the latest Helm chart.
That’s perfect! I’ll try to replicate and check back in the next couple days.
@willbeason, @maxsmythe: Any idea when this change will make it into a release (3.7.x or 3.8)? Please understand that I’m not trying to rush you or put pressure on you, I just need to schedule some other work so it would help me if I had an idea of when this might be ready? Thanks.
also, @srenatus thanks for digging in!
Opa upgrade now comes from framework. Can you try latest commit in master? that is referencing framework that’s using opa v0.35 https://github.com/open-policy-agent/frameworks/pull/167/files#diff-45830b37d8fe6cfa6317672df498ec856ff48ffd48cd2537d18337e6281d6618R14
+1 on showing opa version badge in master, and perhaps for each release doc. thoughts?