Workload Identity not working in logical backups for GCS

• Which image of the operator are you using?
  registry.opensource.zalan.do/acid/postgres-operator:v1.11.0
• Where do you run it - cloud or metal?
  GKE cloud
• Are you running Postgres Operator in production?
  yes
• Type of issue?
  Bug report

Steps to reproduce

1. Deploy Zalando Postgres Operator with Workload Identity/ Application default credentials using k8s service account that is linked to GCP IAM service account and has permissions to GCS bucket
2. Enable logical backups to GCS
3. Wait for backup jobs to start failing
4. Seems like WAL archiving is working properly only logical backups are having issues

Expected outcome
Logical backups are uploaded without issues to GCS bucket. It seems to me that gsutil used in backup job is not properly inheriting service account or doesn't even try to expand Application Default Credentials

Actual Outcome
Logical backups are failing constantly, WAL archiving works

Configuration

        image:
          registry: registry.opensource.zalan.do
          repository: acid/postgres-operator
          tag: v1.11.0
          pullPolicy: "Always"

        enableJsonLogging: true
        configGeneral:
          workers: 8
        podServiceAccount:
          name: postgres-operator-gcp

        configUsers:
          replication_username: standby
          super_username: postgres

        configKubernetes:
          cluster_name_label: dev-k8s
          enable_cross_namespace_secret: true
          enable_pod_antiaffinity: true 
          pod_antiaffinity_topology_key: "kubernetes.io/hostname"
          pod_environment_configmap: "postgres/pod-env-overrides"
          secret_name_template: "{username}.{cluster}.credentials"
          delete_annotation_date_key: "delete-date"
          delete_annotation_name_key: "delete-clustername"

        configLoadBalancer:
          db_hosted_zone: db.dev.internal.com

        configAwsOrGcp:
          wal_gs_bucket: "postgres-wal"

        configLogicalBackup:
          # this is used also for gcs despite name
          logical_backup_s3_bucket: "postgres-backups"
          logical_backup_provider: "gcs"
          logical_backup_schedule: "30 00 * * *"

        configTeamsApi:
          pam_role_name: db

        resources:
          limits:
            cpu: 500m
            memory: 500Mi
          requests:
            cpu: 100m
            memory: 250Mi

Start by reproducing the failing logical backup job with the shown GKE Workload Identity configuration, then compare how logical backups and WAL archiving obtain Google Cloud credentials. Done means logical backups upload successfully to the configured GCS bucket while WAL archiving continues to work.