 Okay, I'm Anders and the topic for today's talk is going to be the compliance business case for Kubernetes in the EU. Get ready for the EU CS. And unfortunately my friend Robert could not make it here today, which is unfortunate given that he's really the one who knows anything about the EU CS, but I'll do my best. So Anders, I work as a developer advocate at Styra, which is the creators and the maintainers of the open policy agent project. And if you want to reach out later for questions, I'm available at most of these services just by me by my first and last name. So to start with the EU CS, the EU CS or the European Cyber Security Certification Scheme, which is a long name, comes out of the article of 48.2, the Cyber Security Act, which is drafted by Anisa. It's currently in a draft mode, so it's not enforced yet or it's not, it's not out there yet. It's available for review. What the EU CS provides is basically a reference set with a whole bunch of security requirements. These are at a high level, so they don't mention things like Kubernetes or Opower, anything like that. But a whole bunch of requirements that you need to fulfill for certification. Most of these requirements are based upon previous standards and national schemes like ISO and IEC 270XX, a C5 standard from Germany and the second on cloud from France. This certification scheme will apply to any cloud service provider. So it's not just for those who actually provide the cloud, but anyone acting in the cloud. So this includes infrastructure as a service, platforms as a service, software as a service. So it's basically most of us. These requirements are grouped into 19 different categories and each of these categories divided into a number of themes. If you do get certified, you get certified for three years across the whole EU. And one reason I think this is going to apply to most of us is the certification is viral, if you so will, in the same sense of software licenses can be. Because if any vendor wants to apply for certification, it will also be all the sub-vendors or subcontractors, sub-processors will also be included in the assessment. And if they are not certified, that's going to be, it's going to be tough. So it's basically will apply to most of us, I think. So the cloud service provider, the way it works, the cloud service provider takes these requirements and does a self assessment. And that assessment is later reviewed by an accredited auditor. There are three basic levels or assurance levels for certification. And I think most companies are probably going to be either basic or substantial, while the high level is for finance, governments, and so on. So for the basic level, you need to minimize the known basic risks of incidents and cyber attacks, meaning a low risk profile. It's a limited assurance, self assessment, but it is reviewed by a third party and focuses on definition and existence of procedures and mechanisms. So for the substantial level, and I think a lot of us are going to aim for that level, it means we need to minimize known cyber security risks and risk of incidents. So it's not just basic risk anymore, the medium risk profile. And we can see as we move further to the right, things are starting. One requirement that starts up here is like this automation. So we now have a requirement to do functional testing. You can't just check things off boxes anymore, but we need to actually verify this. And at the high level, we minimize the risk of state-of-the-art cyber attacks carried out by actors with significant skills and resources, an elevated risk profile. And again, in the bottom there, continues automated monitoring on compliance. So it's not, you can't just assess this, get a certification for the next three years, and then come back three years later, but this needs to be an automated process. The assessment needs to be done continuously. All right. So what does it look like? Here's an example of an EU CS control. And when we say control, that's basically another word for requirement in this context. So a requirement or a control might look something like this. And this is the IM05, regular review of access rights, which has the objective that the fitness for purpose of the user accounts of all types under associated access rights are reviewed regularly. Makes sense. So for basic, for the basic assurance level, we have one requirement, the CSP shall review the access rights of all the user accounts under its responsibility, at least once a year to ensure that they still respond to the current needs. So that seems easy enough. For a substantial level, the review defined in IM051 shall be performed by authorized persons under responsibility of authorized body that has approved access rights policies, and so on. And for each of these steps, the requirements are yet more fine grained, more detailed, and obviously will require more to pass. Mentioning in passing here, one actor, which does a lot of good in this space is Medina. It's an EU funded research project, which has the goal to create a security framework for actually achieving these things that the EU CS talks about. Just continues audit based certification in compliance with the EU wide club security certification scheme. So the EU CS provides the requirements and a big document stating what you need to do while Medina provides actual tools and processes and techniques to maintain compliance or to achieve compliance. So if the EU CS is the more abstract thing, this is more concrete. So that's a useful resource to to check out if you're interested. All right. So that was a quick introduction to the EU CS moving on to the open policy agent. What is that and what does it have to do with the EU CS? So OPA is a general purpose policy ending. How many here have used OPA? Oh, there's a lot. A lot of you have used OPA. That's good. But for those who haven't, OPA is a general purpose policy. And of course, we're talking policy again here. EU CS, obviously another policy. And now we're talking about a policy ending. And a policy is basically a bunch of rules. And a policy ending is basically somewhere you put those rules, and then you can query that ending, provided some input, given that I have this or that, is this resource compliant? Or should this user be allowed to do this or that? That's a policy ending. It's a graduated CNCF project since two years back. What OPA does, it provides a unified framework for working with policy as code across all layers of the stack. And we will see why that is important when we talk about something like the EU CS. Again, the EU CS doesn't mention any specific technologies. So how you choose to implement that is going to be up to you. But OPA works really well for a holistic framework like EU CS. A key concept of OPA is that we want to decouple policy from application logic. And how we used to work with policy is basically we had a couple of if-else statements inside of our source code. We said, if this or this is found in the input, send this back to the user. What we do with OPA is basically we try and decouple those rules. So we can reason about them separately. We can test them independently from applications and so on. So we basically make policy a first-class concept. The policies of OPA, they're written in a declarative language called REGO. We'll look a bit more into that in a bit. So OPA is an OPA source project. Again, it has a big community over 350 contributors, over 100 integrations, spanning all types of technologies. 8,000 GitHub stars, 7,000 Slack users, and a bunch of sub-projects and related projects like OPA Gatekeeper, Contest, Editor plugins for IntelliJ, and Visual Code, and so on. So use cases. We talked about OPA as a holistic tool, and EUCS is an holistic framework, which is of course a benefit when you try and apply a framework like the EUCS across your whole stack. So whether you work with application authorization, whether it's infrastructure or container orchestration, whether it's cloud vendors, whether it's GitOps, CI CD, or data sources, there is likely going to be an integration where you can have OPA. Again, decouple these type of policy questions where you can work with policy independently. And of course, pretty much all of these technologies, they already have some way of working with policy. So OPA did not invent that concept. The problem is, of course, if you have so many different ways of working with policy, how do you manage that at scale across a large organization? Okay, so if OPA can work with so many services, how does that work? If you've ever been to an OPA presentation before, I think you've probably seen this. It's when that is commonly included. The way it works, we have a service and we have a request. When we say service, I could mean a lot of things. It could be a microservice application, it could be a Kafka broker, it could be the Kubernetes API server and so on. So basically anything servicing a request takes that request and rather than making a decision on its own, it sends a policy query over to OPA. Should this user be allowed? Should this resource be deployable? Or and so on. So OPA based on policy and optionally data, considers the input it got from the query and returns a response or a decision. Both the inputs and the outputs are JSON formatted. So basically anything that can handle JSON, which is probably most software components from the last 20 years or so, can work with OPA. And a simplified example here, we have some input. We have a little piece of JSON. We have a user, we have a name for the user, and we have a couple of rows. The rego policy here in the middle, it's basically just says that by default, any request should be allowed, rules should be false. So we should not allow anyone by default, but allow should be true if there is an admin role in the input user roles. And in this case, there is no admin role in the input. So the decision is false. So that's basically a very simplified way of how OPA works and how rego works. Okay, so back to the ECS then. Can we translate that type of policy to policy as code? Because that's really what we all want to work with. And if you check the ECS PDF, and of course that's a PDF, it's not really code. What you really want to go to, it's the annex A. That's where you'll find all these requirements with their assurance levels. 19 categories again, organization of information security, information security policies, risk and asset management, operational security, identity, authentication and access control, development of information systems. And if you ever work with OPA, this seems like a pretty good fit. We do most of these things in OPA. And again, remember a central theme here is continuous automated monitoring. You can't really do that by looking at the PDF file, comparing that to the real world. We need automation. We need automated processes. So the ECS policy, can it be codified? And before we, can we find some way to codify the ECS itself? We could of course try and translate that to rego directly, but that would be rather hard without, since the ECS is not like technology specific. There is an interesting format that I think is interesting, which is called OSCAL, which is recommended for inclusion in the ECS. We'll see. It's from NIST, the American actor, which means open security control assessment language. So it basically means compliance as code. And it's not really code. It's YAML, JSON or XML, whichever you prefer, but rather, but we're at least moving in the right direction because we're moving away from a PDF file to some sort of structured data, a schema, where we describe these rules. And the rules themselves are just one part of OSCAL. That, because OSCAL composes of three different layers, or schemas. The control layer, this is, that's what we've been looking at so far. That's the requirements. The next schema type is the implementation, where you describe, how did you go on about being compliant? How did you solve this problem? What components did you include in that solution? And the next layer or schema is the assessment layer. How do we assess that we are compliant with the standard? And assessment layer also includes an assessment result format. So if you have automated testing and so on, you can output an assessment result, which will tell you, yes, we are compliant or we are not. So no more PDFs. We want to automate everything. We want to be able to exchange these requirements, implementations and assessments across our different systems. And of course, as you saw with OPA, OPA is JSON in, JSON out. So this works really well with OSCAL, it turns out. Because we can use OPA and RAGO to do things like policy on policy enforcement, where we actually check if your assessment, or if your implementation says that you've solved, I don't know, what should we say, if you solve like cryptography and transit or TLS. But OPA can see that you have not specified any components here, which actually fulfills that requirement. That would be a policy violation. So if OSCAL describes the actual policy, we can use OPA to enforce that. And you can do a whole lot of other interesting things with OSCAL and RAGO. You can use OSCAL to build RAGO rules. So try and translate these requirements into actual RAGO. And you can use OPA to generate OSCAL artifacts as well. And now we're getting closer to our goal, our continuous compliance. So an example here would be asset management. And this is, of course, like asset classification and labeling. I think most of you who work with a policy end in, this is a basic thing for you. Most of us have required that any resource must have a label, or it must have some metadata attached to it. This is also a requirement of the UCS. The CSP shall define an asset classification schema that reflects for each asset the protection needs of information it processes, stores, and broadcasts. So let's move into something real, at least resembling something real. So the first one was we need an asset classification schema. An asset classification schema shall provide levels of protection for the confidentiality, integrity, availability, and authenticity protection objectives. So a very basic schema for asset classification might look like this. We have one attribute for availability. We have one for confidentiality. The next requirement, when applicable, the CSP shall label assets according to the classification in the assets classification schema. So we need to ensure that all our assets are labeled. And if we were to do that, we're going to in here make it a bit bigger. We can see here the first thing we can note is our asset classification schema. For admission control, we have something that's about to be deployed. We have a pod in this case. It does have a couple of labels. And we do have a policy which has two rules, one that requires all these labels to be present. The next rule, which requires the values to be valid. So you can't just make any value up. It must be one of those defined by our asset scheme. So if we are to evaluate the report here, we will see that in this case, we have an invalid value for the availability classification. There's the medium availability was either low, high or critical. And we are missing a required label, which is confidentiality. So a basic example of policy enforcement directly taken from the UCS. If I were to do something like the same rule or the same policy applied to cloud formation, which is, of course, an entirely different technology. And if I hop between these two, the thing that we might notice here is the input data here between these two changes, of course. But that's basically all that changes. The one line that changes is number five, where in the case of admission control, we can just go right to the labels. In the case of cloud formation, we need to transform those into a set because I think they're provided as a list of objects. Showing the value of OPA and RAYGO and having a unified way of doing this, we can change one line of code to reuse the same policy for an entirely different technology. So this is part of the value of having a unified framework and a tool to work with policy. So the last one for substantial assurance level, it's the need for protection shall be determined by the individuals or groups responsible for the assets. So a bit contrived example here, but what we're doing here, we imagine that we're in a pull request flow. In that pull request flow, we're going to do a curl request to the GitHub API. We're going to see that the user making this change is, in this case, it's Anders. We're going to do a mapping. We're going to see, for each of these teams, who are the members. And a simple policy to describe that allow, we should allow this deployment if the input PR username is in data teams, labels, label owner members, meaning we match the label provided with the actual owner of this resource. And if I'm not the owner of this resource, I should not be allowed to make modifications. So again, an entirely different technology, GitHub in this case, doesn't really matter. JSON in, it's JSON out. As long as we have that, we can work with OPA. So that's Rago, it's OPA on the more kind of distributed low level side of things. But another important aspect of OPA, and especially in this context, is its management capabilities. Because when you deploy OPA, again, you probably want it in as many places as possible, because it solves a whole bunch of different problems. So OPA is a distributed component. And if you go to any large enterprise or organization, you might find hundreds or even thousands of OPAs. So in order to manage that, you need centralized control. So OPA provides a number of APIs. One of them is the Bundle API, which allows distribution of policy and data from a centralized location. Decision logging, we want to know what all these decisions OPA made, we want to know what they said. That too, we want in a centralized location. We want to centralize configuration, we want to centralize status and health reports. The last places we have to look, the simpler, the auditing. So this model we covered already, that's the distributed part of OPA. The centralized one works something like this, you have a policy repo, where you carry your policy optionally, any other data you might need. And you have a number of data sources, could be things like permissions, user databases or whatnot. And you take whatever data is relevant for your use case, you package that up into a bundle. The bundle is basically just a tarball, which OPA goes and fetches periodically. So you get policy and data updates periodically without having to restart your services. So you can work with policy, the couple from your application logic. So bundles provide a unified management and distribution of policy and related data. So the next thing we talk about is decision logging. So as OPA pulls down bundles, it also emits a whole bunch of decisions. We want those to be somewhere under our control, and we want those to be centralized. And of course, these decisions can then in turn be useful for other things like creating an Oscar assessment report, which is another interesting use case. Access control, it's another big use case for OPA. I think it's probably like 50-50 infrastructure or access control. And access control is an important part of the EUCS as well. So another use case where OPA fits in. There are taken from the EUCS controls. There's management of access rights, regular review of access rights, privilege access rights, and general access restrictions. And again, with the couple model, we get much of this for free. Because if your access controls are scattered over hundreds of different technologies or different services, this is all going to be a chore. But with OPA, we have one way of centralizing control. So we have centralized management, and review of access is made easy by decoupling policy from application logic. And again, we have a unified policy language. So if you know Rego, you can review all of these requirements regardless of what system it's there to protect. A few last words on access control. Because given this is a Kubernetes conference, what you see here is distributed access control. It turns out that distributed authorization is really a challenge. And it's even made worse in heterogeneous environments where you have one service doing Java, another one doing Python, another one is C, Go, and so on. Because given, if we do hard code authorization in these services, and we need to make a change, we need to coordinate that change with all these teams. And how do we know that they did the right change? How do I review that? I can't, I don't know all these languages. And so it requires collaboration and it's really hard to audit. And where is it logged? Where does those logs end up? So again, we introduce OPA. We have one way of managing policy and one way to enforce policy across our whole stack, regardless of other technology choices. And we see the control pane here providing policies, permission, and whatever else is needed for authorization. This is exactly what we want in this context. We need a few places as possible for auditing and for management provisioning of policy. So before we wrap up, a few excerpts since we're in a Kubernetes conference. A few examples here of of of Rego or OPA policy or EUCS policy translated into Rego. And we're not going to go into the actual Rego here, but this is the examples here. One control says you need to maintain a list of exceptions. So if you have, if you have a need to do exceptions from your security policy, that those exceptions must be documented and maintained. Of course, that's very easy to validate in Rego. That's just that's basically just extra data that you provide an allow list or so to your policy. These exceptions need to be limited in time. So we could, for example, schedule a check of the creation time stamp of the resource against the time limit for any resource marked for exception. We should, the CSP shall perform a risk assessment to assess and treat the risks on any project. So we could do something like an allow deny based on labels. Just if we can assume some other system with label are components based on risk, or we can actually calculate a risk in a more advanced policy and determine whether we should allow that to be deployed or not, and so on. So if you're interested in these examples, just check them out. It should be noted though, again, the EUCS is a holistic framework. So it covers a whole bunch of things. And it's not all of these things are even tech. So out of these 19 requirements, I'd say about half of them is our topics where OPA is applicable. Some of these others like human resources, we can't do, we can't really write policy for people. Our physical security is not really where we tend to work with OPA either. But some of these, we can definitely write policy on either way, like cryptography. We don't do cryptography with OPA, but we can we can write policy that enforces and ensures that any component deployed, leverages the right level of cryptography and so on. So our OPA is applicable organization of information security, information security policies, risk management, asset management, operational security, identity authentication and access control, change of configuration management, development of information systems and product safety and security. So a whole bunch of things where we can use one unified technology to work with policy. All right. So to wrap things up, the EUCS, it's a reference set of security requirements. A key here is continuous compliance and automation. That's a key to certification. And the more the further you go on this on these assurance levels, the more automation you will need, the more continuous compliance you need to. It's while the certification is over three years, it's not good enough to just say, okay, we had an auditor here three years ago, so we're compliant. You need to prove that basically at any point in time. The Medina project is a useful resource. So check that out, providing more hands-on things like tools, techniques, processes for auditing and organizations who are in the certification process. Askel is an interesting tool for working with these requirements and to kind of treat even requirements and how we choose to solve them as code as well. So keyword is, of course, that we want to codify as much as possible. And last, OPPA provides a unified way of turning these requirements into enforceable policy across our whole cloud-native stack. So if you want to learn more, a couple of links here for further research. It's the EU's cybersecurity mini-sites, the EU's yes standard itself, of course. Eurek Tiv has a bunch of good articles on the topic. That's the Medina project, it's OPPA, Regal Playground, and the Styra Academy. And since Robert couldn't be here today, he said, if you have any questions on the more kind of legal aspects of EU CS and so on, because he, again, is the subject matter expert, you can reach him on either the CNCF slack or the Kubernetes slack order, or just reach out to me and I'll direct you to him. So that was it. Thanks.