@kapa.ai How can I ensure the SDK fully supports container credentials and EKS Pod Identity? I have deployed airbyte 1.6.0 on eks cluster.

Based on the docs you shared, Airbyte 1.6 does support using the underlying AWS identity of your EKS nodes or pods, but there is no explicit documentation yet about “EKS Pod Identity” or full, automatic STS AssumeRole in the connector SDK. Here’s what is documented for 1.6: 1. Global S3 & Secrets Manager access via IAM roles / instance profiles For S3 and AWS Secrets Manager integrations, Airbyte expects AWS permissions to be provided either by: - An IAM role attached to the EC2 nodes / EKS worker nodes (instance profile), or - Static access keys injected via Kubernetes Secrets. The AWS policies that must be granted are documented for S3 and Secrets Manager. [[AWS infra](https://docs.airbyte.com/platform/1.6/deploying-airbyte/infrastructure/aws)] The secret management config supports:

yaml    global:      secretsManager:        type: awsSecretManager        secretName: "airbyte-config-secrets"        awsSecretManager:          region: <aws-region>          authenticationType: credentials  # or "instanceProfile"

You are instructed to set

authenticationType

to

instanceProfile

when “the compute infrastructure running Airbyte has pre-existing permissions (e.g. IAM role) to read and write from AWS Secrets Manager.” [[Secret values](https://docs.airbyte.com/platform/1.6/deploying-airbyte/integrations/secrets#values)] This is the only clearly documented place where Airbyte 1.6 consumes container / node IAM roles (i.e., what you’d typically expose via IRSA or Pod Identity). 2. Kubernetes secrets vs. external secrets managers The enterprise docs emphasize that if your Kubernetes cluster already has permissions to make requests to an external entity via an instance profile, credentials are not required in Kubernetes secrets—for example, if your EKS cluster “has been assigned a sufficient AWS IAM role to make requests to AWS S3.” [[K8s secrets prereq](https://docs.airbyte.com/platform/1.6/enterprise-setup/implementation-guide#configure-kubernetes-secrets); [Multi-region secrets](https://docs.airbyte.com/platform/1.6/enterprise-setup/multi-region#step-4)] That again implies Airbyte can rely on whatever IAM mechanism exposes AWS credentials to the pod (node role, IRSA, or similar), but the docs do not call out EKS Pod Identity specifically nor show connector‑SDK–level knobs. 3. Connectors & the SDK None of the provided docs describe: - A connector‑SDK configuration flag for “use container credentials / pod identity.” - Specific support for EKS Pod Identity or generic STS AssumeRole in connectors. - Any guarantee that all connectors (or the SDK) automatically read from the container’s AWS env/metadata. The only related roadmap item is a GitHub issue stating a plan to “enable AWS credential injection for connectors… including Instance Profiles, IRSA, EKS Pod Identities, and direct AssumeRole,” but it’s a roadmap issue, not completed behavior, and there’s no confirmed answer yet to whether this extends to global storage/S3 & Secrets Manager. [[STS assume role issue](https://github.com/airbytehq/airbyte/issues/65137)] That means the **current 1.6 docs don’t confirm full SDK‑level support for container creds / EKS Pod Identity for connectors**—only for the platform’s S3 and Secrets Manager integrations via

instanceProfile

. --- ### What you can do on EKS 1.6.0 today Given the above, to “ensure” Airbyte 1.6.0 uses container credentials as far as the docs allow: 1. For global S3 logs/state & AWS Secrets Manager: - Attach the required IAM policies for S3 and Secrets Manager to: - Your EKS node IAM role, or - An IAM Role for Service Account (IRSA) used by the Airbyte pods. [[AWS infra](https://docs.airbyte.com/platform/1.6/deploying-airbyte/infrastructure/aws)] - In your Helm

values.yaml

, use:

yaml      global:        secretsManager:          type: awsSecretManager          secretName: "airbyte-config-secrets"          awsSecretManager:            region: <aws-region>            authenticationType: instanceProfile

so Airbyte pulls AWS credentials from the pod’s environment/metadata instead of static keys. [[Secret values](https://docs.airbyte.com/platform/1.6/deploying-airbyte/integrations/secrets#values)] 2. For connectors (SDK) specifically: - The knowledge you provided does not document a way to guarantee that every connector SDK instance will automatically use container credentials / EKS Pod Identity. - There is a roadmap issue to add richer AWS auth (Instance Profiles, IRSA, EKS Pod Identities, AssumeRole) to connectors, but it’s not documented as delivered in 1.6. [[STS assume role issue](https://github.com/airbytehq/airbyte/issues/65137)] So with Airbyte 1.6 on EKS, you can confidently use instanceProfile/IRSA‑backed IAM roles for platform‑level S3 and Secrets Manager, but based on the docs you shared, you cannot yet rely on a documented, fully supported mechanism in the connector SDK itself for EKS Pod Identity or direct AssumeRole.