# 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. Four roles cover the lifecycle of work in a farm. On a customer-managed fleet, a new host starts with the *worker host role*, uses it to register as a worker, and trades it for *fleet role* credentials. On a service-managed fleet, the service performs that bootstrap for you, so only the other three roles apply. The worker uses the fleet role to receive work and report progress, and receives *queue role* credentials while it runs each job. People and tools get their credentials from the *monitor role* when they sign in to the Deadline Cloud monitor. **Deadline Cloud service roles at a glance** | Role | Who uses its credentials | What it grants | Associated resource | | --- | --- | --- | --- | | [Worker host role](#customer-managed-fleet-host-role) | Customer-managed fleet hosts during startup | Register a new worker and assume the fleet role | The worker host, for example through an Amazon EC2 instance profile | | [Fleet role](#fleet-role) | Workers on the fleet | Receive work, report progress, and write worker logs to CloudWatch Logs | The fleet | | [Queue role](#queue-role) | Jobs while they run; monitor and CLI users working with job attachments and logs | Read and write the queue's job attachments bucket, read job logs, download third-party software, plus any permissions you add for your jobs | The queue | | [Monitor role](#monitor-role) | People signed in to the Deadline Cloud monitor, and the CLI and submitters through the profile it creates | Access to farm, fleet, queue, and job data based on each user's memberships and access level | The monitor | When you create monitors, fleets, and queues in the console, Deadline Cloud can create the fleet, queue, and monitor roles for you with the necessary permissions. You create the worker host role yourself when you set up a customer-managed fleet. Use the following sections to understand each role for troubleshooting, to create the roles yourself, or to extend them. ## 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](cross-service-confused-deputy-prevention.md) 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](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDeadlineCloud-FleetWorker.html) 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 has no effect. ## Worker host role Set up a worker host role if you use customer-managed fleets on Amazon EC2 instances or on-premises hosts. ### What the worker host role does The worker host role (`WorkerHost`) 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 worker host role permissions Attach the following AWS managed policy to your worker host role: [AWSDeadlineCloud-WorkerHost](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDeadlineCloud-WorkerHost.html) 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 worker host role is only used during initial worker startup: 1. The worker agent starts on the host using worker host role credentials. 1. It invokes `deadline:CreateWorker` to register with Deadline Cloud. 1. It then invokes `deadline:AssumeFleetRoleForWorker` to fetch fleet role credentials. 1. From this point forward, the worker uses only fleet role credentials for all operations. After the worker starts running, it no longer uses the worker host role. Service-managed fleets don't need this role because the service performs the bootstrap 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. 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](cross-service-confused-deputy-prevention.md) 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": [ { "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, when you configure your queue in the console, Deadline Cloud 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. The Deadline Cloud CLI and monitor use the queue role (through `deadline:AssumeQueueRoleForRead`) to read job logs from the queue's log group. The Deadline Cloud CLI and monitor use the queue role (through `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. 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](cross-service-confused-deputy-prevention.md) in the *Deadline Cloud User Guide*. `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: + [AWSDeadlineCloud-UserAccessFarms](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDeadlineCloud-UserAccessFarms.html) + [AWSDeadlineCloud-UserAccessFleets](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDeadlineCloud-UserAccessFleets.html) + [AWSDeadlineCloud-UserAccessJobs](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDeadlineCloud-UserAccessJobs.html) + [AWSDeadlineCloud-UserAccessQueues](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDeadlineCloud-UserAccessQueues.html) ### How the monitor role works When using the Deadline Cloud monitor, a service user signs in using AWS IAM Identity Center (IAM Identity Center), and the monitor role is assumed. The assumed role credentials are used by the monitor application to display the monitor UI, including the list of farms, fleets, 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](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html). This named profile is how the Deadline CLI and submitters access Deadline Cloud resources. ### Customizing the monitor role for advanced use cases You can customize the monitor role to modify what users can do at each access level (Viewer, Contributor, Manager, Owner) or to add permissions for advanced workflows. #### Customizing access level permissions The four AWS managed policies attached to the monitor role control what each access level can do. You can add custom policies to the monitor role to grant or restrict permissions for specific access levels using the `deadline:MembershipLevel` condition key. For example, to allow Contributors to update and cancel jobs (which is normally restricted to Managers and Owners), add a policy like the following: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "deadline:UpdateJob", "Resource": "*", "Condition": { "StringEquals": { "deadline:MembershipLevel": "CONTRIBUTOR" } } } ] } ``` With this policy, Contributors can update and cancel jobs in addition to submitting them. #### Adding permissions for advanced workflows You can add custom IAM policies to the monitor role to grant additional permissions to all monitor users. Custom policies are useful for advanced scripting workflows where users need access to AWS services beyond the standard Deadline Cloud functionality. Follow these guidelines when modifying your monitor role: + Don't remove any of the managed policies. Removing these policies breaks monitor functionality. ### How Deadline Cloud monitor uses monitor role credentials Deadline Cloud monitor automatically obtains monitor role credentials when you authenticate. These temporary credentials last for 15 minutes and automatically refresh as long as you are signed in to IAM Identity Center. This capability enables the desktop application to provide 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 uses the access management system in Deadline Cloud 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 the access management system in Deadline Cloud for additional use cases. Only users with access to the specific queue receive these AWS CodeCommit permissions, so you can manage per-project repository access through Deadline Cloud queue membership. Repository access through queue membership is useful when 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** 1. 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}} ``` 1. Configure Git to use this profile for AWS CodeCommit repositories: ``` git config --global credential.https://git-codecommit.{{REGION}}.amazonaws.com.rproxy.goskope.com.helper '!aws codecommit credential-helper --profile queue-codecommit $@' git config --global credential.https://git-codecommit.{{REGION}}.amazonaws.com.rproxy.goskope.com.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" } ``` Deadline Cloud automatically refreshes these credentials as needed, and your Git operations work without additional configuration: ``` 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, so you can control repository access through queue membership in Deadline Cloud.