-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
fix: mTLS does not work when kubelet does not listen on 127.0.0.1 #27583
Conversation
2cc71e6
to
8e60658
Compare
Nice fix! |
Just marking as do-not-merge until @meyskens has had a chance to review. |
8e3bd19
to
4988031
Compare
@meyskens done |
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
/test |
Signed-off-by: weizhou.lan@daocloud.io <weizhou.lan@daocloud.io>
4988031
to
bf3f813
Compare
it looks like the PR has no business making the 'ConformanceGatewayApi' CI fail ? https://github.com/cilium/cilium/actions/runs/5925798992/job/16065936819 I will try to rebase the main branch
|
/test |
@weizhoublue this was indeed an issue we just fixed on the main branch, thanks for rebasing! |
bug description
with latest version v1.14.1, when kubelet listens on a specified local ip address but not 0.0.0.0, spire agent will fail to contact local kubelet with 127.0.0.1:10250, and mTLS feature does not work at all.
some log on issue enviroment:
when node has multiple network interface, kubelet listens on a specified local address
172.16.1.11
but not0.0.0.0
the spire agent fails to contact kubelet of its local node
it could not find any SPIFFE ID with following command , and mTLS could not work at all
how to fix
referring to spire doc and spire code , spire support to specify the kubelet address with an enviroment named "MY_NODE_NAME"
no matter what the local address listened by the kubelet, the spire agent could succeed to contact its local kubelet with status.hostIP
with this fix, it works well