You are developing a strategy for monitoring your Google Cloud Platform (GCP) projects in production using Stackdriver Workspaces.
One of the requirements is to be able to quickly identify and react to production environment issues without false alerts from development and staging projects.
You want to ensure that you adhere to the principle of least privilege when providing relevant team members with access to Stackdriver Workspaces.
What should you do?
Click on the arrows to vote for the correct answer
A. B. C. D.C.
When developing a strategy for monitoring Google Cloud Platform (GCP) projects in production using Stackdriver Workspaces, it is important to consider the principle of least privilege. This principle states that each user or process should be given only the minimum access and permissions necessary to complete its tasks. This is a best practice in security and helps to reduce the risk of unauthorized access or data breaches.
The question specifies that one of the requirements is to quickly identify and react to production environment issues without false alerts from development and staging projects. This means that monitoring should be focused on production projects only, and not on development or staging projects.
Option A suggests granting relevant team members read access to all GCP production projects and creating Stackdriver workspaces inside each project. This approach violates the principle of least privilege as it grants access to all production projects, including those that are not relevant to the team members. Additionally, creating a separate Stackdriver workspace for each project can lead to fragmentation of monitoring data and make it difficult to correlate issues across multiple projects.
Option B suggests granting relevant team members the Project Viewer IAM role on all GCP production projects and creating Stackdriver workspaces inside each project. This approach also violates the principle of least privilege as the Project Viewer role grants broad access to GCP resources, including read access to all project data. Additionally, this approach can result in a large number of Stackdriver workspaces, which can be difficult to manage.
Option C suggests choosing an existing GCP production project to host the monitoring workspace, attaching the production projects to this workspace, and granting relevant team members read access to the Stackdriver Workspace. This approach is better than the previous two options, as it restricts access to the monitoring workspace to a single project and only grants access to relevant team members. However, this approach still requires attaching production projects to the monitoring workspace, which can result in fragmentation of monitoring data.
Option D suggests creating a new GCP monitoring project and creating a Stackdriver Workspace inside it, attaching the production projects to this workspace, and granting relevant team members read access to the Stackdriver Workspace. This approach is the best choice as it adheres to the principle of least privilege by creating a dedicated monitoring project and workspace that is separate from production projects. Relevant team members can be granted read access to the monitoring workspace only, and all production projects can be attached to this workspace for centralized monitoring. This approach provides a single source of truth for monitoring data and allows for easy correlation of issues across multiple projects.
In conclusion, option D is the best choice for monitoring GCP projects in production using Stackdriver Workspaces while adhering to the principle of least privilege.