How to Provide SSE-C CustomerKey (without trailing =)

[gschei]

I use velero-plugin-for-aws:v1.10.1 and velero 1.14.1. I want to encrypt my backups with SSE-C with the following steps:

cat /dev/urandom | head -c 32 | base64 -

I store that base64 string in the cloud-credentials secret as "customer-key".

Next in the BSL I add this config

config:
    customerKeyEncryptionFile: /credentials/customer-key

My Problem is, that the base64 string always contains a trailing "=" (the padding). It looks like I need to provide the encryption key as "raw base64" which does not contain padding. But Kubernetes does not allow to store the "raw base64" without padding.

So how can I properly store the key?

Currently I receive this error and according to my tests the trailing "=" might be the problem

net/http: invalid header field value for "X-Amz-Server-Side-Encryption-Customer-Key"

[kaovilai]

It looks like I need to provide the encryption key as "raw base64" which does not contain padding.

who said so?

[gschei]

Eg. here https://min.io/docs/minio/linux/reference/minio-mc/mc-cp.html#mc.cp.-enc-c

quoting:

Raw Base64 encoding rejects =-padded keys. Omit the padding or use a Base64 encoder that supports RAW formatting.

So for SSE-C encryption with minio cli it worked whenever I removed the trailing "=", otherwise it did not.

But perhaps I am wrong...

[kaovilai]

Key file here is expected to be mounted to the velero pod anyway.

If you could not create k8s secret with such data and mount secret as volume, what's stopping you from creating the file elsewhere then mount that into velero pod?

[kaovilai]

If mounting is not an option perhaps an initContainer that writes that file to /credentials/keyfile.

[gschei]

Thanks for your feedback and ideas! After further investigation I think the decoding from base64 (raw) is minio specific and the error above has a different root cause.

[gschei]

@kaovilai: thanks for your input, but I was completely wrong with my question. Raw Base64 is only needed for minio cli and not applicable to Velero. The raw key is anyway mounted in the container, because during mount of the secret kubernetes decodes base64.

The issue above was caused by missing base64 encoding of the velero-plugin-for-aws, which is of course necessary within the HTTP-Header. I created a Pull-Request for this: vmware-tanzu/velero-plugin-for-aws#225