Secrets with vals

[digiserg]

Please check out the documentation attached describing this feature. This is a rewrite on #390

[digiserg]

In reply to #390 (comment) by @philomori, I'm afraid it won't work at the moment. The code will only work for external backends configured with environment variables.

[philomory]

@digiserg That's fine, maybe support for VALS+SOPS could be something added in a future enhancement. Having support for Vault, AWSSM, etc., is plenty right now. Also if you really want to use SOPS with the current implementation, you could presumably still do ref+sops://<base64data>?key_type=base64; it's a bit cumbersome but would presumably work.

[philomory]

@nickgerace Did you want to review this PR?

[nickgerace]

It's on my list. We are getting a small, unplanned v0.3.7 release together for Rancher v2.6.1 at the moment. Thanks for your patience.

[philomory]

No problem, just wanted to make sure you'd seen it since I realized you hadn't actually been tagged in it yet.

[pnkcigarette]

This looks very promising and would be a big boon to have something native in Fleet for secrets to avoid more bolt on automation for pre-seeding.

I also like it's simplistic approach using vals for those that all ready have an external secret store. Also love the upstream secret option.

I know our org would use this if implemented.

[digiserg]

Hi @nickgerace

Are you looking into this? I keep having to resolve merge conflicts every few days because it's been opened for long time.

Thanks

[millerjp]

@nickgerace any updates on this issue?

[digiserg]

Whilst we wait for this to be review and hopefully merged, we have put together an alternative in the form or an operator. This operator will keep your secrets in sync between any backend supported by vals and Kubernetes.

https://github.com/digitalis-io/vals-operator

[nickgerace]

Hi @digiserg - we've reviewed this internally and are going to think about this further as a new feature rather than the usual PRs we focus on externally: bug fixes and enhancements. As a result, I don't think @StrongMonkey or I will be merging this in the near future since we'd want to ensure we can get "net new" components approved (e.g. https://github.com/digitalis-io/vals-operator) as well as its implications for our QA team to provide coverage.

However, your effort into this PR, its documentation, etc. has not been unnoticed, and I would like for this idea to circulate through our internal product pipeline rather than be left fully out to dry. Thank you so much for the PR; you've done a great job with it.

Due to the above, I've created a new issue and marked it as a "Release Candidate" for those who help get us our work scheduled to take a look at. I've assigned my colleague to it as well and off of this PR for the time being. Admittedly, our SOPS, secret management story, etc. needs more attention and I can see that in other places. It's my hope that user and customer requests make their way to our product teams so that we add net new features from our community with relative ease.

Thank you for understanding, and I'm going to leave this PR open as a result with the issue attached as a result.

[digiserg]

Hi @nickgerace

Thank you for the feedback and looking forward to seeing it as a feature in the future.

Regards

[nickgerace]

Not a problem @digiserg. I'm hoping we get the secrets story more hardened moving forward and we'll use that issue to track this one in particular.

[SheilaghM]

This needs to go through a design meeting before we merge.

[rajiteh]

Vals does look like a decent and a minimally intrusive solution to manage secret values at the controller level at the least. I found that pairing it with a template system allows a good amount of flexibility to pull in global secrets and cluster specific values if need be. I would be curious to see where the design heads towards.

rajiteh#8

[endersonmenezes]

This needs to go through a design meeting before we merge.

any news from this?

EDIT: I believe they are working here right now: #591, sorry I was lost in so many discussions, but I think that's it, I will continue to follow and thank you all.

[kkaempf]

any news from this?

secrets handling is on our backlog but it'll take some time until we've reviewed and consolidated all issues and PRs

[all4innov]

some updates on this issue ?

[areitz86]

would be interested as well

[alexdepalex]

Some updates on this issue? We would be interested as well :)

[manno]

We don't currently plan to implement support for specific operators that manage secrets.

If anyone is looking for examples, here is a blog post about Fleet + External Secret Operator

[willemm]

I looked at the example, and it is completely and utterly unusable for bootstrapping secrets. Quote:

We could use a Fleet bundle to distribute the secret to each downstream cluster, but we don’t want credentials outside of k8s secrets. So, we use kubectl on each cluster manually.

The whole point of this, and similar, requests is to automate the creation of that first bootstrapping secret that is needed for the downstream cluster to do all the other secret-pulling stuff.

sops or sealedsecrets? First you need to get the decryption key on the downstream cluster for the sops-operator
externalsecrets? You'll need to get the credentials for externalsecrets to access the secrets vault

pushsecrets from the rancher cluster? Now you need to manually add a pushsecret for each downstream cluster, thus negating all the benefits of fleet automatically targeting your newly provisioned cluster.

rancher/fleet can create secrets on downstream clusters just fine, all that is needed is for fleet to reference some secret provider to inject them. Even being able to access secrets that are on the upstream rancher-cluster would work just fine.