|
|
@@ -19,7 +19,7 @@ Each role has exact one associated Permission List. An permission list exists fo
|
|
|
|
|
|
The special static ROOT (named `root`) role has a full permissions on all key-value resources, the permission to manage user resources and settings resources. Only the ROOT role has the permission to manage user resources and modify settings resources. The ROOT role is built-in and does not need to be created.
|
|
|
|
|
|
-There is also a special GUEST role, named 'guest'. These are the permissions given to unauthenticated requests to etcd. This role will be created when security is enabled, unless it already exists, and by default allows access to the full keyspace due to backward compatability. (etcd did not previously authenticate any actions.). This role can be modified by a ROOT role holder at any time.
|
|
|
+There is also a special GUEST role, named 'guest'. These are the permissions given to unauthenticated requests to etcd. This role will be created when security is enabled, unless it already exists, and by default allows access to the full keyspace due to backward compatibility. (etcd did not previously authenticate any actions.). This role can be modified by a ROOT role holder at any time.
|
|
|
|
|
|
#### Permissions
|
|
|
|
|
|
@@ -52,7 +52,7 @@ Other types of auth can be considered for the future (eg, signed certs, public k
|
|
|
|
|
|
### Things out of Scope for etcd Permissions
|
|
|
|
|
|
-* Pluggable AUTH backends like LDAP (other Authorization tokens generated by LDAP et al may be a possiblity)
|
|
|
+* Pluggable AUTH backends like LDAP (other Authorization tokens generated by LDAP et al may be a possibility)
|
|
|
* Very fine-grained access controls (eg: users modifying keys outside work hours)
|
|
|
|
|
|
|