You can set access control using roles at the project level. Assign a role to a project member or service account to determine the level of access to your Google Cloud Platform project and its resources.
You can use primitive roles when you are working on smaller projects that have less complex needs. For more fine-tuned access controls, use Identity and Access Management (IAM) roles, which include the App Engine predefined roles. To learn more about IAM, see the IAM documentation.
For information on how to assign roles, see Granting Project Access.
Primitive roles
For App Engine applications, a project member's role also controls the permissible actions in the gcloud app and appcfg command-line tools that are used to deploy and manage applications.
| Role | Google Cloud Platform Console permissions | appcfg permissions |
|---|---|---|
Owner |
All viewer and editor privileges, plus the ability to view deployed source code, invite users, change user roles, and delete an application. Has admin privileges to all resources in the project. | Upload/rollback application code, update indexes/queues/crons |
Editor |
View application information and edit application settings. Has admin privileges to all resources in the project. | Upload/rollback application code, update indexes/queues/crons |
Viewer |
View application information. Has admin privileges to all resources in the project. | Request logs |
Predefined App Engine roles
The predefined roles for App Engine provide you with finer grained options for access control. Each role is listed with its targeted user, as follows:
Predefined roles comparison matrix
The following table provides a complete comparison of the capabilities of each predefined App Engine role.
| Capability | App Engine Admin | App Engine Deployer | App Engine Service Admin | App Engine Viewer | App Engine Code Viewer |
|---|---|---|---|---|---|
| List all services, versions and instances | Yes | Yes | Yes | Yes | Yes |
| View all application, module, version, and instance settings | Yes | Yes | Yes | Yes | Yes |
| View runtime metrics such as resource usage, load information, and error information | Yes | Yes | Yes | Yes | Yes |
| View application source code | No | No | No | No | Yes |
| Deploy a new version of the application | Yes | Yes | No | No | No |
| Change traffic splits, change default version | Yes | No | Yes | No | No |
| Start and stop a version | Yes | No | Yes | No | No |
| Delete a version | Yes | Yes | Yes | No | No |
| Delete an entire module | Yes | No | Yes | No | No |
| Shut down an instance | Yes | No | No | No | No |
| Disable and re-enable an application | Yes | No | No | No | No |
| Access handlers that have a login:admin restriction | Yes | No | No | No | No |
| Update dispatch rules | Yes | No | No | No | No |
| Update dos settings | Yes | No | No | No | No |
| Update default cookie expiration | Yes | No | No | No | No |
| Update referrers | Yes | No | No | No | No |
| Update Email API Authorized Senders | Yes | No | No | No | No |
Deployments with predefined roles
The App Engine Deployer role is the recommended role to grant to the account that is responsible for deploying a new version of a module. A user with Deployer permissions will be able to successfully run the following command:
appcfg.py update app.yaml module1.yaml module2.yaml
This command creates a new version of the application as specified in the app.yaml, but does not update any of the application-level settings specified in dos.yaml or dispatch.yaml, nor does it update any of the Task Queue, Cron and Datastore Index information specified in the queues.yaml, cron.yaml and index.yaml files, respectively.
-
If your deployment process involves updating
dos.yamlordispatch.yaml, you need to grant the App Engine Admin role to the account doing the deployment. -
If your deployment process also involves updating
queues.yaml,cron.yamlorindex.yaml, your deployment account needs to be an Editor on the project.
Separation of deployment and traffic routing duties
Many organizations prefer to separate the task of deploying an application version from the task of ramping up traffic to the newly created version, and to have these tasks done by different job functions. The Deployer and Service Admin roles enable this separation.
A user with only a Deployer role is limited to deploying new versions and deleting old versions that don’t have traffic routed to them. The Deployer-only user won’t be able to change which version gets traffic or change application-level settings such as dispatch rules or authentication domain.
The Service Admin role, on the other hand, cannot create a new version of the application or change application-level settings. However, it can change properties of existing services and versions, including changing which versions get traffic. We suggest granting the Service Admin role to your Operations/IT department that handles ramping up traffic to newly deployed versions.
Permissions the predefined roles do NOT grant
None of the predefined roles listed above grant access to the following:
- View and download application logs
- View Monitoring charts in the Cloud Platform Console
- Enable and Disable billing
- Set up a daily Spending Limit (formerly known as Budget) for App Engine and view dollar amount spent
- SSH into a VM instance running in the flexible environment
- View and edit custom domains and uploaded SSL certificates
- Run Security Scans
- Access configuration or data stored in Datastore, Task Queues, Memcache, Cloud Search or any other Cloud Platform storage product
We expect to control some of these features in the future by their own fine-grained roles.
Using service accounts
The App Engine application continues to have the Editor role on the project at runtime. Reducing the permissions of the service account representing the identity of the application is not supported.
