kubernetes: Pod Security Policy





After studying two As of security ( authentication,authorization ) , next is the admission control.In the last article we studied about security contexts. In this article we are going to discuss about Pod security policy.


With a Pod Security Policy, Kubernetes admins can control the security of a pod specification. But it’s more than that. Pod Security Policies are configurations that define specific security conditions that a pod must meet, in order to be accepted into a cluster. If the conditions are not met, said pod will be rejected. By making use of the PodSecurityPolicy object definition, it is possible to control the likes of:

  • A pod’s ability to run privileged containers.

  • A pod’s ability to use privilege escalation.

  • A pod’s access to volume types.

  • A pod’s access to host file systems.

  • A pod’s usage of host networking objects and configurations.

Creating a PSP


The pod security policy is defined within a YAML file. That YAML file is then applied, with the help of the kubectl command, to define the new policy.

Let’s create a new pod security policy. This policy will do the following (by way of the RunAsAny rule, which is more permissive than the runAsUser option):

  • Disable a pod’s ability to run a privileged container.

  • Allow the use of SELinux.

  • Allow the use of Linux groups.

  • Allow users to run container entry points with a different username.

  • Allow the use of fsGroup (volumes that support ownership management).

[root@node1 kubernetes]# cat  zero-privilege.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: no-privilege
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'
[root@node1 kubernetes]# kubectl create -f zero-privilege.yaml
podsecuritypolicy.policy/no-privilege created

Assign a PSP


After creating a PSP , next step is to assign it. This can be done using ClusterRole and ClusterRoleBinding.We will use the below yaml file to demonstrate it.


[root@node1 kubernetes]# cat  rbac-zero-privilege.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: no-privilege:no-privilege
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  verbs:
  - use
---

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: no-privilege:no-privilege
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: no-privilege:no-privilege
  apiGroup: rbac.authorization.k8s.io
[root@node1 kubernetes]# kubectl create -f rbac-zero-privilege.yaml
clusterrole.rbac.authorization.k8s.io/no-privilege:no-privilege created
clusterrolebinding.rbac.authorization.k8s.io/no-privilege:no-privilege created
[root@node1 kubernetes]# kubectl auth can-i use no-privilege/no-privilege
Warning: the server doesn't have a resource type 'no-privilege'
yes



Hope this article was helpful for you. Thanks for reading !!!!









253 views0 comments

Recent Posts

See All
 

Subscribe Form

©2020 by Linux Advise