Trow-Registry / trow

Container Registry and Image Management for Kubernetes Clusters
https://trow.io
Apache License 2.0
907 stars 101 forks source link

SPIRE/SPIFFE based deployment for TLS #184

Open blaggacao opened 3 years ago

blaggacao commented 3 years ago

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. :wink:

blaggacao commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

How far fetched would it be to utilize https://github.com/heavypackets/rust-spiffe and support SPIFFE for mTLS natively — while preserving the possibility for people to manually set up their own ACME stack?

blaggacao commented 3 years ago

So here is a prototype: