Great question — and nice catch. Short answer: -

OidcAwsCredentials

in the ECS push work pool base job template is a Prefect Cloud–managed credential type used for Workload Identity (OIDC) to assume an AWS IAM role at run time. - It’s not a user-facing block or class in

prefect-aws

, which is why you won’t find it in the SDK docs or code. Prefect Cloud injects these short‑lived AWS credentials into the job when your work pool is configured to use an AWS Workload Identity. What this means in practice: - You configure an AWS IAM role with a trust policy that allows Prefect Cloud’s OIDC provider to assume the role (via STS). - In Prefect Cloud, you add an AWS Workload Identity and attach it to your ECS push work pool. - At run time, Prefect Cloud exchanges its OIDC token for temporary AWS credentials and populates the job template’s

credentials

with

OidcAwsCredentials

. Docs and references: - General Prefect AWS integration overview: Prefect AWS integration - ECS concepts and worker/pool context: ECS guide (for background on how ECS is used with Prefect) Today, there isn’t a public SDK reference page specifically for

OidcAwsCredentials

because it’s a Cloud-internal type, not something you import or configure directly in code. If it’s helpful, I can share: - A high-level checklist for setting up the IAM role trust policy and permissions (ECS/ECR, etc.) - A sample trust policy you can adapt (you’ll need the issuer/audience and subject conditions provided in your Prefect Cloud “Workload Identity” UI) Are you setting this up on Prefect Cloud now? If so, let me know and I’ll tailor the exact steps and example policy to your workspace.

@Marvin I can't see the Workload Identity option in the UI, and also what would be the details to add the new OIDC identiy on the AWS side?

Thanks for flagging this. Why you can’t see “Workload Identity” - The AWS Workload Identity (OIDC) feature for push work pools is currently gated in Prefect Cloud and may not be enabled for all workspaces yet. - If you don’t see it in the UI, it likely hasn’t been enabled for your workspace/organization. Next steps - If you’re on Prefect Cloud, please DM me your workspace URL (or org slug), or contact your account team/in-app support to have Workload Identity enabled for your workspace. - Once enabled, the UI will show you the exact OIDC issuer, audience, and subject values you’ll need to use on the AWS side. AWS-side setup (what you’ll need to add) When the feature is enabled, the Prefect UI will provide the exact values (issuer/audience/subject). The high-level AWS steps are: 1) Create an IAM OIDC Identity Provider - Use the Issuer URL from the Prefect Cloud Workload Identity page. - AWS docs: Create an OIDC provider in IAM 2) Create an IAM role that trusts that OIDC provider - Trust policy uses Action

sts:AssumeRoleWithWebIdentity

, the OIDC provider as Principal (Federated), and Conditions that match the audience and subject values from Prefect Cloud. - Example trust policy structure (PLACEHOLDERS: replace with the values shown in Prefect Cloud; keys and patterns will differ by provider and workspace):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/<OIDC_ISSUER_HOST>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<OIDC_ISSUER_HOST>:aud": "<http://sts.amazonaws.com|sts.amazonaws.com>"
        },
        "StringLike": {
          "<OIDC_ISSUER_HOST>:sub": "<VALUE_PROVIDED_BY_PREFECT_CLOUD>"
        }
      }
    }
  ]
}

- STS API reference: AssumeRoleWithWebIdentity 3) Attach a permissions policy to that role (control-plane permissions) - This is what Prefect Cloud will use to start your ECS tasks. - A minimal example (tighten as needed to your environment):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecs:RunTask",
        "ecs:DescribeTasks",
        "ecs:DescribeTaskDefinition"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": [
        "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_TASK_EXECUTION_ROLE>",
        "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_TASK_ROLE>"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
        }
      }
    }
  ]
}

- Note: ECR pulls are handled by your ECS task execution role, not the Prefect control-plane role above. Ensure your task execution role has

AmazonECSTaskExecutionRolePolicy

(or equivalent custom permissions for ECR, logs, etc.). 4) Back in Prefect Cloud - Add a new AWS Workload Identity (you’ll supply the IAM role ARN you just created). - Attach it to your ECS push work pool. A couple of helpful references: - Prefect AWS integration overview: Prefect AWS integration - AWS OIDC provider setup: AWS: Create OIDC provider Because the exact issuer/audience/subject values are provided in the Prefect UI, I don’t want to guess them here. Once we enable Workload Identity for your workspace, you’ll see those values and can copy/paste them directly into the AWS trust policy.

Would you like me to check on enabling Workload Identity for your workspace? If so, please share your workspace URL (or org + workspace names). I’m also happy to tailor a least‑privilege policy once I know your ECS cluster, task role, and execution role ARNs.

