ACE Syntax
Describes how to construct ACEs.
An Access Control Expression (ACE) is defined by a combination of user, group, or role definitions. You can combine these definitions using the following syntax:
Operator | Description |
---|---|
u | Username or user ID, as they appear in /etc/passwd , of a
specific user. Usage: u:<username or user ID>
|
g | Group name or group ID, as they appear in /etc/group, of a specific group.
Usage: g:<group name or group ID>
|
r | Name of a specific role. Usage: r:<role name> . |
p | Public. Specifies that this operation is available to the public without restriction. Cannot be combined with any other operator. API request or CLI command to save such settings will return an error. |
! | Negation operator. Usage: !<operator> . |
& | AND operation. |
| | OR operation |
() | Delimiters for subexpressions. |
"" | The empty string indicates that no user has the specified permission. |
An example definition is u:1001 | r:engineering
, which restricts access to
the user with ID 1001 or to any user with the role engineering
.
In this next example, members of the group admin
are given access, and so
are members of the group qa
:
g:admin | g:qa
Another example is to have a list of groups to which you want to give read permissions:
- The
admin
group as a whole, but not the admins for a particular cluster (which is namedcl3
). -
Members of the
qa
group who are responsible for testing the two applications (namedapp2
andapp3
). -
The business analysts (group
ba
) in department 7A (groupdept_7a
) -
All of the data scientists (group
ds
) in the company.
u:cfkane | (g:admin & !g:cl3) | (g:qa & (g:app2 | g:app3)) | (g:ba & g:dept_7a) | g:ds
This expression is made up of five subexpressions which are separated by OR operators:
- The first subexpression
u:cfkane
grants the read permission to the usernamecfkane
. -
The subexpression
(g:admin & !g:cl3)
grants the read permission to the admins for all clusters except clustercl3
. The operatorg
is the group operator, the valueadmin
is the name of the group of all admins. The&
operator limits the number of administrators who have read permission because only those administrators who meet the additional condition will have it.The condition
!g:cl3
is a limiting condition. The operator!
is the NOT operator. Combined with the group operator, this operator means that this group is excluded and does not receive the read permission.WARNINGBe careful when using the NOT operator. You might exclude fewer people than you intended. For example, suppose that you do not want anyone in the groupgroup_a
to have access. You therefore define this ACE:!g:group_a
You might think that the data is now protected because members ofgroup_a
do not have access to it. However, you have not restricted access for anyone else except the members ofgroup_a
. The rest of the world can access the data. You should not define ACEs through exclusion by using the NOT operator. You should define them by inclusion and use the NOT operator to limit further the access of the groups or roles that you have included.In the subexpression
(g:admin & !g:cl3)
, the NOT operator limits the number of members within the admin group who have access. Theadmin
group is included, and all users who are also part of thecl3
group are excluded. -
The subexpression
(g:qa & (g:app2 | g:app3))
demonstrates use of a subexpression within a subexpression. The larger subexpression means that only members of groupqa
who are also members of groupapp2
orapp3
have read access to the data. The smaller subexpression limits the number of people who have this permission in theqa
group. -
The next two subexpressions --
(g:ba & g:dept_7a)
andg:ds
-- grant the read permission to the members of groupba
who are also in the groupdept_7a
. It also grants permission to the members of the groupds
.