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

How to simplify the Pod security strategy in production, in view of this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Pod security policy is very important to strengthen the security of K8S cluster. This article continues the previous article with an in-depth introduction to Pod security policy.

First, I briefly introduced how to associate Pod with Pod security policy, and use RBAC to show the specific steps. It then describes how to enable the default PSP in Rancher and create a custom PSP. Finally, we will use a tool to simplify the use of Pod security policy in production and greatly improve productivity.

We deliberately omitted the details of role-based access control (RBAC) and how to connect Pod to a specific PSP. So let's continue to delve deeper into PSP.

Match Pod with Pod security policy

You may have noticed that the PSP schema is not associated with any Kubernetes namespace, Service Account, or Pod. In fact, PSP is a cluster-wide resource. So how do we specify which Pod should be managed by which PSP? The following figure shows how all participating components, resources, and the admission process work.

Maybe it sounds complicated at first. Now, let's introduce it in detail.

When deploying a Pod, the admission control applies the policy based on the object requesting the deployment.

The Pod itself does not have any associated policies-- it is service account that executes the Deployment. In the figure above, Jorge deploys pod using webapp-sa service account.

RoleBinding associates service account with Roles (or ClusterRoles), and Role is a resource that specifies that PSP can be used. In this figure, webapp-sa is associated with webapp-role, which provides permissions for specific PSP resources. When you deploy Pod, the Pod is checked against webapp-sa PSP. In fact, a service account can use multiple PSP, and it is sufficient that one of them can verify the Pod. You can view the details in the official documentation:

Https://kubernetes.io/docs/concepts/policy/pod-security-policy/#policy-order

The admission control will then determine whether the Pod conforms to any of these PSP. If the Pod meets the requirements, the admission control will dispatch the Pod;. If the Pod is not compliant, it will block the deployment.

The above can be summarized as follows:

The identity of Pod is determined by its service account.

If no service account is declared in the specification, the default account will be used

You need to allow the use of declaration Role or ClusterRole

Finally, you need a RoleBinding that associates Role (thus allowing access to PSP) with the Servcie Account declared in the Pod specification.

Let's use some examples to illustrate.

A real example of RBAC

Suppose you already have a cluster with PSP enabled, which is a common way to create a restricted PSP using PSP, which can be used by any Pod. Then you will add a more specific PSP, which has additional privileges to bind to a specific service account. Having a default, secure, and strict policy helps with cluster management, because most Pod do not require special privileges or features and can run by default. Then, if some of your workloads require additional privileges, we can create a custom PSP and bind a specific service account for that workload to a less restrictive PSP.

But how do you bind Pod to a specific PSP instead of the default restricted PSP? And how do you do this using a normal Kubernetes cluster that doesn't automatically add RoleBindings?

Let's look at a complete example where we define some secure default values (restricted PSP that any service account in the cluster can use), and then provide additional privileges to a single service account for a particular deployment that requires the service.

First, we manually create a new namespace. It is not managed by Rancher, so the RoleBindings is not created automatically. Then we try to deploy a restricted Pod in this namespace:

$kubectl create ns psp-test$ cat deploy-not-privileged.yamlapiVersion: apps/v1kind: Deploymentmetadata: labels: app: not-privileged-deploy name: not-privileged-deployspec: replicas: 1 selector: matchLabels: app: not-privileged-deploy template: metadata: labels: app: not-privileged-deployspec: containers:-image: alpine name: alpine stdin: true tty: true securityContext: runAsUser: 1000 RunAsGroup: 1000$ kubectl-n psp-test apply-f deploy-not-privileged.yaml$ kubectl-n psp-test describe rs... Warning FailedCreate 4s (x12 over 15s) replicaset-controller Error creating: pods "not-privileged-deploy-684696d5b5-" is forbidden: unable to validate against any pod security policy: []

Pod cannot be created because there is no RoleBinding in the namespace psp-test and the namespace is bound to a role that allows the use of any PSP. We will solve this problem by creating cluster-wide ClusterRole and ClusterRoleBinding to allow any Service Account to use restricted PSP by default. When PSP was enabled in the previous article, Rancher created a restricted PSP.

ResourceNames:-restricted-psp---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: restricted-role-bindroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: use-restricted-pspsubjects:- apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts$ kubectl apply-f clusterrole-use-restricted.yaml

