-
Notifications
You must be signed in to change notification settings - Fork 763
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
chore: moving k8s-native-validation feature to beta #3476
Changes from 6 commits
3c0e5fd
b62e900
9597954
ed5ea6c
6f0cb45
7bf8f8d
7868066
a533a7a
77a685b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -40,6 +40,10 @@ In summary, these are potential options when running Gatekeeper: | |
|
||
Find out more about different [enforcement points](enforcement-points.md) | ||
|
||
:::note | ||
CEL validation in constraint templates through Gatekeeper is in beta and `--experimental-enable-k8s-native-validation` is turned on by default. Set --experimental-enable-k8s-native-validation=false` to disable evaluating CEL in constraint templates. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. https://github.com/open-policy-agent/gatekeeper/pull/3476/files#diff-6f51397980ac58fff52f433210aa369e522c495bdd049d01ae538eaa3b9118b1R6-R8 should be updated too for 3.17 and this text can be added there instead of here.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. CEL validation in Gatekeeper: VAP management through Gatekeeper: |
||
::: | ||
|
||
## Pre-requisites | ||
|
||
- Requires minimum Gatekeeper v3.16.0 | ||
|
@@ -54,22 +58,9 @@ Find out more about different [enforcement points](enforcement-points.md) | |
runtimeConfig: | ||
admissionregistration.k8s.io/v1beta1: true | ||
``` | ||
- Set `--experimental-enable-k8s-native-validation` in Gatekeeper deployments, or `enableK8sNativeValidation=true` if using Helm. | ||
ritazh marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Get started | ||
|
||
### Option 1: Install with Helm | ||
Update the `enableK8sNativeValidation` parameter in values.yaml or set during deployment | ||
- Enable the K8s Native Validating driver to allow users to create CEL-based rules in addition to the OPA driver and rego rules (alpha feature). Default is `false` | ||
```shell | ||
helm install gatekeeper/gatekeeper --name-template=gatekeeper --namespace gatekeeper-system --create-namespace \ | ||
--set enableK8sNativeValidation=true | ||
``` | ||
|
||
### Option 2: Install with Gatekeeper deployment | ||
Edit the applicable deployments (`controller-manager` and `audit`), and update the following commandline flags: | ||
- Set `--experimental-enable-k8s-native-validation=true` | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since we are defaulting to @ritazh @maxsmythe @sozercan any suggestion on place on the doc for this^^? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added a note above in the same file, here - https://github.com/open-policy-agent/gatekeeper/pull/3476/files#diff-6f51397980ac58fff52f433210aa369e522c495bdd049d01ae538eaa3b9118b1R43 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you should mention the flag is beta, default to true, set to false to opt-out |
||
## Policy updates to add CEL | ||
To see how it works, check out this [demo](https://github.com/open-policy-agent/gatekeeper/tree/master/demo/k8s-validating-admission-policy) | ||
|
||
|
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 can't take any action now, but we should not call flags
experimental
in the name againThere 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 we not? "experimental" sends the message "this may break/go away, do not rely on it", I see no undesireable user impact here. If anything, this means users who were using an experiment are put on notice that its behavior is changing and they should double-check that wont be a problem for them.
Are there impacts other than backwards compatibility? Because, again, backwards compatibility is explicitly not a concern for experimental/alpha things.
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.
Also, given this is no longer experimental, we should change the flag name.
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.
Changing or removing flags will cause the pod to crash during in place upgrade. That's not a good experience even if the feature is in alpha. A feature flag can be used in the future even after the feature is stable to allow users to opt-out. Therefore, starting a flag with "experiment" is odd if it can be used in the future after the feature is stable.
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.
My point is that the flag cannot be used in the future, and that is fine. That is why we used "experimental", we should feel free to change the flag name.
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.
One option can be to leave the old flag but render it useless. This would avoid crashing. The flag should still go away eventually.
However, I would still like to understand how/why a Helm chart cannot handle a binary changing its flags.
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.
This is only true if we plan to never allow users to disable a new feature that is in development. If a new feature can be disabled AFTER it is stable, then it should NOT change or have "experimental" in the flag while it is alpha/beta. Do we not want users to ever disable this feature AFTER it is stable? If so, then we just need to deprecate the flag and return warnings for few releases before removing the flag completely. But if we do plan to allow users to disable a feature, then IMO it should NOT start with "experimental".
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.
I refer you to the K8s API definitions for alpha/beta. They have a policy for flags that say alpha flags can be removed immediately:
https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli
I don't think it's reasonable to hold ourselves to a higher standard than K8s itself.
I also return to the meaning of "experimental"/"alpha" which is:
"The developers are still working on this feature. They make no claim to have any idea as to its final behavior or how it will be configured. Breaking changes are expected"
This isn't about whether we want to continue with a feature gate or not, it's that, at the time of implementation, we were not sure whether/how the feature should work or be gated and wanted to warn the user so that they knew breaking changes are expected.
Whether we want to include "experimental" in a flag name in the future or not... I don't really care much either way. So long as users are put on notice that the API/flag is unstable, the core goal is accomplished.
As to the core question of whether its okay to rename a flag that is in alpha, the answer simply has to be yes. For any reason. We could decide a different name more fully communicates the flag's significance, the underlying behavior the flag controls could change, we could simply not like the name.
Beta is when backwards compatibility becomes a concern, and that is why we want to be careful before graduating a feature to beta, and that is why the flag name needs to change now, because we will not be able to change it in the future -- because we will be held to the requirements of being backwards compatible.
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.
I agree if we need to rename a flag before beta it makes sense. i just want to avoid having to rename when we go to beta because we started with
experimental
.I think both of our concerns can be addressed with:
experimental
to avoid having to change it laterIf everyone agrees, I suggest renaming this flag to
enable-k8s-native-validation
since we are moving to beta.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.
Makes sense to me.