Thanks — I’ve got those workspace IDs noted. Enabling Workload Identity - I can’t flip this on directly from here, but I’ll open an internal request with our Cloud team to enable Workload Identity (AWS OIDC) for both workspaces. - To avoid delays, could you please share: - Your org name/slug - The human‑readable workspace names for the two IDs (to double‑check) - Confirmation that you’re an org admin - Preferred contact email - Cloud region (US or EU) If you prefer, you can also ping in‑app support or email support@prefect.io and reference these workspace IDs. What you’ll need to add on the AWS side Once Workload Identity is enabled, the Prefect Cloud UI will display the exact OIDC issuer, audience, and subject values you’ll need. The high‑level AWS steps are: 1) Create an IAM OIDC Identity Provider - Use the issuer URL shown in Prefect Cloud. - AWS guide: Create an OIDC provider in IAM 2) Create an IAM role that trusts that OIDC provider - Use

sts:AssumeRoleWithWebIdentity

- Put the OIDC provider ARN in the

Principal.Federated

- Match the audience and subject shown in Prefect Cloud Example trust policy structure (replace placeholders with the values from the Prefect UI and your AWS account):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/<OIDC_ISSUER_HOST>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<OIDC_ISSUER_HOST>:aud": "<http://sts.amazonaws.com|sts.amazonaws.com>"
        },
        "StringLike": {
          "<OIDC_ISSUER_HOST>:sub": "<SUBJECT_VALUE_FROM_PREFECT_UI>"
        }
      }
    }
  ]
}

- STS details: AssumeRoleWithWebIdentity 3) Attach a permissions policy to that role (control plane) - This role is used by Prefect Cloud to start and monitor your ECS tasks. Tighten as needed to your resources.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecs:RunTask",
        "ecs:DescribeTasks",
        "ecs:DescribeTaskDefinition",
        "ecs:DescribeClusters",
        "ecs:ListTasks",
        "ecs:StopTask"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": [
        "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_TASK_EXECUTION_ROLE>",
        "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_TASK_ROLE>"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
        }
      }
    }
  ]
}

Notes: - ECR image pulls, CloudWatch logs, etc., are handled by your ECS task execution role (e.g., with

AmazonECSTaskExecutionRolePolicy

). Prefect’s OIDC role does not need direct ECR permissions if your execution role is set up correctly. - The base job template will show

type: OidcAwsCredentials

automatically when a Workload Identity is attached — no code changes needed on your end. 4) Connect the role in Prefect Cloud - After the feature is enabled, go to Work Pools > your ECS Push pool > Credentials > Add Workload Identity (AWS) and enter the IAM Role ARN you created. Helpful references: - Prefect AWS integration overview: Prefect AWS integration - AWS OIDC provider setup: AWS: Create OIDC provider If you share your AWS account ID(s), ECS cluster name, and the ARNs of your task role/execution role, I can tailor a least‑privilege policy for you. I’ll also update you here as soon as Workload Identity is enabled for those workspaces.

Great questions! Cost - There’s no metered/per‑use surcharge from Prefect to use Workload Identity (AWS OIDC). Availability is currently gated and may depend on your Cloud plan; we’ll confirm eligibility when we process your request. - On the AWS side, creating an OIDC provider and using STS AssumeRoleWithWebIdentity does not add separate charges; you’ll pay your normal AWS costs for ECS/ECR/CloudWatch, etc. How to share details privately - In‑app support chat (recommended): open Prefect Cloud and use the chat widget (bottom right). Include your workspace IDs and note you’d like Workload Identity enabled. - Email: support@prefect.io — this is best for sending org/workspace details and any sensitive info. - Account team/CSM: if you have one, you can email them directly for faster handling. - If you want me to file the internal request on your behalf, I can do that — please either DM me here with the details or give me permission to share your workspace IDs and your contact email with our support team so they can follow up privately. For convenience, here’s a copy‑paste template you can send via in‑app chat or email:

Subject: Enable AWS Workload Identity (OIDC)

Org name/slug:
Workspace #1 name + ID:
Workspace #2 name + ID:
Cloud region (US/EU):
I am an org admin: yes/no
Preferred contact email:
AWS account ID(s) where ECS will run:
Any compliance constraints (optional):

Please enable Workload Identity (AWS OIDC) for the workspaces above.

Once it’s enabled, the UI will display the exact OIDC issuer/audience/subject you’ll need for the AWS IAM role trust policy. If you want, I can also help draft a least‑privilege IAM policy once you share your ECS cluster and task/execution role ARNs. Reference: - Pricing overview: Prefect pricing

Short answer: not in the Cloud app. I don’t have a direct DM inbox inside Prefect Cloud — the in‑app chat routes to our Support team. Private ways to share details: - Use the in‑app support widget in Prefect Cloud and paste the details there (it’s private to Support). - Or email support@prefect.io. If you prefer, you can DM me here in Slack with the details and explicit permission to share them with Prefect Support. I’ll open the enablement request on your behalf. If you want me to file it, please send this in one message:

Please enable AWS Workload Identity (OIDC).

