Vulnerabilities

Manage Kubernetes RBAC resources

Property
Language
Severity
Vulnerability Type	omission

Description

Granting write permissions (such as create, update, or delete) on Kubernetes ‘roles’ or ‘rolebindings’ resources provides users with access equivalent to cluster-admin. This allows broad and unrestricted management of access controls within the cluster.

Impact

If exploited, attackers or unauthorized users could escalate privileges, modify or assign roles, and gain full control over the Kubernetes cluster, leading to potential data breaches, service disruptions, or complete compromise of workloads and sensitive resources.

Manage Kubernetes workloads and pods

Property
Language
Severity
Vulnerability Type	omission

Description

Kubernetes roles or cluster roles are granting permissions to create, update, or delete workloads such as pods and deployments, rather than restricting access to only read operations. This overly broad access can allow unauthorized changes to critical resources.

Impact

If exploited, attackers could deploy malicious workloads, escalate privileges, or take over cluster resources, potentially leading to data theft, service disruption, or full cluster compromise.

Manage namespace secrets

Property
Language
Severity
Vulnerability Type	omission

Description

Granting access to manage secrets at the namespace level allows any service account with this role to view or modify all secrets in that namespace, increasing risk if higher-privileged roles are present.

Impact

If exploited, an attacker could access sensitive credentials or escalate privileges by leveraging secrets managed by accounts with broader permissions, potentially compromising workloads or gaining unauthorized access across the cluster.

Manage secrets

Property
Language
Severity
Vulnerability Type	omission

Description

Cluster-wide permissions allowing management of Kubernetes secrets grant users access to sensitive information, such as service account tokens, which are often tied to high-privilege roles. This effectively provides cluster-admin level access to anyone with these permissions.

Impact

If exploited, attackers can retrieve service account tokens and other secrets, enabling them to impersonate privileged users, escalate privileges, access confidential data, or take full control of the cluster, potentially resulting in data breaches or service disruption.

Manage webhookconfigurations

Property
Language
Severity
Vulnerability Type	omission

Description

Roles or cluster roles are configured with permissions to manage ‘mutatingwebhookconfigurations’ or ‘validatingwebhookconfigurations’, allowing creation, modification, or deletion of webhooks that can intercept or alter Kubernetes resources.

Impact

Attackers with these permissions could create, modify, or remove webhooks to intercept secrets, manipulate pod specifications, or block resource operations, potentially leading to privilege escalation, data theft, service disruption, or a complete compromise of the Kubernetes cluster.

Manages /etc/hosts

Property
Language
Severity

Description

Setting ‘spec.template.spec.hostAliases’ in Kubernetes resource definitions allows manual management of /etc/hosts entries inside containers, overriding default behavior and potentially preventing the container engine from updating this file as needed.

Impact

Improper management of /etc/hosts can lead to stale or incorrect DNS resolutions within containers, which may cause service disruptions, hinder container communication, or expose the system to man-in-the-middle attacks if host mappings are manipulated.

Master authorized networks should be configured on GKE clusters

Property
Language
Severity
Service	gke
Provider	Google
Vulnerability Type	omission

Description

The GKE cluster is not configured with master authorized networks, allowing unrestricted network access to the Kubernetes master endpoint. This means any IP address can attempt to connect to the cluster control plane.

Impact

Without network restrictions, attackers can target the master endpoint from anywhere, increasing the risk of unauthorized access, data breaches, or control over the cluster. This exposes critical infrastructure to potential compromise and service disruption.

Memory not limited

Property
Language
Severity

Description

The configuration does not set a memory limit for containers, allowing them to consume unlimited memory resources. This omission fails to enforce resource boundaries in Kubernetes workloads.

Impact

Without memory limits, a container can exhaust node memory, potentially causing denial of service by crashing other workloads or the entire node. This makes the cluster vulnerable to accidental overloads or intentional resource exhaustion attacks.

Memory requests not specified

Property
Language
Severity

Description

The container configuration does not specify a memory request, preventing Kubernetes from reserving adequate resources for the container. This can lead to suboptimal scheduling and resource contention within the cluster.

Impact

Without defined memory requests, containers may be scheduled onto nodes without sufficient memory, increasing the risk of performance degradation, unexpected throttling, or eviction during high resource utilization, potentially causing instability for critical workloads.

microdnf clean all’ missing

Property
Language
Severity
Vulnerability Type	omission

Description

Dockerfiles using ‘microdnf install’ do not include ‘microdnf clean all’ afterward, leaving cached package data in the image. This unnecessary cache increases image size and persists sensitive package metadata.

Impact

Larger image sizes can lead to longer build, transfer, and deployment times, and may expose package metadata that could aid attackers in targeting known vulnerabilities or sensitive dependencies within the container.

< Previous Next >