Some new design docs

design/metal-fabric-message-bus.org

@@ -0,0 +1,43 @@
+#+TITLE: Metal Event Entrypoint
+#+AUTHOR: Adam Mohammed
+
+
+* Problem
+
+We would like other parts of the company to be able to notify Metal about
+changes to infrastructure that crosses out of the Metal's business
+domain. The concrete example here is for Fabric to tell metal about
+the state of interconnections.
+
+* Solution
+
+Metal's API team would like to expose a message bus to receive events
+from the rest of the organization.
+
+Metal's API currently sits on top of a RabbitMQ cluster, and we'd like
+to leverage that infrastructure. There are a couple of problems we
+need to solve before we can expose the RabbbitMQ cluster.
+
+1. RabbitMQ is currently only available within the cluster.
+2. Fabric (and other interested parties) exist outside of Metal
+   firewalls that allow traffic into the K8s clusters.
+3. We need to limit blast radius if something were to happen on this shared
+infrastructure, we don't want the main operations on Rabbit that Metal
+relies on to be impacted.
+
+
+For 1, the answer is simple expose a path under
+`api.core-a.ny5.metalkube.net` that points to the rabbit service.
+
+For 2, we leverage the fact that CF and Akamai are whitelisted to the
+metal K8s clusters for the domains `api.packet.net` and
+`api.equinix.com/metal/v1`. This covers getting the cluster exposed to
+the internet
+
+For 3, we can make use of RabbitMQ [[https://www.rabbitmq.com/vhosts.html][Virtual Hosts]] to isolate the
+/foreign/ traffic to that host. This let's us set up separate
+authentication and authorization policies (such as using Identity-API
+via [[https://www.rabbitmq.com/oauth2.html][OAuth]] plugin) which are absolutely
+necessary since now the core infrastructure is on the internet. We are
+also able to limit resource usage by Vhost to prevent attackers from
+affecting the core API workload.