How Deadline Cloud uses IAM service roles Fleet role Customer-managed fleet host role Queue role Monitor role Advanced customization of Deadline Cloud roles

Service roles

How Deadline Cloud uses IAM service roles

Deadline Cloud automatically assumes IAM roles and provides temporary credentials to workers, jobs, and the Deadline Cloud monitor. This approach eliminates manual credential management while maintaining security through role-based access control.

When you create monitors, fleets, and queues, you specify IAM roles that Deadline Cloud assumes on your behalf. Workers and the Deadline Cloud monitor then receive temporary credentials from these roles to access AWS services.

Fleet role

Configure a fleet role to give Deadline Cloud workers the permissions they need to receive work and report progress on that work.

You usually do not have to configure this role yourself. This role can be created for you in the Deadline Cloud console to include the necessary permissions. Use the following guide to understand the specifics of this role for troubleshooting.

When creating or updating fleets programmatically, specify the fleet role ARN using the CreateFleet or UpdateFleet API operations.

What the fleet role does

The fleet role provides workers with permissions to:

Receive new work and report progress on ongoing work to the Deadline Cloud service
Manage worker lifecycle and status
Record log events to Amazon CloudWatch Logs for the worker logs

Set up the fleet role trust policy

Your fleet role must trust the Deadline Cloud service and be scoped to your specific farm.

As a best practice, the trust policy should include security conditions for Confused Deputy protection. To learn more about Confused Deputy protection, see Confused Deputy in the Deadline Cloud User Guide.

aws:SourceAccount ensures only resources from the same AWS account can assume this role.
aws:SourceArn restricts role assumption to a specific Deadline Cloud farm.


{
  "Version": "2012-10-17", 		 	 	 
  "Statement": [
    {
      "Sid": "AllowDeadlineCredentialsService",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "credentials.deadline.amazonaws.com"
      },
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "YOUR_ACCOUNT_ID"
        },
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:deadline:REGION:YOUR_ACCOUNT_ID:farm/YOUR_FARM_ID"
        }
      }
    }
  ]
}

Attach the Fleet role permissions

Attach the following AWS managed policy to your fleet role:

AWSDeadlineCloud-FleetWorker

This managed policy provides permissions for:

deadline:AssumeFleetRoleForWorker - Allows workers to refresh their credentials.
deadline:UpdateWorker - Allows workers to update their status (for example, to STOPPED when exiting).
deadline:UpdateWorkerSchedule - For obtaining work and reporting progress.
deadline:BatchGetJobEntity - For fetching job information.
deadline:AssumeQueueRoleForWorker - For accessing queue role credentials during job execution.

Add KMS permissions for encrypted farms

If your farm was created using a KMS key, add these permissions to your fleet role to ensure the worker can access encrypted data in the farm.

The KMS permissions are only necessary if your farm has an associated KMS key. The kms:ViaService condition must use the format deadline.{region}.amazonaws.com.

When creating a fleet, a CloudWatch Logs log group is created for that fleet. The worker's permissions are used by the Deadline Cloud service to create a log stream specifically for that particular worker. After the worker is set up and running, the worker will use these permissions to send log events directly to CloudWatch Logs.


{
  "Version": "2012-10-17", 		 	 	 
  "Statement": [
    {
      "Sid": "CreateLogStream",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream"
      ],
      "Resource": "arn:aws:logs:REGION:YOUR_ACCOUNT_ID:log-group:/aws/deadline/YOUR_FARM_ID/*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "aws:CalledVia": [
            "deadline.REGION.amazonaws.com"
          ]
        }
      }
    },
    {
      "Sid": "ManageLogEvents",
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:GetLogEvents"
      ],
      "Resource": "arn:aws:logs:REGION:YOUR_ACCOUNT_ID:log-group:/aws/deadline/YOUR_FARM_ID/*"
    },
    {
      "Sid": "ManageKmsKey",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:GenerateDataKey"
      ],
      "Resource": "YOUR_FARM_KMS_KEY_ARN",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "deadline.REGION.amazonaws.com"
        }
      }
    }
  ]
}

Modifying the fleet role

Permissions for the fleet role are not customizable. The described permissions are always required and adding additional permissions will have no effect or use.

Customer-managed fleet host role

Set up a WorkerHost role if you use customer-managed fleets on Amazon EC2 instances or on-premises hosts.

What the WorkerHost role does

The WorkerHost role bootstraps workers on customer-managed fleet hosts. It provides the minimal permissions needed for a host to:

Create a worker in Deadline Cloud
Assume the fleet role to fetch operational credentials
Tag workers with fleet tags (if tag propagation is enabled)

Set up WorkerHost role permissions

