Skip to main content
The AWS deployment tutorial 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 as written, with these four changes.
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:
Use this trust policy instead, substituting your account ID, region, provider ID, and cluster name:
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:

​
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:
Everything else in the tutorial is unchanged.
Last modified on November 4, 2026