To give a user permission to access particular Google Cloud resources, you assign a role to them. Basic roles act at the project level. There are 3 basic roles available: Owner, Editor, and Viewer. There are also fine-grained roles for individual resources. These are called predefined roles. (They were previously known as curated roles.) For example, the Cloud SQL Viewer role gives read-only access to Cloud SQL resources.

You can assign roles at different levels of the hierarchy, that is, at the organization, folder, project, and resource levels. If you assign roles to the same user at different levels, then their effective permissions are the union of the permissions at the different levels.

For example, if you granted Marie the Viewer role at the organization level and the Editor role at the project level, then she would have Editor permissions for all of the resources in that project. The Viewer role at the organization level would not override the Editor role at the project level. Similarly, if you assigned them in the opposite way, with the Editor role at the organization level and the Viewer role at the project level, Marie would still have the Editor role for all of the resources in that project because the project-level permissions would not override the organization-level permissions.

There are a few principles you should apply when setting roles and permissions. 

First, use the principle of least privilege when granting roles. That is, assign roles with the least permissions required for people to do what they need.

Second, whenever possible, assign roles to groups instead of to individuals. Then, when you need to grant a role to a user, you can just add them to the group. Not only is this easier to manage, but it also ensures consistent privileges among members of a particular group. You can also use a descriptive group name that makes it clear why group members need those permissions.

Third, keep tight control of who can add members to groups and change policies. If you don’t, then people could give themselves or others more privileges than they should have.

Fourth, to make sure that inappropriate policy changes aren’t made, audit all policy changes by checking the Cloud Audit Logs, which record project-level permission changes.

Now let’s apply these principles to GreatInside. First, you would grant the project owner role to a few key system administrators. Owners are the only ones who can change policies (unless you grant users the Organization Administrator role). You should always have more than one owner. Otherwise, if that person is unavailable or leaves the organization, it would be difficult to for someone else to take their place as owner. So avoid that situation by giving the owner role to several people, but choose wisely because owners can do just about anything. 

Similarly, you would have a small number of G Suite administrators who could add users to groups.

Obviously, there would be a large number of users who would need permissions, so I’m not going to talk about every type of user, but I’ll give a couple of examples. One example would be a network administration group that you would grant the Compute Network Admin role to.

Another example would be a QA team. You could grant their group the editor role on the Test Environment project and the viewer role on the Production Environment project. Alternatively, if the QA people don’t need full access to the Test Environment, then you could grant them several predefined roles, such as Compute Instance Admin, Cloud SQL Admin, and Compute Storage Admin.

Regarding audit logs, someone would need to take on the responsibility of checking for policy changes. The Admin Activity audit logs are viewable by all project members, so you wouldn’t need to grant access to the person who does the checking.

And that’s it for roles.