Attach the following AWS managed policy to your WorkerHost role:

AWSDeadlineCloud-WorkerHost

This managed policy provides permissions for:

deadline:CreateWorker - Allows the host to register a new worker.
deadline:AssumeFleetRoleForWorker - Allows the host to assume the fleet role.
deadline:TagResource - Allows tagging workers during creation (if enabled).
deadline:ListTagsForResource - Allows reading fleet tags for propagation.

Understand the bootstrap process

The WorkerHost role is only used during initial worker startup:

The worker agent starts on the host using WorkerHost credentials.
It invokes deadline:CreateWorker to register with Deadline Cloud.
It then invokes deadline:AssumeFleetRoleForWorker to fetch fleet role credentials.
From this point forward, the worker uses only fleet role credentials for all operations.

The WorkerHost role is not used after the worker starts running. This policy is not required for Service-managed fleets. In Service-managed fleets, bootstrapping is performed automatically.

Queue role

The queue role is assumed by the worker when processing a task. This role provides the permissions needed to complete the task.

When creating or updating queues programmatically, specify the queue role ARN using the CreateQueue or UpdateQueue API operations.

Set up the queue role trust policy

Your queue role must trust the Deadline Cloud service.

aws:SourceAccount ensures only resources from the same AWS account can assume this role.
aws:SourceArn restricts role assumption to a specific Deadline Cloud farm.


{
  "Version": "2012-10-17", 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "credentials.deadline.amazonaws.com",
          "deadline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "YOUR_ACCOUNT_ID"
        },
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:deadline:us-west-2:123456789012:farm/{farm-id}"
        }        
      }
    }
  ]
}

Understand queue role permissions

The queue role doesn't use a single managed policy. Instead, the Deadline Cloud console creates a custom policy for your queue based on your configuration.

This automatically created policy provides access to:

Job attachments

Read and write access to your specified Amazon S3 bucket for job input and output files:


{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject", 
    "s3:ListBucket",
    "s3:GetBucketLocation"
  ],
  "Resource": [
    "arn:aws:s3:::YOUR_JOB_ATTACHMENTS_BUCKET",
    "arn:aws:s3:::YOUR_JOB_ATTACHMENTS_BUCKET/YOUR_PREFIX/*"
  ],
  "Condition": {
    "StringEquals": {
      "aws:ResourceAccount": "YOUR_ACCOUNT_ID"
    }
  }
}

Job logs

Read access to CloudWatch Logs for jobs in this queue. Each queue has its own log group and each session has its own log stream:


{
  "Effect": "Allow",
  "Action": [
    "logs:GetLogEvents"
  ],
  "Resource": "arn:aws:logs:REGION:YOUR_ACCOUNT_ID:log-group:/aws/deadline/YOUR_FARM_ID/*"
}

Third-party software

Access to download third-party software supported by Deadline Cloud (such as Maya, Blender, and others):


{
  "Effect": "Allow",
  "Action": [
    "s3:ListBucket",
    "s3:GetObject"
  ],
  "Resource": "*",
  "Condition": {
    "ArnLike": {
      "s3:DataAccessPointArn": "arn:aws:s3:*:*:accesspoint/deadline-software-*"
    },
    "StringEquals": {
      "s3:AccessPointNetworkOrigin": "VPC"
    }
  }
}

Add permissions for your jobs

Add permissions to your queue role for AWS services that your jobs need to access. When writing OpenJobDescription step scripts, the AWS CLI and SDK will automatically use credentials from your queue role. Use this to access additional services needed to complete your job.

Example use cases include:

for fetching custom data
SSM permissions to tunnel to a custom license server
CloudWatch for emitting custom metrics
Deadline Cloud permission to create new jobs for dynamic workflows

How queue role credentials are used

Deadline Cloud provides queue role credentials to:

Workers during job execution
Users via Deadline Cloud CLI and monitor when interacting with job attachments and logs

Deadline Cloud creates separate CloudWatch Logs log groups for each queue. Jobs use queue role credentials to write logs to their queue's log group. The Deadline Cloud CLI and monitor use the queue role (via deadline:AssumeQueueRoleForRead) to read job logs from the queue's log group. The Deadline Cloud CLI and monitor use the queue role (via deadline:AssumeQueueRoleForUser) to upload or download job attachments data.

Monitor role

Configure a monitor role to give the Deadline Cloud monitor web and desktop applications access to your Deadline Cloud resources.

When creating or updating monitors programmatically, specify the monitor role ARN using the CreateMonitor or UpdateMonitor API operations.

What the monitor role does

The monitor role enables Deadline Cloud monitor to provide end users with access to:

