Project-level policies

Below the organization, we have Google Cloud projects. Primitive roles granted at the project level apply to all resources within the project. As with organizations, it is generally a best practice to have more than one project owner. Project owners have full control over all project resources, including IAM and billing. Project Editors can control all resources in the project except for IAM and billing. Project viewers on the other hand cannot directly control any project resources, unless otherwise specified at the resource level. A common practice is to assign project viewer to all members.

Aside from primitive roles, curated roles can be created at the project level to define access for all resources of a given type within the project. For example, if a user or group needs the ability to create files in all Cloud Storage buckets within a project, a project-level policy can be created with storage.objectCreator for that user or group.

As discussed in Chapter 1, Why GCP?, projects in Google Cloud play an architectural role in which they define a basic level of boundaries for communications between resources within a given project. Much like user-defined service accounts, Google creates service accounts for each product. For example, when you enable App Engine in your project, Google will create a service account named <PROJECT_ID>@appspot.gserviceaccount.com. This service account will be used by App Engine and made available to your App Engine services as application-default credentials that we discussed earlier in this chapter. In general, Google assumes that services should be able to communicate with each other within the same project, but this behavior can be controlled by modifying the service's IAM roles.