Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In under five years time, Kubernetes has become the default method for deploying and managing cloud applications, a remarkably fast adoption rate for any enterprise technology. Amongst other things, Kubernetes’s power lies in its ability to map compute resources to the needs of services in the current infrastructure paradigm. But how does this tool work when faced with the new infrastructure layer that is blockchain? Can the two technologies be used in conjunction?

As one of the engineers on the Gravity team here at Gravitational, I was tasked with adding SELinux support to Gravity 7.0, released back in March. The result of this work is a base Kubernetes cluster policy that confines the services (both Gravity-specific and Kubernetes) and user workloads. In this post, I will explain how I built it, which issues I ran into, and some useful tips I’d like to share. Specifically, we will look at the use of attributes for the common aspects of the policy.

In this post, I want to share my observations of how SaaS companies approach the trade-off between having solid cloud infrastructure security and pissing off their own engineers by overdoing it. Security is annoying. Life could be much easier if security did not get in the way of getting things done.

Over the last couple of years, we’ve started to see computers take to the street, and lucky for us, it’s been mostly to help us get deliveries or transport us around. These robots are a combination of sensors, compute units, and some form of connectivity. They have personalities, and if you look closely, two cute eyes on Postmates’ Serve that provide it with stereo vision to navigate the streets.

Blockchain, IOT, Neural Networks, Edge Computing, Zero Trust. I played buzzword bingo at RSA 2020, where the phrase dominated the entire venue. Zero Trust is a conceptual framework for cybersecurity that characterizes the principles required to protect modern organizations with distributed infrastructure, remote workforces, and web connected applications.

If you were running a business that was not oriented to remote work, it has been completely turned upside down. Even if you were “remote-only”, it is likely going to be tough sledding for the foreseeable future given the resulting economic downturn.

There’s no denying that SSH is the de facto tool for *nix server administration. It’s far from perfect, but it was designed with security in mind and there’s been a huge amount of tooling written over the years to make it easier to use. In addition, many popular products and just about every server deployment system integrates with SSH somehow.

The Zero Trust approach to security is based not on where you are, but who you are. This model shifts the focus from network and perimeter-based security to identity-based access. In simple terms, this means: Zero Trust security provides a powerful approach to keeping an organization’s resources secure and usage auditable.

For the impatient, in this blog post, we’ll look into the problem of preparing a Kubernetes application to be deployed into a large number of Kubernetes clusters, even if you, the developer, do not have direct access to them all. The tutorial parts of this post will utilize Gravity 7.0, which you can download here. This version is in beta at the time of publication, so be sure to select pre-releases in the dropdown on the download page to access it.

Today, we are excited to announce the release of Gravity 7.0! Gravity is a tool for developers to package multiple Kubernetes applications into an easily distributable .tar file called a “cluster image”. A cluster image contains everything an application needs and it can be used for quickly creating Kubernetes clusters pre-loaded with applications from scratch or loading applications contained within an image into an existing Kubernetes cluster like OpenShift or GKE.