Kubernetes Internal Resources
Pod Security Policy
Kubernetes Pod Security Policy (PSP) is a cluster-wide resource. It let you control Pod's security-sensitive attributes conformity at creation and modification. Use cases are quite easy to find for example restrain volume type access, privileges, enable read-only file system... It is currently in Beta with the Kubernetes v1.19. To use it you need to turn on the admission controller:
It's important to note that this security measure will not impact your Kubernetes cluster performance. As it runs as an admission controller it will intercept requests to the Kubernetes API and verify their conformity to the PSP.
Then you can create your resources in a Kubernetes cluster like in the following example:
In this example the PSP let you block all pod requesting access to run in a privileged access mod:
In order to add more flexibility and granularity, it is important to note that a PSP can be attached to a Role or Cluster Role. To test the previous code you may need to add rules to your current user.
❗️You should take care when you use this feature in certain cloud providers❗️
For Example, Azure will deprecate this feature after February 1st, 2021. It will no longer be available in favor of Azure Policy for AKS.
Network Security Policy
NetworkPolicy is a Kubernetes resource, it let you control the traffic flow at the IP address or port level. Before using them you should install the Network Plugin In practice, imagine the case of a classic Web application compose of a FrontEnd, Middleware, and a database. In this case, you may want to restrain access to your Database by giving it access only from your middleware.
When you are using Network Policy you should just keep in mind that it applies only to low-level traffic, can't block traffic from a pod to the same pod.
Role Base Access control is one of the most important security concepts in K8s. You may find many articles on it explaining how it works. To sum up it can control the access of resources for users or other resources inside the cluster. You should read with attention the documentation moreover take care of some special features of Kubernetes like Secrets as detail in this article.
Kubernetes External Tools
With a growing community, a lot of external projects are developed to help scan and improve your cluster security In this domain, AquaSecurity is the main actor in the community. You can find several of their tools on Github for example:
Monitoring and alerting is always a good practice. In case of an incident, it could be useful to have all the metrics of your cluster to determine the breach or impact. You can find many tools in the Padok article dedicated to Monitoring linked before.
References / standards
Some organization are currently trying or have already defined standards for example:
CIS creates a benchmark that is used by Kube-bench to verify if your cluster is securely deployed.
Security is a trending topic nowadays especially in the context of Kubernetes. This technology gives us access to several resources to manage the security context.
Configure and properly use those security resources is important. To help you check this the ever-growing Kubernetes community offer tools like Kube-Bench.
Like always using a vulnerable component will influence the global security of your cluster even if it will be confined by your well configure Kubernetes cluster.
To support all those tools standards are being defined by major references in the security domain like CIS or OWASP.
I hope this article will help you gain global knowledge concerning the Kubernetes security tools/resources context. In the future, I will try to do a more technical review related to Kubernetes security.