-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
RFC: protecting membership change RPCs with auth #6899
Comments
mitake
added a commit
to mitake/etcd
that referenced
this issue
Nov 28, 2016
This commit protects membership change operations with auth. Only users that have root role can issue the operations. Implements etcd-io#6899
mitake
added a commit
to mitake/etcd
that referenced
this issue
Dec 6, 2016
This commit protects membership change operations with auth. Only users that have root role can issue the operations. Implements etcd-io#6899
mitake
added a commit
to mitake/etcd
that referenced
this issue
Dec 6, 2016
This commit protects membership change operations with auth. Only users that have root role can issue the operations. Implements etcd-io#6899
mitake
added a commit
to mitake/etcd
that referenced
this issue
Dec 12, 2016
This commit protects membership change operations with auth. Only users that have root role can issue the operations. Implements etcd-io#6899
mitake
added a commit
to mitake/etcd
that referenced
this issue
Dec 15, 2016
This commit protects membership change operations with auth. Only users that have root role can issue the operations. Implements etcd-io#6899
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently membership change RPCs (e.g.
MemberAdd()
) isn't protected by the auth mechanism. As we discussed before, these RPCs should require root role. But The RPCs are a little bit different from other requests so it needs its own customized mechanism. I'd like to share my idea.In the functions e.g.
EtcdServer.AddMember()
, credentials of clients are checked. If the client doesn't have a root role, an error will be returned. If the client has the role, the revision number are set toraftpb.ConfChange
. Let's call the new memberraftpb.ConfChange.AuthRevision
.The ConfChange requests are checked by
RaftCluster.ValidateConfigurationChange()
during its apply phase. In the function, theAuthRevision
is compared with the latest state ofAuthStore
. If the revision is the latest, the check can be passed. If it is old, an error is returned and API functions (e.g.EtcdServer.AddMember()
) will retry.If the changes are reasonable and don't have problems, I'll send a PR.
The text was updated successfully, but these errors were encountered: