> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Use IRSA Instead of EKS Pod Identity

The [AWS deployment tutorial](https://clickhouse.com/docs/cloud/clickhouse-private/tutorials/deploy-aws.md) uses EKS Pod Identity to give ClickHouse pods access to S3. IAM Roles for Service Accounts (IRSA) does the same job through the cluster's OIDC provider and an annotation on the service account.

Use IRSA if a compliance review requires the credential exchange to be TLS end to end. Otherwise we recommend Pod Identity.

## What changes

Follow the [AWS deployment tutorial](https://clickhouse.com/docs/cloud/clickhouse-private/tutorials/deploy-aws.md) as written, with these four changes.

> [!NOTE]
>
> **Create the IAM roles after the EKS cluster.** The tutorial creates IAM roles in Step 4, before the EKS cluster exists in Step 6. An IRSA trust policy names the cluster's OIDC provider, which does not exist until the cluster does. Skip Step 4, complete Step 6 and create the OIDC provider, then create both roles before continuing to Step 7.

### 1. Trust policy

The trust policy names the cluster's OIDC provider, so create one role per ClickHouse cluster. The provider ID is the final path segment of the issuer URL, which you can read once the cluster exists:

```bash theme={null}
aws eks describe-cluster --name $EKS_CLUSTER_NAME --region $REGION \
  --query "cluster.identity.oidc.issuer" --output text
```

Use this trust policy instead, substituting your account ID, region, provider ID, and cluster name:

```json theme={null}
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::0000000000:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/XXXXXXXXXXXXXXXXXXXXX"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.us-west-2.amazonaws.com/id/XXXXXXXXXXXXXXXXXXXXX:aud": "sts.amazonaws.com",
                    "oidc.eks.us-west-2.amazonaws.com/id/XXXXXXXXXXXXXXXXXXXXX:sub": "system:serviceaccount:ns-default-xx-01:ch-default-xx-01-sa"
                }
            }
        }
    ]
}
```

The EBS CSI driver role needs its own copy, with the `:sub` condition set to `system:serviceaccount:kube-system:ebs-csi-controller-sa` instead.

### 2. OIDC provider instead of the agent

In Step 6, skip the `eks-pod-identity-agent` add-on. Create an OIDC provider for the cluster instead, before creating the roles above.

### 3. EBS CSI driver add-on

Pass the role ARN with `--service-account-role-arn` instead of `--pod-identity-associations` so the add-on annotates its service account rather than creating an association:

```bash theme={null}
aws eks create-addon --cluster-name $EKS_CLUSTER_NAME --region $REGION \
  --addon-name aws-ebs-csi-driver \
  --service-account-role-arn $EBS_CSI_ROLE_ARN
```

### 4. Cluster service account

Skip the `aws eks create-pod-identity-association` call. Pass the role ARN to the chart instead, so it annotates the service account it creates:

```bash theme={null}
    --set-json="serviceAccount.annotations={\"eks.amazonaws.com/role-arn\":\"$SA_IAM_ROLE_ARN\"}" \
```

Everything else in the tutorial is unchanged.