Is Your Organization Updated With The Best Practices of Kubernetes Security?

Read time: 3 minutes 42 seconds

Kubernetes is an open-source container-orchestration system used to automate deploy, scale, and manage containerized applications. Kubernetes manages all elements that make up a cluster, including each microservice in an application to entire clusters. Organizations using these containerized applications as microservices can provide them more flexibility and security benefits than monolithic software platforms and introduce other complexities.

Recommendations

1. Kubernetes Pod security
   1. Containers built to run applications should run as non-root users
   2. Run containers with immutable file systems whenever possible
   3. Regularly scan container images for potential vulnerabilities or misconfigurations
   4. Use Pod Security Policies to enforce a minimum level of security, including:
      1. Preventing privileged containers
      2. Denying container features that are frequently exploited to breakout, like hostPID, hostIPC, hostNetwork, allowedHostPath
      3. Rejecting containers that execute as root user or allow elevation to root
2. Network separation and hardening
   1. Lockdown access to the control plane nodes using a firewall and RBAC (Role-Based Access Control)
   2. Limiting access to the Kubernetes, etcd server
   3. Configuring control plane components to use authenticated, encrypted communications using TLS/SSL certificates
   4. Set up network policies to isolate resources. Pods and services in different namespaces can communicate unless additional separation is applied, such as network policies.
   5. All credentials and sensitive information should be placed in Kubernetes Secrets rather than in configuration files. Encrypt Secrets using a robust encryption method
3. Authentication and authorization
   1. Disable anonymous login
   2. Using strong user authentication
   3. Create RBAC policies that limit administrator, user, and service account activity
4. Log auditing
   1. Enable audit logging
   2. Persist logs to ensure availability in case of pod, node, or container level failure
   3. Configuring a metrics logger
5. Upgrading and application security practices
   1. Immediately apply security patches and updates
   2. Performing periodic vulnerability scans and penetration tests
   3. Removing components from the environment when they are no longer needed

Architectural overview

Kubernetes uses a cluster architecture. A Kubernetes cluster comprises many control planes and one or more physical or virtual machines called worker nodes which host Pods, which contain one or more containers. The container is an executable image that includes a software package and all its dependencies.

The control plane makes decisions about clusters. This includes scheduling the running of containers, detecting/responding to failures, and starting new Pods if the number of replicas listed in the deployment file is unsatisfied.

Kubernetes Pod security

Pods consist of one or more containers and are the smallest deployable Kubernetes unit. Pods can often be a cyber actor’s initial execution environment upon exploiting a container. Pods should be hardened to make exploitation much more complex and limit the impact on compromise.

“Non-root” and “rootless” container engines

Many container services run as privileged root users, and applications can execute inside the container as root despite not requiring privileged execution. Preventing root execution using non-root containers or a rootless container engine limits the impact of a container compromise. These methods affect the runtime environment significantly; thus, applications should be tested thoroughly to ensure compatibility.

Non-root containers

Container engines that allow containers to run applications as non-root users with non-root group membership. This non-default setting is configured while building the image.

Rootless container engines

Some container engines can run in an unprivileged context rather than using a daemon running as root. For this scenario, execution would appear to use the root user from the containerized application’s perspective, but the execution is remapped to the engine’s user context on the host.

Immutable container file systems

Containers are permitted mostly unrestricted execution within their context. A threat actor who has gained execution in a container can create files, download scripts, and modify applications within the container. Kubernetes can lockdown a container’s file system, thereby preventing many post-exploitation activities. These limitations can also affect legitimate container applications and can also potentially result in crashes or abnormal behavior. Kubernetes administrators can mount secondary read/write file systems for specific directories where applications require write access to prevent legitimate damaging applications.

Building secure container images

Container images are usually created by either building a container from scratch or building on top of an existing image pulled from a repository. Even after using trusted repositories to build containers, image scanning is key to ensuring deployed containers are secure. Images should be scanned throughout the container build workflow to identify outdated libraries, known vulnerabilities, or misconfigurations, such as insecure ports or permissions.

One approach for implementing image scanning is by using an admission controller. Admission controller is a Kubernetes-native feature that can intercept and process requests to the Kubernetes API before the persistence of the object but after a request is authenticated and authorized. A custom webhook can be implemented to scan any image before deploying it in the cluster. The admission controller could block deployments if the picture doesn’t comply with the security policies defined in the webhook configuration.

Conclusion

This was an introduction to properly managing and securing Kubernetes clusters and securely deploying them in your environment. We will dive deeper into more controls and policies organizations can use to strengthen their security.