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 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||Google 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|
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. A user with Deployer permissions will be able to successfully run the deployment command:
gcloud app deploy
gcloud command creates a new version of the application as specified in
app.yaml, but does not update any of the application-level settings
that are specified in other configuration files.
If your deployment process involves updating the
dispatch.yamlfiles, your deployment account needs to be granted the App Engine Admin role.
If your deployment process also involves updating the
index.yamlfiles, your deployment account needs to be granted the Editor role for the project.
For details about deploying your apps to App Engine, see Deploying a Go App.
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 Cloud Platform project at runtime. Reducing the permissions of the service account representing the identity of the application is not supported.