Global environment variables for s3 endpoint/bucket: do you still need to specify one in your backup/schedule?

[reinout]

I'm using several namespaces and I want them all to back up to the same s3 bucket. So I want as little duplication as possible, I especially don't want to put the secrets in every single namespace. The global environment variables are handy for this:

• BACKUP_GLOBALS3ENDPOINT
• BACKUP_GLOBALS3BUCKET
• BACKUP_GLOBALACCESSKEYID
• BACKUP_GLOBALSECRETACCESSKEY
• BACKUP_GLOBALREPOPASSWORD

I did this with a values.yaml passed to the helm chart.

What I hoped to be able to do is to have a backup in every namespace with just this:

apiVersion: k8up.io/v1
kind: Backup
metadata:
  name: backup-test
spec:
  backend:
    s3:
      # endpoint: https://some-url
      # bucket: some-bucket-name

So: nothing specified, except that I want an s3 backend. Which fails with an error:

k8up.restic.restic.RepoInit.restic.stderr	Fatal: Please specify repository location (-r or --repository-file)

If I specify the endpoint, the bucket/accesskey/etc global variables are picked up just fine.
Same when I specify the bucket: then the endpoint is picked up.

So: if "s3" itself is empty, it won't look at the global variables, but if I specify one of them (either bucket or endpoint), it works fine.

Is there a way to have such an "empty" s3 backend configuration?

[Nickalus12]

Yeah, I've run into this too. I believe the K8up controller requires at least one field in the s3 block to act as a trigger for its S3-specific logic. Even with those BACKUP_GLOBAL variables set, the operator doesn't seem to realize it needs to construct an S3 repository URL unless it sees a bucket or endpoint explicitly defined in the CRD.

IIRC, the logic that assembles the -r (repository) flag for Restic needs to see a non-empty backend type. If the s3 block is completely empty, the operator likely fails to generate the s3://... string entirely, which leads to Restic complaining about a missing repository location.

I don't think there's a way to have a truly "empty" config right now. You'll likely need to keep providing one of those fields to satisfy the controller's internal validation. Usually, specifying just the bucket name is the path of least resistance here.