Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Conversation

liuxu623
Copy link

@liuxu623 liuxu623 commented Jan 20, 2022

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

@istio-testing istio-testing added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Jan 20, 2022
@istio-testing
Copy link
Collaborator

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@istio-testing istio-testing added the needs-rebase Indicates a PR needs to be rebased before being merged label Jan 20, 2022
@istio-testing istio-testing removed the needs-rebase Indicates a PR needs to be rebased before being merged label Jan 21, 2022
Copy link
Member

@Arhell Arhell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/ok-to-test

@istio-testing istio-testing added ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. and removed needs-ok-to-test labels Jan 28, 2022
@istio-policy-bot
Copy link

🤔 🐛 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.

@istio-testing istio-testing added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jan 28, 2022
@istio-testing istio-testing added the needs-rebase Indicates a PR needs to be rebased before being merged label Feb 16, 2022
@kfaseela
Copy link
Member

@liuxu623 you need a rebase on this PR as well?

@istio-testing istio-testing added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. and removed needs-rebase Indicates a PR needs to be rebased before being merged size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Feb 25, 2022
@istio-testing istio-testing added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Feb 25, 2022
@liuxu623
Copy link
Author

@liuxu623 you need a rebase on this PR as well?

@kfaseela Please help me review code, thank you.

@kfaseela
Copy link
Member

@liuxu623 you need a rebase on this PR as well?

@kfaseela Please help me review code, thank you.

sure..will do.. but considering this is an API change, I assume you would have already discussed this in one of the working group meetings, and got a consensus for this enhancement?

@liuxu623
Copy link
Author

@liuxu623 you need a rebase on this PR as well?

@kfaseela Please help me review code, thank you.

sure..will do.. but considering this is an API change, I assume you would have already discussed this in one of the working group meetings, and got a consensus for this enhancement?

No, I didn't discuss this with working group yet...

@@ -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.
Copy link
Member

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?

Copy link

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?

Copy link
Member

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)

Copy link

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

Copy link
Member

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

Copy link
Author

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.

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).

Copy link
Member

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.

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..

Copy link

@shankgan shankgan Mar 16, 2022

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?

@liuxu623 liuxu623 changed the title add namespaceSelectors add injectionSelectors Mar 10, 2022
@hzxuzhonghu
Copy link
Member

Do you have a high-level design? There are too many factors to consider for multi-tenants, we need a design.

@istio-testing
Copy link
Collaborator

@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.

@istio-testing istio-testing added the needs-rebase Indicates a PR needs to be rebased before being merged label Mar 16, 2022
@kfaseela
Copy link
Member

Do you have a high-level design? There are too many factors to consider for multi-tenants, we need a design.

https://docs.google.com/document/d/1y4liRJbQW0NCMeQtqMma46flVqs-izV1/

@howardjohn howardjohn removed the needs-rebase Indicates a PR needs to be rebased before being merged label May 15, 2024
@istio-policy-bot
Copy link

🚧 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.

@istio-policy-bot istio-policy-bot added the lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. label May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multi-Istio deployments in same k8s cluster
9 participants