After we apply these changes, the unprivileged deployment should work properly.

However, if we need to deploy a privileged Pod, it will not be allowed by the existing policy:

Cat deploy-privileged.yamlapiVersion: v1kind: ServiceAccountmetadata: name: privileged-sa namespace: psp-test---apiVersion: apps/v1kind: Deploymentmetadata: labels: app: privileged-deploy name: privileged-deploy namespace: psp-testspec: replicas: 1 selector: matchLabels: app: privileged-deploy template: metadata: labels: app: privileged-deploy spec: containers:-image: alpine name: alpine stdin: true Tty: true securityContext: privileged: true hostPID: true hostNetwork: true serviceAccountName: privileged-sa$ kubectl-n psp-test apply-f deploy-privileged.yaml$ kubectl-n psp-test describe rs privileged-deploy-7569b9969dName: privileged-deploy-7569b9969dNamespace: defaultSelector: app=privileged-deploy Pod-template-hash=7569b9969dLabels: app=privileged-deploy...Events: Type Reason Age From Message-Warning FailedCreate 4s (x14 over 45s) replicaset-controller Error creating: pods "privileged-deploy-7569b9969d- "is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.securityContext.hostPID: Invalid value: true: Host PID is not allowed to be used spec.containers [0] .securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

In this case, because we created ClusterRoleBinding, Pod can use PSP, but restricted-psp does not validate Pod because it requires parameters such as privileged, hostNetwork, and so on.

We have seen the restricted-psp strategy in the previous article. Let's examine the details of default-psp, which was created by Rancher when PSP was enabled to allow these privileges:

$kubectl get psp default-psp-o yamlapiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames:'* 'creationTimestamp: "2020-03-10T08:45:08Z" name: default-psp resourceVersion: "144774" selfLink: / apis/policy/v1beta1/podsecuritypolicies/default-psp uid: 1f83b803-bbee-483c-8f66-bfa65feaef56spec: allowPrivilegeEscalation: true allowedCapabilities: -' * 'fsGroup: rule: RunAsAny hostIPC: true hostNetwork: true hostPID : true hostPorts:-max: 65535 min: 0 privileged: true runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: -'*'

You can see that this is a very loose policy, especially when we allow privileged, hostNetwork, hostPID, hostIPC, hostPorts and other functions to run as root.

We just need to explicitly allow the Pod to use PSP. We bind privileged-sa ServiceAccount to this psp-test by creating a ClusterRole similar to the existing ClusterRole, but allowing the use of default-psp resources, and then creating a RoleBinding for our psp-test namespace:

$cat clusterrole-use-privileged.yaml---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: use-privileged-psprules:- apiGroups: ['policy'] resources: [' podsecuritypolicies'] verbs: ['use'] resourceNames:-default-psp--- apiVersion: rbac.authorization.k8s.io/v1kind: RoleBinding metadata: name: privileged-role-bind namespace: psp-test roleRef: apiGroup: rbac.authorization.k8s.io Kind: ClusterRole name: use-privileged-psp subjects:-kind: ServiceAccount name: privileged-sa$ kubectl-n psp-test apply-f clusterrole-use-privileged.yaml

After a while, the privileged Pod will be created. Then you will notice that restricted-psp and default-psp are now ready to use directly. Next, let's introduce them in more detail.

Default PSP on Rancher

Enable PSP admission control in Rancher by editing the cluster settings, and select one of the defined PSP as the default option:

Rancher will create a pair of PSP resources in the cluster:

Restricted-psp: if you choose "restricted" as the default PSP

Default-psp: the default PSP, which allows the creation of privileged Pod.

In addition to restricted-psp and default-psp,Rancher, a ClusterRole named restricted-clusterrole is created:

Annotations: serviceaccount.cluster.cattle.io/pod-security: restricted creationTimestamp: "2020-03-10T08:44:39Z" labels: cattle.io/creator: norman name: restricted-clusterrolerules:- apiGroups:-extensions resourceNames:-restricted-psp resources:-podsecuritypolicies verbs:-use

This ClusterRole allows the use of restricted-psp policies. So where can Binding allow authorization to use pod ServiceAccount?

