Skip to content

note on dynamic roles caveat #260

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.

Sign up for GitHub

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

Merged
sureshanaparti merged 4 commits into from
Feb 10, 2022
Merged

note on dynamic roles caveat #260

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
95c0010
note on dynamic roles caveat
Jan 26, 2022
da24826
Apply suggestions from code review
DaanHoogland Jan 27, 2022
de4d537
Update source/adminguide/accounts.rst
DaanHoogland Jan 27, 2022
43671bb
saveguard implementation note added
Jan 31, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions source/adminguide/accounts.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -135,6 +135,22 @@ allows CloudStack root admins to create new roles with customized permissions.
The allow/deny rules can be configured dynamically during runtime without
restarting the management server(s).

.. Note:: in versions before 4.16.1, any user given the custom roles
that include permission to create and/or update accounts
will have the ability to assign new custom roles to
themsevles or other users, irrespective of the privileges
given in those roles. This could allow such a user to
escalate their own privileges to include any API they might
not have had before. Therefore, the dynamic roles should be
carefully designed and the `createAccount` and
`updateAccount` privileges should only be given to users who
you are content to have this level of privilege.

Since 4.16.1 a user will be prevented to create an account
with a role that has any permissions that they do not have
themselves. This check will also be performed, since that
version, on updating an account-role.

For backward compatiblity, all roles resolve to one of the four role types:
admin, resource admin, domain admin and user. A new role can be created using
the roles tab in the UI and specifying a name, either a role type or ID of existing
Expand Down