Secure queue configuration

This page provides suggestions for implementing best practices for securing queue creation and configuration, including minimizing the pitfalls described in Use Queue Management or queue.yaml. The key is to restrict queue management methods to a small set of people or entities. For large organizations, it might be necessary to use a service account to run software that enforces proper queue configuration.

The general idea is to separate users and other entities into three categories:

Queue Admins - Users in this group have permission to call Cloud Tasks queue management methods, or to upload queue.yaml files. This group is restricted to a very small set of users so as to reduce the risk of clobbering queue configuration, particularly by inadvertently mixing queue.yaml and Cloud Tasks queue management methods.
Cloud Tasks Workers - Users in this group have permission to perform common interactions with Cloud Tasks such as enqueuing and dequeuing tasks. They are not allowed to call Cloud Tasks queue management methods.
App Engine Deployers - For projects that have App Engine apps, users in this group have permission to deploy the app. They are not permitted to upload queue.yaml files or make any Cloud Tasks API calls, thus allowing the queue admins to enforce the proper policies.

In this scheme, users who are queue admins should not also be Cloud Tasks workers, since that would defeat the purpose of the separation.

If your project uses Cloud Tasks queue management methods exclusively, it might also make sense that queue admins should not also be App Engine deployers, since this would make it possible for an errant queue.yaml file to be uploaded.

Small projects and organizations

Small projects and organizations can assign Identity and Access Management (IAM) roles directly to users to place them into the groups above. This makes sense for teams who prefer configuration simplicity or who make queue configuration changes or App Engine app deployments by hand.

Add users to these groups as follows:

Queue Admin

As a project admin, grant the cloudtasks.queueAdmin role to users who are allowed to make Cloud Tasks queue management API calls or upload queue.yaml files.
```
gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member user:[EMAIL] \
  --role roles/cloudtasks.queueAdmin
```
As a user with the cloudtasks.queueAdmin role, following the best practices above, choose one of the following methods for changing the queue configuration.
1. Use Cloud Tasks API to change queue configuration.
2. Upload queue.yaml with gcloud:
```
gcloud app deploy queue.yaml
```

Cloud Tasks Worker

As there are often many users allowed to interact with Cloud Tasks, you can assign roles to Service Accounts instead of individual users. This type of usage is common in production. For more information, see Large projects and organizations.

As a project admin, grant roles to users who are allowed to interact with Cloud Tasks but not change queue configuration:

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.viewer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.enqueuer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.dequeuer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.taskRunner

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.taskDeleter

As a user with one or more of the roles granted above, you can interact with the Cloud Tasks API.

App Engine Deployer

As a project admin, grant roles to users who are allowed to deploy App Engine apps but who are not allowed to modify queue configuration or interact with tasks:

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member user:[EMAIL] \
  --role roles/appengine.deployer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member user:[EMAIL] \
  --role roles/appengine.serviceAdmin

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member user:[EMAIL] \
  --role roles/storage.admin

As a user with the roles granted above, deploy an App Engine app.
```
gcloud app deploy app.yaml
```

Large projects and organizations

Large projects and organizations can use Service Accounts to separate duties and responsibilities. This makes sense for teams with complex infrastructure for changing queue configuration and perhaps also deploying App Engine apps.

The instructions below are generally appropriate when queue configuration and interaction with Cloud Tasks, and potentially App Engine app deployment, happen through software rather than through a human user directly. This also makes it possible to protect queue configuration without requiring all members of your team to understand the content on this page.

For example, you can create a web app or command line tool that all users must use to create, update, and delete queues. Whether that tool uses Cloud Tasks queue management methods or queue.yaml is an implementation detail of the tool that users do not need to worry about. If the tool is the only entity in the queue admins group, then you can guarantee that there is no inadvertent mixing of Cloud Tasks queue management methods and queue.yaml use.

Instructions for setting up these service accounts follow.

Queue Admin

As a project admin, create the service account.

gcloud iam service-accounts create queue-admin \
  --display-name "Queue Admin"

Grant the cloudtasks.queueAdmin role to the service account so that it can upload queue.yaml files and make Cloud Tasks queue management API calls.

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:queue-admin@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.queueAdmin

