Shulou(Shulou.com)06/01 Report--

How to use Pod security strategy to strengthen K8S security, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail, people with this need can come to learn, I hope you can gain something.

What is the Pod security policy?

Kubernetes Pod security policy (PSP) is a very important component of the Kubernetes security section. Pod security policies are cluster-level resources that control Pod security-related options and are also a mechanism to enhance the security of Kubernetes workloads. Kubernetes platform teams or cluster operators can use it to control the creation of pod and to restrict the functionality that specific users, groups, or applications can use.

To take a simple example, with PSP you can:

Prevent privileged Pod from starting and control privilege escalation.

Restrict host namespaces, networks, and file systems that Pod can access

Restrict the users / groups that can run pod.

Restrict the Volume that Pod can access

Restrict other parameters, such as run-time configuration files or read-only root file system

In this article, we will show you how to strengthen your Pod security in Rancher by enabling a simple Kubernetes security policy.

Can Pod security policy really enhance the security of K8S?

Yes, Pod security policies do enhance the security of Kubernetes. It provides Kubernetes native control mechanism to prevent threats without affecting performance, which is different from the fact that agent must intercept every action on the host.

If you have not enabled PSP in the cluster (or perform equivalent methods such as access control), Kubernetes users may generate privileged clusters. This can be maliciously exploited, such as elevating privileges to break container isolation and access other Pod/ services.

If there is no mechanism to restrict Pod spec privileges, attackers can perform any action through docker commands, such as running privileged containers, using node resources, and so on.

To quickly verify the above statement, you can execute the following script (never operate on the production cluster):

❯. / kubectl-root-in-host.shbash-4.4# whoamirootbash-4.4# hostnamesudo--alvaro-rancher-rancheragent-0-all

You can get instant root access to the Kubernetes node. Aren't you a little scared?

By following the concept of least privilege, you can securely implement PSP in the cluster and ensure that there are no unwanted permissions in the Kubernetes Pod or workload. In addition to the core philosophy of Kubernetes security, the principle of least privilege is also a general security best practice and a core requirement of compliance standards such as PCI, SOC2, or HIPAA.

To sum up:

PSP will provide default security constraints for security features granted by Pod, and the pod can be created by any user on the cluster

PSP can also help you verify compliance by meeting specific compliance benchmarks

Minimum privilege is a concept and a practice that limits access to users, accounts, and computing processes to only the resources needed to perform daily legitimate activities.

Enable Pod security policy in your cluster

In Kubernetes, the Pod security policy can be implemented as Admission Controller. To enable PSP in your cluster, make sure that PodSecurityPolicy is in the enable-admission-plugins list and passed as a parameter to your Kubernetes API configuration:

-- enable-admission-plugins=...,PodSecurityPolicy

Cloud providers that provide managed Kubernetes clusters (you don't have direct access to the API configuration) usually provide advanced settings and users can enable PSP across the entire cluster. In other cases, you may need to edit the / etc/kubernetes/manifests/kube-apiserver.yaml file and add it to the appropriate command parameters.

In Rancher, you can easily enable PSP by editing the cluster on UI:

You can choose which Pod security policy to apply by default. In this example, we chose restricted (restricted).

The advantage of using an Admission controller to enable PSP is that it provides an immediate prevention mechanism that can even stop deploying an overprivileged Pod before scheduling. The disadvantage is that after you enable a PSP, each pod needs to be approved by PSP, making its deployment and transition more difficult.

Enable basic Pod security policy demo in Rancher

In this section, we will demonstrate step by step how to enable the Pod security policy in the cluster through Rancher dashboard, use the restricted policy by default, and learn how to prevent the creation of privileged Pod.

The PSP object itself is a list of requirements and constraints that will be applied to pod specs. The PSP YAML is as follows:

ApiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: examplespec: allowedCapabilities:-NET_ADMIN-IPC_LOCK allowedHostPaths:-pathPrefix: / dev-pathPrefix: / run-pathPrefix: / fsGroup: rule: RunAsAny hostNetwork: true seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny privileged: true runAsUser: rule: RunAsAny volumes:-hostPath-secret

The above PSP has many permissible permissions, such as:

It allows pod to run with other Linux features such as NET_ADMIN and IPC_LOCK

It allows sensitive paths to be installed from the host

Pod can be run as a privilege

Browse the Kubernetes official documentation for a complete list of available PSP controls and their default values:

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

Let's look at an example of how to prevent privileged Pod from running in a cluster.

After enabling PSP in the cluster, try deploying a similar pod:

Deploy-not-privileged.yaml

ApiVersion: 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

It can be used immediately because we tell Rancher to enable PSP with a restricted security policy that allows unprivileged pod to operate normally, as above.

Check the contents of the default PSP, as follows:

$kubectl get psp restricted-psp-o yaml

ApiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: annotations: serviceaccount.cluster.cattle.io/pod-security: restricted serviceaccount.cluster.cattle.io/pod-security-version: "1960" creationTimestamp: "2020-03-04T19:56:10Z" labels: cattle.io/creator: norman name: restricted-psp resourceVersion: "2686" selfLink: / apis/policy/v1beta1/podsecuritypolicies/restricted-psp uid: 40957380-1d44-4e43-9333-91610e3fc079spec: allowPrivilegeEscalation: false fsGroup: ranges :-max: 65535 min: 1 rule: MustRunAs requiredDropCapabilities:-ALL runAsUser: rule: RunAsAny seLinux: RunAsAny supplementalGroups: ranges:-max: 65535 min: 1 rule: MustRunAs volumes:-configMap-emptyDir-projected-secret-downwardAPI-persistentVolumeClaim

Or check from the global perspective of Rancher. Select [Security > Pod Security Policy] and click the restricted option.

The PSP should allow any pod, as long as it runs as a standard user (not root) and does not require any privileges or special features.

Other aspects of PSP and RBAC will be discussed later. For the sake of simplicity, plus that Rancher has set up the necessary bindings for you, we will skip this section now. Let's try to deploy a privileged pod, such as the pod from the kubectl-root-in-host.sh script:

Deploy-privileged.yaml

ApiVersion: apps/v1kind: Deploymentmetadata: labels: app: privileged-deploy name: privileged-deployspec: replicas: 1 selector: matchLabels: app: privileged-deploy template: metadata: labels: app: privileged-deployspec: containers:-image: alpine name: alpine stdin: true tty: true securityContext: privileged: true hostPID: true hostNetwork: true

The pod will not enter the cluster

Warning FailedCreate 2s (x12 over 13s) 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]

PodSecurityPolicy admission controller will not allow the creation of this pod because existing PSP does not allow the use of "hostPID", "hostNetwork" or "privileged".

In this article, we enhance your Kubernetes security by enabling a simple Pod security policy in the Rancher environment. By using the default restricted PSP, we ensure that pod can only run without the need for extended security permissions. Finally, we tried to deploy a pod with many permissions and failed because the existing PSP prevented it from being dispatched to the cluster.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.