 Good afternoon everyone. Thank you for coming to our talk identity with this view in the Cloud Foundry Service Mesh. So today we're going to be going through a quick introduction of who we are, talking a little bit about the landscape and challenges of security and identity, talk a little bit about explaining what Istio and the Service Mesh really are, talk a little bit about why we think the Istio and the Service Mesh are good for identity use cases, and finally, talk a little bit about what we're doing within Cloud Foundry and follow that on with some Q&A. So my name is Tian Wang. I'm the senior product manager over the application and identity workload, application and workload identity problem space, as well as the pivotal single sign-on service. I'm Anubha Dubey. I'm a senior product designer on Cloud Foundry Identity Team. Today's conversation, oopsies, and technical issues. Today's conversation is going to be addressing challenges of securities at scale across all of your applications. We'll be talking about the concept of authentication, which is verifying the process of who you are and the authorization, which is the process of verifying what you have access to. And we will cover how the implementation of these two concepts varies in context of and user identities or simply put as human identity. For example, my Twitter username is my identity to log into Twitter application. The other context would be application identity, where one application needs to verify itself in order to communicate with other application. And we'll also be broadly cocking in the context of the move from monoliths to microservice-based architecture. And in this kind of move, you're really seeing what used to be security for functions within the same compute space. Move into how do we do security for network calls from microservice to microservice. And that means that a lot of the protocols that used to exist in the past, no longer really function as well between these two separate microservices and new protocols that offer things in the space of federation kind of fit better into the new context. So what does that look like then today for a lot of application developers building identity for their apps? Well, for end-user authentication authorization, then there's protocols like LDAP, SAML, or OAuth and OpenID Connect. And you typically implement this then by pulling out some kind of library, using some kind of gateway. If you're really brave, maybe you'll go and try to code that yourself. And what about application identity then? What does that really look like when two applications talking to each other really need to kind of signal who they are? Well, the most common approach that was done in the past was nothing, but some people might wanna check that security box and implement basic auth between those two applications. And if you're really brave, you could try to add search to your applications and then have them do mutual TLS to each other, but that might implement a lot of overhead and become kind of a management nightmare. So building these protocols comes with its own challenges. For instance, non-uniform code across different applications. A lot of manual code writing for application developers to secure their application and that can lead to making more mistakes. Scaling this approach requires expecting your application developers to become security experts and wanting them to learn all protocols, languages, frameworks which are out there. Patches and updates for your applications may require downtime. And as often, patches need changes in code base and that can be hard to do. If you have a lower visibility, what's being done in application code base, it makes a nightmare because you cannot find that part of the code. So gateway helps with a lot of previous challenges, but being a centralized approach, it doesn't explain that what happens after the edge. How traffic talks to the application, how it gets secure. So this approach varies a lot based on your choice of gateway and the platform. But that's not all. There are some other concerns we heard from enterprises that their identity management teams can't keep up with the load of application integration which they need to manage. Application developers are going and building their own identity providers. And because they don't know what's going on with their centralized system. Also, authorization is highly customizable per application and that creates a confusion. Oh, what authorization level is required for my application? And not the least one. Constantly changing regulatory requirements. Which caused the application developers to ask, oh, how do I go and secure my application to work? What compliance do I need now? So we've talked a lot about kind of what are the challenges that you could be facing for security and identity at scale. Now let's move into kind of what is Istio and what is that service mesh. What's this hyped up topic that is on the top of everyone's mouth these days? And that starts with really the basic concept of a service mesh starts at a sidecar. And a sidecar is a proxy that manages all inbound and outbound traffic from your application within the pod or container where the application is running. So that allows it to kind of scale up and down a little bit as you're deploying application instances. And the proxy of choice for Istio is Envoy. This is an open source component written in C++ and Envoy's are used heavily within Istio. When every application has a sidecar you get the concept of a service mesh. So now basically all of these sidecars are intercepting traffic for their corresponding apps and talking to each other. And the service mesh itself can come with a gateway typically called the ingress gateway that manages all inbound and outbound traffic to the service mesh itself. So in that sense you can think of this as a sidecar for the service mesh. And on top of that you have a control plane that is managing the data plane of all of the sidecars and distributing policies, collecting telemetry, managing certificates. And that's essentially what Istio is, right? A combination of a data plane and a control plane that's layering on top of all your applications. And Istio comes with many components of its own besides the Envoy sidecar that we talked about it comes with Gally and Pilot to help manage configs. It comes with Mixer to help manage telemetry and extensions. And it comes with Citadel to help manage certificates. So that's basically Istio in the open source. So now why though would we take a look at using Istio and the service mesh for identity use cases? And that really comes back to the story of application development. So in the early beginnings when you're trying to build authentication authorization for your application you might say, hey, I need to build this as part of the code of my application. And I might go and try to write that myself and figure out how to do it. But then a bunch of smart people figured out, well, I can find open source libraries that have experts that are writing these for me. But the challenges there were really, do I have one for the language that I'm choosing to write? If someone else uses a different language do they have to find a different language library? And then how do I start using that? And I still have to do things in my code to really figure out how to initialize this library and start using that for my application. So then people started looking at, can I externalize that from my application? So that regardless of what application I'm running can it kind of happen outside of my app? Now the questions there become, how do I route the traffic through this proxy to my application? Where is this going to run? How am I going to configure it? So there's a lot of confusion there as well but it's definitely a model that goes back many, many decades in terms of external proxies for your applications. And now we come to kind of then that whole sidecar thing because if this proxy is sitting with your application what'll happen then is basically all traffic being routed to your app can pass through this proxy that's implementing your logic and you can have a central control plane that's sending those policies to this sidecar in order to enforce the corresponding policies that are required for your application. So this vastly simplifies the deployment model and still lets you get the benefits of that proxy model. So let's say now I wanna actually add OIDC logic acquire a token, validate the token. Well if I send that policy to my sidecar and traffic inbound passes through this proxy I can enforce all of that identity logic and I didn't have to add anything to my application to make that happen. And when you start looking across microservices then this really starts kind of showing its value because every application has a corresponding sidecar that traffic is being passed through and you've got a central control plane sending policies to all of these sidecars. So now you can implement consistent identity logic at kind of every layer of your microservices. And then let's move on to mutual TLS and certificate management. So Istio itself can distribute certificates as well to those sidecars that are sitting alongside your applications. So this is actually complimentary with end user authentication that we talked about before because one of them passes through the data alongside your requests. But this one is saying I can also encrypt the channels such that my data is also secure when I'm passing through the two applications. So now you can have end user identity and application to application identity. And lastly of course we can't underestimate the observability features of Istio itself because you've got this sidecar that's able to see traffic coming into your application and traffic leaving your application and it's reporting that back to the central control plane. So you'll be able to see what's going on across all of your different applications and you'll also be able to see what policies are being configured on each of your sidecars so that you can know kind of like what's the security model that's being enforced at each of your apps. So now let's talk about what we're doing then within Cloud Foundry. Well if you went to the keynotes yesterday you probably already know a little bit of this. So today when you CF push your application into Cloud Foundry it's already coming with an on voice sidecar. There's already an Istio control plane. That's somewhat available I believe and routing can already take advantage of this through things like weighted routing. So if you saw UEs presentation of weighted routing demo that is using Istio with the corresponding envoys. So the idea here then is the platform will make that available for all of your applications. Now that being said this is my understanding of what's going on for the most up-to-date information as the routing networking team. They'll be able to provide a much more precise answer. So we touched upon what Cloud Foundry is doing with Istio and envoys service match. And before we get into what we are doing with Istio I want to touch upon who are we. We are a pivotal application single sign on team. Our service powered by UAA. We are persona driven. We have a persona driven approach. We deliver value on top of open source components. So application SSO allows applications on the PCF platforms to indicate securely with their enterprise identity providers like octa, ping, et cetera. Operators uses SSO to configure their enterprise identity providers and make them available for their application developers to use. Application developers comes in and utilize self-service capabilities to create application security policies and utilize low touch integration of spring boot and steel toe to auto-configure their application. This approach allows, this approach provides speed and security by allowing application developers to focus on delivering business outcomes by extracting away auth and not Z to the platform. But the steel toe and spring boot are not the only frameworks where much applications are using. So how does service work with other frameworks? And how can we make it language agnostic? So a lot of what we're trying to do here goes back to Pivotal's mission of how do we transform the way the world builds software. And within our team, we really asked ourselves then, what can we do to help transform how enterprises build identity into their software? And that goes back into what we're working with the Istio open source community on, in terms of envoy and Istio policies. This is a collaboration with the Istio Security Working Group, as well as a collaborator from Tallis out of London. And what we're looking to do today is essentially say, when a request is coming into your application and it's trying to route there, the Ingress Gateway proxy can enforce a policy that says, are you authenticated or not? And if you're not authenticated, let's go ahead and send you to an identity provider for OpenID Connect, an authorization server, essentially, to say, can you go ahead and log in, authenticate, and also be authorized. So we use the open source Cloud Foundry User Account and Authentication component, which also acts as an identity proxy. So if you have downstream LDAP directories, or you're using SAML to connect to directories, or if you're actually just connecting to other OpenID Connect providers through UAA, then your user can go ahead and log in with their enterprise account. And once that happens, the proxy can take care of all of that OAuth dance. And send that token downstream to your application, where that proxy sidecar itself can help continue that security part of this flow and say, do I have the proper validated JOTs? Do I have proper claims, such as issuers? And also do authorization on things like whether it's scopes, groups, external values, custom claims, what do I need to authenticate when authorize a user to access this application? And it doesn't stop there. You can go ahead and send this downstream as well to other applications who can enforce similar proxies or policies at the proxy layer, and possibly as well on different token values. So one thing the SDO OSS community is looking at is to say, can we also swap out for request context tokens that vary based upon which applications are calling which applications to offer you additional security beyond just an OAuth token to prevent things like impersonation. And of course, this is all happening over a mutual TLS. So we're not really worried about channel security. The idea is that the platform can implement that. So you really don't have to then worry about traffic and how that route is being encrypted. And lastly, of course, since this is all built on top of open source SDO, you'll be able to leverage these types of things, whether you're using CFAR, CFCR, or native. So let's go ahead and do a demo. So I'm going to be using the Book Info demo. That's typical in the SDO community. And you can see right now that it's unauthenticated. What I will do is, and I am, oh, I should make this bigger, shouldn't I? OK, I see that. First, I'm just going to go ahead and enable authentication on this application so that it's no longer unauthenticated endpoint. And it's going to take a few seconds for this policy to take effect, but oh, it took effect right away. Nice. So now you can see I'm no longer allowed to just access that Book Info application anymore. So this is enough for an API, but this is not enough for a web application. So what am I going to have to do? I'm probably going to have to tell it, go ahead and let me go log into somewhere and gain access to this application. So I'm going to let it take effect a little bit while the policy applies. Now the idea here will be that I'll be forced to go log in. So this is a UAA that we've set up. And it's acting as the authorization server for my application. And I'm going to go ahead and log in through my enterprise account, which is going to also enforce any enterprise policies that I have at my identity provider. So I'm going to be prompted for MFA if I can type correctly. So let's see. And please don't steal my one-time passcode. And you can see that I've gone ahead and logged in. But now if I go back to my application over here, you might have saw earlier. So it is protected now. And you might have seen that I got past this. This is not letting me past. Who would have thought I would have a problem with that? So you might have seen the Facebook option. Maybe I don't want people being able to log in from just anywhere. Maybe I want to enforce an authorization policy as well. So I can go ahead and apply a different policy so that my original user is still able to access the application. But if I were to come back, let's say, as a different kind of user, the policy would have taken effect eventually. But I think it didn't take effect yet. So I'm just going to clear my cookies. And that wasn't supposed to happen. But now you'll see that it started preventing me from accessing this application. So the idea here is, of course, that all of these policies can be used and applied to your applications so that you could go ahead and adjust the policies, but then eventually kind of settle on a fixed policy that you'll want to apply to your application. We didn't just go and made this demo based on cool technology out there. We took a lot of steps before we get to this point. We wanted to understand what enterprise users are doing in this space. We conducted research with Cloud Foundry and users across different industries. The goal of that research to understand roles, responsibilities, and workflows of how companies organize their application security policies today, and how would they envision that who would manage these policies in future. Some of our learnings from those conversations were people are already moving towards OAuth and OpenID Connect. They prefer having proxy approach, sidecar proxy approach over Gateway. They are already building proxies using open source components. So we saw that, OK, there is a desire. People are building it. But there were other use cases which emerged with it. Enterprise were asking, some enterprise were saying, OK, we don't want our operators to have a lot of control over our policy. Some wanted their developers to have less control. So a lot of use cases emerge around security policies that we need to have a flexibility around it. But these are not the only use cases which would be out there. So we are still working towards it to make it more valuable for your applications. So with that, Cloud Foundry is looking to help you build secure identity across your production grade workloads as part of the platform in new and innovative ways with Istio and the service mesh. And a lot of this is still ongoing in the open source space. So we're always welcoming collaborators. The user account and authentication component backends a lot of the protocol logic that exists in this space. We're also working with the Istio community. So this is a link to our Istio proposal. And we're collaborating with the security working group and a collaborator out of tallest to make this happen. You can find us on CF Slack and Istio or Istio Slack and OIDC proposal. Or talk about us on the Istio Discuss Channel. And if you want more technical details about what's happening under the surface of these policies and what's happening at the Istio Kubernetes layer, feel free to take a look for the service mesh day talk that Cameron Moro and I gave at Service Mesh Day last Friday. The videos are not out yet, but they should be up soon. And with that, thank you for attending this talk. Well. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.