DanielLeens opened a new issue, #11275: URL: https://github.com/apache/seatunnel/issues/11275
## Background The S3File source and sink docs currently document `fs.s3a.aws.credentials.provider` and show examples for `SimpleAWSCredentialsProvider` and `InstanceProfileCredentialsProvider`. Users running SeaTunnel in container environments, such as Kubernetes, ECS, EKS, or Docker-based deployments, often ask whether providers such as `ContainerCredentialsProvider` are supported and how they should configure S3 credentials without embedding access keys in the job config. At the moment, the docs do not clearly explain the supported credential provider boundary for container runtime credentials. ## Goal Clarify how S3File source/sink authentication should be configured in container environments, and document what is supported or unsupported today. ## Suggested scope Please update the English and Chinese S3File docs, and optionally checkpoint storage docs if the same S3 credential pattern applies there: - `docs/en/connectors/source/S3File.md` - `docs/zh/connectors/source/S3File.md` - `docs/en/connectors/sink/S3File.md` - `docs/zh/connectors/sink/S3File.md` - `docs/en/engines/zeta/checkpoint-storage.md` - `docs/zh/engines/zeta/checkpoint-storage.md` The update should cover: 1. Which S3A credential providers are officially supported by SeaTunnel's S3File connector today. 2. Whether container credential providers are supported directly. 3. Recommended configuration for Kubernetes/ECS/EKS style deployments. 4. How to pass additional Hadoop S3A options through `hadoop_s3_properties` when applicable. 5. A short troubleshooting note for `Factory initialize failed` or credential-provider class loading errors. ## Acceptance criteria - The docs explicitly state whether `ContainerCredentialsProvider` is supported. - The docs provide a safe container deployment pattern that avoids hardcoding long-lived access keys when possible. - English and Chinese docs are consistent. - The examples do not include real credentials. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
