Shulou(Shulou.com)05/31 Report--

Why to use OPA security policy, I believe that many inexperienced people do not know what to do about it. Therefore, this article summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

We will demonstrate how to use OPA to enforce the finest-grained security policy. Note that this article is part of a series that will build on the knowledge gained in "OPA as a Code introduction" and "integrating OPA into Kubernetes".

You may already be familiar with Pod security policies, where you can apply very specific security controls to Pod. For example, using Linux kernel features, using host namespaces, networks, ports, or file systems, and many other features. With OPA, you can also exert similar control over pods. In this lab, we will create an OPA policy that does not allow privileged containers to be created in pods. Privileged containers have a higher level of access to hosts than unprivileged containers.

Why use OPA instead of the native Pod security policy?

There is nothing wrong with using the Pod security policy to enforce our security policy. However, by definition, PSP can only be applied to pods. They cannot handle other Kubernetes resources, such as Ingresses, Deployments, Services, and so on. The power of OPA is that it can be applied to any Kubernetes resource. OPA is deployed to Kubernetes as a license controller that intercepts API calls sent to the API server and validates and / or modifies them. Accordingly, you can have a unified OPA strategy that applies to different components of the system, not just pods. For example, there is a strategy to force users to use the company's domain in their services and to ensure that users only extract images from the company's mirror repository. Note that the OPA we are using is deployed using kube-mgmt, not OPA Gatekeeper.

Policy code for Rego

In this article, we assume that you are already familiar with the OPA and Rego languages. We also assume that you have a running Kubernetes cluster with OPA and kube-mgmt containers deployed. Please refer to our previous article for installation instructions. Our no-priv-pod.rego file is as follows:

Package kubernetes.admissiondeny [msg] {c: = input_ containers [_] c.securityContext.privileged msg: = sprintf ("Privileged container is not allowed:% v, securityContext:% v", [c.name, c.securityContext])} input_ containers [c] {c: = input.request.object.spec.containers [_]} input_ containers [c] {c: = input.request.object.spec.initContainers [_]}

Let's take a brief look at this file:

Line 1: contains the package. Note that you must use kubernetes.admission to make the policy work.

Line 2: Deny is the default object, and it will contain the policies we need to implement. If the included code evaluates to true, the policy will be violated.

Line 3: we define a variable that will hold all the containers in the pod and receive values from the input_ containers [c] defined later.

Line 4: if the pod contains the "privileged" attribute, the statement is true.

Line 5: the message displayed to users when they try to run the privileged container. It includes the container name and the security context for the violation.

Line 7-9: the input_ containers [c] function extracts the container from the request object. Notice that the _ character is used to traverse all the containers in the array. In Rego, you don't need to define a loop-the underscore character will automatically do this for you.

Lines 10-12: we define the function for the init container again. Note that in Rego, you can define the same function multiple times. This is done to overcome the limitation that multiple outputs cannot be returned in the Rego function. When the function name is called, two functions are executed and the output is combined using the AND operator. Therefore, in our example, the existence of a privileged container in one or more locations would violate policy.

Deployment strategy

OPA will find its policy in the ConfigMaps of the opa namespace. To apply our code to ConfigMap, we run the following command:

Kubectl create configmap no-priv-pods-from-file=no-priv-pod.rego

The kube-mgmt sidecar container continuously monitors the API server in the opa namespace so that you can deploy the policy simply by creating a ConfigMap.

Operation strategy

Let's ensure that our strategy is effective by trying to deploy a privileged container:

Kubectl-n default apply-f-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.