# KubeSlice security with a focus on 1.25's PSP deprecation blog [WIP]

In Kubeslice security is something that is Step 0 rather than an afterthought, today we will discuss about the security features Kubeslice provides.

Kubernetes itself is a vast ecosystem, with its continuous growth there are things that are deprecated, [Pod Security Policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/)(PSP) is one of those things.

#### So what exactly is Pod Security Policies?
> PodSecurityPolicy is a built-in [admission controller](https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/) that allows a cluster administrator to control security-sensitive aspects of the Pod specification.
One or more PodSecurityPolicy resources are created in a cluster to define the requirements Pods must meet. Then, RBAC rules are created to control which PodSecurityPolicy applies to a given pod. If a pod meets the requirements of its PSP, it will be admitted to the cluster as usual.

**Note**: The [Kubernetes 1.25 release](https://kubernetes.io/blog/2022/08/04/upcoming-changes-in-kubernetes-1-25/) will remove PSP so if you rely on PSP you should follow the instructions for [migration to Pod Security Admission](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/)

### How KubeSlice implements Security and PSS?
KubeSlice segregates the Network using Slices as applications shouldn't need to communicate with all the resources in the cluster this reduces the blast radius, kubeslice creates slices, which is a collection of namespaces, network, applications over clusters or over different clouds.

Kubernetes defines a standard called [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)(PSS),
>The Pod Security Standards define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly-permissive to highly-restrictive.

This guide outlines the requirements of each policy.
| Profile | Description
| -------- | -------- |
| Privileged | Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. |
|Baseline|Minimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration.|
|Restricted|Heavily restricted policy, following current Pod hardening best practices.|

These are Cluster and namespace specific.

However, since Kubeslice creates slices which can span over clusters one can create a secure slice by setting the Pod Security Standards(PSS) for a set of namespaces, these namespaces will then reside inside a slice.

This is how KubeSlice helps with security and reduces the blast radius, this also solves issues that occur on multi-tenant clusters, while securing the applications.

If you want to know more about the project, we encourage you to raise questions in the #kubeslice channel on the [Kubernetes slack](https://slack.k8s.io/) where we hang out. To receive an invite for the office hours and upcoming events and latest updates about the project, join our [Google Group](https://groups.google.com/g/kubeslice-dev).

#### Further Reading
- https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/
- https://kubernetes.io/docs/concepts/security/pod-security-standards/
- https://www.tfir.io/avesha-kubeslice-removes-the-complexity-of-kubernetes-multi-tenancy/