-
Notifications
You must be signed in to change notification settings - Fork 4.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
Expose hubble agent when hubble is enabled #11314
Conversation
@@ -190,6 +190,9 @@ data: | |||
enable-hubble: "true" | |||
# UNIX domain socket for Hubble server to listen to. | |||
hubble-socket-path: "/var/run/cilium/hubble.sock" | |||
# An additional address for Hubble server to listen to (e.g. ":4244"). | |||
hubble-listen-address: ":4244" | |||
hubble-disable-tls: "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.
I'm not a big fan of exposing things without TLS.
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.
Nor do I. But it is a choice of this staying broken in 1.20 or having the feature, but no tls. For 1.21 this will hopefully be fixed
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 would prefer not having the feature. There is nothing as permanent as a temporary shortcut.
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.
So you suggest blocking hubble from being enabled through validation? The flag is already there, so we cannot remove this altogether.
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'll implement serving TLS, but mTLS will be more tricky as kops-controller doesn't have any way of provisioning certs to Deployments.
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 could have kops provision a Keypair
and then render it to a Secret
using a template function.
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.
...ah, that would make the addons manifest secret. We've had a conversation like this before. Perhaps an auxiliary manifest-like thing which provisions secrets from the keystore.
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.
By the way, kops-controller certs have lifetimes that are tied to nodes. Deployments would need a different lifetime and renewal mechanism. This is why people tend to use JWT over mTLS--Kubernetes has the infrastructure for the former.
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.
Turns out cilium starts normal operations, then wait for the availability of the certificate. So there really isn't any chicken/egg issue here wrt cert-manager.
I have deployed addon PKI + 3 certs (hubble server cert, relay client cert, relay server cert) and tried to get them to work, but something in the mTLS setup is failing. It works when I connect with hubble CLI using the same certs and flags that hubble-relay is supposed to have.
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.
My problems were caused by our addon CAs only setting common name. This PR contains a workaround now, but we need to resolve the CA certificate problem later on.
a9cead7
to
659e97a
Compare
2fbecb4
to
5cfe5f5
Compare
path: server.key | ||
name: tls | ||
--- | ||
apiVersion: cert-manager.io/v1alpha2 |
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.
Shouldn't this be v1 already?
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.
ouch yes. not sure how v1alpha2 made it there. thanks for catching
5cfe5f5
to
097a6a6
Compare
097a6a6
to
20455af
Compare
fyi, I have this PR merged and running in one of our clusters and already succesfully used it to debug network failures. |
I am not sure why hubble-ui is failing. but this still solves the hubble issue, so I think we can just merge it. |
Looks like hubble-ui is failing for 2 different reasons:
So, for this PR, I assume that at least 2. should be fixed first. |
Also enables PKI for the addon
20455af
to
7c0be99
Compare
There. Now it works for me. We'll just have to live with relay TLS false when the UI doesn't support TLS. |
/test all |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hakman 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 |
…314-origin-release-1.20 Automated cherry pick of #11314: Expose hubble agent when hubble is enabled
/kind bug