The Business Value of a Kubernetes-based Platform

I hear too many stories of platform teams being under-resourced. This usually manifests itself as an overworked platform team with unrealistic on-call rotations. Critical activities, such as disaster recovery drills, security patches and keeping the tech stack up-to-date get postponed over and over again.

In fact, the CNCF Platform White Paper identified the following challenge with IT platforms:

Platform teams must seek support of enterprise leadership and show impact on value streams

[...]

Many enterprise leaders perceive IT infrastructure as an expense quite disconnected from their primary value streams and may try to constrain costs and resources allocated to IT platforms, leading to a poor implementation, unrealized promises and frustration.

In this post, we will help CTOs, VP of Engineering, and Software Architects explain the business value of a Kubernetes-based platform. I will go “full geek mode” and structure the whole blog post as an architectural decision record.

Context: New Regulations bring New Security Measures

We already wrote two blogs (blog 1 and blog 2) on the NIS2 directive. In short, if you run software and you are located in Europe, you’ll have to comply with the NIS2 directive.

NIS2 Article 21(2) lists 10 so-called minimum requirements, which are minimum security measures that essential and important organizations must implement. One of these requirements is “security in network and information systems acquisition, development and maintenance [...]”.

This line needs to be translated into more specific measures, such as Sweden’s MSBFS. Furthermore, these need to be translated into a specific policy of your organization. Let’s pretend that both of these were done. You’re likely left with implementing something along the lines of:

All communication across the Internet MUST be encrypted with HTTPS and at least TLSv1.2. Certificates MUST be rotated at least yearly. HSTS MUST be employed.

In case you wonder why I capitalized “MUST”, it’s not because I was shouting at you, but because: <quote>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</quote> (Did I remember to warn you about this post going “full geek mode”? 🤔)

For the non-geeks in the audience, the requirement above essentially means encrypt data in transit over untrusted public networks, such as the Internet. This ensures that if someone checks their patient journal using the free WiFi of the coffee shop, only they can see this very confidential information and nobody else, not even the owner of the coffee shop who set up the free WiFi.

So how should you implement this network security measure?

Decision Drivers: “Maximize Bang for the Bucks”

Your decision drivers are going to be unique to you, but the TL;DR of it is in the title of this section. You likely want to minimize the cost of implementing, rolling out and maintaining this security measure.

You might also be worried that this is not the only security measure you will need to implement. The CISO is still drafting the “Use of cryptography” policy, which is also a NIS2 minimum requirement. Hence, you would like to find a solution which can help you gain “security agility” and cost-effectively roll out other security measures in the future.

Considered Options

Now you have a few choices:

1. Do nothing. Do not implement this requirement and pray for the best. At this point, you might be outraged that I wrote this. However, a good decision record needs to also assess the cost of non-action – otherwise, how would you convince your boss what they’re on the hook for, so … this option won’t be edited out. Sorry.
• Good, because it entails zero implementation and maintenance cost.
• Bad, because we expose ourselves to NIS2 fines of up to 2% of last year’s global turnover.
• Bad, because the CEO might be found to neglect the NIS2 Directive – specifically the proposed Swedish Cybersecurity Law – and get fired (Swedish: näringsförbud).
2. Application specific. Each application team adds HTTPS and HSTS support. For example, if you use the Python Flask, the underlying Werkzeug library allows you to add an ssl_context. Similarly, if you have a Go application, you might use the net/http’s ListenAndServeTLS function. Oh, and let’s not forget about the HSTS header.
• Good, because we implement the network security requirements.
• Bad, because each application team will need to come up with a different implementation, hence more opportunities to introduce bugs both initially and in the future.
• Bad, because each application team will need to come up with a different implementation, hence more duplicate work.
• Bad, because we didn’t solve the problem of certificate rotation.
3. Application agnostic. Each application team adds an HTTPS proxy, such as NGINX or haproxy.
• Good, because we implement the network security requirements.
• Good, because the application teams can share know-how and – if done carefully – can reuse the same configuration.
• Bad, because each application team will have to figure out certificate rotation.
• Bad, because the maintenance burden is high. Each application team needs to update their HTTPS proxy and its configuration.
• Bad, because the implementation of each application team risks drifting from each-other.
4. Platform. Each application team runs their application on top of a platform which exposes the application via HTTPS. The platform includes a feature for automated certificate rotation. The platform also adds HSTS headers.
• Good, because we solve the problem once for all application teams.
• Good, because we only pay the cost of maintenance once for all application teams.
• Bad, because we need a knowledgeable platform team.

Recommended Decision

If you have access to a knowledgeable platform team, either in-house or via a supplier, then option 4 “Platform” is in my opinion the best. It allows developers to develop. It also puts clear responsibility on implementing this network security measure on the platform team. They can implement this quite quickly with a combination of Kubernetes, NGINX Ingress Controller and cert-manager.

Having a platform allows you to factor out commonalities between your applications. When the CISO is done drafting the “use of cryptography” policy, you have a single place to check if the encryption algorithms employed by your tech stack conform to your policy. In case there is a gap, you have a single team which is involved in bringing your tech stack in compliance with your new policies.

Sadly, a platform won’t just magically fulfill all your policies. However, with proper safeguards in place, you can save application developer’s precious time and reduce human error when rolling out and enforcing new security measures.

In the context of the upcoming NIS2 Directive, a platform allows you to have more security at a lower cost.