-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Add common config validation service #4811
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
Add common config validation service #4811
Conversation
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
- kind: ServiceAccount | ||
name: istio-galley-service-account | ||
namespace: {{ .Release.Namespace }} | ||
{{- end }} |
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.
add last blank line
- enduserauthenticationpolicyspecs | ||
- enduserauthenticationpolicyspecbindings | ||
- serviceroles | ||
- servicerolebindings |
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.
missing policy.authentication.istio.io
validation. This uses the existing pilot and mixer validation code for now. The k8s webhook specific code, cert provisioning, and registration has been copied from the sidecar-injector. This service is optional (requires >= k8s 1.9) so I created a new component. Instead of creating a throwaway service (i.e. config-validator), and since Galley will be responsible for config validation anyway, I went ahead and created the galley component, charts, etc. The validation service is run from the `validator` subcommand. fixes istio#1894 TODO - [ ] add integration test - [ ] update e2e test(s) to use server-side validation - [ ] update istio.io documentation
dcec14d
to
08afacb
Compare
Codecov Report
@@ Coverage Diff @@
## master #4811 +/- ##
=======================================
+ Coverage 72% 73% +1%
=======================================
Files 302 300 -2
Lines 25376 25035 -341
=======================================
- Hits 18189 18076 -113
+ Misses 6446 6227 -219
+ Partials 741 732 -9
Continue to review full report at Codecov.
|
@@ -144,13 +144,11 @@ var ( | |||
// TODO: move it to a configmap later when we have more services to support. | |||
webhookServiceAccounts = []string{ | |||
"istio-sidecar-injector-service-account", | |||
"istio-mixer-validator-service-account", | |||
"istio-pilot-service-account", | |||
"istio-galley-service-account", |
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.
fyi @yusuoh
cc @mandarjog for helm/install review and top-level OWNERS approval |
galley/cmd/gals/cmd/root.go
Outdated
) | ||
|
||
// resolveConfig checks whether to use the in-cluster or out-of-cluster config | ||
func resolveConfig(kubeconfig string) (string, error) { |
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 all of this? (It looks like this is from Pilot?).
In the code I have, I just ask for config and use BuildConfigFromFlags (I'd prefer to be very explicit with the user, but that's just me.)
If we do indeed keep this, can we move this to to a common package in istio/pkg/? It looks like this should be standardized among all command-line tools expecting a config.
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.
Simple is good. I removed resolvedConfig in favor of calling BuildConfigFromFlags directly with kubeconfig.
galley/cmd/gals/cmd/root.go
Outdated
} | ||
if kubeconfig == "" { | ||
defaultCfg := path.Join(homedir.HomeDir(), ".kube/config") | ||
fmt.Printf("(3) %v\n", defaultCfg) |
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.
Runaway Printf?
galley/cmd/gals/cmd/validator.go
Outdated
) | ||
|
||
// waitSignal awaits for SIGINT or SIGTERM and closes the channel | ||
func waitSignal(stop chan struct{}) { |
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.
Seems like we can use this for other commands as well. Hoist to a different file?
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 created isto.io/istio/pkt/cmd/
for common command functions.
webhookConfigName, err) | ||
select { | ||
case <-stop: | ||
// canceled by caller |
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 : cancelled
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.
https://www.grammarly.com/blog/canceled-vs-cancelled. Given my emacs dictionary is american I chose "cancel". :)
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.
crikey. :)
galley/cmd/gals/cmd/validator.go
Outdated
}, | ||
} | ||
|
||
validatorCmd.PersistentFlags().StringVar(&webhookConfigName, |
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.
Why do we need the webhook-name flags? Seems like these should be constant.
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.
For testing purposes in a shared cluster we might need to scope Istio to a single namespace. Multiple validation webhooks would exist and their names ought to be unique.
stop := make(chan struct{}) | ||
|
||
go func() { | ||
if err := patchCert(stop); err != nil { |
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 when patchCert fails? It looks like the webhook will still try to serve?
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.
Validation will be broken. The webhook will continue to serve but api-server won't call it. The sidecar injector has a similar problem. I'm hoping the environments WG can address this problem as part of k8s install/upgrade process. cc @yusuoh
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.
sidecar injector service will fail if it cannot patch the cert after several retries.
https://github.com/istio/istio/blob/master/pilot/cmd/sidecar-injector/main.go#L86
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 have a tracking bug for this? It would be nice to tag this with a TODO with reference to the bug (otherwise it will most likely get lost and lurk as an issue).
galley/pkg/crd/validation/webhook.go
Outdated
|
||
// CreateMixerValidator creates a mixer backend validator. | ||
func CreateMixerValidator(kubeconfig string) (store.BackendValidator, error) { | ||
info := generatedTmplRepo.SupportedTmplInfo |
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.
These seem problematic. Specifically, this depends on Mixer's own built-in templates, which effectively exposes Mixer internals to Galley. (which is also apparent from the imports in this file).
I wasn't expecting to pull this much Mixer code into Galley. Would it be better if we split this CR and do some refactoring before implementing the webhook in Galley?
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.
Per our offline discussion I'd prefer to reverse the order since config validation is P0 for Istio 1.0. I created #4887 to track the follow-up refactoring.
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.
@geeknoid
FYI. Hopefully, after Mandar lands CRD normalization, we can start utilizing a declarative config check for adapter configs and reduce the scope of dependencies to Mixer to the pkg/ level.
} | ||
case err := <-wh.watcher.Error: | ||
log.Errorf("Watcher error: %v", err) | ||
case <-healthC: |
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.
Why do we need the health check file here? Is this needed for web hooks in general?
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.
All Istio components should have health checks. https://goo.gl/QRRdwm recommends that components use file based health checking.
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.
Yes, but can we move this to use the standard health-check library?
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.
A bit too large to understand, but it's good to move it out of pilot.
I don't think this was enabled in pilot - so would feel more comfortable with keeping it off by default in 0.8.
@@ -8,6 +8,9 @@ global: | |||
sidecar-injector: | |||
enabled: true | |||
|
|||
galley: | |||
enabled: true |
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 it be enabled by default in 0.8 ? What are the dependencies / setup / etc ?
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.
k8s >= 1.9
Config validation is targeted BETA for 1.0. I could disable for 0.8 but would like to (re)enable for 0.9 for additional testing prior to 1.0.
@ayj PR needs rebase |
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
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: costinm, xiaolanz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test all [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue. |
Create a common webhook service for server-side configuration validation. This uses the existing pilot and mixer validation code for now. The k8s webhook specific code, cert provisioning, and registration has been copied from the sidecar-injector.
This service is optional (requires >= k8s 1.9) so I created a new component. Instead of creating a throwaway service (i.e. config-validator), and since Galley will be responsible for config validation anyway, I went ahead and created the galley component, charts, etc. The validation service is run from the
validator
subcommand.fixes #1894
TODO in follow-up PRs