Hi, my name is Steve Judd, I'm chief architect at Jetstack. We're part of Venafi, who are a cybersecurity company, and we in jetstack provide customers with cloud native Kubernetes professional services, and quite frequently that involves security, implementing security best practices. And often as a result of this, I find myself having conversations with security teams about the best approaches they can take in order to implement security best practices such as zero trust within Kubernetes environments. And what this talk is all about is really zero trust. What it is, the principles behind it, the challenges and what kind of tools are available to be able to deploy these into Kubernetes, clusters and environments. So first of all, I want to go through a definition from Forrester about what zero trust really is. So it starts with an information security model that denies access to applications and data by default. So essentially default deny any request. So it continues with threat prevention is achieved by granting access only to networks and workloads utilizing policies. So essentially there will be some policies that define exactly who and what can access or a particular resource or execute a particular API. And exactly how to determine whether the request meets the sort of policy requirements is informed by this contextual risk based verification across users or their devices. So essentially any request that comes in, whether it comes from a user, whether it comes from a device, whether it comes from a service, you need to identify who that service or that user is, what permissions they've got, in effect, whether they're allowed to actually access that resource or execute that API. To sum up then in a bit more of a concise manner, never trust, always verify every single time. So that's kind of a brief, this is what zero trust is all about. But let's talk a bit more about, well, what are the key principles that underpin zero trust. So first off we've got the principle of least privilege, and essentially that's saying you should only give the requester the access they need to execute the request that they're trying to make. So as an example, don't give everyone cluster admin access to your Kubernetes clusters, because for sure they don't need it. Secondly, for each request that's made, you need to establish the identity of the requester and establish what permissions they have against that particular resource or API that they're trying to execute. And this has to be done on a per request basis. So as you can tell, identity is quite a key component of zero trust. So this isn't talking about just users identity it's also talking about identities for machines, machines being servers, virtual machines, IoT devices and so on. And typically we do this with X 509 certificates. And then finally, it's not enough to establish the identity of the requester and figure out whether they've got the right permissions. You also need to start looking at the context within which they're making this request. So, for example, what location is this request coming from? And is it usual for that identity? So in the case of a user that's based in the United Kingdom, would you expect them to be making a request from, say, Russia? So that's what I mean by a context based decision as well. So essentially, all of these principles are designed so that if a malicious actor does manage to gain access to one of your servers, for example, then it will prevent them from being able to explore other parts of your network, other servers or other devices and so on. So that's what I mean by what we mean by lateral movement within the network. Okay, so we've talked about what zero trust is, and we've talked about the principles that underpin it. Well, inevitably there are challenges with introducing a zero trust approach into any environment. So what I'm going to do is spend a few minutes talking about exactly what those challenges are within a kind of cloud native Kubernetes world. So first of all, machines are in a network, and by this I mean servers, devices, services, workloads, pods, jobs, they're increasing at an exponentially rapid rate. And given that all of these need a unique identity based on an X 509 certificate, then it's really not practical to do this manually because we're looking at issuing certificates, renewing them, revoking them and so on. So really you need some kind of tool to help you with this. As an example, venify, provide a tool called TPP, specifically designed for managing expo VI, nine certificates. Secondly, access control. So how do you define this? At what level? How do you update it? How do you enforce it? Thirdly, we've got this idea of shift left security, which is where you move towards the development team, more responsibility for implementing security practices. And genuinely, it's a good idea, but development teams and other teams have got competing priorities. So kind of how do you get some traction with this? How do you actually achieve this? And then finally you've got the whole governance and oversight aspect. So who's responsible for defining these policies, making sure that they're implemented and enforced? So now that we've kind of talked around zero trust, its benefits, and also the challenges that you're going to face when trying to implement it. How do we actually go about solving these in a containerized world? And really what I'm talking about is within your Kubernetes environments. So first of all, Kubernetes comes up with or has a bunch of native features that will help with this zero trust approach. First of all, it has role based access control, which can be incredibly granular and really allow you to very tightly specify exactly what a workload can do within a cluster. Secondly, if you've got the right CNI driver, then you can take advantage of network policies and these will allow you to define what pod can talk to, what other pods on what ports. So as I said, something that many CNI drivers implement, but not all of them. And then finally you have pod security. So that allows you to define within your pod, manifest the constraints within which the containers in that pod have to run. And then as part of that you have a pod security admission controller which is in charge of enforcing those policies. So basically if your pod manifest doesn't contain the right constraints, then this admission controller will prevent that pod from even being deployed into your Kubernetes cluster. So as well as the native features within Kubernetes itself, there are a whole bunch of add ons which also provide a whole bunch of additional security related features. So I'm going to go through three of the most important here. So first of all, you've got Cert manager, which probably many of you are aware is basically the de facto tool for managing x 509 certificates within a Kubernetes cluster. Then you have a variety of service mesh tools out there such as Linkerd and istio. They provide out of the box services like mutual tls between workloads in your cluster. And they provide things like traffic policies so you can enhance, if you like, your network policies to determine exactly where traffic can go and under what circumstances. And then finally we've got these policy based admission controllers like Kiverno and Gatekeeper, and they allow you to specify very sophisticated security policies that all your deployments, your pods, your workloads have to adhere to. Otherwise these admission controllers will deny access to these pods being deployed. So that's great. We've now covered a whole bunch of features and tools within Kubernetes that will help with zero trust. But exactly where then does this shift left security fit into this? Well, here's the thing. Security teams deeply understand what security policies need to be introduced, what they look like, but they aren't necessarily the right people for actually implementing those policies because they probably don't have the right expertise in terms of Kubernetes knowledge. And there are probably better teams, let's say, who will be better placed to do this implementation work. And I'm kind of specifically thinking about the platform engineers and the reason for this is that, well they already have the Kubernetes expertise and they have the know how in kind of automating everything that goes on in your Kubernetes world. And then finally they already are deeply familiar with the tools that are being run in their Kubernetes clusters and the tools that they probably want to run like Istio or Linkerd or cert manager. So really what I'm trying to say here is that although the onus is on the security teams to kind of take the lead and define the policies, it's really the platform engineers folk that are going to be the ones responsible for implementing and probably enforcing these policies. So what I'm trying to say here is the platform teams and the security teams absolutely need to collaborate on ensuring that zero trust approaches can be adopted within Kubernetes clusters. So that really is the end of my talk, so I hope you found it informative and enjoy the rest of the conference.