Kubernetes adoption is up. According to DevPro Journal, organizations’ use of the container management platform increased to 83% in 2020—up from 78% in the previous study. This growth reflects the promise of Kubernetes in minimizing application downtime. According to its documentation, the platform helps to keep critical apps up and running by load balancing the network traffic, changing the actual state of deployed containers to a desired state defined by the user at a gradual rate and killing containers that don’t accord with specified health checks.

Notwithstanding that promise, Kubernetes is giving rise to security concerns that are undermining organizations’ business objectives. PR Newswire reported that nearly half (44%) of respondents to a 2020 survey decided to delay the deployment of cloud-native apps into production as a result of their Kubernetes security concerns, as an example. In doing so, those organizations didn’t get to enjoy the agility and speed that constitute the primary benefits of using containers and microservices.

Fernando Montenegro, principal analyst at 451 Research, explained that these findings highlight the need for more visibility. As quoted by PR Newswire:

One of the most consistent results we get on our own surveys of DevOps and cloud-native security technologies is how important security is for those environments. It is interesting to see how this observation fits well with the… study, highlighting the need for both engineering and security professionals to have visibility and then properly deploy security controls and practices for container and Kubernetes environments.

To better understand Montenegro’s thoughts, it’s useful to understand how visibility relates to Kubernetes security. Let’s explore this below.

Why Visibility in Kubernetes Matters

Kubernetes visibility isn’t something that organizations can overlook. Indeed, they first need to have an understanding of what’s being deployed, where it’s being deployed in the network, what it can access and whether it’s compliant. Using that information, admins can then direct their attention to specific areas of their Kubernetes environment not only for remediation but also for hardening and for implementing proper segmentation.

These areas include the following:

• Clusters: These components lay at the heart of a Kubernetes environment and serve as an entry point for discerning the health of other elements such as containers and pods. By monitoring each cluster, admins can gain insight into whether a pod unsuccessfully failed so that they can investigate why. They can also use monitoring of their node loads and cluster infrastructure in order to improve efficiency.
• Pods: Security admins can’t neglect to monitor the state of their pods, as these components are responsible for hosting an organization’s various workloads. In particular, admins might consider monitoring for an excessive number of pods as well as for misconfigurations in how their pods are deployed.
• Applications: Ultimately, Kubernetes is about supporting whatever applications an organization needs to run. It’s therefore essential that admins monitor for errors, interruptions in availability and transaction traces in order to direct their remediation efforts of potential Kubernetes issues and thereby maximize uptime.

This raises an important question: what resources can admins use to gain visibility of their Kubernetes environments?

Monitoring and Auditing with Kubernetes

Within new clusters, admins can monitor their Kubernetes using two types of metrics pipelines. The first, resource metrics pipelines, are useful when it comes to gaining visibility of cluster components like the Horizontal Pod Autoscaler. The resource metrics pipeline provides this visibility by collecting metrics from the metrics-server, which discovers all nodes on the cluster and queries each kubelet for CPU and memory usage.

The second resource metrics pipeline available to admins is the full metrics pipeline. This resource retrieves metrics from the kubelet and then feeds them to Kubernetes. At that point, the platform can then respond to those metrics by modifying the cluster depending on its actual state.

Simultaneously, it’s important that admins prioritize auditing as part of their security approach to Kubernetes. Auditing helps admins to gain visibility into the events that are occurring in a cluster and thereby address potential issues before they affect application uptime. All Kubernetes audit records begin in the kube-apiserver; depending on the logging configurations specified, the kube-apiserver could consume more memory consumption than it otherwise would in order to store context with each audit record.

Part of the Greater CKS Whole

Monitoring and logging are just two Kubernetes security elements of which candidates can deepen their knowledge by pursuing certification as a Certified Kubernetes Security Specialist (CKS). Through this certification, admins can also learn about setting up a cluster, hardening the system and other topics. Here’s StackRox with some context about the CKS:

The CKS is the third Kubernetes based certification backed by the Cloud Native Computing Foundation (CNCF). CKS will join the existing Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) programs. All three certifications are online, proctored, performance-based exams that will require solving multiple Kubernetes security tasks from the command line…. The CKS focuses specifically on Kubernetes’ security-based features such as role-based access control (RBAC) and network policies and utilizing existing Kubernetes functionality to secure your clusters.

To find out more information about this certification, check out the CNCF’s website here.