 So welcome to the Kubernetes Policy Working Group session. So we are a small working group. Part of the motivation actually comes from the chief architect, Brian Grant from Google. So Brian Grant always envisioned a policy framework being one of the like the shapes of Kubernetes in the future that Kubernetes should transform to. So policy is always like a big thing on his mind. From ourselves, what we find necessary to form a policy working group is because that basically you can find policy defined in many places in Kubernetes. You have policy which is a big one. You have network policy, you have RBAC policy, you have many policy. But if you ask anyone what is Kubernetes policy so I doubt anyone can give a concrete answer to it. So that's actually part of the problem that policy is defined like scattered all around the place. And another thing is that policy description are domestic in nature. We got questions from people like are we going to define a single policy description language through the working group? The answer is probably no because policy language is very tricky and domain specific so we don't think we can standardize that. But what the working group is focusing on is the policy semantics and the control mechanism. So these are things that is universal and could be standardized or generalized. So this is our focus. And also policy is very important in many other aspects outside of Kubernetes. For example, this is the ONAP policy project. And if you have a similar background like I did with writing standard 12 years ago, you know policy plays a big part in the IMS. That was NGN standard like a decade ago. So policy is important and policy is scattered around so we want to form a working group to try to come up with architecture as I said to have a standardized control mechanism. And this is what the purpose of the working group. This is a relationship with the different six. As you can see we keep in touch with many six. Like scheduling, admission, storage, network. Like multi-tenancy working group. And also working group in Kubernetes by definition is cross multiple six. We always have a list of working items for every half year. So this is the work items we focus on for the first half of the year. Probably we will keep focusing on for the second half of this year. So multi-tenancy gatekeeper and policy security policy. These are the three big items we will be focusing on for the Kubernetes side. And we have also some new ideas, very forward-looking almost research items. If you are interested, you are welcome to participate. Okay, so multi-tenancy multi-tenancy has always been a big problem for Kubernetes. There has been a very small proposed by Google and other companies like hard multi-tenancy or soft multi-tenancy. So I think the multi-tenancy working group currently is running a proposal basically have a tenant CRD to populate the tenancy resource, view tenant as a resource and populate the resource via the CRD. So the policy, why do we need a policy here? The policy here is to help basically to tell the tenant CRD where to stop. So the policy will describe what the limits a tenant will have and help automate the process of populate the tenant. So as you can see, these are the I pick it up from the design document from the multi-tenancy. So in a nutshell by defining a policy we help solving the custom resource population problem. So simple idea is something like we can utilize the gatekeeper project. So basically we define a tenant policy object. So in that policy object we described like what the policy should be applied to a certain tenant and then the gatekeeper will help mapping the policy definition to the general working mechanism. So there's still a problem like how do we define the constraint for a population. So the biggest problem still is when do we heat the wall and stop. So this is still like an interesting area for us to explore. The second one is the gatekeeper project. So for those of you are now familiar with gatekeeper is a project spearhead by Microsoft and other companies work with the open policy agent project. So it's basically a policy CRD project. So gatekeeper helps define a way that you can use policy to do the mission control and other stuff in Kubernetes through OPA. So gatekeeper is I think is very promising. They have made a lot of progress and will keep working very closely with the gatekeeper project. And also there will be some very interesting planning for OPA like the Wazem support. Very interesting for us. Another big thing, the third item is the policy security policy migration. So there are discussions about actually migrate the security policy of the core Kubernetes mechanism into a like auto tree operation. So gatekeeper is actually one of the choice under consideration by Seagoth and so we also work very closely with gatekeeper folks to see if we can use gatekeeper actually to do the policy security policy. How do we do that? I think this is one of the most interesting experiment we'll be conducting in the second half of this year. So some new things. The first new experiment we're also running is the formal verification for policy. So formal verification is sort of not the type of thing you usually thinking about for cloud computing is usually done mostly in research. So you have a way of formally verify a mechanism and identify many of the corner cases. So what we find interesting for policy is that we need a way to know how the policy is defined correctly and also when the policy is enforced executed, whether it is executed correctly. So there comes the proposal for the formal verification. So I will spare you the details if you are familiar with the first order logic. You'll be familiar with the SMT solvers. So basically this is what the formal verification is. So we try to verify this logic expression. There are many open source SMT solvers we can take into consideration. I think these three is the most mentioned one. So in order to do the formal verification one thing we need to do for policy is to actually construct a symbolic graph to abstract the policy description for Kubernetes. So for each domain the graph will be different. For example networking will be looking at something like this and for multi-tenancy it will be something like this. You have a privilege escalation or de-escalation from the root to many of the tenant you populated. And for security, mostly likely you have this type of graph. So each domain probably will have different graphs. So the current discussion, we are having discussion with the AWS Automated Reasoning Group. Also with folks from JPMorgan because banking, the financial industry like having the biggest requirement for the formal verification. So the current target is to looking at the use case for privilege escalation because privilege escalation is useful in several use cases. For example for the Kubernetes operator lifecycle management for multi-tenancy and also like in Istio, like out of Kubernetes, Istio also has the problem of doing the privilege escalation or de-escalation. So if you are also interested, you can send me an email or the other working group co-lead Erika to contact us. Policy as a type system. So basically you can view the Kubernetes policy as a type for your whole cluster. So similar to the type we know for the programming language like the integer coding point, the policy here actually serves as a constraint. So as a type system. So basically a policy or Kubernetes policy defines these four things. And so also I won't go into details. I think one of the things that we want to emphasize is a policy different from configuration in a way that policy expect result. So when you define a policy you have to define the result and when a certain action is taken you know there has to be either reward or punishment for certain result. But for configuration you don't expect a certain result you just config. Okay just a couple examples of how we view policy as a type system. So outside of Kubernetes we also have CFY collaboration. We are part of the CNCF security seek. So we are also constructing a cloud native policy white paper. So this is the architecture we are currently having. As you can see we have formal verification, policy engine and a compiler in the sense of Kubernetes CRD controller. So if you are interested you are also welcome to contribute to the white paper. Okay so the best way to contribute or get in contact with the working group is to look at the document. We have a document for all the meeting minutes agenda. All the information is on this document. If you go on Slack we are on a work group policy or you go to the seek security channel. We are on there as well. Okay. Thank you very much.