Error with IAM Role for S3 logs in Airbyte helm chart distribution

Slack Knowledge Base Q&A Platform Questions
, , , ,
1

Summary

User is facing an error ‘Access Denied’ when trying to publish to S3 using IAM Role for S3 logs in Airbyte helm chart distribution. The user has followed the documentation but still encountering the issue.


Question

Hello

I am running the latest helm chart distribution 0.350.0

I currently use

• IAM Role for S3 logs, state
However I keep getting error on the server, worker, all instances

java.lang.RuntimeException: Cannot end publishing: Cannot publish to S3: Access Denied (Service: Amazon S3; Status Code: 403```
This even though I have followed the doc here:

<https://docs.airbyte.com/deploying-airbyte/integrations/storage>

I am using

`authenticationType: _instanceProfile_`

_And there is not much documentation around this that I can find._

_I have verified `AWS_ROLE_ARN` and_ `AWS_WEB_IDENTITY_TOKEN_FILE` are set, and I `SSH` into the pod to check the token at `AWS_WEB_IDENTITY_TOKEN_FILE`.

<br>

---

This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. [Click here](https://airbytehq.slack.com/archives/C021JANJ6TY/p1722000324069329) if you want 
to access the original thread.

[Join the conversation on Slack](https://slack.airbyte.com)

<sub>
["iam-role", "s3-logs", "helm-chart", "access-denied", "authentication-type", "aws-role-arn", "aws-web-identity-token-file"]
</sub>
2

You might want to start here:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html

Rule out the AWS side first before chasing ghosts on the Airbyte side. I forget if all auth requests are logged like they are on GCP, but if so maybe check CloudTrail/CloudWatch and see if you get a more specific message you can use to zero in

There’s some possible org policy and config factors here, and I’m personally not a big fan of how hard it can be to pin those down on the S3 side. But worst case use the CLI or such from your instance and try to auth the same request so you know if it’s permissioning/policy or something specific to Airbyte