SPIRE/SPIFFE based deployment for TLS

[blaggacao]

We have deployed a SPIRE/SPIFFE infrastructure, reason for which I'll be working on a SPIRE/SPIFFE TLS impelementation in the coming days. I think it has the potential to deprecate most of the hack-scripting of what's in quick-install.

Specifically, these parts:
https://github.com/ContainerSolutions/trow/blob/f66fdac14c81f305563ca7c7ac949fe7695dfd69/quick-install/install.sh#L15-L18

I'm reaching out to check if contributions about this would be welcome.

In any case, please be as responsive and decisive as possible about my PRs so we can make the most out of my this week's raid on trow. 😉

[blaggacao]

I think, by now, I have +- a plan. A sidecar spiffe-helper would continously roll the certificates and expose them through a shared ephimeral volume. Remaining open question:

How can I instruct trow to gracefully reload the certificates without service disruptions? (TCP or unix IPC both are possible)

Note: certificates are rolled well ahead of expire at about 80% of TTL.

[amouat]

I'm not 100% sure what your plan is and how it will work. If it simplifies things or is more maintainable or portable to different distros, I'm definitely up for merging it :)

The current solution is a hack, but it's a hack that means the user can get Trow running in a few minutes (if not seconds) with little thought or configuration.

We can definitely figure out something regarding certificate reloading.

[blaggacao]

So here is a prototype:

• ./dev/spire
• how it's deployed
• the custom artifact?
• after up and running
• the SPIFFE identities are loaded — this can be automated with the workload registtrar. The temporary file hacks will soon be simplified