New Admin Roles / Special Admins
- Dennis Kittrell (Deactivated)
- Martin Kraft (Deactivated)
Target release | Q3 2020 |
|---|---|
Epic | |
Edition | E20 |
50% |
Document owner | @Dennis Kittrell (Deactivated) |
|---|---|
Designer | @Michael Gamble (Deactivated) |
Tech lead | @Scott Bishel |
Technical writers | @Justine Geffen (Deactivated) |
QA | @Rohitesh Gupta (Deactivated) |
OKR | |
Request (CR) | N/A |
Request (other) |
|
Design Spec | <pending> |
Technical Spec | |
Test Plan | <pending> |
Objective
New admin roles are additional system roles that have access to designated areas of the system console. This enables System Administrators to delegate certain administrative tasks to other members of their organization without a substantial security risk.
Background
Mattermost Roles and permissions are constrained architecturally from multiple scenarios demanded by enterprise customers.
System Admin Role is currently the only role that can access the System Console and other management functions via API/Command Line. There is a singular permission that is shared by all system admins that essentially provides the “Keys to the Kingdom”. This means that in order to delegate administrative tasks, a system admin must grant equal authority to another on his/her team.
That authority includes:
The ability to remove the first admin from the system
Complete and unfettered access to every command in the API and full access to the CLI/MMCTL
The ability to run compliance reports and effectively read any message that has ever been sent on the system
Full read/write access to the database
Permissions are often not utilized to their fullest potential, blocking growth in larger organizations and preventing adoption from prospective customers with advanced permissions requirements.
Success metrics
Goal | Metric |
|---|---|
| 100% of our customers and prospects are consistently utilizing roles and permissions upon server setup Post-deployment NPS scores for System Admins increase by at least 10 points We have decreased closed/lost reports related to permissions/role management blockers by 90% |
|
|
User Scenarios
Delegate management of users to another member of my Mattermost server without the risk of giving them system admin access to the server
Delegate management of most administrative tasks to a trusted member of my Mattermost server without risk of granting system admin privileges
Delegate plugin management to specific users
Grant read only access to the system console for support managers or operations/compliance teams
Grant limited access and authority to employees responsible for managing authentication & access control systems such as AD/LDAP, SAML, etc.
Grant access to compliance reports and controls to a CISO or CCO or similar
Assumptions
Current RBAC permissions structure will be suitable to support the feature
Phases & Milestones
Areas Touched
Permissions
System Console UI (Permissions and Navigation/Access)
Requirements: Phase I (mmctl Only)
Requirement | User Story | Importance | Jira Issue | Notes | |
|---|---|---|---|---|---|
| 1 | New System Role - System Manager (lower level admin) Default Permissions / Section Access
|
| HIGH |
|
|
| 2 | New System Role - User Manager
|
| HIGH |
|
|
| 3 | New System Role - Read Only Admin
|
| low |
|
|
| 4 | No System Role (apart from System Admin) should have access to edit system roles |
| HIGH |
|
|
| 5 | Every change made by any admin needs to be included in the audit log |
| HIGH |
|
|
| 6 | Chat-facing experience should not be impacted for any users assigned a system role other than System Admin. These Admin roles should have the same permissions as members on chat side (unless they are also team/channel admins - in which case, the higher scoped permissions apply. e.g. System Manager or User Manager should not be able to
|
| medium |
|
|
| 7 | Each admin role can be measured per server for usage analysis |
| medium |
|
|
Requirements: Phase II (Editable Privileges using mmctl)
Requirement | User Story | Importance | Jira Issue | Notes | |
|---|---|---|---|---|---|
| 1 | Each of the permissions / section access can be granted or removed from a system role (all users with that role have the same access) |
| HIGH |
|
|
| 2 | Obscure All Stored Credentials Example: Global Relay |
| Medium |
|
|
| 3 | No privilege should be capable of elevating anyone to system admin or impersonating system admin. Examples:
|
| HIGH |
|
|
| 4 | No privilege should be capable of deactivating or demoting another admin. Examples:
|
| Medium |
|
|
| 5 | No system role can join private channels without being invited. This includes auto-joining private channels via permalink |
| Medium |
|
|
| 6 | Telemetry added to track changes to default admin roles:
|
|
|
|
|
Requirements: Phase III (Manage Roles & Privileges via System Console)
Requirement | User Story | Importance | Jira Issue | Notes | |
|---|---|---|---|---|---|
| 1 | Ability for System Admin to assign roles from the System Console UI |
| HIGH |
|
|
| 2 | Ability for System Admin to modify privileges of each system role from the system console |
| HIGH |
|
|
Open Questions
Question | Answer | Date Answered |
|---|---|---|
How to disable specific fields that could be exploited to self-elevate (e.g. Change LDAP/SAML Admin filter to include self) | (Martin) Currently config fields are either no access, read-only, or read+write for an entire section. This security concern is currently being handled by not providing |
|
How to restrict plugin installation to marketplace (signed plugins) if plugin management is granted to a new admin role (risk is that plugins can be used to self-elevate) | @Martin Kraft (Deactivated) We need to think through this one (for phase II - editable privileges) @Dennis Kittrell (Deactivated) (Martin) I think at most we provide some warning of the risk, but my hope is that a system admin is already aware of the risks involved in plugins. (Martin) |
|
How to obscure credentials such as SMTP/Gify/Global Relay/OAuth Secret Keys/Plugin API keys (e.g. Zoom) |
|
|
How to remove compliance download links if read-only access to compliance page is granted | (Martin) Why would we do this? Download is just another form of a read. |
|
How to force signed plugins only for System Manager Role |
|
|
Should we allow System Admins to decide if System/User Managers can reset passwords and/or change emails? |
|
|
Should we allow System Admins to decide if System/User Managers can manage and force join private channels (with prompt)? (Manage_Private_Channel_Members) |
|
|
Can a system admin remove another admin via guest filter or user filter? |
|
|
Out of Scope
Reset admin role privileges to default (under consideration for future)
Can rename default roles (planned for future)
Can clone/copy default roles (planned for future)
Can create new/custom roles (feature under consideration)
Can rename custom/cloned roles (feature under consideration)
LDAP filter for each role (planned for future)
SSRF risk elimination (admin roles with edit access can scan for open ports)