Grant the iam.serviceAccountActor role to human users, groups, or other entities that are allowed to change queue configuration. This should be a very small number of people, for example administrators who are allowed to respond in emergencies.
```
gcloud iam service-accounts add-iam-policy-binding \
  queue-admin@[PROJECT_ID].iam.gserviceaccount.com \
  --member user:[EMAIL] \
  --role roles/iam.serviceAccountActor
```

Create a service account key so that a human user or another entity can assume the identity of the service account.

gcloud iam service-accounts keys create \
  --iam-account queue-admin@[PROJECT_ID].iam.gserviceaccount.com \
  ~/queue-admin-service-account-key.json

As a user or other entity given the iam.serviceAccountActor role, assume the identity of the service account.

gcloud auth activate-service-account queue-admin@[PROJECT_ID].iam.gserviceaccount.com \
  --key-file ~/queue-admin-service-account-key.json

Following the best practices above, choose only one of the following methods for changing the queue configuration:
1. Use Cloud Tasks to change queue configuration.
2. Upload queue.yaml with gcloud:
```
gcloud app deploy queue.yaml
```

Cloud Tasks Worker

As a project admin, create the service account.

gcloud iam service-accounts create cloud-tasks-worker \
  --display-name "Cloud Tasks Worker"

Grant roles to the service account so that it can interact with Cloud Tasks but not change queue configuration.

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.viewer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.enqueuer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.dequeuer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.taskRunner

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/cloudtasks.taskDeleter

Grant the iam.serviceAccountActor role to human users, groups, or other entities that are allowed to use the Cloud Tasks API in your project.

gcloud iam service-accounts add-iam-policy-binding \
  cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --member user:[EMAIL] \
  --role roles/iam.serviceAccountActor

Create a service account key so that a human user or another entity can assume the identity of the service account.

gcloud iam service-accounts keys create \
  --iam-account cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  ~/cloud-tasks-worker-service-account-key.json

As a user or other entity given the iam.serviceAccountActor role, assume the identity of the service account.

gcloud auth activate-service-account cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
  --key-file ~/cloud-tasks-worker-service-account-key.json

Use the Cloud Tasks API.

App Engine Deployer

As a project admin, create the service account.

gcloud iam service-accounts create app-engine-deployer \
  --display-name "App Engine Deployer"

Grant roles to the service account so that it can deploy App Engine apps but not queue.yaml.

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:app-engine-deployer@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/appengine.deployer

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:app-engine-deployer@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/appengine.serviceAdmin

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member serviceAccount:app-engine-deployer@[PROJECT_ID].iam.gserviceaccount.com \
  --role roles/storage.admin

Grant the iam.serviceAccountActor role to human users, groups, or other entities that are allowed to deploy the App Engine app.

gcloud iam service-accounts add-iam-policy-binding \
  app-engine-deployer@[PROJECT_ID].iam.gserviceaccount.com \
  --member user:[EMAIL] \
  --role roles/iam.serviceAccountActor

Create a service account key so that a human user or another entity can assume the identity of the service account.

gcloud iam service-accounts keys create \
  --iam-account app-engine-deployer@[PROJECT_ID].iam.gserviceaccount.com \
  ~/app-engine-deployer-service-account-key.json

As a user or other entity given the iam.serviceAccountActor role, assume the identity of the service account.

gcloud auth activate-service-account app-engine-deployer@[PROJECT_ID].iam.gserviceaccount.com \
  --key-file ~/app-engine-deployer-service-account-key.json

Deploy the App Engine app.
```
gcloud app deploy app.yaml
```

Limiting access to single queues

To limit access by queue, use the gcloud tasks queues add-iam-policy-binding command specifying the queue using the QUEUE argument. For example, for a queue named my-queue:

    gcloud tasks queues add-iam-policy-binding my-queue --location=my-location \
    --member=serviceAccount:cloud-tasks-worker@[PROJECT_ID].iam.gserviceaccount.com \
    --role=roles/cloudtasks.enqueuer

More information about service accounts

For a comprehensive explanation of service accounts, see the following pages: