Require existing-connection read access when testing an existing connection

[potiuk]

The POST /api/v2/connections/test route was authorizing the caller only as a
connection POST operation (i.e. "can create a connection"). When the request
body referenced an existing connection_id, the route then loaded that
connection from the configured secrets backend and merged its hidden fields
(login, password, parts of extra) into the test object. The route did not
check whether the caller was authorized to read that existing connection — so
a caller authorized to create connections but not to read a given connection
could effectively borrow that connection's secrets, and could probe arbitrary
connection_ids to learn which ones exist.

This change adds a team-scoped GET authorization check on the body's
connection_id before any secrets backend is touched. If the caller is not
authorized to read that connection (or it does not exist), the existing
connection is ignored and the route falls through to the body-only test
path — exactly as it already does for a non-existent connection_id. So:

• An unauthorized caller's response is indistinguishable from the not-found
  case (same status, same body shape) — the endpoint can't be used as an
  existence oracle to enumerate protected connection ids.
• The secrets backends are not queried at all for an unauthorized
  connection_id, so no access-log entries, timing signals, or backend load are
  generated on the caller's behalf.
• The GET check and the secrets lookup both run in the connection's team
  scope (Connection.get_team_name, falling back to the body's validated
  team_name for connections that live only in a team-aware backend like Vault /
  Kubernetes / Akeyless), preserving multi-team isolation.

There is intentionally no 403 for the read-access case: matching the
behaviour of the variable-test path, an existing connection the caller can't
read is silently dropped from the test rather than surfaced as a distinct
error. (The pre-existing route-level POST authorization still returns 403 for
callers who can't create connections at all.)

Test plan

• test_unreadable_existing_connection_indistinguishable_from_missing —
  unauthorized read of an existing id returns the same status + body shape as a
  non-existent id (no enumeration oracle).
• test_unreadable_existing_connection_does_not_trigger_secrets_lookup —
  the secrets-backend lookup is gated on the GET check, never run for an
  unauthorized id.
• test_existing_connection_lookup_preserves_team_scope — the authorized
  team_name is propagated to get_connection_from_secrets.
• test_secrets_only_team_connection_uses_body_team_scope — when the
  connection has no metadata-DB row, the body's validated team_name scopes
  both the authz check and the lookup.
• Existing tests in test_connections.py::TestConnection still pass.
• prek run --from-ref main --stage pre-commit clean on touched files.
• prek run --from-ref main --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[pierrejeambrun]

Code and PR description are not in line.

If user isn't authorized to read a variable, existing variable is just ignored from the test.

            method="GET",
            details=ConnectionDetails(
                conn_id=test_body.connection_id,
                team_name=team_name,
            ),
            user=user,
        ):

This change adds a GET authorization check on the existing connection before its secrets are merged into the test object. A caller authorized to create connections but not to read the existing connection_id now gets a 403.

Also we should probably not reference airflow-s issue from here. (more of the opposite way, reference this from airflow-s, linking is both ways anyway and will prevent people from searching for such airflow-s referencing issues)

[potiuk]

Also we should probably not reference airflow-s issue from here. (more of the opposite way, reference this from airflow-s, linking is both ways anyway and will prevent people from searching for such airflow-s referencing issues)

True. I removed it from the SKILL already.

Code and PR description are not in line.
If user isn't authorized to read a variable, existing variable is just ignored from the test.

Hmm. mot sure. Indeed that's how it is implemented (assuming variable - connection :). The root of the problem here is however, that "require_access_connection" only uses connection parameter - but not body-specified connection_id.

So no matter if the connection belongs to a team or not, with POST the user with test connection could just "run" and allow to enumerate the connections that otherwise they would not be able to know even exist. This is "defense-in-depth" - so nothing serious but still worth checking I guess.

I think the description is pretty accurate.

[pierrejeambrun]

Maybe I missed something but the part I believe isn't accurate is:

This change adds a GET authorization check on the existing connection before its secrets are merged into the test object. A caller authorized to create connections but not to read the existing connection_id now gets a 403.

I would expect a 403 response, while this isn't what the current implementation is doing. It's just ignoring/skipping the connection existing in the db.

if auth_manager.is_authorized_connection(
            method="GET",
            details=ConnectionDetails(
                conn_id=test_body.connection_id,
                team_name=team_name,
            ),
            user=user,
        )

If this returns false, we proceed with existing_conn = None and the connection testing from the body. I would expect an explicit 403 saying, you don't have read access permission on this existing connection to be able to test it.

[potiuk]

If this returns false, we proceed with existing_conn = None and the connection testing from the body. I would expect an explicit 403 saying, you don't have read access permission on this existing connection to be able to test it.

Ahh Right .. updated the description - I indeed changed the solution - to silently ignore it - based on security principle of not revealing anything - but forgot to update the description.

If we had 403 - that on it's own would allow to enumerate the connections, that that caller should not even be aware of existence - so "silent" return (missing) is better than 403.

Updated the description to explain it.

[pierrejeambrun]

I figured it was some previous iteration remnants :)

LGTM, thanks!