You can set access control using roles at the Cloud Platform project level. Assign a role to a Cloud Platform 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.
For fine-grained details about which permissions are granted to the predefined IAM roles, down to the method call level, see Roles in the App Engine Admin API docs.
For App Engine applications, a Cloud Platform project member's role also controls the permissible actions of the command-line tools that are used to deploy and manage applications.
|Role||Cloud Platform Console permissions||Tools permissions|
||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.||Deploy application code, update indexes/queues/crons|
||View application information and edit application settings. Has admin privileges to all resources in the project.||Deploy application code, update indexes/queues/crons|
||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, service, 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|
|Split or migrate traffic||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 service||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 Email API Authorized Senders||Yes||No||No||No||No|
For details about the specific IAM permissions that are granted by each role, see the Roles section of the Admin API.
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 service, although you could also deploy with the App Engine Admin role.
For instructions on how to deploy using the predefined IAM roles, see Deploying using IAM Roles
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 runs using the identity of the App Engine default service account. You can see this account on the IAM page in the Cloud Platform Console.
By default, the App Engine default service account has the Editor role in the project. This means that any user with sufficient permissions to deploy to App Engine can run code with read/write access to all resources within the project.
You can downgrade the default service account permissions in the project by changing its role from Editor to whichever role(s) best represent the access that the App Engine application needs.
To use the Google Cloud SDK, including any of the Cloud SDK development tools, you must first enable the Google App Engine Admin API in your Google Cloud Platform project before you can run commands using your service account: