Kubernetes

System paths can contain sensitive information like configuration files or cache files. Those might be used by attackers to expand permissions or to collect information for further attacks. System paths can also contain binaries and scripts that might be executed by the host system periodically. A compromised or rogue container with access to sensitive files could endanger the integrity of the whole Kubernetes cluster.

A port that is commonly used for administration services is open or marked as being open. Administration services like SSH might contain vulnerabilities, hard-coded credentials, or other security issues that increase the attack surface of a Kubernetes deployment. Even if the ports of the services do not get forwarded to the host system, by default they are reachable from other containers in the same network. A malicious actor that gets access to one container could use such services to escalate access and privileges.

If the administrative port is forwarded through a load balancer, then in most cases this port should be removed from the configuration to make sure it is not reachable externally. Setting the containerPort on a pod is purely informative. Therefore, removing the property is not sufficient to be secure. The port is still open and the service is still accessible.

In both cases, it is most secure to not start any administrative services in deployments. Instead, try to access the required information using Kubernetes’s own administrative tools. For example, to execute code inside a container, kubectl exec can be used. If the administration service is included to access logs, Kubernetes suggests using a sidecar container with a logging agent.

Without a CPU request, a container can potentially be scheduled on a node where there are not enough resources for it. This can lead to unpredictable behavior of the container and the node itself.

n lead to privilege escalation and container escapes.

Linux capabilities allow you to assign narrow slices of `root’s permissions to processes. A thread with capabilities bypasses the normal kernel security checks to execute high-privilege actions such as mounting a device to a directory, without requiring additional root privileges.

In a container, capabilities might allow to access resources from the host system which can result in container escapes. For example, with the capability SYS_ADMIN` an attacker might be able to mount devices from the host system inside of the container.

The absence of whitespace in template directives in Helm can lead to several issues:

Readability: Code is read more often than it is written. When template directives are tightly packed without whitespaces, it can be challenging to distinguish between the braces and the content inside. This can slow down the process of understanding the code, especially for those who are new to the codebase.

Maintainability: Hard-to-read code is also hard to maintain. If a developer struggles to understand what a piece of code does due to poor formatting, they may introduce bugs when they try to modify it.

In summary, not having a whitespace after the opening brace and before the closing brace in template directives can make the code harder to read, understand, and maintain.

ege escalations exposes the Pod to attacks that exploit setuid binaries.

This field directly controls whether the no_new_privs flag is set in the container process. When this flag is enabled, binaries configured with setuid or setgid bits cannot change their runtime uid or gid: Potential attackers must rely on other privilege escalation techniques to successfully operate as root on the Pod.

Depending on how resilient the Kubernetes cluster and Pods are, attackers can extend their attack to the cluster by compromising the nodes from which the cluster started the Pod.

The allowPrivilegeEscalation field should not be set to true unless the Pod’s risks related to setuid or setgid bits have been mitigated.

Ephemeral storage is a type of storage that is temporary and non-persistent, meaning it does not retain data once the process is terminated. In the context of Kubernetes, ephemeral storage is used for storing temporary files that a running container can write and read.

The issue at hand pertains to the creation of a container without any defined limits for this ephemeral storage. This means that the container can potentially consume as much ephemeral storage as is available on the node where it is running.

If an environment variable of a container is declared multiple times with different values, it can become unclear which value will be used by the application and can lead to unpredictable behavior. Also, if an issue arises related to the environment variable, debugging can be challenging. The problem could be due to the overwritten variable, but this might take time to be noticeable.

Without a memory request, a container can potentially be scheduled on a node where there are not enough resources for it. This can lead to unpredictable behavior of the container and the node itself.

rivileged mode can reduce the resilience of a cluster in the event of a security incident because it weakens the isolation between hosts and containers.

Process permissions in privileged containers are essentially the same as root permissions on the host. If these processes are not protected by robust security measures, an attacker who compromises a root process on a Pod’s host is likely to gain the ability to pivot within the cluster. Depending on how resilient the cluster is, attackers can extend their attack to the cluster by compromising the nodes from which the cluster launched the process.

A memory limit is a configuration that sets the maximum amount of memory that a container can use. It is part of the resource management functionality of Kubernetes, which allows for the control and allocation of computational resources to containers.

When a memory limit is set for a container, Kubernetes ensures that the container does not exceed the specified limit. If a container tries to use more memory than its limit, the system will reclaim the excess memory, which could lead to termination of processes within the container.

Without a memory limit, a container can potentially consume all available memory on a node, which can lead to unpredictable behavior of the container or the node itself. Therefore, defining a memory limit for each container is a best practice in Kubernetes configurations. It helps in managing resources effectively and ensures that a single container does not monopolize the memory resources of a node.

