Secure queue configuration

This page provides suggestions for securing queue creation and configuration. 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:

1. 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.
2. 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.
3. 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

1. 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
   

   Replace the following:

   • PROJECT_ID: the ID of your project
   • EMAIL: the email for the member user

2. 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.

1. 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
   

   Replace PROJECT_ID with the ID of your project.

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

App Engine Deployer

1. 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
   

   Replace the following:

   • PROJECT_ID: the ID of your project
   • EMAIL: the email for the member user

2. 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.

To follow the principle of least privilege and simplify access management, these instructions use service account impersonation. To learn more about this pattern, see Use service account impersonation in the Google Cloud authentication documentation.

Caution: If queues are removed from queue.yaml, they enter the DISABLED state and only queue admins can delete them. Since there is no way to delete queues programmatically in the App Engine SDK, your tool would have to delete them via a Cloud Tasks DeleteQueue call.

Instructions for setting up these service accounts follow.

Queue Admin

1. As a project admin, create the service account.

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

2. 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
   

   Replace PROJECT_ID with the ID of your project.

3. Selectively allow impersonation of the "Queue Admin" service account that you created.

   This should usually be a small group of principals who act as queue administrators. Grant these principals the iam.serviceAccountTokenCreator role on the "Queue Admin" service account that you created. To learn how, see Grant or revoke a single role in the IAM documentation.

4. Following the best practices described in Use Queue Management or queue.yaml, choose one of the following methods for changing the queue configuration:

   • Use Cloud Tasks to change queue configuration.

   • Upload queue.yaml with the gcloud CLI

Cloud Tasks Worker

1. As a project admin, create the service account.

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

2. 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
   

   Replace PROJECT_ID with the ID of your project.

3. Selectively allow impersonation of the "Cloud Tasks Worker" service account you created.

   For principals who interact with Cloud Tasks, grant the iam.serviceAccountTokenCreator role on the "Cloud Tasks Worker" service account you created. To learn how, see Grant or revoke a single role in the IAM documentation.

App Engine Deployer

1. As a project admin, create the service account.

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

2. 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
   

   Replace PROJECT_ID with the ID of your project.

3. Selectively allow impersonation of the "App Engine Deployer" service account that you created.

   For principals who deploy App Engine services, grant the iam.serviceAccountTokenCreator role on the "App Engine Deployer" service account that you created. To learn how, see Grant or revoke a single role in the IAM documentation.

Limiting access to single queues

If you have multiple queues in a project and want to limit access to individual queues, you can use IAM policies at the queue level instead of the project level. To limit access by queue, use the gcloud tasks queues add-iam-policy-binding command. For example:

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

Replace the following:

• QUEUE_NAME: the name of your queue
• LOCATION: the location of your queue
• PROJECT_ID: the ID of your project

What's next

• Service accounts
• Understanding service accounts
• Manage access to projects, folders, and organizations
• Creating and managing service accounts
• Use service account impersonation