Announcing a new Managed Security Solution

Today, we are excited to announce our managed security solution for establishing a sensible, comprehensive, and entirely open-source security presence in your clusters. As a company, we have always valued transparency and community, and are excited to offer an uncomplicated and scalable security option based on those values.

To be clear, we aren’t reinventing the wheel, nor are we throwing our hat into the security ring. Rather, we recognize the talent and dedication so many in the community have already put forth, and intend to add polish and management to make it accessible and impactful for even more users. Our security offering, while comprehensive, will not accommodate every possible use case and security requirement. We expect some customers will outgrow it — and when they do, we’ll take that as a sign that we’ve fulfilled our primary obligation to guide them to a mature, robust Kubernetes presence.

We run a great many Kubernetes clusters together with our customers, so what benefits our clusters also benefits theirs. A winning pattern for us has been to commoditize the solutions we build for ourselves and make them available to our customers. The monitoring, ingress, and log management tools we use to run our platform are available for our customers to use in their own clusters. We deploy our management platform using the same App infrastructure our customers enjoy, and as we move more of our platform operations to a GitOps workflow, we enable the same features for our customers to use. More often than not, what works well for us also works well for them, and that co-innovation has helped us build fantastic relationships. 

Our new security solution is no different. In evaluating security products for our own use, we found ourselves thinking it should be far easier to assess and reason about the security of a cluster without spending a mint or placing too much trust in code beyond your own control. To that end, we will now manage a collection of tools covering our most frequently requested security requirements, from admission control to vulnerability management.

Built entirely from open-source projects, the solution will include a selection of cloud-native application protection (CNAPP), cloud workload protection (CWPP), and cloud security posture management (CSPM) features derived from requirements focused on actionable alerting and meaningful protection mechanisms. Any abstraction or management we add on top will remain open-source itself. 

Our journey 

We like to think of our relationships with our customers as a journey. Each customer joins us somewhere along their own path to Kubernetes adoption, and we draw from our experience and that of our other customers to augment their capabilities, upskill their teams, and clear the way for them to reach their full potential. We know what this journey looks like because we have walked it countless times.

About two years ago, we found ourselves on a journey of our own, which will be all too familiar for virtually any company running Kubernetes. Re-evaluating our security posture, we realized that we’d exhausted the Kubernetes-native security mechanisms. We’d made sound architectural decisions, had shifted many security concerns left into our CI/CD pipelines, and had default-deny policies throughout, but, as we’ve written in the past, security is nebulous, and there were still opportunities to improve our security processes and posture which couldn’t be addressed with the tools at our disposal. So, like many of you, we found ourselves asking “where do we even start?” with Kubernetes security tooling.

What followed was another journey we’d walked with our customers - finding a solution for our remaining security requirements that made sense in the Kubernetes world. This process was not new to us; we’ve been through the trial and attempted adoption phase for various vendors with multiple customers. I say “attempted” adoption phase because, in our experience, even with significant investment, these solutions don’t always make it to production. If nothing else, those failed attempts helped shape our requirements for our potential solution.

Going into this process, we had several non-negotiables based on our company values and the experiences we’d had with our customers:

• We can’t compromise existing failure domains.

• We need to be able to fix it.

• Pricing has to scale the way we do.

We want to eventually provide a sensible amount of protection by default in every cluster, so we need our cost to remain controllable if we add 1000 more clusters or our existing clusters all scale up by 500 nodes.

Over the course of many months, we engaged with the major players in the Kubernetes security space, ran demos and trial months in our management clusters, and made more than a few friends in their sales and partnership teams (and we are grateful for the time they spent working with us on our rather unusual model). At the same time, we performed an exhaustive review of the available open-source options in the Kubernetes ecosystem. Given the existence of this blog post, it should come as no surprise what we found.

For starters, we were spoiled for choice — at least superficially. We were inundated with open-source options, from small passion projects to well-supported initiatives from open-source or open-core companies. Many of these options were not stable or feature-rich enough for us in the past, but have matured over the past two years to the point where we now feel confident running them in production. The question wasn’t whether we could use open-source tools to achieve the coverage we needed, it was rather how many we would actually need, and which combination would provide the best coverage and experience.

