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 injectionSelectors #2212
add injectionSelectors #2212
Conversation
Hi @liuxu623. Thanks for your PR. I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
3baca62
to
f4a9e5d
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.
/ok-to-test
🤔 🐛 You appear to be fixing a bug in Go code, yet your PR doesn't include updates to any test files. Did you forget to add a test? Courtesy of your friendly test nag. |
f4a9e5d
to
207bea7
Compare
@liuxu623 you need a rebase on this PR as well? |
207bea7
to
bf50c54
Compare
bf50c54
to
0e3ffd4
Compare
No, I didn't discuss this with working group yet... |
0e3ffd4
to
58595f1
Compare
@@ -1063,8 +1063,31 @@ message MeshConfig { | |||
// configured globally via this field. | |||
istio.networking.v1alpha3.HTTPRetry default_http_retry_policy = 62; | |||
|
|||
// A list of Kubernetes selectors that specify the set of namespaces, | |||
// Istio will create istio-ca-root-cert configmap in selected namespaces. |
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.
If this is only for the istio-ca-root-cert configmap it seems like the name namespaceSelectors
is far too broad?
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.
Maybe this could become injectionSelectors
and additionally control whether the sidecar injector accepts an injection request from a namespace?
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.
That is already defined by the mutating webhook; a mesh config setting cannot actually control it at all (unless it becomes an operator for the Webhook)
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 understand, but since scoping the istio-ca-root-cert configmap will allow deploying multiple distinct istiod instances, there may then also be multiple mutating webhook configs that each invoke /inject on the same pod but different webhook services.
An istiod instance with injectionSelector
could return false at injectRequired(), similar to the handling for "special" k8s namespace at https://github.com/istio/istio/blob/098cc47dfcbdca202208bd241d9dee35cd230a4d/pkg/kube/inject/inject.go#L201-L205, if the pod namespace does not match the selector.
I would not currently expect that turning it into an operator for the webhook will be necessary
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.
They should use revisions so they only match their own distinct istio.io/rev
.
if we want to define a full multitenancy proposal then I would recommended we have a holistic design doc on how this will work.
An istiod instance with injectionSelector could return false at injectRequired()
This is much worse than the current Webhook scoping of istio.io/rev, since now ALL istiods are points of failure for a pod starting. Doing it in webhook selector -- which already exists using revision -- filters at the k8s level and does not add single point of failures
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.
@howardjohn John, do you think there is a way with existing methods to solve the isolation of config-map creation, so that I don't have to add an additional namespaceSelector like this.
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 don't understand how istio.io/rev doesn't solve this. It was explicitly designed to handle the case if ensuring different namespace use different control planes for injection. Can you elaborate?
Yes, revisions DO solve parts of the problem. But if we are talking multi-tenancy, each tenant should have its own rootCA and control a subset of namespaces both with and without revisions. This means that the same revision could occur in each tenant and yet be distinct/unrelated. Effectively, xSelectors (placeholder) should represent a namespace boundary beyond which a particular control plane instance should not make changes (s.a. creating config map or injecting proxies).
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.
istio.io/rev can isolate differenet verison istiod,but it seem couldn't isolate multi same verison istiod.
It does, there is no reason they need to be different versions.
This means that the same revision could occur in each tenant and yet be distinct/unrelated.
I don't agree this is valid use case. Kubernetes is fundamentally not entirely multitenant. There are shared resources that Istio depends on - CRDs and webhooks. There must be something distinguishing these between tenants, and some higher level admin ensuring these do not conflict. In Istio, that is revision. If you would like to introduce a different mechanism for this I would suggest a design doc holistically describing how multitenancy is expected to 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.
You are right, CR consumption must also be limited along with the aforementioned CM creation and proxy injection. That is why I had expressed interest when extending discovery selectors to CRs was proposed in istio/istio#36639. But probably it will be better if both are part of the same config toggle instead of having to fine-tune several. And webhooks of course need some attention. I will try to see if I can condense all that into a design doc when I have some time..
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.
In addition to what John mentioned about revisions - assuming we can support multiple instances of the same version of Istiod in the cluster (one for each tenant), each with different revision, would it make sense to make the istio-ca-root-cert config map revision based - i.e istio-ca-root-cert-revision. This would still install configmaps in all namespaces, but each tenant would have its own root of trust?
58595f1
to
987b564
Compare
Do you have a high-level design? There are too many factors to consider for multi-tenants, we need a design. |
@liuxu623: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
https://docs.google.com/document/d/1y4liRJbQW0NCMeQtqMma46flVqs-izV1/ |
🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2022-09-14. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions. Created by the issue and PR lifecycle manager. |
InjectionSelectors
is a list of Kubernetes selectors that specify the set of namespaces, Istio will create istio-ca-root-cert configmap in selected namespaces.If omitted, Istio will create istio-ca-root-cert configmap in all namespaces except kubernetes system namespaces.Fix istio/istio#31115