Kubernetes Penetration Testing

CREST Accredited, Cloud Native and Kubernetes Security Testing Specialists

Introduction

Kubernetes is a fantastic platform upon which to both develop and run your applications. It is also incredibly complex and easy to slip up from a security perspective. 4ARMED are one of very few providers worldwide who truly understand and specialise in Kubernetes penetration testing.

What is a Kubernetes Penetration Test?

Often this forms part of a wider scope of work looking at your application but a Kubernetes penetration test can certainly be delivered as a standalone engagement to give assurance over your cluster configurations.

We will review your clusters both from an external and internal perspective.

External Testing

The external review will focus on the cluster's Internet-facing services to assess whether they are protected as expected and whether any ingress points are exposed unexpectedly. This may include services like the Kubernetes Dashboard, misconfigured API services, vulnerable Kubernetes versions or, as is pretty common, internal cluster management and monitoring tools such as Prometheus, Grafana or Elasticsearch exposed to the Internet without adequate protection.

Internal Testing

Internal Kubernetes security testing takes things to a deeper level and looks at your cluster from inside, simulating the threat from an attacker who has either compromised a pod or found a vulnerability which enables them to make requests from inside a pod in the cluster.

There are a wide variety of security issues that can affect a cluster's configuration and even in the most recent versions of Kubernetes, some of these can still result in a total compromise of the cluster unless specific configuration is put in place to prevent this.

Some examples of issues we regularly encounter are:

  • Unsecured Kubelet API
  • Unprotected Helm Tiller service
  • Sensitive cloud metadata unrestricted
  • Secrets not protected adequately
  • Lack of Network Policy
  • Internal services unprotected without Ingress authentication
  • Unauthenticated etcd access
  • Privileged/root containers
  • Excessive service account privileges

We will work with your team, typically remotely though on-site is certainly an option, talking through the issues as we find them. Most of our testing utilises a private Slack channel to discuss progress and keep everyone up to speed. Unlike most testing companies we actively encourage resolution during the testing window where possible.

We can test your cluster whether it's managed (Google GKE, Amazon EKS, Microsoft AKS, DigitalOcean Kubernetes, etc) or unmanaged (Kubeadm, Kops, Typhoon, OpenShift, Tectonic, etc) where you control your own masters.

We've worked with many different organisations from FinTech startups to some of the biggest names in the Kubernetes landscape and we'd be happy to discuss what you need in more detail.


Benefits

bug_report
Assurance

Security Testing helps you gain assurance over your risk. Your Kubernetes clusters should be configured correctly and securely but testing provides assurance that no mistakes have been made.

check_box
Compliance

Penetration Testing is required by a number of compliance standards such as PCI DSS. Our security testing services can help you achieve or maintain compliance for your Cloud Native environment.

Specialists

We're not generalists who can wing it with your Kubernetes cluster. We've been working with this technology for years, we use it day-in, day-out for our own IT infrastructure, have spoken at tech conferences on the subject, blogged and released open source testing tools for Kubernetes.

Continual Improvement

Each report contains a root cause analysis and, if you take a Managed Security Testing contract we can help you implement a continuous improvement cycle focused on your specific problem areas.


What To Expect

Scoping

A typical engagement process flow can be seen here. The most important part when considering a penetration test is getting the scope right.

In some cases this is relatively simple as it may be you require a test of a single system or application whose boundaries are clearly defined. In other cases the scope will be more complex. A good example of this is when conducting a penetration test to meet PCI DSS requirement 11.3 which will need us to verify the scope for testing actually covers all in-scope systems.

For simple requirements we can typically scope a test accurately via a phone call or email, more complex tests will require a scoping form to be completed. A link to this can be found in the Resources section below.

A longer description of the stages of a typical penetration testing engagement can also be found in the Resources section below.

Delivery

Communication is key to the delivery of a good security testing engagement. You will be assigned a project lead who will handle all of the logistics of testing with you and give you one point of contact should you need to discuss anything. We will keep you updated throughout testing as required and a free-of-charge wash-up call between our consultants and relevant parties from your organisation can be scheduled once you have reviewed the detailed report provided. This gives you the opportunity to discuss the findings and recommendations in more detail and evaluate further your best course of action.

  • Confirmation of scope
  • Escalation process agreed
  • Test Authorisation
  • Communication requirements agreed
  • Enumeration
  • Vulnerability Identification
  • Exploitation
  • Post-Exploitation
  • Regular Testing Updates As Agreed
  • Report Completed By Lead Tester
  • Issues Rated By Impact & Exploitability
  • Root Cause Analysis
  • Internal QA Prior To Issue
  • Optional Wash-up Call
  • Post-Test Support For Recommendations
  • Arrange Re-testing If Required

Application Security Testing with Source Code

Earlier we highlighted the different testing levels we typically work to – Opportunistic, Standard and Advanced – but, when it comes to application security testing there is always the option to provide us with access to the source code during the test.

Often referred to as white box testing this enables our consultants to achieve far wider and deeper coverage of an application in the same amount of time. This is because suspected issues can be verified more quickly and searched for in other parts of the code. The majority of tests we conduct these days are performed in this manner.

Source code is stored in accordance with our ISO27001 information security requirements and is securely deleted once the engagement has completed.



Resources


Next Steps

Want to discuss your requirements further? Wondering whether Kubernetes Penetration Testing is right for your business? There's an easy way to find out, give us a call or complete the contact form below to tell us where you're at and we will work with you to find the best solution for you.