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

This article mainly explains "how to create Kubernetes PodSecurityPolicy". The content in the article is simple and clear, easy to learn and understand. Please follow the editor's train of thought to study and learn "how to create Kubernetes PodSecurityPolicy".

PodSecurityPolicy introduction

By default, Kubernetes allows you to create a Pod with privileged containers that are likely to threaten system security, while PodSecurityPolicy (PSP) protects the cluster from privileged Pod by ensuring that requesters have permission to create Pod as configured.

PodSecurityPolicy is a cluster-level resource that controls how Pod runs and what it can access. The PodSecurityPolicy object defines a set of conditions that indicate that Pod must run under conditions that the system can accept.

Here is what PodSecurityPolicy can control:

PodSecurityPolicy are Kubernetes API objects, and you can create them without making any changes to Kubernetes. However, some of the policies we created are not enforced by default. We need an admission controller, kube-controller-manager configuration, and RBAC permission configuration. Let's explain these configurations one by one.

Admission Controller

Edit / etc/kubernetes/manifest/kube-apiserver.yaml, add PodSecurityPolicy, enable controller for PSP.

-enable-admission-plugins=NodeRestriction,PodSecurityPolicy

But at this point, our cluster now lacks some security policies, so the creation of the new Pod will fail. Create a Pod from the following file:

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploy namespace: default labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.15.4

But the replicaset controller does not create a Pod, so you need to use ServiceAccount at this point.

# kubectl describe rs nginx-hostnetwork-deploy-76c46fdb6Name: nginx-hostnetwork-deploy-76c46fdb6Namespace: defaultSelector: app=nginx Pod-template-hash=76c46fdb6Labels: app=nginx pod-template-hash=76c46fdb6Annotations: deployment.kubernetes.io/desired-replicas: 1 deployment.kubernetes.io/max-replicas: 2 deployment.kubernetes.io/revision: 1Controlled By: Deployment/nginx-hostnetwork-deployReplicas: 0 current / 1 desiredPods Status: 0 Running / 0 Waiting / 0 Succeeded / 0 FailedPod Template: Labels: app=nginx pod-template -hash=76c46fdb6 Containers: nginx: Image: nginx:1.15.4 Port: Host Port: Environment: Mounts: Volumes: Conditions: Type Status Reason-ReplicaFailure True FailedCreateEvents: Type Reason Age From Message-Warning FailedCreate 1s (x12 over 11s) replicaset-controller Error creating: pods "nginx-hostnetwork-deploy-76c46fdb6-" is forbidden: PodSecurityPolicy: no providers available to validate pod requestServiceAccount Controller Manager

Generally speaking, users rarely create Pod directly, usually through controllers such as Deployment, StatefulSet, Job or DasemonSet. Here we need to configure kube-controller-manager to use a separate ServiceAccount for each controller it contains. We can do this by adding the following flag to its command startup parameters. Edit / etc/kubernetes/manifest/kube-controller-manager.yaml, add:

-- use-service-account-credentials=true

In general, the above flag is turned on by default in most installation tools (such as kubeadm), so you don't need to configure it separately.

When kube-controller-manager turns on the above flag, it uses the following ServiceAccount automatically generated by Kubernetes:

# kubectl get serviceaccount-n kube-system | egrep-o'[A-Za-z0-9 -] +-controller'attachdetach-controllercalico-kube-controllercertificate-controllerclusterrole-aggregation-controllercronjob-controllerdaemon-set-controllerdeployment-controllerdisruption-controllerendpoint-controllerexpand-controllerjob-controllernamespace-controllernode-controllerpv-protection-controllerpvc-protection-controllerreplicaset-controllerreplication-controllerresourcequota-controllerservice-account-controllerservice-controllerstatefulset-controllerttl-controller

These ServiceAccount specify which controller can resolve the configuration of which policies.

PodSecurityPolicy