As if in confirmation of that sentiment, we were pleased to find many of the enterprise offerings are also themselves backed by open-source, community-focused projects. Sysdig uses CloudCustodian in support of their cloud security posture management (CSPM) offering and has contributed Falco to the CNCF. Aqua maintains numerous fantastic open-source tools, including even the CIS benchmark tool used by Sysdig. Transparency and cooperation are fundamental to the Kubernetes community, and we consistently bet on companies and technologies that embrace that philosophy. We attribute part of Giant Swarm’s success to “standing on the shoulders of giants”, and in this case, we are happy to see the giants supporting not just the community, but even each other.

Our evaluations of the various enterprise offerings were equally enlightening. This post is not about the feature parity of different security platforms, but suffice it to say we experienced a range of capabilities. Among the vendors whose product fit our security use cases, we found the largest differences between the enterprise and open-source options to be primarily related to the user interface, predictive/assistive capabilities (machine learning-supported or otherwise), and management of users and policies in the context of more traditional large organizations. For us, those things weren’t necessarily worth the tradeoffs we’d have to make to adopt the product in the way we’d hoped.

Returning to our priorities above, we ultimately faced a few limitations that we couldn’t find a way around were we to adopt one of the commercial options:

• They introduced a single point of failure.

In most cases, we’d either need to cede control to a central SaaS backend, or would need to self-host that central backend at a significant cost. Bringing management of our entire fleet into one database would have some admittedly nice upsides, but it isn’t in line with how we manage risk. Instead, our managed solution runs per cluster to keep failures local.

• We couldn’t fix them.

Security tools are often necessarily powerful and fail closed, and we’ve been burned when they fail. With closed-source components, we have very little recourse or opportunity to unblock ourselves or our customers. The vendors we evaluated all included proprietary components for which we could only open support tickets and wait if something went awry. The tools comprising our security solution are entirely open-source, meaning we or any of their users can fix it in a pinch or modify it to suit their needs.

• The licensing got complicated.

We don’t believe in per-node pricing, which many security vendors have adopted for their license model. Part of the power offered by cloud adoption is the ability to scale, and it is much less operational overhead for us to manage appropriately-sized clusters than for us to manage overcrowded clusters artificially restricted to minimize cost. We appreciate the many folks who took the time to explore alternatives with us, but add in the overhead of triangular contracts and a third-party vendor involved with each customer, and we simply could not see a way to maintain the same flexibility that we allow our customers. Our offering incurs no additional licensing requirements or third parties.

• Adoption was all-or-nothing.

This was not an original requirement, but something we learned along the way. Our customers have different security requirements as well as different levels of adoption-readiness, but commercial products tend to combine many different concerns into a small number of in-cluster components (e.g. a single agent for admission control, log analysis, and network policy enforcement). This means security is either on or off, with little room in between. Enabling a more gradual opt-in with only a subset of the controls in place has already accelerated real adoption by our customer teams. It also has the added benefit of allowing us to selectively disable or remove a component if it becomes incompatible or must be disabled temporarily for maintenance or upgrades, without losing the entire security presence.

All that is not to say we dislike the security products on the market today — before landing on our own managed offering, I was personally a proponent of adopting one such vendor, imperfect as it may have been for our needs. There are undeniably powerful and innovative developments being driven by those giants, and for some, those platforms may be a better fit for their requirements. We encourage everyone, including our customers, to continuously re-evaluate their threat model and security posture and adopt controls which effectively move them toward their target risk. But, you can’t buy security. For those just starting out with Kubernetes as well as seasoned veterans who just want an option that uncomplicates compliance, we’re here for you.

Join us! 

We’re excited about the new solution, and we hope you are, too.

For our current customers, refer to our docs and find the Apps in the catalog to get started, or simply drop us a message in your channel and we’ll be happy to schedule an intro session. 

If you’re still managing your own clusters but like the idea of someone else holding the pager, get in touch for a demo of our platform, of the security solution, or of any of our managed offerings.

Or, if you want to help us in our quest for open-source security proliferation, check out our careers page or drop us a PR on GitHub.