GCS backend only allows short lived token

[Critical-Impact]

Description

At present when specifying a GCS bucket as the backend, you have the ability to set the following

1. projectIDSecretRef
2. accessTokenSecretRef
3. bucket

This appears to set GOOGLE_ACCESS_TOKEN on the restic side which is a short lived token. This is a problem if you create a schedule as the short lived token would expire.

Additional Context

No response

Logs

No response

Expected Behavior

Would it be possible to either specify a GOOGLE_ACCESS_TOKEN or GOOGLE_APPLICATION_CREDENTIALS when using GCS? As far as I can see this is supported natively by restic https://restic.readthedocs.io/en/latest/030_preparing_a_new_repo.html#google-cloud-storage

So you'd have

1. projectIDSecretRef
2. accessTokenSecretRef
3. applicationCredentialsSecretRef
4. bucket

Steps To Reproduce

No response

Version of K8up

2.7.2

Version of Kubernetes

v1.26.13-gke.1052000

Distribution of Kubernetes

GKE

[okgolove]

@Critical-Impact I was able to deal with it using PodConfig:

apiVersion: k8up.io/v1
kind: PodConfig
metadata:
  name: podconfig
spec:
  template:
    spec:
      containers:
        - name: backup
          env:
            - name: GOOGLE_APPLICATION_CREDENTIALS
              value: /opt/secret/key.json
      volumes:
        - name: k8up-secrets
          secret:
            secretName: k8up-gcs-key
---
apiVersion: k8up.io/v1
kind: Backup
metadata:
  name: k8up-backup
spec:
  failedJobsHistoryLimit: 1
  successfulJobsHistoryLimit: 1
  backend:
    repoPasswordSecretRef:
      name: k8up-restic
      key: resticPassword
    gcs:
      bucket: secret-k8up-backups
    volumeMounts:
      - name: k8up-secrets
        readOnly: true
        mountPath: /opt/secret
  podConfigRef:
    name: podconfig

[zjustus]

Thank you!