fix(auth): centralize cert discovery logic and steps

[nbayati]

• Centralize mTLS configuration file path discovery by replacing disparate checks in check_use_client_cert and has_default_client_cert_source with a unified _get_cert_config_path helper.
• Ensure X.509 Workload Identity Federation (WIF) takes precedence over SecureConnect by checking _get_cert_config_path before CONTEXT_AWARE_METADATA_PATH in has_default_client_cert_source.
• Remove temporary Cloud Run certificate and key path overrides from _get_workload_cert_and_key_paths.
• Properly honor CLOUDSDK_CONTEXT_AWARE_CERTIFICATE_CONFIG_FILE_PATH in availability checks, fixing an existing mismatch where auto-enablement would evaluate to true but the downstream source checker would miss the path.
• Allow mTLS auto-enablement to properly trigger off the default gcloud configuration file (~/.config/gcloud/certificate_config.json), resolving previous contradictory behavior.
• Ensure strict environment variable precedence: invalid paths supplied via environment variables now correctly result in failures rather than silently falling back to default disk locations.
• Update tests to reflect the new centralized resolution.
• fixes Auth(mtls): _has_logged_mtls_warning masks distinct mTLS configuration errors #17697

[gemini-code-assist]

Code Review

This pull request removes the temporary Cloud Run certificate path patch and its associated tests. It also refactors and simplifies certificate configuration path resolution in check_use_client_cert and has_default_client_cert_source by utilizing the helper function _get_cert_config_path, updating the corresponding unit tests to match. I have no feedback to provide as there are no review comments.

[parthea]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors mTLS configuration path resolution by centralizing path retrieval in _get_cert_config_path and removing the temporary Cloud Run patch. It also changes mTLS auto-enablement failure logging from warnings to debug messages. The review feedback highlights a potential TypeError crash if the loaded certificate configuration JSON is not a dictionary, and suggests validating the JSON type before accessing its keys.

[gemini-code-assist]

If the certificate configuration file contains a non-dictionary JSON value (such as null, 123, or true), json.load(f) will return a non-dict type. Checking "cert_configs" in content will raise a TypeError and crash the application.

Furthermore, to prevent security vulnerabilities or confusing downstream authorization errors, we must not silently fall back to standard TLS when mTLS configuration or certificate loading fails. Instead, we should fail fast by raising an appropriate exception.

        try:
            with open(cert_path, "r") as f:
                content = json.load(f)
            if not isinstance(content, dict):
                raise ValueError("Certificate configuration file is not a JSON object.")
        except (FileNotFoundError, OSError, json.JSONDecodeError) as e:

References

1. Do not silently fall back to standard TLS if mutual TLS (mTLS) configuration or certificate loading fails. Silently falling back can introduce security vulnerabilities or cause confusing downstream authorization errors; instead, fail fast by raising an appropriate exception.

[nbayati]

The first point is incorrect. The code already explicitly performs an isinstance(content, dict) check before interacting with the JSON payload, so no TypeError can occur.

Regarding the suggestion to raise an exception: check_use_client_cert() has historically fallen back to standard TLS by returning False if auto-enablement cannot proceed. Changing this behavior to raise an exception would be a breaking change for downstream users and violates backwards compatibility. We will stick with the current graceful fallback behavior.

[andyrzhao]

LGTM overall - thanks for working on this Negar!

[lsirac]

_has_logged_mtls_warning from _mtls_helper.py was deleted, but this still sets _mtls_helper._has_logged_mtls_warning = False

[lsirac]

The docstring for check_use_client_cert() in _mtls_helper.py lists three paths: GOOGLE_API_CERTIFICATE_CONFIG, CLOUDSDK_CONTEXT_AWARE_CERTIFICATE_CONFIG_FILE_PATH, and ~/.config/gcloud/certificate_config.json. The updated docstring for should_use_client_cert() in mtls.py omits the default ~/.config/gcloud/certificate_config.json path.

[lsirac]

The PR introduces two untested branches:

• No test calls has_default_client_cert_source(include_context_aware=False) to verify that setting include_context_aware=False skips checking CONTEXT_AWARE_METADATA_PATH.
• No test verifies that _get_cert_config_path logs a debug message when an explicitly specified certificate configuration file (is_explicit=True) does not exist.