 Good afternoon all. Cloud and cloud native identity and access management challenges and opportunities. Enterprise IT paradigms are constantly evolving. Multi-cloud, hybrid environments, container platforms, microservices, architectures and APIs for partners and subsidiaries. This is becoming the new norm. At the same time, the threat landscape is ever-evolving. Cloud misconfigurations and all the breaches that we've had pose more and more challenges for enterprises and hence they have to move towards zero trust architecture. Yet identity and access management is a space where there are a number of challenges enterprises are facing. Basically because of the sheer scale, dynamic and distributed nature of cloud and cloud native technologies. So in this panel discussion, we will discuss some of those challenges and opportunities available to enterprises. So without further ado, let me introduce this panel to you. My name is Radna Chital. I work for TIA and I'm the coach here for CNCF tax security. Nathan, you want to go ahead and introduce yourself? Sure. Nathan, you're coughing. I'm a chief strategy officer of Cloud Entity focused on bringing identity and access management to the cloud native world. Thank you. Greg? Oh, I'm sorry. Go ahead, Greg. I'm Greg Blana. I have been doing IAM for gosh, at least 20 years with the Boeing company independently here recently and have recently accepted a position with Costco. Congratulations. Thank you. And Craig Thomas, president of C2 Labs. We serve as a digital transformation partner for our customers, largely focused on DevOps, cloud native and full stack development. Thank you, Greg. So my first question, I'll start with you, Greg. What do you think are the biggest challenges for traditional enterprises, especially the regulated enterprises in the space of identity and access management? Thanks. So what we've seen working with various customers in these areas, primarily in the highly regulated spaces are, there's identities all over the place. They've got a lot of homegrown solutions, different directory services, whether it be SAP, Oracle, Active Directory, other systems, various networks and shared no shared identities across those networks. And it seems like a million passwords still largely focused on the user rather than processes and services and rely on the user in this password that continues to be social engineer continues to be least common denominator for all these disparate systems. And then the big one today is this lack of modern authentication, right? So as we are developing new modern technologies and modern apps, there's not that modern authentication mechanism in a lot of these homegrown solutions that they had to invent, they won't die or they can't die. And then these batch processes, instead of real-time APIs across these various systems. So you often get this, we made a change, wait until tomorrow and try it again or wait until that runs at the end of the week versus real-time go and get logged in or get the additional permissions that they need. And then we've got this lack of skills in IAM, especially as the technology ever changes this skill gap that we see. And dealing with certificates today, still very manual, you know, separate monitoring if they're good. We continue to see even in Microsoft and others, these certificates that expire and cause problems across the board. And now with regulations and other things, HSPD 12, PIV cards, smart cards, tokens, Yubiquis, adaptive auth, I guess it's just kind of all over the board. And organizations continue to struggle with that, both from an end user perspective as well as from kind of an IT administration perspective. Also, IAM is not a core part of the project planning, right? And so we have, cyber has gotten better at being baked in and network architecture baked in. But having this IAM as part of this project planning and this IAM board of, hey, you're going to bring on a new project or a new system, it has to support this identity structure. Black of modern enforcement points as we look across containers and other things, you know, how do we enforce identities? How do we, you know, enforce these policies at different levels rather than just this edge case of firewalls and, you know, network ACLs. And then just finally the frustration of users by of using this, you know, lack of funding priority of the business and IT of fixing the identity issues to be able to support kind of the next generation of IT architectures and projects. Thank you, Craig. So, Nathan, you've been doing identity for a couple of decades now. Would you shed some light on how to mesh container platform identity and access management and enterprise and cloud IAM provided by the providers in a multi-cloud environment? Absolutely. You know, what we've really seen over the last, you know, four or five years with the advent of distributed services, microservices, Kubernetes, right, is the need for a workload identity. And that's really where Spiffy arises, you know, generating that common identity framework, you know, for everyone. It's really what the definition of Spiffy is, right? And, you know, and the beauty of that is now we have what we think of as service identity in the past. It's been done by things like, you know, API keys or by, you know, shared X509 certificates, things that are obviously just as bad as sharing passwords in the old user identity context. And so now we're taking that and we're expanding it outward, right? We're thinking how can we federate across, you know, across Kubernetes clusters, across service meshes, across different parties, and be able to maintain that unique identity for the workloads and then cross-reference that into very much a zero trust algorithm, right? Making sure that you can identify and authenticate the workload to identifying and authenticating the service or the API to identifying and authenticating the actual user, right? And being able to corroborate all three of those and then build a zero trust authorization, right? To interlay and control how data is flowing in between those three disparate entities, right? Being able to authenticate them strongly, being able to pass that authentication on, and then being able to authorize exactly what is being passed down to them. And that's really what we're seeing kind of emerge, particularly in that hybrid and multi-cloud world is. We've got developers building the net new, and we've got kind of a lot of the legacy, more traditional items, you know, that might still be on-prem or at least a bit, or maybe have been re-platformed into your cloud. But how do you start to interconnect those, right? How do you securely connect services and APIs from your monoliths out to your next generation, you know, functions? And Spiffy, coupled with OAuth and Opa, began to solve that problem in a very elegant manner. Thank you very much. So I have a follow-up question. But still, the traditional identity and access management on-premise for enterprises and this disparate identities and management systems, this still caused a lot of integration issues. So do you have any ideas as to how we'll mess them together? Yeah. So what we've seen in 2012, 2013, right, as we saw the advent of OAuth and OIDC. And what that was designed to do is separate apart your user authentication away from your service identity and your service authorization, right? Literally, OAuth is designed for delegated authorization. And so by decoupling those, right, now you're able to continue to use your existing IDPs, use a standard-based way of federating them, whether that's OIDC or whether it's something like SAML, now aggregate all of that as identity context, right? And then you start sharing that identity context into what you can almost think of as your service IDP, which is a combination of OAuth client IDs, as well as obviously Spiffy identifiers, being able to correlate those. And now you've got a very secure way of authenticating your user. And that could be MFA, it could be adaptable authentication, it could be even legacy user ID password, and carrying that over into your service identity. So it's now also have their own strong authentications, again, using things like OAuth client identities or using Spiffy. Thank you, Nathan. Well, my next question, Greg, I want to talk to you a little bit about claims of error and externalizing, claims of error applications and externalizing access decisions out of the application. This has been a concept that has been discussed in the industry quite a bit, but I haven't seen a whole lot of progress made in this space. So do you want to shed some light on this, please? Yeah, I don't know if I'd call it a pet peeve, but it's definitely an annoyance of mine. I find it frustrating. You know, we look at the OAuth top 10, either for API or for web applications, and we see access control as a major issue. It's gaining in prominence. I think I just saw a very recent release of OAuth top 10 for web authentication or web applications and authentication, broken authentication went to the top. So it's definitely a problem. I also think that as we see, I'm an optimist, I think we're going to see gains in our ability to protect ourselves with ZTA technologies, that sort of thing. It's going to become more and more enticing to go for that low hanging fruit. We're going to go to the front door and knock on it and say, hey, can I have your gold and your jewels? And if we get the answer, yes. Great. That's a great attack. So this is definitely a problem. It's definitely going to continue to be worse and worse until we do something about it. In this sort of scenario, maybe I would look at the industry and say, okay, I'd like to point my fingers at the standards bodies. They're not giving us answers. But I think we all here are aware that NIST has been giving us answers for getting close to 20 years now. And they've been evolving those answers quite well as security technologies evolve. And so I can't really blame the lack of answers. I could look at vendors and say they're not giving us the solutions. They are. We had our first go around with the exact role. I think there were concerns there about performance, et cetera. But as we move into cloud native, the opportunities to sidecar some of these capabilities, I think eliminates that concern. And so what's the problem? Why are we still moving rapidly towards a dark picture around access control? We just need to have, I think enterprises step up and adopt this as a very important part of their security stance. We need to be able to go out and do a quick scan on the internet or talk to someone who maybe just got out of school and not get three or four or five answers as to how we should be stepping up our access control scenario. We should all be speaking from the same playbook. And I think until that happens, we're going to continue to see this problem get worse. But at the same time, externalizing access from applications in traditional applications is a hard problem. It requires investments, it requires development work. Greenfield applications, I agree that it's easier to implement. But why have we not seen a migration in this direction? And Nathan, could you shed some light on this as to whether it is being adopted? I haven't seen much success in this. Yeah, well, so there's a couple things there, right? So it's a multi-part question. So it is being adopted by forward-looking organizations, but it's few and far between to your point. Now, I think what's happening is we've been kind of caught in between a rock and a hard place or a legacy equipment and what our developers are building today. And there hasn't been a good bridge built, right? So if I go and talk to a traditional IAM person, right, he's still worried about how do I add IAG to SAP, right? Trying to think of kind of an older application, right? How am I going to do role management? All of these things. And those are defined and known problems that have existed for last decade and a half. And they really have no idea what's going on in the developer landscape today, meaning if the typical identity person went and looked and said, oh, my goodness, you guys are rolling out APIs that have no concept of user identity, that are leaking data, all these other things have no real authorization built in, much less externalized authorization built in, they would pull their hair out, right? And that's why we see developments slowed down so often by security because there hasn't been a good model built for how to pull kind of these two very disparate worlds together. It's not not I can replatform in the cloud. It's literally, I have to rethink how I'm going to address identity, user identity, start incorporating service identity, and build in a robust externalized authorization to connect what those different pieces look like. And it's only been in the last couple of years that we've started to see this start to emerge in the industry. There's been some standards out there, you know, OIDC, OPA, well, OPA is not a standard, but CNC, I think you better project, right? And Spiffy that can be used to interconnect kind of these three big, or these different disparate pillars. However, right? It's the technology is not quite there yet. And we need much more automation. I mean, we're working with customers now that you have tens of thousands of containers. And each of those containers ends up having its own unique identity, right? That also needs to be able to corroborate and authenticate the user identity or the requester identity or the service identity is coming in from other SaaS or other partners, right? So it builds a fairly complex landscape in exactly what's transpiring. And you've got to use authorization kind of at this governing body, right? That's ensuring that only the right data is going to the right services after then accordingly authenticated. I don't know if you could pop up that diagram, but I can kind of walk through how they all fit together. Probably a good time for it. Sounds good. I will share. So real quick, you know, we've got three major, you know, standards ask, or at least open source CNCF protocols that are interoperating here, right? We've got Spiffy, we've got OAuth2 combined with OIDC, and we've got Rego policies or Opal policies. And as we see these net new services pop up, right? The services first have to get their own identity. And they'll go back through a Spiffy spire, go back into your Kubernetes Citadel service or your Istio Citadel service, and they'll get a workload identity, right? They'll get this SFID that is a very strong concept and a very short-lived certificate that provides the actual workload, the carbon, essentially, its own identity. Now, to communicate, right, and to start authorizing, can Service A talk to Service B or can a requester actually get data from this service, right? A couple other things need to happen. One, we've got this OIDC framework, and we've got this OAuth framework that need to be interspersed, right? So OIDC, that's how the user's going to authenticate. We'll just say the user's a requester in this instance. So I go and I authenticate my user, I get an OIDC token, I take my SFID token coming from my Spiffy identifier from the service. Now, I use that and correlate that SFID token with an OAuth client identity, because more often than not, I'm actually going to speak over an API. So once I do that, now I have a correlated Spiffy identifier, SFID certificate, and I have an OAuth client ID that my service now has access to. So as a user, I can take another OAuth client that's on my device or make an API call with it, that then gets passed through to that service, they can mutually authenticate each other, strong authentication, and I can start applying authorization policies. Now, authorization also looks very different than it did a few years ago. It used to be we're only concerned about what's happening inside of our network, right? We pretended we had this great strong perimeter, and everything inside the perimeter was okay. Now as I moved to distributed services, that perimeter actually moves right to the edge of the API or the edge of the service itself. So authorization needs to be not just can service A talk to service B, and not just what can user X do within that service, or what does that service look like to that user, but also with privacy consent, it has to look at what can this service know about the user, and what can that service share about the user. So we've gotten a much richer set of requirements, as well as a much richer set of tools that when they all work together, right, can accomplish this in a very automated, seamless manner, and then wrap a rich layer of governance around it. However, like if you're just on day one, you got to start somewhere, and you have to say, I'm going to start with giving my workloads identity. Hence, let's I'm going to start using spiffy and using things that are out of the box, you know, within things like Istio. And then I'm going to carry that forward and tie it together with my OAuth. And then I carry that forward and tie it together with my existing IDPs and use an IDC. And then I'm going to start protecting that data based upon authorization policies that are aware of the context of the service, meaning, is it passive financial data? Is it regulated data? Is it privacy data? And then perform authorization policies right on top. So it all has to work together in a very cohesive manner. And we do now have the tools, right, available to us to start building these options. However, we have not, most companies have not actually started that path, you know, in a rich manner. We'll do it for a project or two, but they certainly haven't done it, you know, at a cloud center of excellence or an API architecture point of view. Thank you, Nathan. So Craig, I have a follow up question for you. So this is a great architecture, but how does Istio fit into this, right? And what value does Istio provide in addition to provide greater zero trust model? Is that to Greg or Craig? I'm sorry. Craig. Oh, yes. So, no, I appreciate it. And I think we dove in really well here and it kind of goes into how do you deal with, you know, zero trusts across containers and other things, right? How does, how does Istio fit in? Like Istio becomes your control point, right? Or your policy enforcement mechanism. So taking, taking these various pieces, um, and then enforcing that policy, um, you know, now the big thing is how do you then, the governance around that, right? That, that the same as when we're managing firewalls and everything, right? Because now identity has become the new firewall, right? We've heard and so managing, you know, Istio policies and others in much the similar ways you're managing firewall policies, making sure that you're going through the approval process and you're understanding what's opened, um, you know, up with those new policies and rules. Yeah, my concern would be, um, the dynamic nature and the volume of transactions, right? And whether Istio is able to, um, keep the scale up, right? For all the dynamic interactions that services need to have or predefined policies that you can set the Istio mesh with and then, you know, what transactions are going to communicate through those channels and vests, you can use side cut proxies. Does that make sense? Yeah, and I agree that, uh, you know, I can't speak to the level of robustness of that, but certainly have those same concerns as we scale it out. And maybe Nathan has a little more experience or Greg, in scaling that out versus kind of like you were talking about, Nathan, just kind of a POC, you're a small, small scale deployment. Yeah, I'm just curious, Greg or Nathan, do you have any opinion on that, that you'd like to share? Well, yeah, yeah, so it's definitely scaling out and, and scaling out in very big ways, meaning tens of thousands, hundreds of thousands of transactions per second as well as tens of thousands of containers, right? And so what's happening, right, is obviously all that's not in a singular Istio cluster or in a singular Istio service, a single Kubernetes cluster, a singular Istio service mesh, right? So you have to start federating, which is part of the, the more recent SVID work, I'm sorry, spiffy work, federating in between your different, you know, Kubernetes clusters or Istio service meshes, right, to start to share that data. However, by, by up-leveling it kind of one notch and saying, okay, it's going to be API communication, or at least, let's start identifying it with API communication and tie in OAuth, right? We've seen OAuth scale massively already, and being able to start to incorporate that as the defining body for delegated authorization, you know, can the services talk to each other, what data can the services see, as well as now with the latest grant spec within OAuth, you're able to start tying together rich policy with how data is being released and how services are communicating. So we have the frameworks there. We have seen it scale up to millions of services, even with, you know, even more users accessing it. However, now it needs to start moving into how can it be, you know, better product ties and how can it move into production faster and be adopted faster by more companies, which is to your point. Thank you very much. I think we are at time. We have to leave some time for questions and answers too. I want to thank you all for this discussion today. Thank you all. Have a good day. Thank you. Thank you.