Thanks for the response, Steve. I did see that patch before I opened this JIRA, but I felt this issue was worth addressing separately for the following reasons.
All of the AWS SDKs, and most standard AWS tools (including the AWS CLI) accept AWS credentials from the standard environment variables AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY. It's what any experienced user of these tools would expect from S3A, and it's a very useful capability (as in the CI scenario I described). I would say it's at least as useful and important as the ability to accept credentials from an IAM role (which S3A also supports out-of-the-box). Given that it's literally a one-line change (see attached patch), that all standard AWS tools support the same functionality by default, and that it enables common use cases that can't be addressed otherwise, I think S3A would need a very good reason not to support EnvironmentVariableCredentialsProvider by default. If there are valid security concerns with this change, then I certainly would like to hear about them. Environment variables can certainly be used insecurely, but they can hardly be any worse than the widely supported practice (in Hadoop and elsewhere) of storing credentials in plaintext configuration files.
So, given that environment variable support is trivial to implement, extremely low-risk, widely useful, and is already supported by pretty much all standard AWS tools, I thought it would be reasonable to support it implicitly rather than force clients to implement an extension.