In our current example, we will create two policies, the first of which is to provide a "default" policy to restrict access, ensuring that the Pod cannot be created when using certain privilege settings, such as using hostNetwork. The second is an "elevated" licensing policy that allows privileges to be set for certain Pod, such as permissions for Pod created under the kube-system namespace.

First, create a restrictive policy as the default policy: (psp-restrictive.yaml)

ApiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: restrictivespec: privileged: false hostNetwork: false allowPrivilegeEscalation: false defaultAllowPrivilegeEscalation: false hostPID: false hostIPC: false runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes:-'configMap' -' downwardAPI'-'emptyDir' -' persistentVolumeClaim'-'secret' -' projected' allowedCapabilities: -'*

Although restricted access is sufficient for most Pod creations, for Pod that needs to elevate access, some permission policies are needed. For example, kube-proxy needs to enable hostNetwork, which requires the creation of a permission policy to elevate creation permissions: (psp-permissive.yaml)

ApiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: permissivespec: privileged: true hostNetwork: true hostIPC: true hostPID: true seLinux: rule: RunAsAny supplementalGroups: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny hostPorts:-min: 0 max: 65535 volumes: -'* 'RBAC

Now that the configuration is in place, we need to introduce Kubernetes authorization so that we can determine whether the user requesting Pod creation or ServiceAccount has resolved the restrictive or permissible policy, which requires RBAC.

When we enable the Pod security policy, there may be confusion about RBAC. It determines the policies that can be used by an account, and using cluster-wide ClusterRoleBinding can provide ServiceAccount (such as replicaset-controller) with access to restrictive policies. Using namespace-scoped RoleBinding, you can enable access to license policies so that you can operate in a specific namespace, such as kube-system. The following demonstrates the resolution path for daemonset-controller to create kube-proxy Pod:

Start by creating a ClusterRole that allows the use of restrictive policies. Then create a ClusterRoleBinding that binds the restrictive policy to all controller ServiceAccount in the kube-system namespace of the system: (psp-restrictive-rbac.yaml)

Kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: psp-restrictiverules:- apiGroups:-extensions resources:-podsecuritypolicies resourceNames:-restrictive verbs:-use---kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: psp-defaultsubjects:- kind: Group name: system:serviceaccounts namespace: kube-systemroleRef: kind: ClusterRole name: psp-restrictive apiGroup: rbac.authorization.k8s.io

Then let's recreate the Deployment we defined above:

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploy namespace: default labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.15.4

After the creation is completed, also take a look at some of the resource objects we created under the default namespace:

# kubectl get po,rs Deploy- l app=nginxNAME READY STATUS RESTARTS AGEpod/nginx-deploy-77f7d4c6b4-njfdl 1/1 Running 0 13sNAME DESIRED CURRENT READY AGEreplicaset.extensions/nginx-deploy-77f7d4c6b4 1 1 1 13sNAME READY UP-TO-DATE AVAILABLE AGEdeployment.extensions/nginx-deploy 1/1 1 1 13s

We can see that the Pods is successfully created, but if we try to do something that is not allowed by policy, it should normally be rejected. Now let's add hostNetwork: true to nginx-deploy to use the privilege of hostNetwork: (nginx-hostnetwork.yaml)

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-hostnetwork-deploy namespace: default labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.15.4 hostNetwork: true # pay attention to adding hostNetwork

After the creation, also look at some resource objects under the namespace default:

# kubectl get po,rs Deploy- l app=nginxNAME READY STATUS RESTARTS AGENAME DESIRED CURRENT READY AGEreplicaset.extensions/nginx-hostnetwork-deploy-74c8fbd687 1 0 0 44sNAME READY UP-TO-DATE AVAILABLE AGEdeployment.extensions/nginx-hostnetwork-deploy 0/1 0 0 44s

Now that we find that ReplicaSet has not created Pod again, we can use the kubectl describe command to view the ReplicaSet resource object we created here for more information:

