In cloud computing, particularly on the Google Cloud Platform (GCP), controlling access to resources is paramount for security and operational integrity. Two fundamental roles that often cause confusion are roles/viewer and roles/reader. While both grant read-only access, their scope and intended use differ significantly, with the choice between them having important implications for security best practices.
The core distinction lies in their breadth of permissions: roles/viewer is a broad, project-level “basic” role, offering a wide but indiscriminate view of all resources within a project. In contrast, roles/reader represents a more granular and recommended approach, acting as a “predefined” role that provides read-only access to a specific service.
At a Glance: Key Differences
| Feature | roles/viewer | roles/reader |
| Type | Basic (Primitive) Role | Predefined Role |
| Scope | Project-wide | Service-specific (e.g., Compute Engine, Cloud Storage) |
| Granularity | Coarse-grained | Fine-grained |
| Best Practice | Avoid; violates the principle of least privilege | Recommended for granting read-only access |
| Example | Can view all Compute Engine instances, Cloud Storage buckets, and BigQuery datasets in a project. | A user with roles/compute.reader can only view Compute Engine resources. |
Delving Deeper: Understanding the Implications
The roles/viewer role, a legacy from GCP’s earlier days, grants thousands of individual *.get and *.list permissions across all services within a project. This means a user with this role can see virtually everything, from virtual machine configurations and storage bucket contents to IAM policies and billing information. While convenient for a quick overview, this broad access often violates the principle of least privilege, a security cornerstone that dictates users should only have the minimum permissions necessary to perform their tasks.
The modern and recommended approach is to use predefined roles like roles/reader. These roles are curated by Google to provide a set of permissions tailored to a specific service. For example:
roles/compute.reader: Allows a user to view Compute Engine resources like virtual machines, disks, and images, but not resources in other services like Cloud Storage or BigQuery.roles/storage.objectViewer: Grants permission to view objects within Cloud Storage buckets.roles/bigquery.dataViewer: Enables a user to read data from BigQuery tables.
By using these granular reader roles, you can provide users with the specific read-only access they need without exposing them to sensitive information in other parts of your project.
A Concrete Example: roles/viewer vs. roles/compute.reader
Imagine you have a team of developers who need to check the status of your production web servers running on Compute Engine.
- If you grant them
roles/viewer, they can indeed see the virtual machines. However, they can also see all your Cloud Storage buckets, including potentially sensitive data, and all your BigQuery datasets. - If you grant them
roles/compute.reader, their visibility is restricted solely to Compute Engine resources. They can view the necessary server information without having access to unrelated and potentially confidential data.
This example highlights how roles/reader enhances security by limiting the “blast radius” in case of a credential compromise or insider threat.
The “Browser” Role: A Special Case
It’s also worth noting the roles/browser role in GCP, which can sometimes be confused with viewer. The Browser role is even more limited and primarily allows a user to browse the project hierarchy and see the existence of resources. However, it does not grant permissions to view the actual content or details of most resources. For instance, a user with the Browser role could see that a Compute Engine instance exists but would not be able to see its configuration details.
Beyond GCP: A Look at Other Cloud Platforms
The concept of granular, read-only access is a standard security practice across major cloud providers, though the implementation details vary.
- Amazon Web Services (AWS): AWS utilizes IAM policies to grant permissions. The ReadOnlyAccess managed policy is conceptually similar to GCP’s
roles/viewer, providing broad read-only access to most AWS services and resources. AWS also offers a more restrictive ViewOnlyAccess policy that grants permissions to view service consoles and list resources but not read their content. For more granular control, AWS encourages the creation of custom IAM policies with specific read-only actions for individual services. - Microsoft Azure: Azure uses Role-Based Access Control (RBAC). The built-in Reader role in Azure is analogous to the service-specific reader roles in GCP. It allows users to view all resources within a subscription or resource group but not make any changes. Similar to GCP’s predefined roles, Azure offers more specific reader roles for certain services, such as Virtual Machine User Login which provides read access to a virtual machine.
The Verdict: Embrace Granularity with roles/reader
In conclusion, while both roles/viewer and roles/reader provide read-only access in GCP, their application and security implications are vastly different. The roles/viewer role, with its broad, project-wide scope, should be used sparingly, if at all, in production environments. The best practice is to adhere to the principle of least privilege by utilizing the more granular, service-specific roles/reader. This targeted approach significantly enhances your security posture by ensuring that users and services have only the access they absolutely need.