On Kubernetes and Databases. Q&A with Ev Kontsevoy
Q1. Do you have your own Kubernetes distro? How does it automate the tasks of running cloud-native apps?
Gravity developers do not like when it is called a “distro”. Gravity allows developers to capture the desired state of a Kubernetes cluster, including all of its applications, in a single file called “cluster image”. The obvious analogy that we prefer is virtual machine images (AMI on AWS or VMDK on VMWare), but cluster images contain entire clusters as opposed to single machines. The benefits are similar as well: Gravity delivers true application portability for cloud-native solutions.
Q2. How privileged access management (PAM) and database security is affected by migrating some (or all) of the workloads to Kubernetes?
It’s a great question. Obviously, the majority of popular databases are not Kubernetes aware and have their own security model, requiring microservices to authenticate. This creates the need to store microservice credentials somewhere. Kubernetes offers convenience features like “secrets” for this.
PAM is more interesting. As organizations adopt Kubernetes, they realize that it presents a second door into their infrastructure, the first one being good old SSH. Kubernetes, being a cloud-native beast, is easier to integrate with a corporate identity, apply role-based access control (RBAC) policies to, etc. SSH is not as flexible and the SSH access at most organizations is quite antiquated. The simple but crude thing to do is to disable SSH entirely. Unfortunately it does not always work for low-level use cases like updating operating systems components.
We address this problem head-on with Gravity by automatically synchronizing RBAC rules between Kubernetes and SSH via a unified authentication gateway which provides both SSH and Kubernetes API endpoint.
Q3. What is a “permissions-follow-data” model?
Permissions-follow-data or permissions-follow-workload model is a term that we are trying to popularize because it closer resembles the real-world security and compliance requirements.
Consider a simple rule: “developers must not access production data”. Trying to impose this rule for SSH on a machine level is a fool’s errand because a machine has no idea if it’s a part of production or staging environment or if it has any data on it. This knowledge exists on a higher level, i.e. on a cluster level. You may have two separate Kubernetes clusters for production / staging, or two separate namespaces within the same cluster. Furthermore, you can tag database pods and volumes and restrict access to them.
But this wonderful story is ruined by developers gaining SSH access to production machines bypassing Kubernetes. We solve this by introducing “permissions-follow-workload” model to the SSH layer, this effectively means that your SSH permissions to a box depend on what pod (or any other workload, actually) is running on it, or on what kind of storage volumes are attached to that box, or on any other attribute that constitutes a “workload”.
It’s neat because we’re taking new, cloud-native capabilities and extending them to legacy tooling and processes, because in the real world we rarely obsolete systems. This allows organizations to move forward while simultaneously lowering operational overhead and increasing security.
Q4. For Gravity, what use cases do you typically encounter from your customers?
The three popular use cases are:
– Quickly creating downloadable versions of SaaS products for easy on-premise deployments.
– Running cloud-native applications globally, on different infrastructure form factors, i.e. combination of private data centers and public clouds.
– Delivering consistent Kubernetes experience within an organization. By publishing an officially approved “cluster image”, an internal ops team can lower operational overhead of having many Kubernetes clusters across different infrastructure form factors, and simultaneously enforce security and compliance.
—————————
Ev Kontsevoy is a Co-Founder and the CEO of Gravitational. Before Gravitational, he launched the on-demand OpenCompute servers at Rackspace. Prior to Rackspace, he co-founded Mailgun, the first email service built for developers. Ev has been a fighter against unnecessary complexity in software for 20 years. He abhors cars but loves trains and open source software that doesn’t require an army of consultants to operate.