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 mixingqueue.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 uploadqueue.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.Use Cloud Tasks API to change queue configuration.
Upload
queue.yaml
withgcloud
: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 uploadqueue.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:
Use Cloud Tasks to change queue configuration.
Upload
queue.yaml
withgcloud
: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:
- Service accounts
- Understanding service sccounts
- Manage access to projects, folders, and organizations
- Creating and managing service accounts