 Thanks for joining me from San Francisco today. I'm on a Zoom. I wish I was in a room, but here we are. And I appreciate any feedback and some of these ideas and just starting to scratch them down. And hopefully we'll both have a good time kicking this around. So hit me on Twitter. I'm at Waters James. If you watch this, let me know you saw it. Let me know what you think. Thanks so much. We'll keep it fun like that. Next slide here. So everywhere I go over Zoom today, I'm running into more and more teams that consider themselves essentially the platform teams of these organizations. So they're not pure infrastructure teams. And they're not, you know, if you were pure application teams, their reason for being is that they're connecting developers to infrastructure in a secure pipeline, typically using Kubernetes as the final infrastructure API. And I'm seeing, you know, a convergence in enterprises at least where security has always been a paramount value. Essentially, you know, the definition of an enterprise is you become an institution. And the first job of an institution is survivability, sustainability in some sense. And so this focus on DevSecOps has been really strong in these platform teams. And I'd say about 60% of the organizations I meet, there's now someone carrying a director of DevSecOps title. So in some ways that's a new and exciting thing. And I think it reflects that organizational patterns have changed. Our security culture and methods are evolving to meet modern applications. We want the continuous delivery of features. We want to be able to respond to a user need in days or under a week versus on a more waterfall six month, three month, two month schedule. And we'd like to see those changes, you know, make their way to production for feedback to the developers as rapidly as possible. I'm going to talk a little bit about how I think security as part of DevSecOps is really just coming along for that ride and how in the same way that as an organization wants to get a feature to production as fast as possible. If there's a vulnerability discovered somewhere in the world, as opposed to there being meetings about it, I think our modern cloud native software systems need to be responsive. And almost at the moment of that event of that vulnerability occurring, start to kick off a series of processes and control a reconciler patterns that bring it to production as rapidly as possible. So this is a time of great adaptation to this era of microservices, continuous delivery, containerization. And there's a ever-growing focus on concepts of things like zero trust. Now that we've got these distributed microservices and you're suddenly adding all of this networking into the core business logic of an application. Well, how do we build our application level networks? Before a Java program, 1200 functions running in one JVM, you understood the privilege model of that application because it was all inherently one application, but now you've introduced networking. And so the idea of the zero trust, heavily identity-centric network has come into play. And in some ways that feels like a new fresh take on how we should do networking. But in some sense, I think that's also not true. And we've been on this trend of least privilege for a long time. In fact, if you go back to, you know, ACM journals in the early 70s, there were people articulating this idea of least privilege then. The idea that every program and every privileged user of the system should operate the least amount of privilege necessary to complete the job. And I think while in some sense, the internet was really not about least privilege because the internet was built for collaboration and sharing like HTTP, SMTP. These were protocols really meant to say, here's some content I want to share with you. And that's a great quote from the woman who founded Ubiqui where she said, hey, we're now trying to retrofit, you know, kind of identity and access management and controls into an organization, into a series of protocols built for sharing a collaboration first. But if you think of the cloud really as a modern at scale continuously delivered model of what the mainframe really was providing in the 70s, this articulation of least privilege starts to make sense. And you can start to look at some of the zero trust networking DevSecOps, a lot of these modern security practices as bringing cloud computing back into that era of design. And I think as I think back over the last 10 years that I've worked in computing, I've always seen security and especially designs of enterprise systems that favor least privilege to be highly attractive. And I like to think about this quote from Jeff Bezos where he basically articulates that everyone talks about what will change over the next 10 years. But what you can really build on is what won't change. And I think as I think over the last 10 years that I've been working on cloud native systems, the idea of least privilege and high security has been something I consistently bet on and our organization has consistently bet on successfully. We took, you know, I'll articulate it more. We took one bank from, you know, on average a six month wait for patching of their core systems and platforms. So about an every three day pace because we made it a first class object of the system they were using of the platform they were using. And they were so excited about it. The CIO is excited about it. Everyone was excited about it. And someone asked me once they said, well, you know how did you know to design for security? How did you know to make security a focus of that microservices platform? And actually it was pretty inarticulated at the time. It was almost like a fish in water. I had been so close to enterprises that always favored this model that I wasn't able to be crisp about why. But I think this idea of least privilege coming to cloud native is an important articulation of why enterprises really want to bet on this for the next 10 years as well. And what we saw with the first generation of our cloud native designs was that we were able to articulate and expose the right set of interfaces such that we achieve what we called at the time the three Rs. And those are still really important, I think for the cloud native community design around. I'll give you an example of the three Rs in terms of repair. If a CVE came out, we would automatically do a rolling update of that system. So one note at a time would be replaced declaratively, a manifest would inspect version one versus version two, see the diff and apply the diff. And we did that the entire way from the operating system up to some of the application runtime vulnerability. So anytime a repair event hit the system, it would be replaced. We would as part of that repair also recreate those immutable images from scratch. And so organizations were much more comfortable that the platform they were consuming was free of malware because we were always rebuilding from sign source. And people as high up as CIOs and major banking organizations now swear by this repaving model where they're like, every week we rebuild every note in the system. And I think this is a really important part of it of modern application platform security designs. We'd also build as much as possible of the controls right into the standard developer experience. So as you went to execute a pipeline, say 10 out of 12 controls were embedded in the process already. So while the developer might be responsible for ensuring some of the controls were still met, a lot of them were automated and part of the developer experience. And finally, if anyone who's seen some of the post mortem on the Equifax study knows that letting secret space credentials languish in the system or be exposed in plain text or persist is a really dangerous thing. A lot of the exploits we see come down to the acquisition and exploitation and privilege and escalation of these credentials. So we really, you know, fashioned our platform after idea that constantly anytime a node would be touched you could rotate the credentials. So these were the three Rs. And there was incredible demand almost that Jeff Bezos like limitless demand to go as fast as possible in those three Rs. Just like an Amazon customer would rather have everything they order as a consumer to be cheaper and sooner. Enterprises really liked this model of lease privilege in terms of what any node in the system, how long it persisted, how long it kept credentials and how long it went without being updated and how compliant the pipeline was by default. And I think if we apply some of those Gen 1 platform designs to our modern systems that we're building now as a next generation in Tanzu I think of the checklist sort of like this and a baseline of course, immutability and manifest based deployments so that governance and controls are very clear and explicit. So that's a baseline, but I don't think it's enough. I really think this trend towards a high more highly ephemeral system is part of modern lease privilege. I think time has entered out as a dimension of how long something should even exist is almost in a sense part of the metaphor of privilege. The shorter something is available the less time anyone tried to exploit it could exercise its privilege. And so the idea that nodes should be rebuilt constantly replicated from sort of a sign source model of the original intention is important. The identity of that short-lived node is also important. And I think in Tanzu we're tilting away from this idea of the shared secrets sort of like the aftermarket secrets model versus more of an inherent strong ephemeral identity baked into the platform with things like Spiffy Inspire. I'm very excited about some of the demonstrations I've seen where more of an event driven vulnerability management I'll talk a little bit about build packs but as a vulnerability is found the build pipeline is automatically updated in some cases the application is automatically updated to remove that vulnerability. So ideally just like that Jeff Bezos statement we should be converging to zero time between vulnerability discovery and vulnerability patching in the system if possible. Enterprises are always going to want a shorter and shorter time between the discovery of a vulnerability and the replacement of it in a safe way. And finally one of the biggest things we've seen is this merge of DevX and control is super powerful. So by paving the path for developers by giving them a set of conditions by which they can get code to production quickly that also meet compliance and security needs. It's an incredible one plus one equals five. So these are some of I think the modern principles of least privilege that I'm going to keep riffing on and looking to encourage all of our teams building Tanzu around. Let me give you some examples of where I think this is going to take off and I'll close with that. I'm super excited about the ephemeral node model of Knative that scales to zero because as you start to articulate an application as more of the serverless model where you've got an API or a route and then you've got a series of revisions and you can constantly restart that node based off of traffic. Well, that gives us the opportunity to refresh the node to make it more ephemeral to make sure that its identity is short-lived. So I think building applications that fit the serverless Knative model first when possible is super exciting. And we're looking to bring a modern DevX the whole way to this Knative model. And I think this application pattern this modern microservices pattern mixed with modern security practices together is super powerful because it allows that three hours model of security to come into the next generation of platform designs. And we can start to say shorter and shorter time to lives for all of the nodes, identities, secrets, access, et cetera on the platform. We're also going to bring a modern software supply chain to the Knative experience. So the tons of build service and the modern software supply chain we're building with it. Let me just give you a quick highlight of why I think that's so important. By default, a developer should not have to craft a Python microservice or a Java microservices Docker file. In a sense, that's a real violation of least privilege instead of just having the application to be deriving the Docker image through the build service the build service runs a process in a build pack called detect compile. It detects what's in the application what it needs and it compiles in a safe and secure way that's constantly updated for vulnerabilities a fresh image and runs that in the Docker registry of your choice to me that's right on this idea of least privilege is that we're converging more and more on throughout the DevSecOps pipeline by reducing the privilege of the developer themselves. She no longer is crafting her own custom Docker image and the vulnerabilities are automatically updated. I think that fits that modern model of least privilege at DevSecOps. So it's super exciting and we're seeing people almost debate what build service is. Is it a security layer or is it a DevX layer? Is it a speed layer? We have some organizations calling it all three and all three are right. And that's that magic convergence of developer experience and controls that I think are made possible through this new serverless model of applications and platforms. We want to bring that same OS patching speed and alacrity in a declarative fashion that we had in generation one platform designs to Tanzu and to our next generation of systems. And so we're working with some of those same customers that did that continuous rebuild of their operating system to bring OS management and OS update to cluster API. So now we've got the Kubernetes native cluster API way of articulating configurations. We've got that declared to config. The OS is just baked into it. So as the IaaS rolls a node you're rolling the OS and building the event and alerting model around when that OS needs updated and patched right into our platform is an important part of this modern security posture. So imagine the one plus one here of a K native style serverless application and then a cluster API managed OS. Anytime that you want to update that OS your application is always ready for a restart because it's inherently scale out, scale to zero. So applying these updates becomes really intuitive and proven operational model for the platform team. So that DevSecOps team can say if there's a vulnerability in either the application in the build pack or in the OS and in Kubernetes between cluster API and the build pack model we're going to patch that and update that immediately. And I think we'll see that same convergence to as the event happens, it can be updated. And I think that's really this long standing demand in the market for more and more security over time. It's never fast enough. Really quickly touching on this there's some things that aren't custom applications for things that aren't custom applications for things that are packaged open source. We have a secure pipeline that builds something called the Tanzu application catalog to give you proven proof of testing open source deployed to production with confidence. We have so many people are saying, Oh, we used to go out and just grab any open source off the web, compile it ourselves. We're now trusting this proven software supply chain from the Tanzu application catalog to surround our custom applications with that code. The last thing then though is that, you know these microservices running in containers or apps often apps. And so we're building into the spring framework more and more out of the box, DevX around security. And I won't cover it all today but I'll give you a quick preview of where we're headed there. If you think about that K native serverless application it starts to expose an API and you really want to mix the best of API management and microservices management. And in the past, we saw that there were separate teams one that was running the application another was running the API security team. And if you wanted, you know strong authentication rate limiting, routing or security controls on that application say anomaly detection of the application and API behavior you had to have one team separate from the other. So we're doing two things there. We think this lease privilege also applies to the applications models as well. We think that every microservices should have full API security both in terms of a micro gateway to protect it from DDoS attacks with rate limiting should have strong OIDC integration for authentication. And then we're taking that even further than just the spring gateway itself and we made an acquisition of a company called mesh seven and now we're starting to take what used to be the exclusive capabilities of these API security gateways and we're bringing that into the Envoy ecosystem into the cloud native ecosystem. And we're saying with the extensible Envoy model could we bring an overtime potentially even wasm compatible ecosystem of security and observability features to every Envoy such that every microservice can be protected as it's created within Kubernetes as opposed to that being a separate job of an API only team. And I'll just close with this example of why I think that's another, you know the endless demand for security within enterprises always bringing that closer to that DevSecOps model. We've talked to some organizations where they might have 2000 APIs but only 800 of them formally protected by their API management team. And the reason was is that that API management team wasn't as close to the SDLC to container management to that DevSecOps pipeline team. But now with mesh seven and the spring gateway we think we can bring all of the security and control and observability of those enterprise API management tools to every microservice. And what's a microservice? What's an API? They have the superpowers of each other immediately. So you can deploy with the speed of microservices and the security and control of an API all in one. So we're really excited about kind of that roadmap bringing this least privilege, this endless demand that enterprises want to be more and more secure every day to every application. So that's a little bit of my current thinking. You know, I'm pretty excited about looking to bring that model to our modern application platforms on Kubernetes. And I think it's an extension really of a trend we've seen for a long, long time but we're bringing to this distributed application model. So it's an exciting time to work on distributed applications container applications as we start to bring some of the security we might have had to consolidated monoliths and to consolidated systems to our distributed systems. So thanks for listening in on the talk. Throw me a tweet if any of this makes sense or is thought provoking. I'd like to continue to work on this kind of least privilege for distributed applications model together. Thanks so much.