-
Notifications
You must be signed in to change notification settings - Fork 9.9k
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
etcd v2 auth guest role not working in non tls mode #6075
Comments
Please try ./etcdctl --endpoints=http://localhost:2379 mk key1 value1
./etcdctl --endpoints=http://localhost:2379 user add root
./etcdctl --endpoints=http://localhost:2379 auth enable
./etcdctl --endpoints=http://localhost:2379 -u root:password get key1
# Without password, it will error
# Error: 110: The request requires user authentication (Insufficient credentials) [0] And I believe this is the correct behavior. In versions prior to ./etcdctl --endpoints=http://localhost:2379 get key1 @xiang90, or did we expect this to work in etcd version 2? |
If auth == "" && we cannot find the user. we should mark it as "" again. "" might mean guest. |
@xiang90 Ok, I will try to fix it with tests. Thanks. |
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Aug 1, 2016
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Aug 1, 2016
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Aug 1, 2016
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Aug 1, 2016
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Aug 1, 2016
gyuho
added a commit
that referenced
this issue
Aug 4, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
in etcd v3.0.4, guest role is not working in default installation, when tls had not been configured.
Steps to reproduce
Try to get key1 uysing ./etcdctl get key1 , it fails with an error
Error: 110: The request requires user authentication (Insufficient credentials) [0]
The same test case is working for etcd v 3.0.3 and previous versions.
As far as I can see, this is because of the line
in ./etcdserver/api/v2http/client_auth.go
In my case I think clientCertAuthEnabled is not enabled as I am not using tls.
Please confirm if the change in behavior is intended or if this is a bug.
The text was updated successfully, but these errors were encountered: