More and more organizations are adopting the Kubernetes container orchestration platform. As reported by , a 2020 survey found that Kubernetes use grew to 48% of respondents in 2020—up from 27% two years earlier. This finding reflects how Kubernetes benefits those organizations that are looking to manage their containers in order to ensure there is no downtime. Container Journal For instance, Kubernetes uses load balancing to distribute container network traffic and ensure the deployment remains stable. The platform also enables admins to designate a desired state for their deployed containers, at which point Kubernetes will automatically change those containers’ actual state to the desired state at a controlled rate. Finally, Kubernetes’ specifies how the platform is capable of killing and replacing containers that don’t respond to user-defined health checks. documentation The problem? Organizations that are adopting Kubernetes are experiencing plenty of security challenges along the way. In its “State of Container and Kubernetes Security - Fall 2020” report, for instance, found that 90% of survey respondents had experienced a security incident in their Kubernetes and container environments over the previous 12 months. Two-thirds of those respondents said that they had weathered a misconfiguration incident. This was followed by a major vulnerability incident (22%), a runtime incident (17%), and a failed audit (16%). StackRox RBAC and PSPs as Limited Fixes The findings above highlight the need for admins to help defend their organizations against a security incident. One of the ways they can do this is by using Role-Based Access Control (RBAC) as a way to restrict what can run in the cluster. According to Kubernetes’ , RBAC enables admins to regulate access to an organization’s Kubernetes environment through the declaration of four objects. These are as follows: website : This Kubernetes object creates a set of permissions within a specified namespace. Role : Like a Role, a ClusterRole defines permissions, but it enables admins to do so on non-namespaced resources. Admins can thereby use this object to assign the same permissions across individual namespaces, all namespaces or cluster-scoped resources. ClusterRole : This Kubernetes object takes the permissions defined within a Role and assigns them to a user or a set of users within a specific namespace. RoleBinding : Admins can use a ClusterRoleBinding to grant a user or a set of users the same level of permissions cluster-wide. ClusterRoleBinding That being said, RBAC can take organizations’ Kubernetes security only so far. StackRox elaborated on the reason why in a : blog post "While RBAC controls are a critical part of Kubernetes security, they do not provide the ability to control the settings, content, or configuration of cluster objects. For example, you may want to allow users in a database group to create and edit deployments in the database namespace, but any pod containers in that namespace should not run as the root user. You may also have a requirement that all resource objects in your cluster have a specific set of labels." Some admins are turning to (PSPs) in response to specifically prevent their pod containers from running as root. These objects enforce a , which defines privilege and access control settings for a pod and container, in order to control what pods can be accepted into a system. They come in one of the following three varieties: Pod Security Policies security context : This is an unrestricted PSP that allows for privilege escalations. Privileged : This type of PSP has some restrictions while still allowing for privilege escalations. Baseline/Default : This is the most heavily restricted PSP; it follows pod hardening best practices and does not allow for privilege escalations. Restricted But PSPs aren’t airtight in their security functionality, either. noted in a blog post that PSPs are cumbersome to work with. They also don’t cover all security concerns such as defining resource limits for pods or ensuring that images come from a trusted registry. It’s therefore not surprising to hear industry chatter from that PSPs, a beta feature that never made it to General Availability, could be deprecated as early as sometime in 2021. Amazon TechTarget Where That Leaves Organizations Admins would be better off looking to something RBAC and other than PSPs to limit access to the cluster. In particular, they might want to consider looking into Open Policy Agent (OPA) Gatekeeper. A customizable admission webhook for Kubernetes, Gatekeeper lets admins specify configurations for customizing admission control and bring awareness to the state of their cluster. In doing so, it enables admins to limit the types of container registries from which images can be pulled, can define resource limits for pods and can perform other security functions that are beyond the scope of PSPs. in addition to Admins can learn more about how they can use Gatekeeper to advance their organizations’ Kubernetes security by . They can also learn more about Kubernetes security in general from . reading up about the project on GitHub kubernetes.io

Amazon

RBAC and PSPs Can Only Bring Your Kubernetes Security So Far

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

3 Types of Security Policies You Can Use with Your Kubernetes Pods

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

3 Types of Security Policies You Can Use with Your Kubernetes Pods

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps