feat(iam): support an alternative env to decide if mtls should be enabled

[amtk3]

CLOUDSDK_CONTEXT_AWARE_USE_CLIENT_CERTIFICATE is another endpoint that can be set in Gcloud CLI to enable Certificate Based Access. We should support it as well.

[gemini-code-assist]

Summary of Changes

Hello @amtk3, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the IAM authentication logic by incorporating an additional environment variable to control the enablement of client certificates for mutual TLS. This change ensures broader compatibility with Gcloud CLI configurations for certificate-based access, offering more flexibility in how mTLS is activated within the system.

Highlights

• Environment Variable Support: The pull request introduces support for the CLOUDSDK_CONTEXT_AWARE_USE_CLIENT_CERTIFICATE environment variable.
• mTLS Enablement: This new environment variable provides an alternative mechanism to enable mTLS (mutual TLS) for certificate-based access, aligning with Gcloud CLI's configuration options.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds support for the CLOUDSDK_CONTEXT_AWARE_USE_CLIENT_CERTIFICATE environment variable to enable mTLS, which is a good addition. My review includes a suggestion to refactor the logic for checking environment variables to improve readability and maintainability.

A few additional points for consideration:

• It would be best to define CLOUDSDK_CONTEXT_AWARE_USE_CLIENT_CERTIFICATE as a constant in google/auth/environment_vars.py and import it to avoid using a magic string and maintain consistency with other environment variables.
• While the changed code is marked with pragma: NO COVER, consider adding a test case for this fallback logic to prevent future regressions. This would likely involve mocking hasattr(mtls, 'should_use_client_cert') to return False and then testing the behavior with different environment variable settings.

[chalmerlowe]

@amtk3 Thanks for submitting this PR.

As I grow more familiar with this codebase and some of the capabilities it provides... I have several concerns with how the code has evolved/is evolving.

• I worry that we are duplicating checks instead of centralizing them (I understand that the existing code may imply that the duplicate checks are ok/necessary/the right way of doing things, but if we have duplicated checks, I prefer to not propagate that any further).

• We have several functions in mtls.py and _mtls_helpers.py that concern themselves with checking whether we should be using a client cert.
• should_use_client_cert() is a wrapper around check_use_client_cert(), which is where the majority of the logic appears to be (and probably should be).

The purpose of check_use_client_cert() is to: Returns boolean for whether the client certificate should be used for mTLS. In that function, we start off with:

• A check to see if GOOGLE_API_USE_CLIENT_CERTIFICATE is set by looking into the environmental variable dict and if yes, we immediately return a bool.
• Then, in iam.py, we call check_use_client_cert() via a call to should_use_client_cert() and if we get a response of false, the first thing we do is check to see if GOOGLE_API_USE_CLIENT_CERTIFICATE is set OR not.

I feel like we should only really have that logic in one place. I am leaning toward in check_use_client_cert()

In addition to the above, we need to add the environmental variable to environment_vars.py file to set a default value and ensure that all vars can be found in a uniform location. Let's mirror the definition of the environmental variable GOOGLE_API_USE_CLIENT_CERTIFICATE.

And we have existing testing in our test suite to ensure that logic related these checks (using GOOGLE_API_USE_CLIENT_CERTIFICATE) perform as expected. Once we decide on where the logic should be, we will need to modify, add, remove tests to accommodate.

CONTEXT: For context for anyone else reading this PR, this environmental variable is apparently used with boto configs:
https://docs.cloud.google.com/storage/docs/gsutil/addlhelp/ShimforRunninggcloudstorage#[credentials]

NOTE: including @gemini-code-assist to see what it says.

[chalmerlowe]

As a related matter. IF this is not a high priority problem, I would recommend:

• we close this PR
• we open an issue and document our thought processes
• identify what changes need to happen across the code base
• confirm whether similar checks against these environmental variables are happening elsewhere
• with an agreed upon design, issue a PR in the future home of this repo (NOTE: this repo is about to be migrated into the google-cloud-python mono-repo).

[chalmerlowe]

@gemini-code-assist

Please examine the content in this comment and provide your thoughts:

#1945 (comment)

[gemini-code-assist]

Thank you for tagging me, @chalmerlowe. I've reviewed your detailed comments regarding the current pull request and the broader concerns about the codebase's evolution, particularly the duplication of client certificate checking logic.

I agree with your assessment that centralizing the logic for determining whether to use a client certificate is a critical improvement. Having this logic in multiple places, such as mtls.py, _mtls_helper.py, and now potentially iam.py (as a fallback), can lead to inconsistencies, make maintenance more difficult, and increase the risk of bugs.

Specifically, I concur that check_use_client_cert() in google/auth/transport/_mtls_helper.py is the most appropriate place to consolidate all checks related to client certificate usage, including the newly introduced CLOUDSDK_CONTEXT_AWARE_USE_CLIENT_CERTIFICATE environment variable.

To address your points:

• Centralization of Checks: All environment variable checks for client certificate usage should ideally reside within check_use_client_cert(). This function would then be the single source of truth for this decision.
• environment_vars.py: It is indeed important to formally define CLOUDSDK_CONTEXT_AWARE_USE_CLIENT_CERTIFICATE in google/auth/environment_vars.py, following the pattern established for GOOGLE_API_USE_CLIENT_CERTIFICATE. This ensures discoverability and consistency.
• Testing: As you noted, updating the test suite will be essential. Tests should cover all relevant environment variables and their interactions, ensuring the centralized logic behaves as expected under various conditions.

If the logic were centralized in check_use_client_cert(), the iam.py file would then simply call mtls.should_use_client_cert() (which in turn calls the centralized check_use_client_cert()) without needing its own fallback os.getenv checks. This would simplify iam.py and ensure consistency across the library.

Regarding your subsequent comment about closing the PR and opening an issue due to the mono-repo migration, I understand the strategic considerations. My role is to provide technical feedback on the code changes themselves, and from that perspective, addressing the architectural concerns you've raised would significantly improve the maintainability and correctness of the codebase.

[amtk3]

Hi @chalmerlowe,

This issue is a bit urgent since, we have users encountering error while making IAM calls after enablement of mTLS control so I want it to be pushed now rather than waiting for the mono-repo migration.

I agree with using check_use_client_cert() and that was what I originally proposed - link.

I updated the PR based on your feedback and made the following changes

• Using check_use_client_cert() to check if MTLS is enabled.
• Defined the following two alternative envs
  • CLOUDSDK_CONTEXT_AWARE_USE_CLIENT_CERTIFICATE
  • CLOUDSDK_CONTEXT_AWARE_CERTIFICATE_CONFIG_FILE_PATH
• Defined the alternative envs in environment_vars.py

Let me know if any other additional changes are required.