Role-based access control
Special users and roles
There is one special user, root
, and one special role, root
.
The root
user, which has full access to etcd, must be created before activating authentication. The idea behind the root
user is for administrative purposes: managing roles and ordinary users. The root
user must have the root
role and is allowed to change anything inside etcd.
Role root
The role root
may be granted to any user, in addition to the root user. A user with the root
role has both global read-write access and permission to update the cluster’s authentication configuration. Furthermore, the root
role grants privileges for general cluster maintenance, including modifying cluster membership, defragmenting the store, and taking snapshots.
The user
subcommand for etcdctl
handles all things having to do with user accounts.
A listing of users can be found with:
Creating a user is as easy as
$ etcdctl user add myusername
Creating a new user will prompt for a new password. The password can be supplied from standard input when an option is given.
Roles can be granted and revoked for a user with:
$ etcdctl user grant-role myusername foo
The user’s settings can be inspected with:
$ etcdctl user get myusername
$ etcdctl user passwd myusername
Changing the password will prompt again for a new password. The password can be supplied from standard input when an option --interactive=false
is given.
Delete an account with:
Working with roles
The role
subcommand for etcdctl
handles all things having to do with access controls for particular roles, as were granted to individual users.
List roles with:
$ etcdctl role list
Create a new role with:
$ etcdctl role add myrolename
A role has no password; it merely defines a new set of access rights.
Roles are granted access to a single key or a range of keys.
The range can be specified as an interval [start-key, end-key) where start-key should be lexically less than end-key in an alphabetical manner.
Access can be granted as either read, write, or both, as in the following examples:
# Give read access to a key /foo
$ etcdctl role grant-permission myrolename read /foo
# Give read access to keys with a prefix /foo/. The prefix is equal to the range [/foo/, /foo0)
$ etcdctl role grant-permission myrolename --prefix=true read /foo/
# Give write-only access to the key at /foo/bar
# Give full access to keys in a range of [key1, key5)
$ etcdctl role grant-permission myrolename readwrite key1 key5
# Give full access to keys with a prefix /pub/
$ etcdctl role grant-permission myrolename --prefix=true readwrite /pub/
$ etcdctl role get myrolename
Revocation of permissions is done the same logical way:
As is removing a role entirely:
$ etcdctl role remove myrolename
The minimal steps to enabling auth are as follows. The administrator can set up users and roles before or after enabling authentication, as a matter of preference.
Make sure the root user is created:
$ etcdctl user add root
Password of root:
Enable authentication:
$ etcdctl auth enable
After this, etcd is running with authentication enabled. To disable it for any reason, use the reciprocal command:
Using etcdctl
to authenticate
etcdctl
supports a similar flag as curl
for authentication.
The password can be taken from a prompt:
$ etcdctl --user user get foo
Otherwise, all commands remain the same. Users and roles can still be created and modified, but require authentication by a user with the root role.