Add gssapi authentication method

[hb1915]

Add gssapi authentication method

Summary

This PR adds a new method: gssapi to dbt-trino's profile schema, backed by trino.auth.GSSAPIAuthentication (introduced upstream in trinodb/trino-python-client#454).

The existing method: kerberos is untouched — gssapi is offered as a parallel option, mirroring the two-class separation that trino-python-client deliberately adopted.

Why a new method instead of patching kerberos

trino-python-client ships two distinct authentication classes:

• KerberosAuthentication — uses requests-kerberos (less actively maintained, depends on pykerberos).
• GSSAPIAuthentication — uses requests-gssapi plus the modern gssapi library.

The two classes have different defaults (e.g. mutual_authentication defaults to REQUIRED in the legacy class and DISABLED in the new one) and different semantics around credential acquisition (legacy is keytab-centric; the new one defers to gssapi.Credentials, which uses the default credential cache when no principal is given). Squashing them into one dbt method would hide that distinction; mirroring the upstream split keeps both paths available and makes the underlying library choice explicit.

Practical benefit for users

The current kerberos method requires a keytab — connections.py unconditionally sets KRB5_CLIENT_KTNAME from the keytab field, so any value other than a real path causes a TypeError. That forces operators to provision a keytab even when they already have a TGT in their credential cache.

The new gssapi method has no such requirement. With principal unset (the default), GSSAPIAuthentication calls gssapi.Credentials() with no name argument, which falls back to whatever's in KRB5CCNAME. So:

kinit user@REALM.EXAMPLE.COM
dbt run

just works — no keytab, no extra profile fields beyond method: gssapi, host, port, and user.

API choices

mutual_authentication is exposed as a case-insensitive string taking one of "REQUIRED", "OPTIONAL", "DISABLED", translated internally to trino-python-client's integer constants (MUTUAL_REQUIRED=1, MUTUAL_OPTIONAL=2, MUTUAL_DISABLED=3). Defaults to "DISABLED" to match the upstream class default. An invalid value raises DbtRuntimeError with a clear message at connection time.

Rationale: the existing kerberos method types this as Optional[bool] (line 190 of connections.py), which can only express REQUIRED/DISABLED and silently misbehaves when given False (which becomes int 0, not a value the underlying requests_kerberos.HTTPKerberosAuth recognises). The string-enum API is the dbt-idiomatic way to expose a small set of named choices and avoids that footgun.

All other parameters mirror the existing kerberos method's surface: principal, krb5_config, service_name, force_preemptive, hostname_override, sanitize_mutual_error_response, delegate, cert.

Example profile

my_target:
  type: trino
  method: gssapi
  host: trino.example.com
  port: 443
  user: alice@EXAMPLE.COM
  database: hive
  schema: analytics
  # All optional below this point:
  principal: alice@EXAMPLE.COM      # if omitted, uses default credential cache
  krb5_config: /etc/krb5.conf
  service_name: trino               # paired with hostname_override per upstream contract
  hostname_override: trino-internal.example.com
  mutual_authentication: OPTIONAL   # REQUIRED | OPTIONAL | DISABLED (default: DISABLED)
  force_preemptive: true
  delegate: true
  cert: /etc/ssl/certs/ca-bundle.crt

Tests

Three unit tests added in tests/unit/test_adapter.py:

1. test_gssapi_authentication — full profile happy-path, mirrors the existing kerberos test.
2. test_gssapi_authentication_default_mutual_authentication — default value resolves to MUTUAL_DISABLED.
3. test_gssapi_authentication_invalid_mutual_authentication — bad string raises DbtRuntimeError.

I haven't added a docker-compose-based integration test because the existing kerberos integration test fixtures are scoped to the legacy library; happy to add gssapi-side fixtures in a follow-up if you'd like.

Out of scope (deliberately)

Two pre-existing bugs in TrinoKerberosCredentials were noted during this work but are not changed here, to keep this PR focused:

1. mutual_authentication: Optional[bool] = False — wrong type; can't express OPTIONAL. Same string-enum fix would apply.
2. os.environ["KRB5_CLIENT_KTNAME"] = self.keytab crashes when keytab is None despite the field being typed Optional[str].

Happy to follow up with a separate PR for these if you'd prefer them addressed; or if you'd rather have them bundled here, let me know and I'll amend.

Checklist

• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests
• README.md updated and added information about my change (no Kerberos-specific section currently exists; the canonical docs live at docs.getdbt.com/reference/warehouse-setups/trino-setup — happy to file a companion PR to dbt-labs/docs.getdbt.com once this lands)
• I have run changie new to create a changelog entry

[findinpath]

Please address the conflicts on setup.py

[hb1915]

Please address the conflicts on setup.py

Should be done