Access Control

Beta

This is a Beta release of IAM access control. This feature is not covered by any SLA or deprecation policy and may be subject to backward-incompatible changes.

This document describes the access control options available to you in App Engine, including IAM curated controls.

Overview
Choosing the right access control
Setting access control
Primitive Roles
Curated App Engine roles
1. Curated roles comparison matrix
2. Permissions the Curated Roles do NOT Grant
3. Using Curated Roles with Deployments
Limitations and restrictions

Overview

In App Engine, you use the Google Cloud Platform Console to set access control using roles at the project level for both primitive roles and App Engine curated roles. In general, primitive roles provide broader access, whereas curated roles provide a more focused and restricted access.

For more information about IAM access control, see the IAM overview page.

Choosing the right access control

If you are just experimenting with App Engine, the simplest approach to access control is to grant the Editor role to all people involved with the project, following the console instructions below. Keep in mind that only an Owner can add other people to the project.

When your project is ready for more fine-grained access controls, we recommend that you do the following:

Identify all the different job functions that need access to the project.
Set up a Google Group for each of these job functions.
Add members as desired to each Google Group.
Follow the console instructions below to add each Google Group as member of the project and set roles on each group.

Setting access control

To set access controls:

Visit the Permissions page for your project.
Click Add member to add new members to the project and set their roles using the dropdown menu. You can add an individual user email or you can supply a Google Group email (example-google-group@googlegroups.com) if you use Google Groups to manage group roles as described above.
Assign one of the primitive roles Owner, Editor, Viewer, or assign one of the App Engine curated roles for more fine-grained control: App Engine Admin, App Engine Viewer, App Engine Deployer, and App Engine ServiceAdmin.
You'll notice that there are other curated roles in the dropdown menu. Those apply to other Google Cloud Platform products. We'll cover only the roles that apply to App Engine in this document.

Primitive Roles

The primitive roles for App Engine and their permissions are the following:

Role	Permissions
Viewer	Provides READ access to all resources in the project.
Editor	Provides Viewer access, plus the ability to write to or modify any resources, upload and roll back application code, and edit application settings.
Owner	Provides Editor access, plus the ability to change membership and permissions in the project, disable serving on the app, delete the app, and manage billing.

Primitive roles and the admin user

Roles and Admin User

In your application configuration (login:admin), you can specify that only admin users can access a particular URL. Be aware that this means that any logged in user with Viewer, Editor, or Owner roles can access that URL.

Similarly, if you query the current user to determine whether the user has admin permissions, using isUserAdmin, the query will return true if the current user has Viewer, Editor, or Owner roles.

Curated App Engine roles

The curated roles for App Engine provide you with finer grained options for access control. Each role is listed with its targetted user, as follows:

Role	Capabilities	Target User
App Engine Admin	Read/Write/Modify access to all application configuration and settings.	Application owner/administrator On-call engineer sysadmin
App Engine Viewer	Read-only access to all application configuration and settings.	User needing visibility into application, but not to modify it. Audit job checking App Engine configuration for policy compliance.
App Engine Deployer	Read-only access to all application configuration and settings. Write access only to create a new version; cannot modify existing versions other than deleting versions that are not receiving traffic.	Deployment account Release engineer
App Engine Service Admin	Read-only access to all application configuration and settings. Write access to module-level and version-level settings. Cannot deploy a new version. Note: Service Admin is basically a Module Admin role. However, because we expect to rename Modules to Services soon, this role uses the new name.	Release engineer DevOps On-call engineer Sys Admin

Curated roles comparison matrix

The following table provides a complete comparison of the capabilities of each curated App Engine role.

Capability	App Engine Admin	App Engine Deployer	App Engine Service Admin	App Engine Viewer
List all modules, versions and instances	Yes	Yes	Yes	Yes
View application, module, version and instance settings - traffic splits, instance type, etc.	Yes	Yes	Yes	Yes
View runtime metrics such as resource usage, load information, and error information	Yes	Yes	Yes	Yes
Deploy a new version of the application	Yes	Yes	No	No
Change traffic splits, change default version	Yes	No	Yes	No
Start and stop a version	Yes	No	Yes	No
Delete a version	Yes	Yes	Yes	No
Delete an entire module	Yes	No	Yes	No
Shut down an instance	Yes	No	No	No
Update dispatch rules	Yes	No	No	No
Update dos settings	Yes	No	No	No
Update default cookie expiration	Yes	No	No	No
Update referrers	Yes	No	No	No
Update Email API Authorized Senders	Yes	No	No	No

Note: The curated roles are enforced in the Google Cloud Platform Console, the Admin API, and other access methods, such as appcfg.

Permissions the Curated Roles do NOT Grant

None of the curated roles listed above grant access to the following:

Disable and re-enable the application
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 Curated Roles with Deployments

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.sh update <directory-path>/my-application/my-module

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.yaml or dispatch.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.yaml or index.yaml, your deployment account needs to be an Editor on the project.

Separating 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 modules 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.

Limitations and restrictions

The following limitations apply to these roles, and some may persist beyond the Beta period:

Restriction	Notes
Apps running in the flexible environment are not supported.	The App Engine curated roles only work for apps running in the App Engine standard environment. This means, for example, that a user trying to deploy a module to the flexible environment must use the primitive Editor role on the project. The Deployer and App Admin roles do not currently grant sufficient permissions for a deployment to the the flexible environment to succeed.
None of the roles allow access to pages that have a `login:admin` restriction.	To access a page designated as `login:admin` in the `app.yaml`, use an Owner, Viewer or Editor role. In the future, we expect that App Admin as well as Service Admin will allow this access.
You must use the Google Cloud Platform Console with curated roles.	Users granted these new curated roles must use the Google Cloud Platform Console to manage their applications, not any older, legacy consoles.
The App Engine application continues to have Editor role on the project.	The application itself, at runtime, continues to have edit access to all the resources in the project. Reducing the permissions of the service account representing the identity of the application is not supported.

10 April 2024

Google App Engine Java Documentation Help