Table of Contents
This chapter describes some best practices for setting up your access control permissions. As each organisation has a different way of implementing their MySQL installations and monitoring, the scenarios described are general guidelines.
The following scenarios are described:
Open: an organisation with one, or more, DBAs. All users can see, but have varying access to, all monitored assets.
Strict: an organisation with several DBAs and developers, and many monitored assets, grouped according to the applications and users which use them. Some users within the organisation have access to all monitored assets, some have access only to a subset of those assets and cannot see any asset which falls outside their responsibilities. This scenario adopts a production vs. development pattern.
Typically, in this type of scenario, there is a strict separation between production and development. That is, those roles which have complete access on the development assets, have only limited access, or no access, to the production assets.
The roles involved in each scenario are as follows:
Database Administrator (DBA): responsible for the proper operation of the MySQL instances. As such, they need access to the data collected on the monitored instances. In most scenarios, the DBA can access the majority of the MySQL Enterprise Monitor functionality, such as Advisors, Event Handlers, and Query Analysis.
NoteWhile there is a default DBA role included in your installation, it is recommended to create a separate DBA-type role for your installation. The default DBA role exists to facilitate migration from previous versions. Also, it is not possible to edit the default DBA role.
For the purposes of this chapter, the DBA role is taken by SeniorDBA and JuniorDBA.
Group/User Administrator: responsible for user, role, and group management. This role defines who has access to MySQL Enterprise Service Manager and defines the grouping of the servers. Users in this role are typically high-level DBAs, IT administrators, or project managers. In large organisations, the Group Administrator role may also be responsible for managing Event Handlers, Event Blackouts, and Notification Groups. It is strongly recommended that a group administrator is assigned in all setups. The scope of the Group Administrator role's permissions can vary, depending on the size of the organization. In smaller organisations, members of this role are solely responsible for the addition of users, roles and groups. While, in larger organisations, they are also responsible for managing the event traffic via email/SMTP notifications, group management, and so on.
The GroupAdmin role is a lock-and-key role. It is defined in such a way that it cannot be used on its own. To add groups, users or roles, it must be used in combination with a role which grants the top-level permissions, Server Group and MEM Web Application. That is, for a user to have permissions to edit users, roles and groups, they must be members of both the GroupAdmin role and another role which grants the dependent permissions.
The GroupAdmin role is recommended for all implementations except the most basic.
Developers: responsible for the code deployed on the assets. As such, they need to see the impact of their code on the monitored assets. In a production environment, the developers have access to Events, Query Analysis, graph data, and so on.
The Open implementation has no group-specific roles. This scenario has the following role types:
Manager: responsible for all monitored assets, advisor configuration, group configuration, query analysis, event handling and communications. (Default role. Complete access.)
DBA: responsible for monitored assets, query analysis, event investigation.
The following users are involved in this scenario:
Manager: responsible for all monitored assets.
DBA: responsible for monitoring MySQL instances, investigating issues and repairing those issues.
This section describes the Manager role definition for the Open implementation. Users in this role are power users. They are responsible for configuring everything. This role is permitted to perform the following actions:
All possible actions .
Table 24.1 Manager Role Definition
| Permission | Level |
|---|---|
| Server Group | Administer |
| MySQL Instances | Administer |
| Query Analysis Aggregate Data | Read-Only |
| Query Analysis Example and Explain Data | Read-Only |
| Web Application Login | Read-Only |
| MySQL Enterprise Monitor | Administer |
| Advisor Configuration | Administer |
| Event Blackout | Administer |
| Event Handling | Administer |
| New Group Creation | Administer |
| Settings | Administer |
| Users and Roles | Administer |
The Manager users are responsible for configuring Advisor thresholds and defining the Event Handlers and Notification Groups. The Notification Groups contain the members of the standard DBA role, and the Senior DBA members.
This user has the permission to close Events, due to MySQL Instances being set to Administer.
This section describes the DBA role definition for the Open implementation. Users in this role are monitoring users. They are responsible for investigating events and resolving issues with the monitored MySQL instances. This role is permitted to perform the following actions:
All tasks except User Management and editing MEM settings.
Table 24.2 DBA Role Definition
| Permission | Level |
|---|---|
| Server Group | Administer |
| MySQL Instances | Administer |
| Query Analysis Aggregate Data | Read-Only |
| Query Analysis Example and Explain Data | Read-Only |
| Web Application Login | Read-Only |
| MySQL Enterprise Monitor | Read-Only |
| Advisor Configuration | Administer |
| Event Blackout | Administer |
| Event Handling | Administer |
| New Group Creation | Administer |
| Settings | None |
| Users and Roles | None |
It is possible, in this Open implementation, to add all DBA users to the default DBA role. However, for any size installation, it is recommended to have a well-defined hierarchy of users. Particularly for SMTP or SNMP notifications which can, if unmanaged, produce a very high volume of notification traffic. It is recommended to have a single group of senior users manage Advisor, Event Handler, and Notification Group configuration. All requests should go through those senior users.
Also, it is not possible to edit the default DBA role.
The Strict scenario is a group-based implementation. Users are assigned to roles with varying access to the groups.
This scenario focuses on two groups, Development and Production. Development is the group of MySQL instances where the product is developed and tested. Production is the group of MySQL instances to which the finished product is deployed for customers to use.
This implementation requires the following asset groups:
Development: all assets used by the development and quality teams are grouped in the Development group.
Production: all assets deployed for use by the customer are grouped in the Production group.
When installing agents to monitor the assets, it is critically important to chose the correct group during the installation process. If the incorrect group, or no group, is chosen, the assets fall outside the scope of the Roles defined here and cannot be seen by any user except those in the SeniorDBA roles.
This implementation requires the following roles types:
GroupAdmin: System-wide role. Members are responsible for user, role, and group management only. This role is limited in the sense that it does not have the Server Group or MEM Web Application permission set to a usable value. To access the UI or create groups, the users assigned to this role must also be assigned to roles with usable Server Group permissions (Read-Only or Administer).
SeniorDBA: System-wide role. Members have access to all monitored assets on both Production and Development groups. No group-specific permission sets.
JuniorDBA: members have read-only access to the monitored assets in the Development group, only.
SeniorDev-Development: members have limited access to monitored assets in Development group. Members of this role need permissions to view events, QuAN data, and create event handlers on the Development assets. Members of this role are responsible for inspecting the impact their code has on performance and existing functionality.
SeniorDev-Production: Same members as SeniorDev-Development, but restricted rights on the monitored assets. Permissions to observe, only, no rights to create event handlers, set blackouts, or access the QuAn Explain or Example functionality. This role does not include any observation of customer data, but does allow its members to view events generated on the monitored assets.
If a member of this role requires an event handler or advisor threshold edit on the Production group, it must be requested from a member of the SeniorDBA role.
JuniorDev-Development: members have access to the Development group, only. For the most part, their permissions are read-only. They are entitled to view events, QuAn data, and so on.
This implementation requires the following users:
DBA Teamlead: manages the DBA team and has complete access to all monitored assets. This user is a member of the SeniorDBA and GroupAdmin roles. This combination of permissions gives them complete access to all monitored assets.
Senior DBAs: responsible for the monitored assets. Has complete access to all monitored assets. No user management rights.
Junior DBAs: responsible for investigating issues. Read-only rights on all Development assets. No access to Production assets.
Senior Developers: responsible for deploying code to the Development group and reviewing impact on performance and functionality. No user management rights, event blackout rights, and so on. Permitted to view events on the Production group, but not to add event handlers, notification groups, and so on.
Junior Developers: responsible for deploying code and viewing events on the Development group. No access to the Production group.
For each of these roles, select System-Wide Permissions in the Core Monitored Assets frame.
Table 24.3 System-Wide Role Definition
| Permission | SeniorDBA | GroupAdmin |
|---|---|---|
| Server Group | Administer | None |
| MySQL Instances | Administer | None |
| Query Analysis Aggregate Data | Administer | None |
| Query Analysis Example and Explain Data | Administer | None |
| Web Application Login | Read-Only | None |
| MySQL Enterprise Monitor | Administer | None |
| Advisor Configuration | Administer | None |
| Event Blackout | Administer | None |
| Event Handling | Administer | None |
| New Group Creation | None | Administer |
| Settings | Administer | None |
| Users and Roles | None | Administer |
The membership of these Roles is:
SeniorDBA Role: DBA manager and Senior DBAs.
GroupAdmin: DBA manager and at least one Senior DBA, for redundancy.
For each of these roles, select Group-Specific Permissions in the Core Monitored Assets frame, and select from the group drop-down list.
Table 24.4 Development Group Role Definition
| Permission | SeniorDev | JuniorDev | JuniorDBA |
|---|---|---|---|
| Server Group | Administer | Read-Only | Read-Only |
| MySQL Instances | Read-Only | Read-Only | Read-Only |
| Query Analysis Aggregate Data | Read-Only | Read-Only | Read-Only |
| Query Analysis Example and Explain Data | Read-Only | Read-Only | Read-Only |
| Web Application Login | Read-Only | Read-Only | Read-Only |
| MySQL Enterprise Monitor | Read-Only | Read-Only | Read-Only |
| Advisor Configuration | Read-Only | Read-Only | Read-Only |
| Event Blackout | None | None | None |
| Event Handling | Read-Only | None | Read-Only |
| New Group Creation | None | None | None |
| Settings | None | None | None |
| Users and Roles | None | None | None |
Currently, Advisor Configuration and Event Handling are global permissions. Changes made at that level can affect all users of the MySQL Enterprise Monitor. As such, only a senior user, with System-Wide permissions, should be permitted to change these settings.
For this role, select Group-Specific Permissions in the Core Monitored Assets frame, and select from the group drop-down list.
Table 24.5 Production Group Role Definition
| Permission | SeniorDev |
|---|---|
| Server Group | Read-Only |
| MySQL Instances | Read-Only |
| Query Analysis Aggregate Data | None |
| Query Analysis Example and Explain Data | None |
| Web Application Login | Read-Only |
| MySQL Enterprise Monitor | Read-Only |
| Advisor Configuration | Read-Only |
| Event Blackout | None |
| Event Handling | None |
| New Group Creation | None |
| Settings | None |
| Users and Roles | None |
The Strict implementation is also useful for large companies with globally distributed teams, accessing central server farms.
This implementation involves the following:
Company server farm with DBAs and individuals responsible for liaising with departments.
Departments with their own DBAs, Developers, and so on. This implementation includes the following departments, each with an identical permissions set: BlueTeam, RedTeam, GreenTeam, YellowTeam, and OrangeTeam.
Groups must be configured for each department. In this scenario, BlueGroup, RedGroup, GreenGroup, YellowGroup, and OrangeGroup. Where each group contains the assets dedicated to each department.
