-
Notifications
You must be signed in to change notification settings - Fork 732
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
Provide the flag for disable unsafe builtins #1191
Conversation
fc1c58f
to
ff909dd
Compare
Codecov Report
@@ Coverage Diff @@
## master #1191 +/- ##
==========================================
- Coverage 49.98% 49.86% -0.13%
==========================================
Files 64 65 +1
Lines 4469 4470 +1
==========================================
- Hits 2234 2229 -5
- Misses 1926 1932 +6
Partials 309 309
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Can we add a test in e2e to validate this? Although, this might be hard to do since there is no easy way to add flag without helm charts etc |
We add flags in parts of the Makefile. What do you think about:
|
main.go
Outdated
@@ -109,6 +110,7 @@ func init() { | |||
_ = statusv1beta1.AddToScheme(scheme) | |||
_ = mutationsv1alpha1.AddToScheme(scheme) | |||
// +kubebuilder:scaffold:scheme | |||
flag.Var(disabledBuiltin, "disable-builtin", "disable opa built-in function, this flag can be declared more than once.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: disabledBuiltins
plural for the variable name, as it's a slice. The flag name is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any guidance we can provide on what valid builtins are for this flag? Can we link to OPA documentation for example?
main.go
Outdated
@@ -231,7 +233,7 @@ func setupControllers(mgr ctrl.Manager, sw *watch.ControllerSwitch, tracker *rea | |||
<-setupFinished | |||
|
|||
// initialize OPA | |||
driver := local.New(local.Tracing(false)) | |||
driver := local.New(local.Tracing(false), local.DisableBuiltins(disabledBuiltin.ToSlice()...)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to worry about duplicate strings in the slice, or is that handled elsewhere?
I was thinking adding the disable-builtin flag in deploy yaml used by e2e OR patch the deployment in the test runtime. |
main.go
Outdated
@@ -109,6 +110,7 @@ func init() { | |||
_ = statusv1beta1.AddToScheme(scheme) | |||
_ = mutationsv1alpha1.AddToScheme(scheme) | |||
// +kubebuilder:scaffold:scheme | |||
flag.Var(disabledBuiltin, "disable-builtin", "disable opa built-in function, this flag can be declared more than once.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should the flag be called disable-opa-builtin
to be more explicit?
Is this only a runtime error that is returned when the constraintTemplate/rego is executed? How does the error get bubbled up? Is it only visible in GK logs? Is there any validation for this when the constraintTemplate is deployed so that the policy owner can act on this? |
I think this would wind up being a compile-time error and be reported on the CT's status? |
Modifying the deploy yaml would probably be less flaky. Fewer moving parts at that time. |
92b03d8
to
093e48e
Compare
Thinking about the user experience. Is it possible to block/validate the CT from being created/updated or at least give an error/warning if an opa builtin is found in the rego but it's part of this disable list? |
That seems like a significant scope increase. Currently any unrecognized function only fails at compilation time and gets reported on status:
Running compilation as part of the webhook would put us at risk of timing out (compilation can take a while) |
Definitely not suggesting this. I was thinking if we could statically identify this is used in the rego. Like say look for specific string values? |
I don't think we can reliably do static analysis without compilation here, unfortunately. Simple string matching risks matching against non-active code (e.x. denying a constraint template because there is a comment: Removing the unsafe function from Rego's lexicon and relying on the compiler to find unbound references is the only reliable method AFAIK. |
47c15cd
to
d94f572
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -69,6 +69,7 @@ spec: | |||
- --exempt-namespace={{ .Release.Namespace }} | |||
- --operation=webhook | |||
- --enable-mutation={{ .Values.experimentalEnableMutation}} | |||
- --disable-opa-builtin={{ .Values.builtinHttpSend }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens here if no value is provided? Will this still work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works with unset value in this case, but seems like a good idea to remove empty string in FlagSet.ToSlice().
package k8sdenynamehttpsend | ||
violation[{"msg": msg}] { | ||
input.review.object.metadata.name == input.parameters.invalidName | ||
response := http.send({"method": "get", "url": "https://github.com/"}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ironically, any kind of "get" in our tests makes me nervous. It's a good thing this is disabled!
cmd/build/helmify/static/values.yaml
Outdated
@@ -70,3 +70,4 @@ pdb: | |||
controllerManager: | |||
minAvailable: 1 | |||
service: {} | |||
builtinHttpSend: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably want to name this something like disabledBuiltins
and allow it to take a list of disabled builtins. Helm chart users may want to disable more than HTTP send
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on naming and we need a default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed the variable into a list, that solves the unset --disable-opa-builtin
for us.
It looks like the upgrade test is failing because --disable-opa-builtin isn't getting set for that test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
charts/gatekeeper/templates/gatekeeper-controller-manager-deployment.yaml
Outdated
Show resolved
Hide resolved
Signed-off-by: Becky Huang <beckyhd@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Becky Huang beckyhd@google.com
What this PR does / why we need it:
Provide the flag allowing us to set
--disable-builtin=http.send
to toggle off opa http.send builtinWhich issue(s) this PR fixes (optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when the PR gets merged):Fixes #1137
Special notes for your reviewer:
Reused the flag struct implemented by exempt-namespace, it's now moved to util package.