-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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 kubernetes registry in front of ServiceEntry #51003
Conversation
for i, r := range c.registries { | ||
if r.Provider() != provider.Kubernetes { | ||
// insert the registry in the position of the first non kubernetes registry | ||
newRegistries := make([]*registryEntry, len(c.registries)+1) |
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: can we use slices.Insert to avoid this complex code
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.
good to know that function.
Any impact on backwards compatibility ?
Should we prevent WE from using the same IP as a pod instead ? Any security
implications ?
…On Sun, May 12, 2024 at 9:07 PM hzxuzhonghu ***@***.***> wrote:
*Please provide a description of this PR:*
Fix #50968 <#50968>
Without this we can get proxy labels from WLE when the wle's address = pod
ip
------------------------------
You can view, comment on, or merge this pull request online at:
#51003
Commit Summary
- 777917f
<777917f>
add kubernetes registry infront of serviceentry
- 6f4d577
<6f4d577>
add test
- 01185dd
<01185dd>
add release note
File Changes
(3 files <https://github.com/istio/istio/pull/51003/files>)
- *M* pilot/pkg/serviceregistry/aggregate/controller.go
<https://github.com/istio/istio/pull/51003/files#diff-4ab8bb2188afa1dc914f11b5eaab7e1a544454457d25ef3841fdb6f2c23b1d7b>
(19)
- *M* pilot/pkg/serviceregistry/aggregate/controller_test.go
<https://github.com/istio/istio/pull/51003/files#diff-dc650829e52b22a3c617acbdae1a4056d9b30786e674aeaf6a8d4deb6a9aa159>
(19)
- *A* releasenotes/notes/serviceregistry-order.yaml
<https://github.com/istio/istio/pull/51003/files#diff-d969d95e5d54d68d378c17658dfcfc4441a6c3512d6f6f10b78f25d7540a0483>
(8)
Patch Links:
- https://github.com/istio/istio/pull/51003.patch
- https://github.com/istio/istio/pull/51003.diff
—
Reply to this email directly, view it on GitHub
<#51003>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUR2TR6HQGL5GTVVIR5XDZCA4BNAVCNFSM6AAAAABHTNN2FCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4TCNZVHEZTQMY>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
That can not be 100% possible.
@costinm Maybe no, and in services ordering we have already sort kubernetes service before serviceentry |
On Tue, May 14, 2024 at 7:38 PM hzxuzhonghu ***@***.***> wrote:
Should we prevent WE from using the same IP as a pod instead ? Any security
implications ?
That can not be 100% possible.
We do build a map from IP to 'workload info' - so it should not be
impossible to detect.
Or giving users a mechanism to set CIDR ranges allowed for WE ( assigned to
their VMs
and separate from the Pod/Services CIDR).
To be fair - Endpoints and EndpointSlices don't seem to have any protection
either. I don't remember
if we still consume them (for the 'custom' EndpointSlices and selector-less
cases ).
Any impact on backwards compatibility ?
@costinm <https://github.com/costinm> Maybe no, and in services ordering
we have already sort kubernetes service before serviceentry
I see, so this will sort Pods before WE ?
I think it's reasonable - we don't make guarantees and it's probably
something wrong if users set pod IPs in WE.
+1 from me.
|
OK, i know your point. We can do that in istiod. I meant we cannot prevent it from creating with validating webhook |
It seems out certificate used for test has expired again
|
/retest-required |
/test integ-pilot-istiodremote-mc |
1 similar comment
/test integ-pilot-istiodremote-mc |
In response to a cherrypick label: #51003 failed to apply on top of branch "release-1.21":
|
In response to a cherrypick label: new issue created for failed cherrypick: #51055 |
In response to a cherrypick label: #51003 failed to apply on top of branch "release-1.20":
|
In response to a cherrypick label: new issue created for failed cherrypick: #51056 |
In response to a cherrypick label: new pull request created: #51057 |
In response to a cherrypick label: #51003 failed to apply on top of branch "release-1.21":
|
In response to a cherrypick label: new issue created for failed cherrypick: #51058 |
In response to a cherrypick label: #51003 failed to apply on top of branch "release-1.20":
|
In response to a cherrypick label: new issue created for failed cherrypick: #51059 |
In response to a cherrypick label: new pull request could not be created: failed to create pull request against istio/istio#release-1.22 from head istio-testing:cherry-pick-51003-to-release-1.22: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"A pull request already exists for istio-testing:cherry-pick-51003-to-release-1.22."}],"documentation_url":"https://docs.github.com/rest/pulls/pulls#create-a-pull-request"} |
In response to a cherrypick label: #51003 failed to apply on top of branch "release-1.20":
|
In response to a cherrypick label: new issue created for failed cherrypick: #51060 |
In response to a cherrypick label: #51003 failed to apply on top of branch "release-1.21":
|
In response to a cherrypick label: new issue created for failed cherrypick: #51061 |
In response to a cherrypick label: new pull request could not be created: failed to create pull request against istio/istio#release-1.22 from head istio-testing:cherry-pick-51003-to-release-1.22: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"A pull request already exists for istio-testing:cherry-pick-51003-to-release-1.22."}],"documentation_url":"https://docs.github.com/rest/pulls/pulls#create-a-pull-request"} |
Please provide a description of this PR:
Fix #50968
Without this we can get proxy labels from WLE when the wle's address = pod ip