KNOX-2997 - Add kafka ui support in service definition. #830
Conversation
|
issuse: KNOX-2997 |
| <param> | ||
| <name>responseExcludeHeaders</name> | ||
| <value>WWW-AUTHENTICATE</value> | ||
| </param> |
There was a problem hiding this comment.
Hmmm - why is this necessary here? Generally speaking, a request shouldn't get to the actual endpoint without Knox authenticating the user and then knox itself should be authenticating to the proxied endpoint as the knox user via kerberos. I feel like if you found this was necessary then there was something else fundamentally wrong.
There was a problem hiding this comment.
Hi lmccay, you are right, I will improve my pr to suit the case of kerberos authentication.
There was a problem hiding this comment.
I want to make sure that we are clear on what is expected. Please excuse me if I explain something you already know but this is important to have clear for Knox contributions like this.
Knox is a trusted proxy or proxyuser in the hadoop ecosystem. That means that it will authenticate users in some knox admin configured manner and tell the backend service the identity of the authenticated user. The backend service trusts Knox to assert this identity because the knox user is authenticated to the service via kerberos in addition to the authenticated user's identity being sent as a doas param. So, there are many front end authentication methods available through Knox (including but not limited to kerberos) and kerberos is required between Knox and the backend service that is being proxied.
So, the fact that you have excluded the WWW-AUTHENTICATE header points to something that you were likely working through in you dev env. Perhaps, you don't have kerberos enabled and the proxyuser settings for kafka set to included Knox or something like that.
Bottom line is that you shouldn't have to do anything with the authentication header from the proxied service to Knox for the kerberos challenge in the service definition. So, we have to figure out why you found that you needed to.
There was a problem hiding this comment.
Thank you for your guidance, lmccay. I use Knox with LDAP users logging in through Knox SSO. Since Kafka does not support Kerberos authentication and is a simple UI proxy, I did not notice any impact of excluding the WWW-AUTHENTICATE content. In the early stages, when writing the service.xml, I referred to the approach of Ranger UI, which interfaces with Knox SSO instead of communicating with Knox backend through Kerberos. Ranger UI includes the exclusion of WWW-AUTHENTICATE content, and I forgot to remove it when developing Kafka UI. This is my oversight, and I apologize for it.
There was a problem hiding this comment.
No worries, just wanted to make sure that you didn't add it for some issue that you encountered. I wasn't aware that Ranger is excluding that. Interesting. This shouldn't be necessary even with native KnoxSSO support. I'll have to look into that separately.
There was a problem hiding this comment.
@upczsh - hmm - if kafka doesn't support kerberos then how is it working with Knox? Are you not proxying the in order to get KnoxSSO support? There really aren't really anymore services that are natively supporting KnoxSSO that are not supporting proxy based SSO.
Before services like Ranger supported trusted proxies, they still were proxied by Knox but implemented the authentication themselves. You can see some evidence of this in the Ranger 0.5.0 version service.xml file. They force the authentication provider to be Anonymous. Knox doesn't try and to authenticate the user for services that have that and send a doas=anonymous then the service can do the authentication - including native support for KnoxSSO.
If that is what you are looking to do then you may need to add the policies element that Ranger has in its 0.5.0 service.xml.
There was a problem hiding this comment.
Based on your screenshots, it does seem that you are proxying access to the the UI. So, I think we need to consider that policies override approach.
There was a problem hiding this comment.
@lmccay Happy 2024😄. As we know, knox supports kerberos by adding kerberos authentication information to the HTTP request to interact with kafka ui. If kafka does not have its own authentication system (without kerberos or simple authentication, anyone can access its UI), then This HTTP request can still be successful, so the proxy can be successful.
On the other hand, I don't understand what ''Policy overrides method'' means, what do I need to do to improve it?
thanks！
(It is very important that you created an Apache Knox JIRA for this change and that the PR title/commit message includes the Apache Knox JIRA ID!)
What changes were proposed in this pull request?
Apache Kafka is a distributed streaming platform initially developed by LinkedIn and later open-sourced as an Apache Software Foundation project. Designed for handling real-time data streams, Kafka supports high throughput, persistent storage, and horizontal scalability.kafka has its own ui.
We can support it in knox service definition.
How was this patch tested?