 Hi, everyone. Thanks for joining us. My name is Kristin Nicola, and I work for the Mass Open Cloud. I'm also a core in Keystone. And this is a. Hi, I'm Morgan Feinberg. I'm a core in Keystone. I work for Red Hat. And we're going to talk about seamlessly federated multi-cloud installations. So let's start with a really quick level set. Keystone is the core of all identity within OpenStack. And we deal with the upcoming stuff for Keystone's identity federation, where you have the ability to talk multiple forms of single sign on from multiple identity providers. So it allows you to do an identity proxy, coming from, say, your Active Directory Federated Services, translate that to an OpenID connect, or to a Keystone token that then OpenStack can talk to, depending upon what your service providers need. On top of that, Keystone can provide virtual organization mapping, meaning I have some people from one identity provider, from one university, some people from, say, Red Hat coming in, and you add them to a group. And that conveys access to some subset of your service providers and your infrastructure. One cool thing about Keystone is that you can federate two clouds together using Keystone as an IDP for one cloud, and using Keystone as an SP for the other cloud. And that tends to work really well for identity federation. What if you want to share something else besides that entity? What if you want to share resources, like have a VM in one cloud connect to a volume in another cloud, or have a VM in one cloud be able to boot from an image in another cloud? You need a deeper level of integration between the two clouds to accomplish that, to be able to combine resources in this seamless way. And that, for us, is very important, because the MOC is hosted at the MGH PCC data center, which is a huge cloud in running collaboration between five universities. And these clouds want to be able to collaborate with each other, but also maintain administrative control over their open stack deployments. So we need to be able to share resources and share identities while allowing these partner organizations to maintain the control over their own infrastructure. And to accomplish that, we have a built tool called Mix and Match, which allows open stack services to consume resources from federated clouds. So as I said, volumes and block storage. Or, yeah. The way this works is you have one cloud, which is the BU cloud in this case. You have your normal Keystone, your compute, which is NOVA, block storage, which is Cinder. And you have one VM attached to a volume. And now you want to collaborate and be able to attach a volume from the northeastern cloud, which is partnering with you for this research project. So the way this works is the user comes in and makes a request for NOVA to attach the volume 2 in this case. And NOVA makes an API call to whatever service is registered in the service catalog as Cinder. In this case, the service catalog will contain the entry for Mix and Match instead of Cinder. Mix and Match will receive the request to attach volume 2 and will perform Keystone to Keystone authentication, which is a method of federating identities from one cloud to another. And go figure out where volume 2 is, and then forward your API request to attach volume 2 and then send the response back. And then through Iskasi, NOVA will be able to attach volume 2 to VM 1 in this case. This also works for images. And there is a spec for Neutron called Neutron to Neutron Interconnect, which allows VMs in different clouds to be connected with private networks together without the overhead of a VPN connection. So as I said, it's a proxy service. It's fully compatible with the OpenStack API, so we haven't made any changes to any of the OpenStack APIs. It just sits on top of everything. It uses Keystone to Keystone, and it can automatically find the location of requested resources among multiple clouds by doing a broadcast search and then caching the location of the resources so it doesn't have to go and look for them again. And it's possible to build extensions to customize behavior. So what are the next steps? So the next steps beyond what Mix and Match already does and what Keystone already does is to allow for providing direct access to services within your cloud to your resources, such as a VM. What if a VM wants to talk to a monitoring service and inject data or figure out where it's supposed to log its data, something along those lines, and allow you to provide that level of integration and identity there? It also is providing direct identity to the VM such as a assert or other such data that allows it to talk to other resources within the more global network of clouds. Not just its cloud, but in the case of the previous diagram, BUN Northeastern. So not only for service-to-service communication, but also resources will have their own identity, which has been a pain point in OpenStack for a while now. How do we have resources have their own identities so that a VM can make use of the resources of the cloud on behalf of the user, which spent it off? And thanks, everyone.