DEV Community: K8Studio

Using CloudMaps to monitor Clusters

Guillermo Quiros — Thu, 14 Nov 2024 19:15:22 +0000

Monitoring Kubernetes today is a complex task. Even with carefully chosen tools, we often face an overwhelming array of dashboards brimming with countless charts, necessitating multiple monitors.

This information overload makes it challenging to pinpoint what truly matters. Critical information gets buried under a sea of metrics, hindering our ability to quickly understand what is going on and make appropriate decisions. As Kubernetes clusters grow, the complexity increases exponentially, making observability even more crucial. So, what do we do to keep track without losing our minds? Please don’t say another dashboard!!!

At K8Studio we think that the way to tackle this problem is through effective data visualization. We need a data visualization that provides a summarized view of our cluster’s status, giving us context and revealing relationships between events and objects within the cluster. It should also allow us to drill down into details when necessary. An intuitive visualization that quickly communicates high volumes of data directly to our brains is essential.

At K8Studio, we believe the way to tackle this problem is with state-of-the-art data visualization. This visualization needs to have the following properties:

Provide a holistic view of our cluster.
Describe the cluster structure and the relationships between the different parts.
Surface relevant information and minimize noise.
Enable us to easily navigate to different levels of detail and back, while maintaining the context of the navigation.
Excel in communicating high volumes of data intuitively and effortlessly.

You may wonder what this magical visualization is. And the answer, like all good things in life, is pretty simple and straightforward: MAPS!

Since ancient times, humans have used maps to represent complex worlds. Over time, we have adapted to consume maps efficiently, which is why most of us can understand a map without needing any explanation. Maps have the unique ability to show relationships and interactions between different objects, giving us the big picture while allowing us to drill down into details without losing focus. Combined with heatmaps, they enable us to surface the relevant information effectively.

At K8Studio, we have tried to adapt the concepts of maps to cloud computing, and more specifically to the management of Kubernetes Clusters. That is why we have introduced a new concept called CloudMaps in our latest release of K8Studio.

The primary function of CloudMaps is to represent your cluster as a map using color coding and heatmaps, providing a clear view of the status of different objects. It organizes objects by namespace and shows the network relationships between them, allowing you to understand who is connecting to whom. Additionally, CloudMaps features robust zoom capabilities with a minimap to enable detailed drill-downs when needed without losing focus of the whole. Cloud Maps combine the power of intuitive mapping with the precision needed for Kubernetes observability, helping us master the complexity of our clusters with ease.

This is how Cloud Maps look. When zoomed out, we can see the composition of our cluster and the workloads in different namespaces organized by application name. We can observe the number of pods and the status of both workloads and pods. The map also displays the relationships between objects, such as service-to-workload and workload-to-PVC connections. Workloads are marked with application icons to provide us with more information about the deployed images. All of this offers us a holistic view of the cluster. In this example, we can clearly see all the workloads with issues highlighted in yellow. Even someone unfamiliar with the cluster can grasp its composition and status within three seconds.

Once we have the big picture, we can zoom in on the map to see more detailed information about a specific part of the cluster that interests us. For instance, in this example, we can zoom in and see a Redis deployment with six unscheduled pods. We also see two services and their ports accessing the pods, and six PVCs, each bound at 8Gi. Just by zooming in, we gain more in-depth information, similar to how we would use a physical map to explore an area in greater detail. For example, at this zoom level, we can see the ports and target ports of the services, the size of the PVC, and their status.

To obtain more information about any object, we can simply click on the object to select it. A right-hand panel will appear, displaying additional details about the selected object.

In this panel, you can view even more detailed information. As the pictures below show, this panel includes different sections:

The Quick Editor: Showing the basic information and status.
YAML Editor: Providing access to the full YAML configuration.
The Timeline: Combining status and events ordered by time.
Metrics: Showing relevant metrics of the selected object, including CPU, memory with request and limit, network, and I/O operations.

This panel enables us to gather extensive information, empowering us to detect issues and take the appropriate actions. Moreover, when the selected object is a pod, we can seamlessly establish an SSH connection or access the specific container logs via our integrated terminal.

To conclude, we’ve incorporated nodes into the map, providing insight into their status, CPU, and memory utilization, along with details on the pods they host and the capacity for additional pods. An intriguing feature is that when selecting a pod, it will also be highlighted within the workload objects, facilitating a clear understanding of pod distribution and placement within the cluster. This comprehensive view enables seamless navigation and informed decision-making within the cluster environment.

The application can be downloaded at K8studio or on our GitHub Page

BTW If you like what we are building give us a star on GitHub.The team and I would be extremely grateful.

Pod Security with K8Studio

Guillermo Quiros — Thu, 14 Nov 2024 19:01:54 +0000

K8Studio 2.0.0 introduces significant improvements focused on Pod Security to streamline and enhance Kubernetes security management. This release addresses three core security areas essential for assessing and enforcing pod-level security policies:

