this doesn't support auth feature

[raoofm]

if auth feature is enable then etcd-viewer get unauthorized issue. There is no way to pass user:password for etcd

[nikfoundas]

Can you please provide some further details about your environment?
The latest version of etcd-viewer supports etcd up to version 2.0.x. I think that authentication was added to etcd 2.1. Nevertheless it would be nice to enable authentication on the viewer that would delegate to the etcd server. Would that be sufficient?

[raoofm]

./etcdctl -version
etcdctl version 2.1.0-rc.0

Sure just being able to pass user:pasword to the call would work as right now there is no option to pass user credentials when auth is enabled.
If we can actually have a box to add user : password to connect to the registry then it should do

On a separate note, it would be great if we can do user/role management as we do key/value management today using this viewer. (Though it is great to pass this viewer to the prod admin for key/value maintenance - it makes it much more usable if the admins could manage users/roles as well. I'm thinking of looking into this myself, if time permits)

[nikfoundas]

@raoofmd Thank you very much for you feedback and ideas!
I haven't really checked the etcd authentication api, but I don't believe it would be hard to integrate.
Requesting authentication upon connection (using a modal form for example) sounds great.
User, role management and tuning authorization is a totally separate subject.
Let me have a closer look at the api and I hope I will have a solution pretty soon.
Of course any contributions are always welcomed!

[nikfoundas]

@raoofmd After some studying and experiments I have managed to create a solution that is working, but I still have some open points to resolve and prepare a next release to upload.

1. The solution should be backwards compatible with registries that do not support authentication.
2. Etcd server supports only basic http authentication and each client should provide the Authorization header along with every request. The most appropriate place to store the authentication data is the web session. The web session should keep information about the selected etcd registry, the username and the base 64 encoded value of the authorization header to avoid providing the credentials all the time.
3. When the selected registry is changed the web session with all the authentication data should be erased. Also upon the session timeout the authentication data should expire also and we should configure the session expiration to a reasonable value.
4. Etcd viewer should detect is authentication is enabled on some registry and optionally enable the user to provide the credentials against the etcd registry. If no credentials are provided and anonymous access is allowed you should be able to access the registry.

Etcd server by default has a guest user and guest role and even if authentication is enabled initially you should be able to view and populate the registry without providing any credentials. If you delete the guest role then you start to get unauthorized exceptions. Can you please verify that this is your case?
The etcd server version that I used to perform the tests was 2.1.1.

One last thing ... Have you tried to build the application from the source or are you using the docker based distribution? If you are comfortable using the source I could push some draft changes to the master to have an actual overview and provide some feedback without waiting the next release ...

Looking forward for your response!

[raoofm]

@nikfoundas appreciate for putting the approach together. I would like to discuss the above points:

1. I know that you are trying to support v0.4 of etcd and it can be done, but I think it is the right time to drop supporting v0.4 as etcd is now moving to v3 and I'm aware of plenty of critical issues that v0.4 had, as is it cannot be used in prod. v2 and v3 are more stable, more secure, and stands for high availability that etcd is known for. I think it is good for long term interest and it will be safe to do so and might be the right time to do so.
2. Agree
3. Agree. Just wanted to make sure that the registry is present and the session expires then the next time the user should be allowed to add user credentials. As I see it today I'm unable to modify a registry, I have to delete and create new. In this scenario on switching registries I may loose auth data but not registry, so I should be prompted to add credentials.
4. Agree

Absolutely, I revoked guest user.

I'm using your source, successfully built it using maven3 and deployed on tomcat 7 and 8, jdk8

[nikfoundas]

@raoofm My question regarding the use of the source code was to push some changes and have your feedback prior to releasing the modifications. Please check my latest commit on the master branch which adds support for authentication.

One "quite big" change is that the etcd registry selection is now performed through the top level menu. The selected registry is not stored in the web session any more. So you can navigate multiple registries using different tabs on your browser.

After some discussions with some collegues we decided that authentication information should NOT be erased when switching between registries. Only if you choose to sign out explicitely from some registry or the session expires after 5 minutes or you choose to sign out entirely. So authentication information is kept in the same session for many different etcd registries at the same time.

Authentication information is provided on the top level menu on a form that is visible when the selected registry has authentication enabled and no credentials are yet provided. When you have signed in some registry the Sign out menu appears and you can sign out any user from any registry and sign in as another user.

The registy selection panel on the navigation page is temporarity disabled because I haven't made up my mind where should I put the etcd cluster monitor and management of registries (add/remove etcd cluster).

I would really appreciate your feedback and ideas!

[nikfoundas]

@raoofm I have pushed some more improvements and some bug fixes that were accidentally introduced during the implementation of the auth feature. Please check the latest commits on the master branch.

[raoofm]

@nikfoundas ya noticed that and started debugging those. Good that you have pushed the fixes, let me try that out. Thanks.

[ivan1993spb]

@nikfoundas ping