For namespaces that belong to projects in Rancher, it also sets the RoleBinding configuration for you:

$kubectl-n default get rolebinding default-default-default-restricted-clusterrole-binding-o yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: annotations: podsecuritypolicy.rbac.user.cattle.io/psptpb-role-binding: "true" serviceaccount.cluster.cattle.io/pod-security: restricted labels: cattle.io/creator: norman name: default-default-default-restricted-clusterrole-binding namespace: default...roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name : restricted-clusterrolesubjects:- kind: ServiceAccount name: default namespace: default

The resource name (default-default-default-restricted-clusterrole-binding) can be confusing, but in fact it consists of:

Default-serviceaccountname-namespace-restricted-clusterrole-binding

And if you create a new serviceaccount similar to myserviceaccount, a new role binding will be automatically created:

$kubectl create sa myserviceaccountserviceaccount/myserviceaccount created$ kubectl get rolebindingNAME AGE---default-default-default-restricted-clusterrole-binding 13mdefault-myserviceaccount-default-restricted-clusterrole-binding 4s

With this amazing feature, you don't need to configure RBAC for secure pod that doesn't require any elevated privileges.

Create your PSP in Rancher

PSP is a standard Kubernetes resource, and the whole process is Pod security policy, so you can use it through Kubernetes API or kubectl CLI.

You can create your custom PSP by defining them in the YAML file, and then use kubectl to create resources in the cluster. Check the official documentation to learn about all available controls (https://kubernetes.io/docs/concepts/policy/pod-security-policy/). After defining the control set in YAML, you can run:

$kubectl create psp my-custom-psp

To create a PSP resource.

With Rancher, you can view or add new policies directly from UI:

PSP is very powerful, but also very complex.

Configuring Pod security policies is a tedious process. After you enable PSP in the Kubernetes cluster, any Pod you want to deploy must be allowed through one of the PSP. Implementing strong security policies can be time-consuming, and it can be a burden to generate one for each deployment of each application. If your policy is very loose, the least privileged access method is not enforced; however, if it has many restrictions, you may break your application because Pod cannot run successfully in Kubernetes.

The ability to automatically generate Pod security policies with a minimum set of access requirements will help you install PSP more easily. And you can't just deploy them in a production environment without verifying that your application works, and manual testing is cumbersome and inefficient. What if you could validate PSP against the runtime behavior of Kubernetes workloads?

How to simplify the use of PSP in a production environment?

Kubernetes Pod security policy Advisor (also known as kube-psp-advisor) is an open source tool for Sysdig. Kube-psp-advisor scans the existing security context from Kubernetes resources (such as deployment, daemonset, replicaset, etc.) as the reference model we want to execute, and then automatically generates Pod security policies for all resources throughout the cluster. Kube-psp-advisor creates the recommended Pod security policy by looking at different properties:

AllowPrivilegeEscalation

AllowedCapabilities

AllowedHostPaths

HostIPC

HostNetwork

HostPID

Privileged

ReadOnlyRootFilesystem

RunAsUser

Volume

Check out the kube-psp-advisor tutorial for more details on how it works:

Https://sysdig.com/blog/enable-kubernetes-pod-security-policy/

Automatically generate PSP using Sysdig Secure

Sysdig Secure Kubernetes Policy Advisor can help users create and validate Pod security policies.

The first step is to set up a new PSP emulation environment. You can perform multiple simulations for different strategies in different ranges (such as Kubernetes namespaces).

Sysdig analyzes the requirements of the Pod specification in your Deployment definition and creates the least privileged PSP for your application. This controls whether privileged Pod is allowed, which the user runs as a container, volume, and so on. Ni can fine-tune PSP and define namespaces for the simulation environment you are about to run:

The policy on the left destroys the application because nginx Deployment is a privileged Pod and has host network access. You must decide whether to expand the PSP to allow this behavior, or choose to reduce the privileges of the Deployment to accommodate the strategy. In any case, you will detect this before you apply PSP, which will prevent Pod from running and cause damage to application deployment. By granting or denying access to specific resources, PSP gives you fine-grained control over the Pod and containers running in Kubernetes. These policies are relatively easy to create and deploy and should be useful components of any Kubernetes security policy.

This is the answer to the question on how to simplify the Pod security strategy in production. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.