 And I'm just bringing up the meeting notes. We have, since I've been in flight with no Wi-Fi, I haven't been able to check, but I saw a Slack notice that we have a email group now that is set up by the CNCF. So you all should have gotten an invite if you're on the calendar. If not, we will add it as soon as I can figure everything out. Did anybody see anything about that? I think I see it in my calendar now. So I think it's, I guess it's a good indication. I didn't get a notification about it though. I just popped up. Okay. Does anybody want to volunteer to take notes today? It would be great to have a couple of scribes. I do it. Thank you. Here we go. Oh, and do we have a second? And just the notes are attached to the calendar invite. I'll drop them in the chat. And so you can just add, who said I'll do it? I was not looking at the window. Lorenzo. Lorenzo, thank you. So, yeah, as you can just dive in there and add, I'll add you as a scribe. Oh, I was writing in our other documents. Great. So let's, I don't think we, so let's just start. We'll do a little stand up. See if we end up with Dan and JJ joining us. And then chat about the, then we'll have the presentation from Opa. So I'll just call on people in the order that I see them. In the Zoom, Roger, we want to introduce yourself and say what you want to do. Sure. So I'm product manager for SusaCast platform and container Kubernetes and originally specifically container security, but it kind of grew into the whole platform at Susa. And I've been working on getting a release out and getting audits and benchmarks into the release process, but not, but which has torn me away from the community for a couple of months, but I'm back. Yay. Thank you, Roger. Ash. I've just been working on OpaTalk for next week's CubeCon and for today's presentation. So that's pretty much what I've been doing. Great. Brandon. Yeah, so pretty much also looking at the stuff for the OpaReview, I think Ash's documents were helpful for the business as usual. We're still trying to, the encrypted containers work forward with hopefully pushing up the OCI. The OCI? Yeah. OCI? The OCI and Mitch back. Great. Maybe you could drop a link to that for people who don't know about it. I'm also kind of curious, how is the OCI also considered policy and CF or is it? No, OCI is a separate, the next foundation, foundation, which I think actually predates CNCF and there was an attempt and it was originally designed as a standards organization, only though it's slightly weird because it owns the RunC implementation as well. There was an attempt to merge it into CNCF but it about last year, but it failed for legal complication reasons, come pre-starring out of town, so you couldn't do it. But it's fairly strongly affiliated with CNCF in that sense. And so what have you been doing with OCI, Brandon? I just put a link to the, it's the open containers initiative, right? Yeah, we opened the PR too. So this is something that I've been working on just in the comic as well. It's around the encrypted containers. We talked about this at DockerCon. So we are modifying the OCI spec to allow specification for encryption. And part of that is trying to push it to the standard quality. Great. The next is Dan. Hey. You made it. So, for the foremost apologies for running a little bit late this morning. Getting together with the team and sort of aligning and making sure we get the last six security stuff set up. I noticed as I was doing some internal bookkeeping that some of our active members didn't get onto the meeting invite. So I tried to sort of coax everybody over and looks like Mark Bennett and Cheney. So great to see everybody. And I hope everyone now has the new time updated on their calendar. One decision that point that we did come up with was to continue with weekly. I tried to sort of merge the streams of having our working sessions on Thursdays and the meeting on Fridays into bi-weekly meetings where we do our working session one week and our meetings on another week. And I think it was just moving too many dials. So having our weekly consistency in this meeting at our new time, I think will be the best strategy for the near future. Great. Thanks, Dan. Also, Dan and Brandon reviewed our charter. So I'll link that in. Cheney, if I'm saying your name right. Yeah, that's how you pronounce my name, Cheney. I'm working on for Fifth Third Bank, which is a regional Midwest Bank, just driving them to the cloud were primarily on OpenShift and looking at GKE on Google Cloud. So just a lot of things related to hybrid cloud and securing our communication between having OpenShift clusters in our data centers and on AWS right now. Great. Christian. Hey, sorry, I haven't been participating for a while. I was super busy. So one of the things that I have been starting to think about is, and that may actually be interesting for Cheney, we think that there is a new persona, which we kind of call the platform team that has been discussion internally here at Google. So a lot of the large customers that are looking at hybrid have a team that is responsible for making sure that all the policies they would like to express are available at all those different deployment platforms. And I don't think that is a persona we had on our radar so far, right? We mostly cater to the people that come after that, the people that then use and set those policies, but what do those poor platform people do that get tasked with their bank accounts and they say, make sure all the deployment options we have allow us to stay compliant. So I'm not sure if we want to extend the personas we look for, but I think there is a distinct thing that is the platform team and maybe Cheney can comment on that because it sounds to me like he is part of one of those. Yeah, no, I think that you're spot on that is kind of an emerging persona that we're seeing as well. There's a lot of questions, especially, well, from what I'm seeing hybrid cloud is really just getting more and more unified from my perspective at where I'm at. And so it's kind of setting groups up differently than past places that I've been in terms of a shift of who's your customer and how you need to pay attention to them. Yeah, because your customer is then the administrator, right? The customer of the platform team are the different administrators that you have. But if you say that things are more, sorry, I'm taking over the conversation here. We should maybe make that a separate point of discussion at some point. But a quick thing, do we, if you say that things are harmonized, are you harmonizing at the CNCF level? So essentially everything you can express in Kubernetes policies, is that good enough for your platform? I mean, that definitely is a good place to start. I mean, I think it's good enough right now. I'm always trying to push forward at what's going to be the next level. That's definitely what we're pursuing right now, though. All right. Christian, would you volunteer? Because we do have an agenda. For today, would you volunteer to make an issue that describes this? It might fall under the operator bucket, or maybe it's another one, but just write some narrative about it. And then we can start. No, that sounds like the right way to go about this. Yeah. This is Michael Ducey. So I agree with what you're seeing, Christian. And so once you open that issue, I'll add my color to it as well. But we see this a lot as well. Out there in our customer accounts. Great. All right. So then we have Howard. Hey, Howard from Huawei. Half wake, half asleep in China. I'm focusing on the policy. So I'm the go-to guy. If you guys have the like similar problems, just, just mentioned by Christian. Yeah. Happy to participate today. Great. And Howard's also agreed to join. Justin Kapos in the deep dive presentation next week. Thanks, Howard. No problem. All right. I have lost everybody. They've changed order. Justin Kapos. Maybe people come in in alphabetical order. I don't know. So I've been busy with kind of both sides of assessment work. Asking a lot of questions. And some of them, and I think in a very Colombo, Esquire, so a lot of dumb questions. And then just kind of, oh, one more thing, one more thing. And also been chatting with you and Justin Cormack. Thank you for getting the in-toto assessment things together. That's been helpful from our side. So we've been working on that at angle. Great. Justin Cormack. Yeah. So I was working on the in-toto assessment. With Sarah. And also the, you know, And then Mark underwood. Oh, wait a skip Lorenzo. Lorenzo. Well, I'm new here. So, I work on. I'm like, seems like short weeks. I was working on the initial assessment with Sarah. And also the one. And then Mark. Underwood. Oh, wait, I skipped Lorenzo. I've been thinking over as an entertainer, so I will be talking about that probably more. And we just released 0.15 that support for container D and fixes a bunch of security issues on FAP itself. So that's my update for now, and we'll figure out what I have to say here. Next meetings. We were discussing the other day about whether we should take a look at file care as one of the projects that we examine from our point of view. Hang on. So did you say you'd be interested in that, Lorenzo? Yeah, that's what he said, sorry. That's actually why Lorenzo's on the call. So I actually saw Dan had shared out the meeting minutes today, and I went in and looked at the meeting minutes and saw the mention about FALCO. And so I feel like the charters kind of changed from when we were safe into security now. And so Lorenzo is on the same team as me at SISTIC as well as another engineer, and we're all dedicated to the FALCO project and how we can make it successful within the CNCS. So whatever you want to do around that security assessment, yeah, the assessment, we'd be happy to help and kind of continue our participation in this group. Awesome, thanks, Michael. Yeah, so I think that we, in becoming SISTIC security, the goal, it happened to coincide with a burst of effort around the security assessments. But at least from my perspective was not intended to completely shift our focus to security. And we are still have a big policy focus. It's just a little quieter now while we're getting these assessments together. But Howard and a bunch of other people have been working on a policy white paper, and we have a whole lot of other aspects of the group. So I really appreciate you coming because our security assessment team is working on developing processes and OPA is going through, is the first to formally go through this process that we have just defined by doing the INTOTO assessment to kind of create the process. So good timing and we're very excited to have FALCO kind of help us through this and be able to come up with artifacts that we hope will be very useful for the cloud native community in assessing the security of dependencies and deciding which systems to use in securing their cloud native systems. So Chase, Pettit. It's by some urgent work stuff at the moment. Oh. Half of me. Do we need to come back to you? We just, I was going through the list for check-ins. You can skip me and I'll speak up to you in time. Thank you. All right, okay. Mark, Mark, are you here? Able to speak up? We're not hearing you, or I'm not hearing you. Oh, you may need to push star six, Mark. I saw the mute going on. How about now? Yes. Yay. Okay, hi everybody. Hey, sorry. Yeah, so those of you who haven't heard from me before, I'm kind of quasi-representing some of the activities at NIST and some of IEEE related groups and in particular the virtualized NVF community where it's time to chair. Nothing really new to report though in this cycle, so I'll mainly be listening. Great, thanks, Mark. Who do I miss? Robert. Hi, I knew nothing too specific to report this week. Okay, and Michael, do you see you introduced yourself a little bit, but did you wanna check in about anything that's new? Sure. So just been really focused on, we've seen a few users create use cases around building client Kubernetes clusters and using Falco and a few other pieces of open source software to basically build a product offering around that. Right now they're kind of, and so we're trying to kind of look at how we can actually start to take that and put it into product clusters, whether it be HIPAA or PCI or whatever guidelines that they need to try it. Great. And is there anybody, oh, TK. Oh, yes. I was actually playing around a little bit on the security white paper. I'm still assuming that that should be still on the agenda at some point. I have not done too, I have not uploaded anything, but I kind of started playing around a little bit draft and extending some of the things that are already there. That's about it. I don't have anything else to report right now. Yeah, the security white paper is definitely something that is often asked about. And I think that we started a draft a while back and as soon as we finished the logistics with the SIG process, then we'll re-engage with the writer who's gonna help us kind of draft and do the editorial around that. But yeah, whatever anybody wants to chime in on the Google Doc, it's linked from an issue that'd be fabulous. So I'm glad you're thinking about that, TK. Okay. So if we have something new, should we upload that one or should it, how do we handle that? So there's a, well, I think there's a Google Doc and I think adding to that. Adding means, yeah, adding means what I was thinking whether I should, that is a second version. You want to keep the old record or how? I mean, I'm not sure exactly. Well, I think we have version history. Okay. Although, I mean, I think that like, if there's, did you have another thought about additional content? No, I was thinking like, if I'm editing offline and extending that thing and so forth and I don't want to retype, obviously, so certainly on the Google Doc again, I'll just upload it. And just for the record purpose, if you want to keep previous version somehow or something like that, then we may have to have some sort of way of maintaining that without confusing people. So I think that we, I think we can do that with version control. If there's some things that you think are, I mean, I think doing things with suggested edits and then we'll try to like merge things that are not contentious or a great debate and, you know, or you could add another section if you feel like it's really a different approach. But I think keeping it in one doc will be easier for people to scrub in on. Okay, I'll look into it, thanks. Great, thank you. All right. So now I want to switch gears and give Ash the floor so that we have time for his presentation and the discussion. Unless I missed anybody. I think, okay. Should I share my screen? Yes, please. And do you have actually a link to your slides? Not right now. Okay, we'll do that afterwards. I'll put a link to the doc in the notes, but if you share your screen, that'd be fabulous. Can you guys see the screen? Yes. Yes. Oh, and also for the new people here, if you go to the SIG Security repo in CNCF, there's a process, we're following a process where a group of us, and it was open to the whole SIG to read, you know, Ash prepared a document. Justin, who's leading this assessment, Justin Capos went through and asked a lot of like, you know, sort of quote dumb questions of clarifying questions. And then offline, we each read and thought about the security implications. And then the idea that this presentation kind of cues up a discussion about the security implications of OPA. All right, take it away, Ash. Okay, cool. So I'm Ash Nargar. I'm a software engineer at Styra, and I'm a core contributor to the Open Policy Agent Project. And so today we want to make it easy to enforce fine-grain authorization in your systems. So let's get started. In this talk, I'll cover a bit about OPA's community, a background about policy, introduce the Open Policy Agent, talk about its features, integrations, use cases, and then we'll see a demo on Kubernetes Admission Control, and finally a security analysis of OPA. So the project was started in 2016 at Styra, and the goal of the project has been to unify policy enforcement across the stack. One of the earliest adopters of OPA was Netflix, and they use OPA for AP authorization for their HTTP and GRPC APIs. A company like Medallia uses OPA for risk management in Terraform, and there are more than 20 companies using OPA in production for use cases such as Admission Control, authorization, data protection, data filtering, and so on. A little more about the project itself, it's a CNCF project. We have around 59 contributors on Git. We have a healthy Slack community of more than 800 members, and just to give you some context, at the beginning of the year, we had around 400 members on Slack, and so it's great to see OPA growing and people liking OPA, and which is why we have more than 2000 stars on GitHub for the project. And OPA is integrated with more than 20 of the top most open source projects out there, including a lot of CNCF projects, which we will cover later in the discussion. So what is policy? Policy is a set of rules that govern the behavior of your service. So an example would be authorization policies, network policies, and so on. Every organization has policies, and policies are essential for the long-term success of an organization because they encode important knowledge about how to comply with legal requirements, work within technical constraints, avoid repeating mistakes, and so on. And so policy enforcement becomes a really important problem for which we need to have a good solution. So when it comes to policy enforcement, a lot of companies will write down their policies in docs, in wikis, and hope that the policies get enforced. Or if you have a policy question, you will ask somebody in the company, and that person makes a conflict change to secure your system. Some companies even hard-code their policies in software. And this not only makes the policies difficult to understand because they are so tightly coupled with the underlying system, but it also adds to cost. Because now, whenever a policy changes, a new version of the software needs to be released. So there are multiple policy solutions out there, but they lack the expressiveness that is needed to say what you want in your policies. Many are domain-specific and do not provide access to context or data that is needed to make a policy decision. Sometimes you want to know more than just an allow or deny or through a false, a bullion decision. You may want to know which users are allowed or which fields can be displayed. Also, the policy languages in these solutions are not very sophisticated. They do not give you the ability to write functions, rules that can be reused inside your policy code base. So what we see currently is that the underlying system is tightly coupled to the policy decision-making and the policy enforcement process. And this is bad because it makes it difficult to audit policies, modify policies, and makes it difficult to gain visibility of policy throughout your system. So a better model would be to treat policy as a separate concern like databases, messaging, logging, monitoring. It would be better to think about policy as a separate component in your architecture. And if you do that, if you decouple your policy decisions from policy enforcement, you gain better visibility of policy and security throughout your system. And these are some of the problems that the open policy agent or OPPA was created to solve. So what is OPPA? OPPA is an open source general purpose policy engine. You can take OPPA and you can use it at any layer of the stack in any system. When you use OPPA, you are decoupling policy decisions from enforcement. So your services can offload policy decisions to OPPA by executing queries. So let's try to understand this a bit more using this figure. Now imagine you have a service and this can be any service. It can be your own custom service. It can be an API gateway. It can be the Kubernetes API server. It can be anything. So when this service gets an incoming request, it's going to ask OPPA whether this request is allowed or not by executing a query. And so this query can contain the request path, the request method, the request user, basically any JSON. And so OPPA is going to evaluate this query based on the policies and the data it has access to and send a decision back to your service where it gets enforced. And again, this decision can be a Boolean, like a true false, allow deny, or it can be any other JSON value. So what I need to emphasize here is that OPPA is not tied to any data model or to any domain. As long as you give it some structured data, you can write policies for HTTP APIs, for SSA, SUDO, Kafka, because to OPPA, it's all just data. Hey, Ash, I think someone's trying to ask a question. Sorry? Yeah, sorry, I don't know if my audio is garbled. So, and I just want to first make a meta statement here, which is that part of the reason, in fact, the big reason why we're having this presentation is so people can jump in and ask questions at different times. And so I want to ask a clarifying question that I know the answer to, but I don't know that, like, I don't know, maybe there are people here that don't know the answer to. So what does it mean to query OPPA in this case? Where is OPPA? Where is OPPA? Yeah, it's like, okay, so you talk about querying OPPA, but what does it mean to query OPPA? What does that actually mean from a code standpoint? Is, yeah, so go ahead. Yeah, so there are multiple deployment models for OPPA. So in this case, you can deploy OPPA, say, like a sidecar, you can deploy it as like a host-level demon, and you can do like an HTTP call to call out to OPPA and provide all this as input in your HTTP call, basically. Right, and so there'll be different security concerns and different potential risks depending on which way this happens, but there's flexibility in the OPPA model with this, which means that there's, you know, there are also like sort of different attack services depending on which of those models is used. Sure, yeah. So again, so we have a way to secure OPPA itself, which I'll get to later in the talk, but yeah, you have different deployment models and flexibility with those and different security levels as well, depending on how you're deploying OPPA. Do you have a preferred one? I mean, is there a strong recommendation? The recommendation, again, depends on your use case. Like if you're having like, if you're writing, say, go code, you can embed OPPA as a library, or if you're having like a microservice architecture, you can deploy OPPA as a sidecar inside your pod. So it again depends on the kind of use case you have and the kind of requirements you have for your specific use case, like latency requirements and stuff like that. Thanks. Should I continue? Yeah, please continue. Okay, great. So yeah, so depending on OPPA returns a decision back to your service, and so it does not matter the kind of policies you're trying to enforce as long as you give some OPPA some structured data, it's gonna make a decision for you. And that is why we say OPPA is a general purpose policy engine. Now, so let's look at some of OPPA's features. So at the core of OPPA is a high level declarative language called as Reggo. And so with Reggo, you can answer questions like can user X do operation Y on resource Z? Or which fields is a user allowed to see? So with Reggo, you can write policy decisions which are not just Boolean values like allow or deny through or false, but you can also write decisions that are collection of values. OPPA is written in Go and you can embed it as a library, you can deploy it as a sidecar as a host level demon. It's designed to be as lightweight as possible. So all the policies and the data it needs for evaluation is stored in memory. And so you can think of OPPA as a host level cache for your policy decisions. Your OPPA and your service normally run on the same machine and this is done so that you have low latency on the request path and you have high availability. Once OPPA is deployed, it does not have any dependencies for policy evaluation, which means it does not need to talk to any external service or an external database to make a policy decision. But you can however make OPPA talk to an external service for fetching policy and data, but that is completely optional. And what happens if you have a situation where there is something external and then now these things are not in the same sort of failure domain so or there's a network disconnection or something happens where they can't communicate. What do you mean like OPPA can't communicate to your external service? Yes. So in that case, OPPA is gonna just return an error on its status API and then it's up to you how you handle that. It's certainly possible configuration to say that if it doesn't see a policy of the data that's expiry on it. So do you just to keep freshness? So I didn't understand the question. Can you please repeat the question? Is there a way to specify that if you don't see an updated policy and say like a day, then you should somehow just let the current policy should not be valid any longer. Kind of just like a expiry mechanism in case you have some kind of denial or some attack on the policy bundle or server. So you're saying that if the policy bundle itself is not available, like can OPPA do something about that? Yeah, can you somehow specify to say that, you know, stop authorizing or send me an event that says that, you know, I no longer am able to get the policy, talk to the policy bundle server. So I should stop serving requests in case because my policy is not up to date anymore. Okay, so OPPA will report this via a status API and it will report it in its logs, but it won't do anything like actively to stop it from downloading the policies. So it's gonna tell the user, it's gonna that, you know, I'm having a problem connecting to your external service and now you need to do something about it. So, but it won't stop like download, it's gonna keep on trying to download policies from your server, unless you do something about it. So this is part of something like a health check that the user can monitor? Yeah, so it's the API which the user can use to check what's going on with OPPA itself, what's the status of those bundles OPPA is downloading. So it's gonna provide all that information to the user and then the user can, you know, do what they want from there using that information. Okay, all right. And so, yeah, it does not have these dependencies for evaluation, but you can always extend OPPA to talk to external services. And speaking of which, so it does provide you some management APIs to download policies and data from a remote server. It also allows you to update status logs to a remote server. The status logs include information about OPPA itself as well as the status of the bundles it has downloaded. And also it allows you to upload decision logs to a remote server. And these decision logs contain the policy that was queried, the input that was given to that policy, and the result of that policy query and much more information which you can use for debugging your policies and for offline auditing of your policies. And so finally, along with the core policy engine, OPPA provides a rich set of tooling that you can use to build, test, and debug your policies. OPPA provides a unit test framework which you can use to test your policies so that you're confident about what you're doing in the policies is what you want. It provides a trace functionality which you can use to see the steps involved in policy evaluation. And also to make it easy to author policies, OPPA provides integrations with editors like VS Code and Vim. And so just to recap, these are some of OPPA's features, a declarative language, multiple deployment models, management APIs, and a rich tooling set. So these were some of OPPA's features. Now let's look at OPPA's integration. So like I mentioned before, OPPA is integrated with more than 20 open source projects and these are some of them. One of the hottest use cases for OPPA right now is admission control in Kubernetes. And we will see a demo of this later. And so with admission control, you can enforce policies like restrict container images from coming from public repositories. So you can do policies like that with OPPA and admission control. OPPA also has an integration with Terraform in which you can unit test Terraform plans before they're actually implemented. With OPPA and Docker, you can prevent users from running insecure containers. OPPA is also integrated with service mesh projects like Envoy, Istio for API authorization. Using Linux spam and OPPA, you can have fine-grained authorization over SSH and pseudo. There's also an integration with Ceph in which you're protecting the data stored in the Ceph's object storage. In the Kafka use case, there are certain topics which have high fan out and you want to prevent corrupt data from being written on those topics because it will be read by many consumers. So with OPPA, you can authorize which users are allowed to write on such high fan out topics. One of the newer use cases for OPPA is around data filtering in which OPPA does not return a result like an allow or deny back to you, but it returns a set of conditions which can then be translated to SQL or elastic search queries and then enforced on the database. So I have a question here. So looking at the example of data protection, is OPPA stateful in a way? So can it tell if I put in two transactions for $9 million within a second of each other? Does OPPA understand that that violates that rule or is it just there's a single transaction that you need to authorize with your local information? So it's gonna be a single transaction. It's not gonna be stateful, but OPPA can take external context into account when making a decision. So if you have like this context stored somewhere about the transactions being made per second or like the frequency of those, OPPA can take those into account to make the decision for you, but it's not gonna maintain a state for you. There's a trouble there with the consistency though, because it's not the synchronous operation. So I guess if you do something like that, you need some guarantees about the state, right? So sorry, Brandon, I didn't understand the question. No, I'm just wondering, because it seems based on the densities of my understanding is that you're obtaining the data from this endpoint, you're making the decisions as they come in. So if you're relying on a certain state, because you do not control the store, it may take some time to propagate the information. So decisions may not take into account the most recent state. So yeah, that's true. It's based on the eventual consistency model. So yeah, you won't, sometimes depending on the frequency of how you're downloading that information, how you're passing it to OPPA, it may be eventually consistent. But what you can do is that you can also run OPPA in your existing cluster with some policies and you can find out the violations in your cluster. So you can counter that using a audit strategy because it's by design, it's a eventually consistent model. So with the recommendation for this, we should run OPPA as a admission but also as kind of an enforcement across the cluster as well. So yeah, you can also do auditing with OPPA so you can have certain policies which you can then enforce on your cluster. And OPPA, and the way you write those policies, it's OPPA will return the violations in your existing cluster based on the policies you've written. So in that way, you can kind of audit your existing cluster if something which you couldn't catch probably before that enforcement. Okay, yeah, that makes sense, thanks. So yeah, so these are some of OPPA's integrate, sorry. Sorry, I just wanted to kind of like tie it back to my original question here for a minute. So what can someone meaningfully say about the trade succeeding a certain amount? They can say that an individual trade can exceed that amount, but do you feel that OPPA can provide meaningful guarantees to say that the volume of trades executed between 5 p.m. and 9 a.m. in the next morning from a single trader cannot exceed $10 million? Or is that something that OPPA just isn't in the right position to actually be able to do? So OPPA can do that given the right context. So like I said, you can feed any kind of context into OPPA and it can make a decision on that. So if you have like information about this specific trader and what he's been doing over a specific time, and if you give that to OPPA, it can use that to make a policy decision. But OPPA itself is not gonna know what that trader's been doing over the last given hours or between 9 to 5. You got it? Okay, so it's that contact, it's that context that has to be provided, but then OPPA can just do the check of the summation or the check of the actual value. I see, okay. Yeah, yeah. But the context is never gonna be transactional. Sorry. Sorry. Can you call out to Sabah to kind of create a query for yes or no? I didn't cast the question, sorry, Brandon. Sorry, so this is kind of talking about this scenario where you wanna find out whether you can perform this trade, right? So if you have the data in a server, can you perform like external query, which is synchronous to make sure that data is up to date? Because all the state is scattered and it knows a more fine-grained policy information there. So, sorry, what's the question? I don't understand the question. I'm just thinking whether, because I feel like this, the situation that Justin Kapal's mentioned, it could be also solved if you could make a query externally to augment your decision that you're making. So in the case where you could query the trading platform and say that if I do a trial run of this trade, would it still work? Right, so this is just a simple example, but you can imagine writing more complex policies which you probably won't want to do it in code. So this is just a simple example of like accumulating the policies, but you wanna do something which is more concrete or more fine-grained. I think that is where OPA really shines. I don't know if this answers your question directly though. I think I get the idea. I guess the question is really about how expressive the policy can be. Can it take into account external for a reason to different services and so on? Yeah, like I said, it can take into account anything that you provide to OPA. It does not matter. It's up to you how expressive or how less expressive you want to make your policy. It's all up to how you author your policies. Yeah, and I think that maybe I'll just restate it and you can tell me whether I'm restating it correctly that OPA can take into account any inputs, like yet it's all within the context of a single call or query, right? There's a single transaction that or call that OPA is given context for and it evaluates all of the data at that time. And if you wanted to say do things over a time window, then you need to keep that state. You need to track that and that can be one of the inputs to OPA. OPA doesn't have that outside of OPA's scope. Yeah, so you can, perfect, makes sense. Great. But you'd probably still have to wrap it in some kind of distributed transaction to make that meaningful across for this kind of case. So it's going to be quite a different use case from the normal kind of use case. Well, if each of your things were transactional, maybe. How many of them are taking place potentially simultaneously? Yeah, it's really, I think only that you would really only be able to do it from an auditing perspective. You wouldn't be able to block something from happening if they could happen simultaneously. But again, all these would be like a per request thing. So it's at that moment, what's happening that that's what OPA is going to enforce on. What's going to take place at that instant, at that moment. Exactly. So like across multiple requests is it not, is it kind of outside the scope? That's yeah, that's more of an auditing feature. That's not more of like, because you need low latency in your request path. So this is more on per request than an accumulation of over time or something like that. Okay, so these are some of OPA's integrations and you can start using OPA with any of these integrations out of the box without having to write any piece of code. So let's look at how OPA actually works. So we've seen this figure before. So basically your service gets a request, your service queries OPA for a decision. OPA looks at the policy and data it has access to and evaluates that query, sends a decision back to your service for enforcement. Now let's say you have a salary service and this salary service is going to provide information about salaries of employees in a company. And the policy that you want to enforce in English says that employees can read their own salary and the salary of anyone they manage. Now let's see how we can take this policy in English and write it in Rego and implement it in OPA. So like I said before, your service provides OPA some input and in this case it could be the request method, it could be the path, it could be the authenticated user who's making the request. And so now let's see how we can take this policy and we can write some Rego. So to make it easy to getting started with OPA and to experiment with Rego policy, we recently launched the Rego playground. Yeah, so we recently launched your, is someone typing? Oh, sorry, I should have been on mute. I think that we only have, we have like seven minutes left of our official work time. I wasn't keeping an eye on the check-ins and I was wondering whether we should pause the presentation and then you can kind of flip forward when it comes to questions or in a like to shift gears a little bit to make use of that last seven minutes as well. Okay, so I can show you guys a quick example of a Rego policy if that's interesting so we can skip over the demo then. Justin, you're- Yeah, I think that's a good plan. So go ahead and show us the quick example of the policy. Okay, cool. Schedule additional time and- Yeah, I think we should circle back and have another demo another time. We just wanna make sure that we cover the security threats. Absolutely. Sure, so let me just give a quick example of policy and then we can go to the security analysis. So yeah, so we launched the Rego playground and the way you write, this is what the playground looks like. You can see some syntax highlighting for Rego code to make it easy to read and debug your code. So the way you read this policy is that allow this through if input dot method is get and input dot path is salary employee ID and input dot user is employee ID. And so the cool thing about this policy is that the employee ID variable on line seven and eight will be bound to a value from the input. And so the way you provide input to this policy is by clicking the input button. And now the question here is can Bob access his own salary? And so now if I check the output allow this through which means Bob can access his own salary because all the statements in the body of the rule evaluated to through. So now if say Alice wanted to access Bob's salary in that case, if I say Alice and if I evaluate this policy now it's going to be false because line eight is not going to hold through. So this is how you can write like a simple policy that says that an employee can see his own salary. The second part was about the managers seeing the salary of their employees. So you can imagine this, you need to tell OPA about this information like I said external context. So you can store this information in your LDAP server and have OPA put it from there or you can provide it as a job token to OPA as well. So this is how you can write a simple policy in OPA in regular using the playground. I'm just going to skip the use cases. So like I mentioned before it's a general purpose policy engine used for these use cases and you can use it at different layers of the stack. I'm going to skip over the admission control use case and the demo and I'm going to go directly to the security analysis. So we are going to talk about some attack surfaces for OPA and so one of them is the vulnerability on initial startup. So when OPA starts up for the first time it does not contain any policies or data and you can imagine an attacker can access an unauthorized service while OPA is still loading. To protect against this we would recommend your services should fail close if it does not get a 200 reply from OPA it doesn't get the right reply from OPA. That would be one way to. When it starts up, what state is it actually? I mean, what does an empty OPA do given an empty query or a full query for that matter? I mean. It will return a non 200 reply. Yeah. And so we hope that like we recommend that your service should basically fail close in such scenarios. And I think that way you can counter this initial startup of initial startup vulnerability for OPA. Second is OPA is API security itself. So by default OPA does not restrict access to any of its best API endpoints that are used to fetch, create and update policy and data. And it's possible that an attacker can corrupt the policy and data loaded into OPA thereby bypassing OPA's authorization checks altogether. So to counter against this OPA's API can be secured using TLS authentication and authorization so that your traffic between OPA and the clients is encrypted. Your clients can verify OPA's endpoint identity. OPA can verify client identities. Was that TLS or just TLS? Sorry. Sorry. Was that MTLS or just TLS? It's just TLS. It's TLS right now. And so, and so clients can, so you can have certain clients being granted access to specific APIs or specific sections of the policy. And so, yeah, so you can have OPA, you can start OPA with like an authorization policy and which can verify client identities and then control client access to OPA's APIs and data. The third attack surface could be the bundle feature compromise. So as you guys know, OPA can be configured to fetch policy and data from remote HTTP servers using its bundle feature. Now the files inside that bundle are TARGZ compressed and an attacker who has access to that remote server can cause a denial of service by providing a bundle file that will consume OPA's servers memory and therefore crash OPA. So one of the ways you can, we've counted this is we've set a bundle size, the maximum bundle size, which policy bundle can have. And so in that way, we can avoid protect against GZip bombs. I think there's bigger problems here because I think we talked about this earlier, but as I understand it, if the party gets here, they can also add, change, remove, do anything they like with OPA policies, which presumably is very bad. If I'm getting this unless I'm misunderstanding something. Sure, so that's why you can protect OPA's API itself. So when you have that startup authorization policy in OPA, you can prevent access to certain parts of the policy and actions certain users can take. So in this way, you can prevent like a bomb from updating a policy, like for example, basically. So I would assume that if you want to secure OPA, if you want to secure the deployment itself, you would have like an authorization policy which prevents access to certain APIs. And that's okay, but does it, are there untrusted APIs that will willingly open Zip files? Because like, I guess the, if Bob isn't trusted to provide a, like to change your policy, why is Bob trusted to have OPA like unpack a tar ball? So again, like OPA does not, OPA assumes that the user is authenticated, right? OPA is not trying to solve the problem of authentication. So it's gonna verify the identity that you provide for Bob and it's gonna give Bob the roles that you have set in the authorization policy. So it's on the user of how they define this authorization policy. OPA is not gonna make any kind of assumptions about Bob. So it's how you define that authorization policy and it's how you provide the identity of Bob to OPA to make that decision. Okay, thanks. I think we're, I think we're already out of time. I don't know, Sarah, what we want to do here. I think we need more time. Yeah. To fully complete this, if you're willing to come back and continue this discussion next week, I think that would be the best way to, or next week or a subsequent week. Yeah, or we could just have a breakout session where we, like we can do it in two weeks after KubeCon or we could have a breakout session and wrap it up, whichever. So we can, I won't be available for the next two, three weeks because I'm gonna be on vacation. So I can come back towards the end of June or towards the beginning of July, if that works for you guys. Or you can- Yeah, so maybe we can offline schedule a regroup. And I apologize for not managing the meeting timing well today. Justin Kappos, do you have a thought about, or we can go longer, like if some of us are available. Yeah, we're in kind of a sticky situation here. I don't really know the best way to handle this. We could try to continue for a bit. I think of those who have had questions, are there people doing the assessment? Are there people that are, that have like burning questions that they have yet to ask? Are there a lot of those? I've got a question that came up in the discussion and I kind of put on the table at least because it came up in some of other people's comments and I hadn't quite managed to formulate a comment for it yet. But one of the things that happens when you have any kind of policy framework is that people write policies that have significant bugs in them. So for example, I mean, I know that AWS have had a lot of experience with their IAM policies. People write a large number of bugs and they can tell us because people have policies that can have large amounts of statements and that can never be true, for example. So they know they must be buggy because people don't tend to write dead code and policies. And Oprah is very unopinionated about your policies. It doesn't even have a default deny, close or anything. Along those lines and therefore it's very prone to potentially people writing buggy policies because I mean, also the JSON is untyped. So you have no idea if you've actually chosen the right bit of the input data to match against. It'll just kind of potentially just give you an empty list for which could lead to a sort of cat-caging failure as well. And I understand it does have tests, which is great as a built-in thing, which kind of helps, but this has definitely been an area which in other policy frameworks has been a very large problem. Yeah, I think this might now be like Oprah's like Oprah can deal with this problem alone. Actually the policy team just, we just had a chat with AWS Automated Reasoning Group, Brian Cook. So we are actually looking at like building a open source solution for the formal verification of policies, I think which might could help address justice. Yeah, I mean, that certainly that certainly that deals with my reasoning team have done a lot of work with IAM policies in AWS. But IAM policies are more strongly structured. So it's kind of easier, whereas IPU policies are very, I mean, it's a program language. You can write anything you want. It's a much more open problem. I think it's gonna be harder. Yeah. I'd also like to say I'm skeptical that formal verification is the right tool for what you're doing now. I even think there's a lot of usability things that I saw when the, oh gosh, I've forgotten his name again, that fellow who did the very nice talk in the panel that a lot of us were in in the security session at DockerCon. That, yeah, the- That's full on, Tim. I think, or Tim. Yeah, yeah, Tim, Tim, he did that. He made a very nice demo in things. Someone is ringing. Okay. So he did a very nice demo. And I think there were a lot of areas there in things he did, and even just like watching that as an outsider, there's a lot of sort of usability things and areas where it's like, oops, I made this error and oops, this happened because of this sort of thing. So I even think that kind of shoulder surfing exercises to pick out and fix a lot of the more obvious and initial pitfalls your users will fall into would go a very long way and won't require people to do any formal verification of their policies which people haven't really done in practice. One thing we normally recommend along with unit testing to be confident of your policies is that you have like a deny rules and then you do a bunch of whitelists. So you have like a top level deny or something like that where you deny everything by default and then you have specific of these least privileged rules that you put in the policy to only get access to specific things. So that's one way you can counter this, that's one way you can write your policy structure your policies in that way. That's one thing that we recommend. I think it can help like recommendations are nice but like giving people access to go off the rails right away and just saying, oh yeah, you know, it's yes, it looks really pretty here in whatever else but you can just fall right off the edge putting some safety rails in place and making it hard for people to shoot themselves in the foot is I think would help. And I don't think it would necessarily be that hard to do because I heard Justin Cormack's concern that there are a lot of, there are a lot of kind of programming errors that people could make here. And if, and when you have an act like a formal security audit, I think one of the really interesting things to happen for the auditors would be to look at a bunch of your users policies to try to understand are users actually using OPA correctly or do they think they're using it correctly but they just have really bad security. So this is more of like a user not writing correct policies and thereby kind of thinking what OPA is supposed to do and not doing that, that use case basically. That's what we're talking about. Right, it's like PHP versus Rust. Like you can blame PHP programmers for writing buggy code and you can say, well, you know, Rust, like this Joe who writes Rust code must be a much better security person because he doesn't have a lot of the same problems but the languages themselves make such a big difference that, yeah, that I think there's some meaningful things here and so there are some things that could make OPA less PHP and more Rusty in ways. And so once we're done with that. I was just gonna say that, like I wanted to echo that they were the, like that it started to go in that direction with the tests and so forth. And I just seconding that point. Go ahead, Ash. Yeah, so one thing that we are gonna come up soon is with a library of policies which users can use like these bunch of common policies that we've seen users ask for and they can then just parameterize those policies based on their specific use case. So I think that can kind of help in making those, making the errors less during writing policy by the user itself just for getting started, I guess. Yeah, that sounds like it would help. So yeah. So are there other, should we shift gears? And if there's, are there any other questions that people were that were on people's minds that were different questions? So we know whether to what extent we can do the follow up asynchronously or whether we need to get together in order to fit the assessment. I only had a few more commands kind of the document itself. So nothing related to the technology itself but for the document. So I'll comment on it. Please edit and make comments. I mean, make comments and questions in the document itself. Thank you very much. Yeah, I've got a guy but I will make some comments in the document. All right, so thank you very much Ash for your presentation and we'll be syncing offline and thanks everybody for your questions and attention. Thank you so much Ash. You were really patient with all this. So we will have some more follow up for you and give you both a kind of one pager and also a slide or so, explain what our thoughts are. Yeah, it sounds good. Thanks for the opportunity. All right, I'm gonna close the meeting now. Bye. Bye. See some of you next week, keep going. Bye.