Deeper support for AWS Credential sources

[mattmauriello]

Is your feature request related to a problem? Please describe.
We have a significant foorptint in AWS, and the AWS Workload Identity Federation is VERY compelling to us, but the feature as implemented today only supports 2 of 11 official credential sources for AWS:
https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html#configuring-credentials

1. Passing credentials as parameters in the boto3.client() method
2. Passing credentials as parameters when creating a Session object
3. Environment variables
4. Assume role provider
5. Assume role with web identity provider
6. AWS IAM Identity Center credential provider
7. Shared credential file (~/.aws/credentials)
8. AWS config file (~/.aws/config)
9. Boto2 config file (/etc/boto.cfg and ~/.boto)
10. Container credential provider
11. Instance metadata service on an Amazon EC2 instance that has an IAM role configured.

Describe the solution you'd like
of the ones listed, #10, the container (Docker: ECS, Fargate, etc...) credential provider is most interesting to us, as most of our workloads are conatainerized.

Describe alternatives you've considered
As an experiment, I actually made a code modification in auth/aws.py that's fairly simple, but I dont know how good of a practice it is. the AWS libraries, specifically boto3 (which requires botocore) have built in functions to retrieve the credentials from all the official sources. for example
import boto3 boto3.Session().get_credentials()
returns a credential object. I simply inserted a block at the beginning of the get_aws_security_credentials function that uses that, if boto3 is available.

Patch/Diff:

--- google/auth/aws.py.orig     2025-07-07 16:18:28.503658900 -0400
+++ google/auth/aws.py  2025-07-07 16:39:44.508200400 -0400
@@ -420,6 +420,18 @@

     @_helpers.copy_docstring(AwsSecurityCredentialsSupplier)
     def get_aws_security_credentials(self, context, request):
+        #see if we can use botos built in code for this. if boto3 is in the
+        #environment and can be loaded, use it. otherwise, fallback to googles code
+        try:
+            import boto3
+            botocreds = boto3.Session().get_credentials()
+            return AwsSecurityCredentials(
+                botocreds.access_key,
+                botocreds.secret_key,
+                botocreds.token,
+            )
+        except Exception as e:
+            pass

         # Check environment variables for permanent credentials first.
         # https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html

I'm curious if the maintainers here would consider this too "Hacky", or if a PR with this change would be welcomed. Or, what changes might make it acceptable, if it isn't already.

[harkamaljot]

Thank you for filing this detailed issue and for the thoughtful proposal, including the sample code patch. We really appreciate the time you took to investigate this and share your findings.

You've correctly identified that boto3 has a very comprehensive and convenient credential discovery chain.

A core design principle for google-auth-library-python is to keep its dependencies to a minimum, ensuring it remains lightweight and avoids potential version conflicts for users. For that reason, we are hesitant to add a direct dependency on boto3 or other large SDKs into the core library.

However, we anticipated the need for flexible and custom credential-sourcing scenarios like the one you've described. To support this, we've provided the ability to use a custom AWS credential supplier. This allows you to implement any credential logic you need—in this case, using boto3—and pass it directly to the AWS credentials object.

This approach gives you the full power of boto3's credential resolution without requiring a change to the auth library itself. Here is an example of how you could implement this for your use case:

import boto3
import google.auth
from google.auth.aws import Credentials, AwsSecurityCredentials, AwsSecurityCredentialsSupplier

class Boto3CredentialSupplier(AwsSecurityCredentialsSupplier):
    """An AWS credential supplier that uses the boto3 SDK.

    This supplier will use the default boto3 credential resolution chain,
    which includes support for container metadata, instance profiles,
    web identity tokens, and more.
    """

    def get_aws_security_credentials(self, context, request):
      # return back cred based on boto3 custom logic

aws_credential_supplier = Boto3CredentialSupplier()

credentials = Credentials(
    project_id="<YOUR_GCP_PROJECT_ID_NUMBER>",
    aws_credential_supplier=aws_credential_supplier,
)

This solution allows you to leverage the container credential provider and any of the other 11 sources supported by boto3.

Could you let us know if this approach would work for your use case? We'd be keen to understand if there are any gaps or difficulties with using a custom supplier that we might need to address.

Thanks again for the great suggestion and for engaging with the community!

[mattmauriello]

I appreciate the consideration, and understand the concerns. Part of my reasoning was to do the import "opportunistically", like if it's there use it, if not, dont, so that it's not a hard dependency and doesn't bloat the package. And really, my hope was to see if the SDK maintainers across languages might implement something similar.
That said, I have a colleague who has had some success essentially doing what you've described, so I believe we'll have to align with something like that going forward.

Again, Thanks for reviewing it.

[harkamaljot]

Thanks for the thoughtful follow-up.

You've raised an excellent point about the opportunistic import. While it cleverly avoids a hard dependency, it introduces challenges. First, it creates implicit behavior that can be difficult for users to debug.

More importantly, as you alluded to, it would create a significant maintenance burden for us. If we were to build in this logic, any breaking change introduced by the AWS SDK would force us to issue a new release of our own. This would tightly couple our library's stability and release cycle to theirs, which is a situation we need to avoid.

The custom supplier pattern solves this by keeping the concerns separate: our library remains independent, and your application can leverage boto3 directly, giving you full control.

I am glad to hear this approach will work for you. Thanks again for the great discussion! I will go ahead and close this out, but feel free to reach out if you need anything else.