Classify secret-resolution failures for AWS, GCP, Azure, and GSM

Lachlan Grantrequested to merge
39574-classify-secret-resolution-failures into main

What does this MR do?

Extends the per-cause secret-resolution failure classification already in place for the Vault resolver (!6904 (merged)) to the AWS, GCP, Azure, and GitLab Secrets Manager resolvers, so a job-configuration problem (wrong secret path, permission denied on a specific secret) reports as an accurate failure reason instead of always defaulting to runner_system_failure and paging operators for something they can't fix.

  • gitlab_secrets_manager: reuses the same StatusCode()-based classification as Vault (400/401/403/404 -> configuration, 5xx -> external dependency), since it authenticates through the same JWT+role mechanism the job configures directly.
  • azure_key_vault: classifies by *azcore.ResponseError.StatusCode (403/404 -> configuration, 5xx -> external dependency).
  • aws: classifies by aws-sdk-go-v2 typed errors (ResourceNotFoundException, AccessDeniedException -> configuration; server-fault errors -> external dependency).
  • gcp_secret_manager: classifies by gRPC status.Code() (PermissionDenied/NotFound -> configuration; Unavailable/Internal -> external dependency).

For AWS, Azure, and GCP, outright authentication failures (401, Unauthenticated, STS role-assumption denial) are deliberately left unclassified: unlike Vault/GSM, these providers authenticate through a runner- or admin-configured trust, so a broken trust should still page operators rather than surface as a job configuration error.

What's the best way to test this MR?

Each resolver's classifyError is tested against a real error type from its own SDK (not a hand-rolled stub) through the resolver's actual wrap chain:

go test ./helpers/secrets/...

What are the relevant issue numbers?

Closes #39574 (closed)

Merge request reports