Allow providing cluster-wide age identity via controller env var

[mraerino]

SOPS has the handy feature of allowing to read the identity for decryption from SOPS_AGE_KEY. Because of the keyservice implementation detail of Flux you can't use that env var to set a cluster-wide identity on the controller.

This change implements that ability using the env var FLUX_SOPS_AGE_KEY. When you set that variable on the Kustomize Controller it will be used as an additional key in decryption and allows omitting the spec.decryption.secretRef property on the Flux Kustomization (it is marked as optional in the API).

[makkes]

This is a convenient feature. However, we need to think about the security implications of this in multi-tenant environments. If we agree to add this feature, we must document it in https://fluxcd.io/flux/components/kustomize/kustomization/, https://fluxcd.io/flux/guides/mozilla-sops/ and https://fluxcd.io/flux/security/secrets-management/. Likely also in https://fluxcd.io/flux/security/best-practices/.

[makkes]

For the case where the env var is not set and no secret is provided in the Kustomization, this just bails out but it should actually return an error because providing a decryption provider without any keys is a user error.

[mraerino]

that behaviour was there before, i did not introduce it?

[mraerino]

However, we need to think about the security implications of this in multi-tenant environments.

i'm happy to discuss them. the hope was that since this is an env var for the controller, people setting this would need to know what they're doing? it's also prefixed with FLUX so it's unlikely to get there by mistake?

[stefanprodan]

We have a dedicated section in the API docs for Controller global decryption, this the place where this feature should be documented.

[mraerino]

so it seems like we have precedent for secret-less decryption?

[stefanprodan]

so it seems like we have precedent for secret-less decryption?

No, not with some hardcoded private key, all the global options are for KMS & OIDC.

[stefanprodan]

we need to think about the security implications of this in multi-tenant environments.

No one should use this on multi-tenant clusters. Given that it requires a cluster admin to add the env var to kustomize-controller, it can't be enabled by mistake and it's opt-in, I think it's safe to add this feature. @hiddeco what's your opinion on this?

[hiddeco]

Think it would be okay to include.

However, I am not really sure about the naming of the FLUX_SOPS_AGE_KEY environment variable, and think it may be wise to wait a tiny bit until we have the next SOPS release out which will remove all forked keysource implementations.

[mraerino]

I am not really sure about the naming of the FLUX_SOPS_AGE_KEY environment variable

What are your doubts about it? Any kind of conventions or existing patterns you'd like it to follow instead?

[hiddeco]

SOPS itself already has default places where it looks for things, and it may thus be better to inherit these for environment defaults: https://github.com/getsops/sops/blob/02a866f27d8545fdc3de3b44a563e46f8e9c9df9/age/keysource.go#L19-L27

[mraerino]

if you prefer omitting the FLUX_ prefix, that's totally possible, i was just thinking it might be nicer to scope it. would that help? i can also implement the SOPS_AGE_KEY_FILE if that makes it easier to accept this change

[mraerino]

@hiddeco @stefanprodan do you think it makes sense to get this implemented?