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 !!!!