# kubectl describe rs nginx-hostnetwork-deploy-74c8fbd687Name: nginx-hostnetwork-deploy-74c8fbd687.Events: Type Reason Age From Message-Warning FailedCreate 80s (x15 over 2m42s) replicaset-controller Error creating: pods "nginx-hostnetwork-deploy-74c8fbd687-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used]

We can see that Hostnetwork is obviously not allowed, but in some cases, we do create a Pod that uses hostNetwork under a namespace (such as kube-system), so we need to create a ClusterRole that allows execution, and then create a RoleBinding for a specific namespace, binding the ClusterRole here to the associated controller ServiceAccount: (psp-permissive-rbac.yaml)

Kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: psp-permissiverules:- apiGroups:-extensions resources:-podsecuritypolicies resourceNames:-permissive verbs:-use---apiVersion: rbac.authorization.k8s.io/v1beta1kind: RoleBindingmetadata: name: psp-permissive namespace: kube-systemroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: psp-permissivesubjects:- kind: ServiceAccount name: daemon-set-controller namespace: kube-system- kind: ServiceAccount name: replicaset-controller namespace: kube-system -kind: ServiceAccount name: job-controller namespace: kube-system

Now we can use hostNetwork under the kube-system namespace to create the Pod, changing the above nginx resource list to the following kube-system namespace:

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-hostnetwork-deploy namespace: kube-system labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.15.4 hostNetwork: true

After the creation is completed, also check the corresponding resource object creation:

# kubectl get po,rs Deploy- n kube-system-l app=nginxNAME READY STATUS RESTARTS AGEpod/nginx-hostnetwork-deploy-74c8fbd687-7x8px 1 Running 0 2m1sNAME DESIRED CURRENT READY AGEreplicaset.extensions/nginx-hostnetwork-deploy-74c8fbd687 1 1 1 2m1sNAME READY UP-TO-DATE AVAILABLE AGEdeployment.extensions/nginx-hostnetwork-deploy 1/1 1 1 2m1s

Now we can see that Pod has been created successfully under the namespace kube-system.

Application-specific ServiceAccount

What if we now have a requirement to enforce the restrictive (restrictive) policy we created under a namespace, but an application under that namespace needs to use the permissive (license) policy? In the current model, we only have cluster-level and namespace-level resolution. In order to provide a separate licensing policy for an application, we can provide the application's ServiceAccount with the ability to use the ClusterRole of permissive.

For example, create a ServiceAccount named specialsa under the default namespace:

Kubectl create serviceaccount specialsa

Then create a RoleBinding to bind the specialsa to the above psp-permissive CluterRole: (specialsa-psp.yaml)

ApiVersion: rbac.authorization.k8s.io/v1beta1kind: RoleBindingmetadata: name: specialsa-psp-permissive namespace: defaultroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: psp-permissivesubjects:- kind: ServiceAccount name: specialsa namespace: default

Then add the serviceAccount attribute to our above Deployment: (nginx-hostnetwork-sa.yaml)

ApiVersion: apps/v1kind: Deploymentmetadata: name: nginx-hostnetwork-deploy namespace: default labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.15.4 hostNetwork: true serviceAccount: specialsa # Note the permission binding of sa used here

At this point, we check that the Pod with hostNetwork under the default namespace has also been created successfully:

# kubectl get po,rs Deploy- l app=nginxNAME READY STATUS RESTARTS AGEpod/nginx-hostnetwork-deploy-6c85dfbf95-hqt8j 1/1 Running 0 65sNAME DESIRED CURRENT READY AGEreplicaset.extensions/nginx-hostnetwork-deploy-6c85dfbf95 1 1 1 65sreplicaset.extensions/nginx -hostnetwork-deploy-74c8fbd687 000 31mNAME READY UP-TO-DATE AVAILABLE AGEdeployment.extensions/nginx-hostnetwork-deploy 1amp 1 1 1 31m Thank you for your reading The above is the content of "how to create Kubernetes PodSecurityPolicy". After the study of this article, I believe you have a deeper understanding of how to create Kubernetes PodSecurityPolicy, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.