Skip to content

KubeTLS

Rahul Jadhav edited this page Jun 17, 2023 · 1 revision

Introduction

TLS is the most widely adopted protocol designed to facilitate privacy and data security for communications. Every security book starts by quoting that the services should enable TLS by default and that the TLS configuration be chosen from standard best practices such as NIST TLS Best practices guide SP 800-52. Every Zero Trust book (for example NIST Zero Trust Architecture) starts by stating that all the services should follow secure communications practices regardless of where they are deployed.

The Problem?

The problem of enabling TLS begins by identifying what services do not have it enabled in the first place. In AccuKnox, we have 25+ microservices deployed in our k8s cluster consisting of 20+ worker nodes and I realized that there was no easy way of finding out which services are running securely and which of them are not. This is not a very big scale and still, we were facing problems identifying what services are secure. Then there were other problems with understanding if we were using the right TLS configuration and certificate options. Most of the developers and DevOps folks have never dealt with these settings before. Kubernetes makes the job simpler since now we have a deterministic way to discover all the service ports in the cluster that will be used for inter-microservice communications and to identify ports that might be connecting to external sources. Having said that, we could not find any simple tool that provides TLS enablement and configuration visibility across the microservices while not being intrusive i.e., not inserting itself as a proxy or a sidecar.

The problem was to:

  • Check which services were using secure transport
  • Were they using TLS with the right configuration?
  • Were the certificates self-signed? Or revoked?

Possible Solutions?

I was surprised to see my internal DevOps team struggling to determine if the ports were secure. In one case they recommended deploying Kiali just to determine if the services are using TLS with the right configuration since some of our services were already using Istio for authorization. The proposal sounded like using Thor’s hammer to swat a housefly.

Another proposal was to enlist all the services port in an Excel file and follow up with the developers or to manually check if the services are using secure transport.

The Design?

We decided we could do something about it. With the Kubernetes service model, there was an easy way for us to enlist all the in-cluster services using something like a k8s job. We decided to build KubeTLS scanner that would use OpenSSL and other tooling to connect to the services port to determine their TLS and certificate configuration through the k8s job.

image

What Next?

The immediate next step is to fulfill all the NIST TLS best practices guidelines and provide a detailed view of the services ports. Further, the intention is to grow into a tool that fingerprints and validates best security practices across multiple application protocols.

Clone this wiki locally