A CPU limitation for a container is a specified boundary or restriction that determines the maximum amount of CPU resources that a container can utilize. It is a part of resource management in a containerized environment, and it is set to ensure that a single container does not monopolize the CPU resources of the host machine.

CPU limitations are important for maintaining a balanced and efficient system. They help in distributing resources fairly among different containers, ensuring that no single container can cause a system-wide slowdown by consuming more than its fair share of CPU resources.

Without a storage request, a container can potentially be scheduled on a node where there are not enough resources for it. This can lead to unpredictable behavior of the container and the node itself.

Allowing command execution (exec) for roles in a Kubernetes cluster can pose a significant security risk. This is because it provides the user with the ability to execute arbitrary commands within a container, potentially leading to unauthorized access or data breaches.

In a production Kubernetes cluster, exec permissions are typically unnecessary due to the principle of least privilege, which suggests that a user or process should only have the minimum permissions necessary to perform its function. Additionally, containers in production are often treated as immutable infrastructure, meaning they should not be changed once deployed. Any changes should be made to the container image, which is then used to deploy a new container.

Service account tokens are Kubernetes secrets created automatically to authenticate applications running inside pods to the API server. If a pod is compromised, an attacker could use this token to gain access to other resources in the cluster.

For example, they could create new pods, modify existing ones, or even delete critical system pods, depending on the permissions associated with the service account.

Therefore, it’s recommended to disable the automounting of service account tokens when it’s not necessary for the application running in the pod.

The Docker daemon provides an API to access its functionality, for example through a UNIX domain socket. Mounting the Docker socket into a container allows the container to control the Docker daemon of the host system, resulting in full access over the whole system. A compromised or rogue container with access to the Docker socket could endanger the integrity of the whole Kubernetes cluster.

Using wildcards when defining Role-Based Access Control (RBAC) permissions in Kubernetes can lead to significant security issues. This is because it grants overly broad permissions, potentially allowing access to sensitive resources.

RBAC is designed to limit the access rights of users within the system by assigning roles to them. These roles define what actions a user can perform and on which resources. When a wildcard is used, it means that the role has access to all resources/verbs, bypassing the principle of least privilege. This principle states that users should have only the minimal permissions they need to perform their job function.

stem namespaces can lead to compromise of the host systems. These attacks would target:

These three items likely include systems that support either the internal operation of the Kubernetes cluster or the enterprise’s internal infrastructure.

Opening these points to containers opens new attack surfaces for attackers who have already successfully exploited services exposed by containers. Depending on how resilient the cluster is, attackers can extend their attack to the cluster by compromising the nodes from which the cluster started the process.

Host network sharing could provide a significant performance advantage for workloads that require critical network performance. However, the successful exploitation of this attack vector could have a catastrophic impact on confidentiality within the cluster.

Clear-text protocols such as `ftp, telnet, or http lack encryption of transported data, as well as the capability to build an authenticated connection. It means that an attacker able to sniff traffic from the network can read, modify, or corrupt the transported content. These protocols are not secure as they expose applications to an extensive range of risks:

Even in the context of isolated networks like offline environments or segmented cloud environments, the insider threat exists. Thus, attacks involving communications being sniffed or tampered with can still happen.

For example, attackers could successfully compromise prior security layers by:

In such cases, encrypting communications would decrease the chances of attackers to successfully leak data or steal credentials from other network components. By layering various security practices (segmentation and encryption, for example), the application will follow the defense-in-depth principle.

Note that using the http` protocol is being deprecated by major web browsers.

In the past, it has led to the following vulnerabilities:

Code is sometimes annotated as deprecated by developers maintaining libraries or APIs to indicate that the method, class, or other programming element is no longer recommended for use. This is typically due to the introduction of a newer or more effective alternative. For example, when a better solution has been identified, or when the existing code presents potential errors or security risks.

Deprecation is a good practice because it helps to phase out obsolete code in a controlled manner, without breaking existing software that may still depend on it. It is a way to warn other developers not to use the deprecated element in new code, and to replace it in existing code when possible.

Deprecated classes, interfaces, and their members should not be used, inherited or extended because they will eventually be removed. The deprecation period allows you to make a smooth transition away from the aging, soon-to-be-retired technology.

Check the documentation or the deprecation message to understand why the code was deprecated and what the recommended alternative is.

Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately. However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase. This description explores why this is a problem and how it can be fixed to improve the overall code quality.

A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes. {identifier_capital_plural} hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern. Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.

This rule checks that {identifier} names match a provided regular expression.