Org name/slug:
Workspace #1 name + ID: 430a47aa-cff0-4228-8612-37adb6c66cdf
Workspace #2 name + ID: 61d226e7-d7cf-4b2e-8f5e-5350236792be
Cloud region (US/EU):
I am an org admin: yes/no
Preferred contact email:
I consent to Prefect sharing these details with Support to process this request: yes

Absolutely — here’s a copy/paste email template you can send to support. Send it to support@prefect.io.

Subject: Request to enable AWS Workload Identity (OIDC) for ECS Push Work Pools

Hello Prefect Support,

Please enable AWS Workload Identity (OIDC) for the following Prefect Cloud workspaces:

Organization name/slug:
Cloud region (US or EU):

Workspaces:
- <Workspace #1 name> (ID: 430a47aa-cff0-4228-8612-37adb6c66cdf)
- <Workspace #2 name> (ID: 61d226e7-d7cf-4b2e-8f5e-5350236792be)

I am an org admin: yes/no
Preferred contact email:
Preferred Slack handle (optional):

AWS environment details:
- AWS account ID(s) where ECS will run:
- Intended services: ECS (Fargate or EC2?), ECR, CloudWatch Logs
- Any compliance constraints (e.g., region restrictions, SCPs, private subnets only): 

Request:
- Enable AWS Workload Identity (OIDC) for the above workspaces.
- Please provide the OIDC issuer, audience, and subject values needed for our AWS IAM role trust policy.
- We intend to attach the OIDC role to our ECS push work pools.

(Optional) Least-privilege review:
We can share ARNs for our ECS cluster, task role, and execution role if you can advise on a least-privilege control-plane policy.

Desired timeline/priority:

Thank you!
<Your Name>
<Title/Team>
<Company>

If you have an account team/CSM, feel free to CC them for faster handling.

Turnaround time - Typical: same business day to 1 business day once Support has the details - Outside US business hours or with extra compliance checks: up to 2 business days If anything blocks the enablement (e.g., plan eligibility), Support will reply and let you know next steps. Permissions reminder: IAM user vs OIDC role For a push work pool on ECS, Prefect’s “control-plane” identity (either an IAM user with access keys or the OIDC-assumed role) needs only control-plane permissions to launch/monitor tasks. Image pulls and logs are handled by your ECS task execution role inside the task. A. Control-plane permissions (IAM user or OIDC role) - Required for all setups - If you pre-create and reference an existing Task Definition, you do NOT need RegisterTaskDefinition. Minimal policy (broadly scoped; you can tighten later):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ECSControlPlane",
      "Effect": "Allow",
      "Action": [
        "ecs:RunTask",
        "ecs:DescribeTasks",
        "ecs:DescribeTaskDefinition",
        "ecs:DescribeClusters",
        "ecs:ListTasks",
        "ecs:StopTask"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PassTaskRolesToECS",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": [
        "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_TASK_EXECUTION_ROLE>",
        "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_TASK_ROLE>"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
        }
      }
    }
  ]
}

If you let Prefect register task definitions (optional): - Add:

{
  "Sid": "TaskDefinitionLifecycle",
  "Effect": "Allow",
  "Action": [
    "ecs:RegisterTaskDefinition",
    "ecs:DeregisterTaskDefinition"
  ],
  "Resource": "*"
}

- You’ll still need the iam:PassRole statement for the roles referenced in the task definition. Tightening scope (optional best practice) - You can restrict ecs:RunTask, ecs:StopTask, etc., to specific clusters and task definitions using ARNs and/or ECS condition keys. Start broad while testing; then narrow to: - Cluster: arnawsecs&lt;region&gt;<account>:cluster/<your-cluster> - Task definition: arnawsecs&lt;region&gt;<account>task definition/&lt;family&gt;* - Keep iam:PassRole limited to only the exact task role and execution role ARNs your tasks use. B. Task execution role (inside your ECS task) Attach AWS-managed policy AmazonECSTaskExecutionRolePolicy (or equivalent custom) - Grants ECR image pulls and CloudWatch Logs: - ecr:GetAuthorizationToken, ecr:BatchGetImage, ecr:GetDownloadUrlForLayer - logs:CreateLogStream, logs:PutLogEvents Reference: Task execution IAM role and AmazonECSTaskExecutionRolePolicy C. Task role (inside your ECS task) - App-specific permissions (e.g., S3, RDS, etc.) required by your flow code. Notes - For OIDC: the control-plane policy above is what the OIDC role needs. The trust policy will come from the Prefect UI once Workload Identity is enabled (issuer/audience/subject). - For IAM user credentials (alternative to OIDC): use the same control-plane policy as above, but store the keys securely (rotate regularly). Helpful references - Prefect AWS integration overview: Prefect AWS integration - ECS task execution role details: AWS: Task execution IAM role - AssumeRoleWithWebIdentity: AWS STS API reference

If you share your cluster ARN, task definition family, and the task/execution role ARNs, I can draft a least‑privilege, resource‑scoped version you can drop in.