> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/vendor-specific-data-sources/amazon/amazon-s3/create-a-workload-federated-identity-role.md). # Create a Workload Federated Identity role Learn more about creating a Workload Federated Identity role in Cortex XDR. If you do not designate a separate AWS IAM user to provide access to Cortex XDR to your logs and to perform API operations, you can create a Workload Federated Identity (WIF) role in AWS that trusts the Cortex XDR log collector through OpenID Connect (OIDC) federation. This role grants Cortex XDR access to your logs with a short-lived OIDC token, without storing any long-lived AWS credentials. For more information, see [Create a role for OpenID Connect federation (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html). When setting up any type of Amazon S3 Collector in Cortex XDR, these instructions explain setting up a Workload Federated Identity role. To use an assumed role instead, see [Create an assumed role](/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/vendor-specific-data-sources/amazon/amazon-s3/create-an-assumed-role.md). {% hint style="info" %} **Prerequisite** You need to ensure that you have an Amazon S3 bucket and Amazon Simple Queue Service (SQS) already configured, as they're needed to configure an IAM policy. The S3 bucket and SQS required depend on how you plan to configure your Amazon S3 data source: * When using a CloudFormation script provided by Cortex XDR to configure Amazon S3 with SQS notifications, you'll need to either: * Use the out-of-the-box Amazon S3 bucket and Amazon Simple Queue Service (SQS), whose names change according to the Amazon S3 log type you are defining. * Create a new S3 bucket and SQS according to your system requirements. * When configuring data collection from Amazon S3 manually, create an S3 bucket and SQS according to your system requirements. When creating the S3 bucket and SQS, follow any other relevant instructions provided, for example in the prerequisite section, for the specific type of Amazon S3 data you want to ingest in the relevant topic. {% endhint %} 1. Register the Google OIDC identity provider in the IAM console of the AWS Management Console. This step registers the Google OIDC endpoint so that AWS STS can validate the token that Cortex XDR presents. For more information, see [Create an OpenID Connect (OIDC) identity provider in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html).

If Google (accounts.google.com) is already registered as an identity provider in your AWS account, skip this step and verify that sts.amazonaws.com is listed in its audiences.

1. Log in to the AWS Management Console, and open the IAM console in the same region as your AWS account. 2. In the navigation pane on the left, select **Access Management** → **Identity providers**, and click **Add provider**. 3. Configure the provider: * **Provider type**: Select **OpenID Connect**. * **Provider URL**: Enter `https://accounts.google.com`, and click **Get thumbprint**. * **Audience**: Enter `sts.amazonaws.com`. 4. Click **Add provider**. 2. Create a policy in the IAM console in the same region as your AWS account. 1. In the navigation pane on the left, select **Access Management** → **Policies**, and click **Create policy**. 2. For the **Policy editor**, select the **JSON** tab. 3. Copy the following JSON policy and paste it within the editor window. The **``** and **``** are placeholders. These are filled out using the S3 bucket and SQS that you configured in the prerequisite steps above.

Note

  • You can retrieve your bucket's ARN by opening the Amazon S3 Console in a browser window. In the Buckets section, select the bucket, click Copy ARN, and paste the ARN in the field.
  • You can retrieve the SQS queue ARN by opening another instance of the AWS Management Console in a browser window, opening the Amazon SQS Console, and selecting the Amazon SQS that you created. In the Details section, under ARN, click the copy icon, and paste the ARN in the field.
```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "/*" }, { "Effect": "Allow", "Action": [ "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:ChangeMessageVisibility" ], "Resource": "" } ] } ``` 4. Click **Next**. 5. Review and create the policy. 3. Create a role for Cortex XDR in the IAM console. For more information, see [Create a role for OpenID Connect federation (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html). 1. In the navigation pane on the left, select **Access Management** → **Roles**, and click **Create role**. 2. On the **Select trusted entity** page, use the following values and options: * **Trusted entity type**: Select **Web identity**. * Under **Web identity**, configure the following settings: * **Identity provider**: Select **Google**. * **Audience**: Select `sts.amazonaws.com`. 3. Add a condition to restrict the role to the Cortex XDR log collector service account by setting the following: * **Key**: Select `accounts.google.com:sub`. * **Condition**: Select **StringEquals**. * **Value**: Enter the Cortex XDR service account identifier. To get this value, in Cortex XDR select **Settings** → **Data Sources & Integrations**, add or edit an Amazon S3 data source, select **Workload Federated Identity** as the authentication method, and in the **Copy service account identifier** section, click **Identifier**. 4. When you finish adding the condition, verify the **Web identity** settings. 5. Click **Next**, and add permissions by selecting **Use existing policy** and choosing the policy that you created. 6. Click **Next** to name, review, and create the role. 7. **Role name**: Specify a name for the new role, and click **Create role**. 4. Copy the **Policy ARN** and **Role ARN** for future use by opening the policy and role that you created. 5. Continue with the task for the applicable Amazon S3 logs you want to configure. The following types of logs are available: * [Ingest audit logs from AWS CloudTrail](/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/vendor-specific-data-sources/amazon/amazon-s3/ingest-audit-logs-from-aws-cloudtrail.md) * [Ingest network flow logs from Amazon S3](/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/vendor-specific-data-sources/amazon/amazon-s3/ingest-network-flow-logs-from-amazon-s3.md) * [Ingest network Route 53 logs from Amazon S3](/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/vendor-specific-data-sources/amazon/amazon-s3/ingest-network-route-53-logs-from-amazon-s3.md) * [Configure data collection from Amazon S3 manually](/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/vendor-specific-data-sources/amazon/amazon-s3/configure-data-collection-from-amazon-s3-manually.md) When you configure the Amazon S3 collection in Cortex XDR, enter the **Role ARN**, and enter `sts.amazonaws.com` in the **Audience** field. The **Test** button isn't available for Workload Federated Identity, so click **Enable**. ### Reference: Resulting trust policy To verify your configuration, the trust policy created by the steps above, which is shown on the **Name, review, and create** page, looks like the following. Replace `` with the identifier that you copied from Cortex XDR. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRoleWithWebIdentity", "Principal": { "Federated": "accounts.google.com" }, "Condition": { "StringEquals": { "accounts.google.com:sub": [ "" ], "accounts.google.com:aud": [ "sts.amazonaws.com" ] } } } ] } ``` {% hint style="warning" %} Keep the `accounts.google.com:sub` condition. Without it, any Google service account can assume the role. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/vendor-specific-data-sources/amazon/amazon-s3/create-a-workload-federated-identity-role.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.