 So thank you for joining my talk. The title is generalizing policy as code for compliance posture management on multi-cloud infrastructure. So today I'd like to share with you about the value of automated and community-based compliance posture management using compliance operator and for managed multi-clusters with hyper six. So this presentation consists of three subtopics. One is about hypersift, which is an open-source managed cluster enablement tool. So you may have an experience using some of the managed tools, but let me introduce an open-source tool hypersift. And second topic is compliance operator and compliance code, which are open-source compliance posture management, or CPM, tool and policy. So the compliance posture management is another important workload for the many cluster or multi-cloud environment. So I'd like to talk about that in the second topic. And finally, this is the new feature in this year. So adoption of the compliance operator to hypersift for consistent compliance posture management. That's the two topics. Okay, let me start with hypersift. Hypersift is an open-source managed cluster enablement, which focuses for the Red Hat open-sift clusters. And you may have an experience to use the managed cluster tools offered by cloud service provider. So you can create or delete your cluster by just clicking the button. And you may also have an experience that you use the standalone tools to manage the lifecycle of the multi-crust or managed cluster, like Terraform, Argo CD, or Tecton, through the lifecycle management API, like Kubernetes cluster API. So the hypersift is a similar tool for such standalone tools. So you can create or delete your own cluster on your bare metal or the infrastructure on the cloud service provider. And its unique feature is a hosted control plane. So I think it is better for me to introduce what control plane means. So you may know that, but let me introduce that. The left-hand side, small box, shows the inside of the standard Kubernetes cluster. It consists of two kinds of components. One is control plane component and another is worker component. So control plane, in short, the infrastructure components for Kubernetes clusters. For example, API server, ETCB, pod scheduler, or controller manager. So it is a very important component and they run on master nodes. And other workloads like users application, like database or web application or like so on, are classified as worker component and they run on worker nodes. So in a standard Kubernetes cluster, they consist one cluster with two kinds of the nodes. But in the hypersift environment, the control plane hosted on another cluster, called the management cluster. So this, the center picture shows the architecture of the hypersift. If user attempts to create a cluster, then the worker will be created for that cluster. But its control plane will be hosted in another cluster and the control plane exposes its APIs to the worker components. So the worker and the exposed APIs virtually forms the Kubernetes cluster. So when user attempts to create another cluster, then the another worker will be deployed, but the control plane will be deployed into the same management cluster. So in other words, the multiple control plane will be deployed in a single cluster. So what the benefit of the hypersift? The first benefit is that we can reduce workload by centralized management. I mean, for example, an infrastructure engineer need to apply patch to the control plane. In that case, the infrastructure engineer just need to log in the single management cluster and perform the management operations at a single operation. So that's the first benefit. And second benefit is that the managed cluster or user's cluster can be deployed quickly because the basic components like basic resources like network or strays have already been deployed as a part of management cluster. And what we need to do is just deploying the control plane components ports like API server and so on. So it can reduce the time for deployment. And finally, the improved resource utilization are similar to the virtual machines and the virtual machine monitors. Many control planes can be packed into a single cluster and it improves the resource utilization. So that's the advantages of hypersift and we can leverage it to how to say optimize the managed cluster workloads. And what other unavoidable workloads we can reduce? That is the compliance posture management. The compliance posture management is the process to ensure that an IT system complies with internal or external policies. So you may think about what the difference between security and compliance. So compliance policies often contains many security rules like minimum password links should be longer than eight characters or the length of encryption key should be larger than 1,024 bits or larger. But the important difference is that in the compliance process we need to not only configure the IT system secured but also we need to ensure or check that the system is configured as expected. That's the difference. So the compliance posture management consists of four steps. Let's go through with example policy. This is one of the rules in CIS benchmark for Kubernetes. In this rule, API server must not run with options in secure bind address. In this case, first step is collecting fact. So fact can be thought of as a configuration toward the IT system. And in this case, the facts can be collected by this file pass in the master node. And then the second step is applying policy. The rule say the string insecure bind address should not exist in this fact file. And the results should be reviewed by the compliance engineer. And then fix violation if this kind of violation is found. So in the compliance posture management, it is important that the automation and open community-based technology play important roles, especially for cloud native compliance posture management. Why? So why automation matter? As you may use the cloud native tools like DevOps and GTOPS based tools, it frequently or continuously changes the IT system. And therefore we need to perform this process frequently or continuously. In that case, how to say the legacy process like monthly or quarterly or annually, such annual check doesn't matter. So we need to perform a frequent check. So then therefore automation is essential. And the second is that open community-based. So why open matters? So as I wrote the external policies, so the many laws and industry standards exist. And that can be commonly applicable. Many organizations, for example in the financial company in Japan, such an organization need to comply with the security standard given by the Japanese financial agency. So in addition to that infrastructure is now common. Infrastructure is now common, you know, the Kubernetes. We use Kubernetes as a standardized infrastructure and therefore we can apply same policy to similar or identical infrastructure over multiple organizations. And therefore the open community is very important for this topic. Okay, let's move on to the concrete tools. The first one is compliance operator, which is an open source compliance posture check engine. So this is an operator, Kubernetes operator, but the inside of the operator, there are many mature technologies, but it is wrapped by cloud-native technology. So this figure is the same one in the previous slide, but these steps consist of multiple techniques. The for collecting fact, the cloud-native technologies like QBAPI or storage access to the host will be used to collect the fact, for example, file in the master node. And then for the applying policy, the very mature technologies used for 2008, this open SCAP started in 2008, and policies is written in XCCDF, which was standardized in 2005. And to review the result, we can use the both matured and cloud-native technologies on the XCCDF, and we can also use Prometheus metrics. And also the sum of the big, violation of fixed process is automated with the Kubernetes manifest or Ansible playbook. So with compliance operator, we can gain several benefits. The first biggest one is that we don't need to write policies from scratch. So we can use existing XCCDF rules, and I will introduce it in detail in the next slide, which is called compliance as code. And also we can integrate it with both cloud-native tools and legacy tools. For example, we can deploy and configure a compliance operator with cloud-native tools, including operator-like-cycle-manager and the ROCD or tecton. And as I told in the review result, observability tools can be used for the reviewing the result. So the compliance operator exposes its result as a Prometheus metrics, and we can use Prometheus or the Grafana for the graphical user interface or dashboard. And also we can use the matured or legacy technologies like XML, XSLT, or CSS to review the result through the browser or the PASIC to another tools via through the XML technology. And the compliance as code is a set of tech rules which are maintained by the open community, and it consists of the rules and remediation script. And the rules are written in YAML file as shown in the bottom of this slide. So it consists of location for fact, for example, in this case, so this is the same one that I introduced previous slide, disable use of insecure bind address. So in this case, the fact can be collected through the Kubernetes API with this URL and it also contains a logic for a check. In this case, the string insecure bind address should not exist in this fact data. So it supports the whole infrastructure. I mean, it contains the operating system rules and the middleware and application rules including the open shift cluster. And it supports various regulations. For example, in case of the clusters, NIST SP 853, CS benchmark, PCI DSS are supported. So all of them are very popular compliance regulations or standards in the IT industry. So let me share the architecture slide of the compliance operator working with compliance as a code. So rectangle represents components of compliance operator. First, the resource collector collects the facts from cluster which is indicated in the location in the policy. I mean, compliance as a code. And then facts will be scanned by the compliance operator with check logic provided by policy. And the result will be consumed by various tools including the metrics exporter and report generator and the automated remediator for clusters. Okay, so far I have talked about two kinds of tools. One is hyper shift for managed cluster and another is the compliance operator for the compliance posture management. So the next challenge for us is, you'd like to apply the compliance operator not only for the standalone clusters but also for hyper shift managed clusters. So the challenge here is how to support the hosted control plane feature. As I introduced in the second slide, the managed clusters under the hyper shift are split into two, how to say two or multiple parts. One is the cluster and another is management cluster. And the control planes are hidden from the user's cluster. It just exposes the APIs and the control plane component themselves are hidden and the compliance operator running in the user's cluster can't access the control plane itself. So we need to use another compliance operator instance on the management cluster. And this instance need to support multiple control planes on a single cluster. While standard compliance operator just need to check a single control plane. So that's the challenge. But if we can generalize this compliance operator both for the worker and this hosted control planes, then we can enable consistent compliance posture management. I mean, we can use same tool and same policy. So the result of check can be thought of very consistent result. KD, this is how such a feature is achieved. Actually, this is what I contributed to the open community. The adoption of compliance operator to hyper shift hosted control planes. So the most important thing is that the each control plane is, how to say encapsulated. So one control plane for one managed cluster is located in a single name space. So if there are two control planes, there are two specific name spaces for each control plane. So in a standard rules, the name space name is hard coded but we need to replace them with place for holders like this and some of the resource name is changed and therefore we also need to replace them with place holders in the compliance of the code rules. And also we need to add runtime parameter assignment feature to compliance operator. So when compliance operator instance on the managed cluster tried to perform check, then we can assign specific parameter for specific control planes. For example, the name space name is CP1 or the scan for the control plane too, the name space name might be CP2 or like so on. So that's the new functionality and with these features, we can apply the compliance operator or automated compliance posture management to the managed clusters powered by hyper shift. So these are key takeaways. So first I have introduced the hyper shift to one of the managed cluster enablement too and then introduced the compliance posture management and the concrete tools compliance operator and the compliance as a code. And I have also mentioned about the importance of the open community for this operation. And then I have introduced the adoption of compliance operator to the hyper shift. So thank you so much. So that's all from me. Please ask me any question about my presentation. Thank you. I have actually multiple questions. So like my first question is like is hyper shift and your compliance operator only works with open shift or it can work with normal Kubernetes as well? Thank you, very good question. So actually it is a QB operator and it can run on any Kubernetes clusters and you can check the underlying operating system with compliance operator for the check for Kubernetes. It only supports the hyper shift. Okay. And is there anything like it can check during the deployment as well or like it will check only after the deployment is done and it will fetch metrics? Sorry, could you say again? Like when you say Prometheus and metrics, right? Like things which are deployed, right? After that only it can scan and it can filter out the things, right? Like saying that, okay, this is not matching the compliance, right? But if I can catch those things during the deployment itself, is that possible like using some kind of GitHub actions or like, you know, something like that? No predefined trigger or like something like that doesn't exist in the compliance operator but the output is created not only for the Prometheus metrics but also the custom resource generated for the results. So maybe we can use some hook for Kubernetes resources to trigger some other actions like GitHub action. Okay. So means like after deployment only is it possible but not during the deployment or like it can catch? What deployment I mean? Like when we deploy applications, right? Like, you know, the deployment service, the state will set or config map secrets, right? So during the deployment, like, you know, while it's happening, can it stop saying that, okay, you are doing something wrong, don't push the code? I see, yeah, I see, yeah. Actually the answer is no. So this checks the runtime. So I mean the, maybe you're, what you want to do is the prevent. Correct. Like admission control, yeah. So that operation should be done with some other tools like the on the GitHub, you can use Travis or something with hook and when you would like to prevent on the Kubernetes some, yeah. So the controller like a Qiverno or OPA can work for that. Okay, thank you. Thank you, thank you for your question. Any other questions? Thank you, thank you for joining my session.