MySQL Enterprise Monitor 8.0.38 Manual
This chapter describes some best practices for setting up your access control permissions. As each organization has a different way of implementing their MySQL installations and monitoring, the scenarios described are general guidelines.
The following scenarios are described:
Open: an organization with one, or more, DBAs. All users can see, but have varying access to, all monitored assets.
Strict: an organization with several DBAs and developers, and many monitored assets, grouped according to the applications and users which use them. Some users within the organization 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 functionality such as Advisors, Event Handlers, and Query Analysis.
While 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 organizations, 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 organizations, members of this role are solely responsible for the addition of users, roles and groups. While, in larger organizations, 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.