Network Policies — Provides visibility into applied network policies, including detailed checks on ingress and egress rules, to control traffic flow to and from pods and secure inter-pod communication.
Security Context — Offers insights into the security context of each pod, allowing you to verify configurations such as user privileges, Linux capabilities, and namespace isolation levels, which are critical for securing workloads.
Service Account Roles — Enables examination of service account roles linked to pods, providing information on the permissions granted, which is crucial for understanding access scopes and limiting exposure.

These features collectively offer a structured approach to assessing pod security configurations, making it easier to identify and address potential vulnerabilities across deployed Kubernetes environments.

Network Policy

In this version, the dashboard’s Workload Widget now includes a section that provides a quick overview of workloads with ingress or egress rules applied, helping you instantly assess whether each workload is properly secured by network policies.

In the Quick Editor, we’ve added a detailed view of network policies, allowing you to see exactly which ports are open for both ingress and egress traffic on each workload. This feature provides visibility into the specific protocols and port ranges configured, making it easier to verify and adjust access rules directly from the editor. By offering granular insights into traffic flow, this enhancement helps ensure that workloads are configured with the appropriate network security settings to minimize exposure and control communication paths effectively.

Security Context

In the Quick Editor, users can access detailed security context configurations that fall under three main categories: RunAsUser, RunAsGroup, and FsGroup. Each of these categories includes key properties for fine-tuning pod-level security:

RunAsUser
Defines the user identity under which the container’s processes will run. This setting is essential for enforcing least-privilege access:

RunAsUser — Specifies the user ID (UID) that processes within the container will use, allowing you to avoid root-level execution and enforce user-specific permissions.
RunAsNonRoot — Enforces that the container runs as a non-root user. Setting this to true ensures that the container operates without root privileges, adding an extra layer of security even if RunAsUser is not set.
AllowPrivilegeEscalation — Controls whether a process in the container can escalate privileges (e.g., gain root privileges). Setting this to false prevents potential privilege escalation attacks within the container, restricting processes to the permissions initially assigned.

RunAsGroup
Specifies the primary group identity for the container’s processes, which is helpful for managing group-based access permissions:

RunAsGroup — Defines the primary group ID (GID) that container processes will use. This setting enables group-specific access control within the container, particularly useful in multi-user environments.
Capabilities — Provides fine-grained control over Linux capabilities granted to the container. By specifying capabilities to add or drop, such as NET_ADMIN (for network management), you can limit the permissions granted to processes, further controlling the container's security scope.

FsGroup
Sets the group ID applied to the filesystem for volumes within the pod, offering centralized control over file and directory permissions:

FsGroup — Assigns a filesystem group ID to all files within the pod’s mounted volumes, making it easier to manage file permissions for shared storage scenarios.
ReadOnlyRootFilesystem — Enforces a read-only root filesystem for the container, ensuring that the container’s core files cannot be altered. This setting prevents accidental or malicious modifications to the root filesystem, reinforcing the container’s immutability.
Privileged — Grants the container elevated permissions to access all host resources. This setting effectively removes the usual container security boundaries, which can be useful in specific cases (such as hardware access) but should be used cautiously due to security implications.

By grouping these properties, the Quick Editor in K8Studio 2.0.0 offers a structured and intuitive approach for configuring security contexts, allowing users to define user, group, and filesystem permissions clearly. This setup supports more granular control over pod security and aligns deployments with Kubernetes best practices.

Service Account

In this release, we’ve implemented a feature in the Quick Editor that shows which Roles or ClusterRoles are bound to the service account assigned to each pod. This addition is crucial for providing visibility into the access controls applied to workloads.

Importance of Service Account Roles in Pod Security
In Kubernetes, each pod runs with a service account, which is associated with specific permissions defined by Roles or ClusterRoles. These permissions control the actions that a pod, through its service account, can perform within the cluster. Understanding the roles associated with a service account is critical for the following reasons:

Access Control — Roles and ClusterRoles define what resources a pod can access and which operations it can perform on those resources (e.g., get, list, create, delete). This helps prevent unauthorized access to sensitive resources by ensuring each pod only has the permissions it truly needs, following the principle of least privilege.
Resource Isolation — By carefully assigning roles to service accounts, you can isolate workloads based on their function or security requirements. For example, a pod handling sensitive data might have restricted access to certain namespaces or be limited to read-only actions, reducing the risk of accidental or malicious modifications to cluster resources.
Minimizing Attack Surface — Restricting the service account’s permissions reduces the potential impact if a pod is compromised. A tightly scoped service account ensures that even if an attacker gains access to the pod, they cannot escalate privileges or access unrelated cluster resources, limiting the security impact of a breach.
Auditing and Compliance — Assigning explicit roles to service accounts provides a clear audit trail of what permissions were granted to each pod. This is important for compliance and security audits, as it allows teams to verify that pods are running with the correct permissions and no excess access.

With these new features, we aim to enhance the visibility and identification of potential security vulnerabilities within your Kubernetes cluster. By providing clear insights into pod security configurations, network policies, and service account roles, K8Studio 2.0.0 empowers users to proactively assess and mitigate security risks. This streamlined approach allows for quicker detection of security holes, enabling you to maintain a robust and secure Kubernetes environment effectively.