multi-cluster secret sharing

[v0lkan]

should be doable since SPIRE supports cluster federation.

This way, a workload can talk to an Aegis Safe in a separate cluster.

You can even put Aegis Sentinel in a totally different cluster with more isolation if needed.

[v0lkan]

Smells like 1.1.0 to me.

[v0lkan]

I am not sure this is a use case that makes sense though because for best performance Aegis safe should better be in the cluster that the workload is.

Moving aegis sentinel out can be a legitimate use case (instead of adding one sentinel per cluster)

What makes the use case less relevant is the fact that a workload cares about its secrets only.

If Workload A in Cluster A needed to know about Workload B in Cluster B, then this would have been a legitimate use case.

However, right now it is just an overkill.

--

To show that this works "in theory" though, we can deploy Aegis Safe in one cluster, Aegis Sentinel in a totally different cluster, workloads in a yet another cluster and show that the interaction still works (i.e. we can still assign secrets to workloads).

We can then extend it to assigning secrets from Sentinel in Cluster S to Safe in cluster A to be registered to workload C in cluster C and workload D in cluster D.

Behind-the-scenes, this will require a 4-cluster federated SPIRE installation.

From the workloads’ perspective; there will be a single Aegis Safe regardless of the cluster they are in. Same goes for Sentinel.

so as long as there is a route to Aegis Safe, things should work (though it would probably take some experimentation).

--

Regardless of the practical need, it would be a fun experiment to try out.

[v0lkan]

Not immediately needed. Relatively low-prio

[v0lkan]

Marked as good-first-issue. As long as you are comfortable with SPIRE, this exercise should not include much code change.