Same-account S3 Access Point authentication (IRSA or EKS Pod Identity)

Use this guide when the EKS cluster, the Acceldata Data Plane, the S3 bucket, the Access Point, and the IAM role all exist in the same AWS account.

The goal is that ADOC reaches S3 only through an Access Point. The Access Point allows the IAM role, and that role is bound to the Data Plane's Kubernetes service accounts using one of two authentication methods: IAM Roles for Service Accounts (IRSA), or EKS Pod Identity.

Complete the shared setup once, then choose exactly one authentication option:

• Option 1: IRSA

• Option 2: EKS Pod Identity

For a scenario where the bucket and Access Point live in a different AWS account from the cluster, see Cross-account S3 Access Point authentication. This is also a different mechanism from Cross‑Account Access Setup, which grants direct cross-account bucket access without an Access Point.

Placeholders

Service accounts to bind

Confirm the live service account names in your namespace before you begin:

Bind the IAM role to these service accounts:

• analysis-service

• analysis-standalone-service

• spark-scheduler

• torch-monitors

• analysis-sql-service

• spark-history-server

• acceldata-dataplane-spark

Skip any service account that does not exist in your deployment.

Shared setup

Step 1: Create the S3 bucket

1. In S3, create bucket <bucket> in <region>.

2. Keep Block Public Access enabled.

3. Upload sample files under <prefix>, for example allowed/sample.csv.

Step 2: Create the Access Point

1. Open bucket <bucket> and create Access Point <ap-name>.

2. Choose network Internet, or the VPC your cluster uses.

3. Keep Block Public Access enabled.

4. Copy the Access Point ARN and alias after creation.

Step 3: Create the IAM role with Access Point-only permissions

Create IAM role <iam-role>. Its trust policy depends on the authentication option you choose in Step 4 or Step 5, but the S3 permissions are the same for both options.

Attach this inline policy. Use Access Point ARNs only. To keep the role strictly Access Point-only, do not add arn:aws:s3:::<bucket> to the role.

Do not add an s3:prefix condition to s3:ListBucket. ADOC's Test Connection uses HeadBucket, which does not send a prefix. A prefix condition causes Test Connection to fail even when object reads work.

Step 4: Add the Access Point policy

On Access Point <ap-name>, set a policy that allows only <iam-role>:

Step 5: Add the bucket policy

The Access Point policy only works if the bucket policy also allows the request. An Access Point policy by itself is not enough — if the bucket policy is empty and only the Access Point ARN is allowed in IAM, head-bucket returns 403.

Add this statement to the bucket policy. If the bucket already has a policy, keep the existing statements and add this one.

The bucket policy is required in addition to the Access Point policy.

Option 1: IRSA

Confirm the cluster OIDC provider

If the result is empty, associate the provider:

Configure the trust policy

In IAM, open <iam-role> and go to Trust relationships. Configure Web Identity for this cluster's OIDC provider, with audience sts.amazonaws.com. Set sub to every service account listed above.

A Pod Identity association on the same service account overrides IRSA. For an IRSA-only setup, remove any existing associations first:

Bind the role to service accounts

Skip service accounts that do not exist. Restart the deployments, skipping any deployment that is already broken.

Wait until the deployments are ready, then confirm IRSA on a pod:

Pass: AWS_ROLE_ARN=arn:aws:iam::<account-id>:role/<iam-role> is present, and AWS_CONTAINER_CREDENTIALS_FULL_URI is absent. Authentication in ADOC is AWS IAM Roles For Service Accounts.

Option 2: EKS Pod Identity

Check the Pod Identity agent

The agent must be running.

Configure the trust policy

In IAM, open <iam-role> and go to Trust relationships. Add this statement. If the role already has the IRSA trust statement, keep it and add this one — do not change the Access Point policy, bucket policy, or S3 inline policy.

Bind associations

Do not annotate the service accounts for Pod Identity.

Skip service accounts that do not exist, then restart the deployments.

Confirm Pod Identity on a pod:

Pass: AWS_CONTAINER_CREDENTIALS_FULL_URI is set and AWS_ROLE_ARN is absent, because Pod Identity overrides IRSA. Authentication in ADOC is EKS Pod Identity. If you already added an S3 data source using IRSA credentials, create a new ADOC data source rather than reusing that one.

Prove AWS access before configuring ADOC

Delete any leftover test pod first. Logs from an earlier run are not proof the current configuration works.

Wait until the pod status is Completed, then run:

Pass: the logs return JSON containing BucketRegion. A 403 response points to an IAM, Access Point, or bucket policy problem, not to ADOC. Do not exec into this pod — it has already exited. An Access Point-only role on torch-monitors may return 403 for existing SQS-based monitors; this is expected.

Add the ADOC datasource and validate

In ADOC, add a new AWS S3 datasource. For the general steps to open the Add Data Source wizard, see Amazon S3. Use these values for an Access Point connection.

Add datasource / Test Connection

Never enter s3://... in Bucket Name. This is the literal string AWS's HeadBucket call uses. Select Test Connection. A successful result shows the datasource connected.

Asset / Observability configuration

After the connection succeeds, create an asset with any name and set:

Run the crawl, then run the profile.

GET /validate on analysis-service is a health probe. The relevant jobs for datasource testing use type CONNECTION_VALIDATION.

Troubleshooting