-
Notifications
You must be signed in to change notification settings - Fork 129
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
UI shows sensible authentication credentials #50
Comments
That would be great. Over there we went another step fwd, as lenses supports different auth roles (admin/write/read) and proxies REST calls, he have added security on the API layer as well |
I want to point out that this only serves to provide a false sense of security. Is it sane to let users believe their credentials are safe whilst they are not? Maybe a better solution would be to add a button in the UI for show password. This way one |
I guess @andmarios is absolutely right. Neither would it provide actual security, nor would my proposed solution prevent anyone from calling the API directly. Hiding the password only in the UI would be much better and even simpler to implement, but I'm somehow still missing the possibility to not reveal the password anywhere. Do you know if there is an option for Kafka connect applications to use Environment variables or sth. similar to access credentials? |
Unfortunately this is how Kafka Connect is coded. The ideal solution would be for this to be handled at the Connect level —so a kafka patch (connect is part of the Kafka codebase) that will be accepted by the Kafka maintainers. There are other ways to handle it. One is to firewall all connect endpoints and serve them via some middleware proxy that removes passwords. This is the approach we take with our commercial solution (Lenses for Kafka, we will release soon and it will be free for developers, check https://www.landoop.com for more info). Another way would be to change the connector code, so that instead of loading the credentials as configuration properties, it would load them via a file, or an env variable etc and not expose them. This has the downside that this env variable or file should be available to all the workers that run this connector. Configuration properties are the way to share configuration between workers, everything else should be made available to all. For the first two solutions, there is an extra problem. The credential fields aren't common between connectors. So any solution would need some heuristics, maybe basic, such as if the field contains the string password but still there will always be the possibility of exposing a sensitive field. Ideally if the solution come within the Connect framework, there will be an option to set the field as sensitive. |
Hi,
first, thanks for this nice Interface.
While playing around with your UI and the MongoDB sink connector, we had to establish authentication against the database. Once the settings were defined, the UI always reveals the password in plaintext.
I would request any connector properties ending with 'password' to be replaced with some asterisk chars.
If you like this feature, I would like to submit a pull request in the next couple days.
Kind regards
Cedric
The text was updated successfully, but these errors were encountered: