Elasticsearch: Support alternate AWS authentication methods in repository-s3 plugin

[chonton]

Feature Request:
AWS has many authentication methods available. As the AWS sdk evolves, the many authentication methods are updated in the DefaultAWSCredentialsProviderChain. Specifically interesting to Kubernetes deployments are the Security Token Service authentication methods.
The STS methods federate alternate Identity providers including web token federation which allows fine-grained IAM roles for Kubernetes service accounts.

By using the DefaultAWSCredentialsProviderChain in place of EC2ContainerCredentialsProviderWrapper, every authentication method that the SDK supports can now be used by Elasticsearch. DefaultAWSCredentialsProviderChain currently supports:

• Basic or Session credentials specified in environment variables or system properties
• Web identity tokens (JWT etc.)
• Credentials saved in aws profiles
• Credentials obtained from EC2 metadata endpoint

[elasticmachine]

Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore)

[DaveCTurner]

The lack of support for credentials in environment variables, system properties and AWS profiles is a deliberate choice, and unfortunately that means we cannot use the DefaultAWSCredentialsProviderChain since there's no way to disable these credentials sources.

Credentials obtained from the EC2 metadata endpoint are already supported.

This leaves the question of web identity tokens, which are currently unsupported but this is already an open issue at https://github.com/elastic/elasticsearch/issues/52625. Therefore I'm closing this issue as some combination of "won't fix", "already fixed", and "duplicate".

However, a PR to address https://github.com/elastic/elasticsearch/issues/52625 would be very welcome.

[chonton]

Is there documentation that explains decision criteria for which authentication methods will or will not be supported?

[DaveCTurner]

No, I don't know of anything outside of comments here on Github. The earliest such that I can find is https://github.com/elastic/elasticsearch/issues/23039#issuecomment-279510903.

[t0rr3sp3dr0]

@DaveCTurner, I think this should be reconsidered as it was decided 3 years ago and things have changed. AWS now has native support for authenticating via AWS SSO and other identity providers can be used by setting credential_process in ~/.aws/credentials. We use the credential_process property to authenticate on AWS via Kerberos, which is far more secure than using AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (that is the current alternative). Either way, I don't think Elastic should be the one deciding whether or not some authentication method is secure or not and that it can be used. By using the DefaultAWSCredentialsProviderChain, you leave this responsibility to AWS and decrease compatibility issues when using different authentication methods.

[DaveCTurner]

We use the credential_process property to authenticate on AWS via Kerberos

This would require Elasticsearch to run an external process, which we forbid at a very low level. Also the AWS docs for credential_process have a big red warning at the top recommending against using this and instead "that you use the supported, secure alternatives provided by the AWS CLI and AWS to reduce the risk of compromising your credentials."

which is far more secure than using AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (that is the current alternative)

No, Elasticsearch will not read credentials from environment variables either.

FWIW if you absolutely require credentials to be sourced from an external process then you can point the SDK at a custom instance metadata service.