Skip to content
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

[3.4.0] Documentation (learning-design_auth_v3) : Path to client.go updated #12544

Merged
merged 1 commit into from
Dec 14, 2020

Conversation

sid597
Copy link
Contributor

@sid597 sid597 commented Dec 11, 2020

Currently the path to client.go is : etcdserver/api/v2http/client.go updated this to server/etcdserver/api...

@sid597 sid597 changed the title [3.4.0] Documentation (learning-design_auth_v3) : Path to client.go outdated [3.4.0] Documentation (learning-design_auth_v3) : Path to client.go updated Dec 11, 2020
@@ -25,7 +25,7 @@ The v3 protocol uses gRPC as its transport instead of a RESTful interface like v

The metadata for auth should also be stored and managed in the storage controlled by etcd's Raft protocol like other data stored in etcd. It is required for not sacrificing availability and consistency of the entire etcd cluster. If reading or writing the metadata (e.g. permission information) needs an agreement of every node (more than quorum), single node failure can stop the entire cluster. Requiring all nodes to agree at once means that checking ordinary read/write requests cannot be completed if any cluster member is down, even if the cluster has an available quorum. This unanimous scheme ultimately degrades cluster availability; quorum based consensus from raft should suffice since agreement follows from consistent ordering.

The authentication mechanism in the etcd v2 protocol has a tricky part because the metadata consistency should work as in the above, but does not: each permission check is processed by the etcd member that receives the client request (etcdserver/api/v2http/client.go), including follower members. Therefore, it's possible the check may be based on stale metadata.
The authentication mechanism in the etcd v2 protocol has a tricky part because the metadata consistency should work as in the above, but does not: each permission check is processed by the etcd member that receives the client request (server/etcdserver/api/v2http/client.go), including follower members. Therefore, it's possible the check may be based on stale metadata.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sid597 thanks for your doc update PRs, this looks good to me but if you are working on doc updates for fixing broken paths (due to recent such changes), it would be nice to combine the fixes into a single PR as possible. Great job again with fixes! Thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spzala thanks for the reviews, will do so from next commit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @sid597

@spzala spzala merged commit a3174d0 into etcd-io:master Dec 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants