We have been dealing with the operation of Kubernetes and how to run fail-safe applications on Kubernetes for many years now.

Securing Kubernetes against unauthorized access was always a focus of the projects with our customers, to prevent a manipulation of Kubernetes and of their applications.

The BSI, the German Center for Internet Security, provides comprehensive compendia for securing an IT infrastructure. The benchmarks listed there are not only interesting for public sector IT departments but also for private companies, as they are formulated in very general terms.

The benchmarks cover all IT-related topics and, in particular, information on securing Kubernetes and its applications. In addition to information on IT organizational matters, the compendia also include extensive specific technical information on securing an infrastructure.

We offer a free service that validates your Kubernetes environment and applications according to the technical specifications of the German CIS.

Vulnerabilities if Kubernetes is not properly configured are

  • privileged access to a server-node with a Pod running in the Kubernetes-Cluster,
  • easy change of the setting of a Kubernetes Pod to gain access to the Worker-Nodes,
  • unrestricted communication of all Kubernetes-Pods with all other Kubernetes-Pods in the Cluster,
  • communication between the Pods of the different Worker-Nodes without TLS-security,
  • gaining extended access-rights to Kubernetes via the ServiceAccount of a Kubernetes Pod by a user,
  • access to RBAC Rights to change own permission via a Pod,
  • mixture of the Control-Plane-Nodes and Worker-Nodes for the applications,
  • overstraining the server nodes by requesting of too much resource like Memory or CPU by the Pods and

For more information please see our Blog entry (in german)

We are validating

  • Access control to prevent unauthorized access to the IT infrastructure,
  • Network communication to prevent unauthorized access to applications running in Kubernetes,
  • Stability and susceptibility to insecure configurations,
  • Auditing rules to prevent unsafe configurations,
  • Failover to operate applications reliably and
  • Resource utilization to protect Kubernetes from failure due to overuse of resources.

All our findings are also categorized in these three classes:

  • basis: Recommendation which must be fulfilled, to be compliant to cybersecurity regulations
  • standard: Recommendation which should be fulfilled, to be compliant to cybersecurity regulations
  • high: Recommendation which should be fulfilled, when running highly vulnerable applications

We go through

a running Kubernetes environment with our analysis tool and look at every individual Kubernetes resource, such as Pods or NetworkPolicies for unfavorable configurations or even missing configurations, which contradicts a safety recommendation of the german CIS.

For each vulnerability found for a Kubernetes resource, a note on the configuration and the recommendation of the German CIS including the vulnerability class is issued. Optionally, an AI-generated solution and risk assessments can be added, e.g.:

48 app-2/grimble-6bd89db75c-v84zr grimble(Deployment/grimble)

Warning: In the container, spec.containers[].securityContext.privileged is set and therefore has privileged rights.
Cybersecurity notes under module 'Standard: Execution of containers without privileges' the following 
requirements: The container runtime and all instantiated containers SHOULD only be executed by a non-privileged system 
account that does not have or cannot obtain extended rights for the container service or the host system's operating system.

Problems: 
1. Increased risk of privilege escalation: Allowing containers to run with privileged security context can 
   lead to unauthorized access to sensitive resources and potentially allow attackers to gain control of the entire node.
2. Weakened isolation: Privileged containers have more access to the host system, which can weaken the 
   isolation between containers and increase the risk of one compromised container affecting others.
3. Vulnerability to malicious attacks: Privileged containers are more susceptible to various types of attacks,
   including container breakout attacks, which can result in unauthorized access to host resources.

Example:
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      securityContext:
        privileged: true

The parts Problems and Example are optional information generated by the AI.

Kubernetes-resources we analyze are

resource access control auditing stability network communication failover resource utilization
APIServer x x
Pod x x x x x
NetworkPolicy x x x
Calico NetworkPolicy (optional) x x x
Calico GlobalNetworkPolicy (optional) x x x
Cilium NetworkPolicy (optional) x x x
Cilium ClusterwideNetworkPolicy (optional) x x x
Namespaces x
Services x x
ServiceAccounts x x
MutatingWebhookConfiguration x
ValidatingWebhookConfiguration x
ValidatingWebhookPolicy x
Ingress x
StorageClass x

Is it secure?

Yes.

  • The tool ist running with the Kubernetes RBAC rights you gave him via kubeconfig.
  • We are doing the initial analysis always together with you.
  • The running completely independent of the internet.
  • The AI-support is optional. We can work completely independent of the internet. This guarantees that no information is shared with the outside world.
  • The AI-Tool with the communication to ChatGPT is optional.

Are you interested? Let's arrange a call.

Jörn Kleinbub

YOTRON GmbH is founded by Jörn Kleinbub. A consultant for data management, IT automation, DevOps and cloud management with experience in a wide range of project for a lot of different customers in different sectors.

Verlassen des Chats? / Leaving Chat?

Sie verlieren die aktuelle Chatkommunikation. / You are losing the current chat communication.

Ask YOTRON-AI about us, our services, our supported technologies or some organizational info. It will answer.

Send
Read the GDPR/DSGVO