Basic roles in GCP allow data-level actions, even though at first glance it might seem like they don’t. Here, learn risk factors and how to keep data safe.
Join the DZone community and get the full member experience. Most GCP users know that granting basic roles is a really bad practice, but you may be surprised to learn that the risk is much more serious than it might seem because basic roles actually grant far more than what appears on the permissions list (which is already excessive, of course). For the owner role, we can assume that most project administrators are aware it includes the resourcemanager. projects. setIamPolicy permission which allows for straightforward privilege escalation and managing the risk accordingly. However, for Viewer or Editor, you could make the very reasonable assumption that even though the roles provide a wide set of permissions – spanning every resource type in a GCP project – at least they won’t allow anything else. Well, it appears this assumption is WRONG. In case you didn’t know, when you grant a principal a basic role on a project or above (folder/organization), they are automatically placed in a group corresponding with the basic role granted to them called “ s of project:.”
So for example, if you provide a principal with the Viewer role on project Ermetic-Production, it would be a member of the group “Viewers of project: Ermetic-Production.”
We found out that bindings for these groups are created automatically on key resources, giving the principals with the basic roles more permissions (and even different kinds of permissions) than you bargained for. Specifically, current and future members of these groups are automatically awarded roles that provide them with permissions to data-level actions, and not just control plain actions, which is really counter-intuitive. Since the bindings are created on the resource level (e.g., storage bucket) and not on the project level, you may not notice them because IAM policies for each resource are rarely reviewed. To do so would require inspecting the IAM policy for each resource which is not feasible. As an example, let’s see how this plays out with storage buckets. Viewers of the project receive, by default, the Storage Legacy Object Reader role, which includes storage. objects. get, and the Storage Legacy Bucket Reader role, which includes storage. objects. list. These roles combined grant the Viewers the ability to access the data itself in the storage bucket.