Basic functionality required for the Deadline Cloud Integrated Submitters, CLI and monitor
Custom functionality for end users

Set up the monitor role trust policy

Your monitor role must trust the Deadline Cloud service.

aws:SourceAccount ensures only resources from the same AWS account can assume this role.


{
  "Version": "2012-10-17", 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "credentials.deadline.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "YOUR_ACCOUNT_ID"
        }
      }
    }
  ]
}

Attach monitor role permissions

Attach all of the following AWS managed policies to your monitor role for basic operation:

How the monitor role works

When using the Deadline Cloud monitor, when a service user signs in using the monitor role is assumed. The assume role credentials are used by the monitor application to display the monitor UI, including the list of farms, fleet, queues and other information.

When using the Deadline Cloud monitor desktop application, these credentials are additionally made available on the workstation using a named AWS credential profile corresponding to the profile name provided by the end user. Learn more about named profiles in the AWS SDK and Tools reference guide.

This named profile is how the Deadline CLI and submitters access Deadline Cloud resources.

Customizing the monitor role for advanced desktop use cases

Follow these guidelines when modifying your monitor role:

Don't remove any of the managed policies. This will break monitor functionality.
You may add additional permissions for advanced scripting workflows.

How Deadline Cloud monitor uses monitor role credentials

Deadline Cloud monitor automatically obtains monitor role credentials when you authenticate. This enables the desktop application to provide enhanced monitoring capabilities beyond what's available in a standard web browser.

When you log in with Deadline Cloud monitor, it automatically creates a profile that you can use with the AWS CLI or any other AWS tool. This profile uses the monitor role credentials, giving you programmatic access to AWS services based on the permissions in your monitor role.

Deadline Cloud submitters work the same way - they use the profile created by Deadline Cloud monitor to access AWS services with the appropriate role permissions.

Advanced customization of Deadline Cloud roles

You can extend Deadline Cloud roles with additional permissions to enable advanced use cases beyond basic rendering workflows. This approach leverages Deadline Cloud's access management system to control access to additional AWS services based on queue membership.

Team collaboration with AWS CodeCommit

Add AWS CodeCommit permissions to your Queue role to enable team collaboration on project repositories. This approach uses Deadline Cloud's access management system for additional use cases - only users with access to the specific queue will receive these AWS CodeCommit permissions, allowing you to manage per-project repository access through Deadline Cloud queue membership.

This is useful for scenarios where artists need to access project-specific assets, scripts, or configuration files stored in AWS CodeCommit repositories as part of their rendering workflow.

Add AWS CodeCommit permissions to queue role

Add the following permissions to your queue role to enable AWS CodeCommit access:


{
  "Effect": "Allow",
  "Action": [
    "codecommit:GitPull",
    "codecommit:GitPush",
    "codecommit:GetRepository",
    "codecommit:ListRepositories"
  ],
  "Resource": "arn:aws:codecommit:REGION:YOUR_ACCOUNT_ID:PROJECT_REPOSITORY"
}

Set up credential provider on artist workstations

Configure each artist workstation to use Deadline Cloud queue credentials for AWS CodeCommit access. This setup is done once per workstation.

To configure the credential provider

Add a credential provider profile to your AWS config file (~/.aws/config):


[profile queue-codecommit]
credential_process = deadline queue export-credentials --farm-id farm-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --queue-id queue-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Configure Git to use this profile for AWS CodeCommit repositories:


git config --global credential.https://git-codecommit.REGION.amazonaws.com.rproxy.govskope.ca.helper '!aws codecommit credential-helper --profile queue-codecommit $@'
git config --global credential.https://git-codecommit.REGION.amazonaws.com.rproxy.govskope.ca.UseHttpPath true

Replace farm-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX and queue-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX with your actual farm and queue IDs. Replace REGION with your AWS region (for example, us-west-2).

Using AWS CodeCommit with queue credentials

Once configured, Git operations will automatically use the queue role credentials when accessing AWS CodeCommit repositories. The deadline queue export-credentials command returns temporary credentials that look like this:


{
  "Version": 1,
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "SessionToken": "...",
  "Expiration": "2025-11-10T23:02:23+00:00"
}

These credentials are automatically refreshed as needed, and Git operations will work seamlessly:


git clone https://git-codecommit.REGION.amazonaws.com/v1/repos/PROJECT_REPOSITORY
git pull
git push

Artists can now access project repositories using their queue permissions without needing separate AWS CodeCommit credentials. Only users with access to the specific queue will be able to access the associated repository, enabling fine-grained access control through Deadline Cloud's queue membership system.

Warning Javascript is disabled or is unavailable in your browser.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

AWS managed policies

Troubleshooting