Like any great technology, the interest in and adoption of Kubernetes (an excellent way to orchestrate your workloads, by the way) took off as cloud-native and containerization grew in popularity. With that came a lot of confusion. Everyone was using Kubernetes to move their workloads, but as they went through their journey to deployment, they weren’t thinking about cloud native observability and security until they got to production.
This post was originally published in Tigera.
With Kubernetes, you can’t wait until the end when you’re ready to move workloads to production; you need to think about security early on. If security is not thought through in a system like Kubernetes, workloads are left vulnerable and you will not end up with a solution that is effective.
Why is this? What makes cloud-native so different? Let’s take a look at some of the differences to understand why they warrant a more holistic approach to security and observability for cloud-native applications, whether in Kubernetes or another environment.
Cloud-Native Origins
What we’re used to (if we remove cloud-native from the equation) is having a client-server architecture, where servers are running on virtual machines (VMs) and you have a cluster of servers with clients connecting to them. This is how we are used to building and deploying client-server applications.
Cloud-native is completely different for a variety of reasons. If we look at it from the server perspective, most practitioners would say that VMs are too ‘heavy duty’ for the simple tasks that need to be carried out (for example, retrieving something from a database or evaluating an HTTP request and sending it out). For these types of tasks, practitioners don’t need a VM, they just need a simple process. But you can’t run a process in isolation—you need to add boundaries around the process. This is how the concept of containers was born.
With a container, you get a particular space inside of your host. The container needs a few things: Its own access to resources (its own chunk of CPU, memory and shared file system access), storage and networking. So you can designate a part of your host (it could be a VM or a node) as your container and run a process inside of that to carry out your task. Because one VM can host several different containers, and each of these containers needs a network, you’ll need an orchestrator to manage containers. That’s where Kubernetes comes in: It’s the most popular orchestrator. (So popular, in fact, that many in the industry tend to loosely associate cloud-native with Kubernetes.) Kubernetes takes your containers and essentially handles almost everything for you; you just need to specify what you want to run.
Why did Kubernetes catch on? Because it offers a tremendous amount of flexibility. While it used to be that you had a server with a set of IPs and maybe a few interfaces that provided access to compute resources, that’s not how it works anymore. Now, you have a server that’s split into multiple containers that can be deployed on any host and you define which application(s) those containers need to communicate with. Kubernetes manages this and takes care of stitching everything together and executing these functions.
Key Differences and Challenges
Cloud-native is different in two important ways: How you secure workloads and how they are delivered. From the security user’s point of view, there is no notion of identity. While container identity used to be denoted by the IP and port, Kubernetes simply takes care of that now; your container could be on one IP today and some other IP tomorrow. This forces you to think differently about how you will secure your workloads.
In terms of the way workloads are delivered, things have changed considerably. Previously, you would build your application, create an image, executable or installer and hand it off to the security team. The security team would then decide which servers to use and create perimeters around them. When everything was ready, they would deploy the application with the confidence that it would be secure. With the automation of the CI/CD pipeline, however, this type of participation by the security team is now gone.
Why is that? Well, with CI/CD, you build a container that generates a certain set of image files that are stored in your repository, and there are automated processes that validate these and deploy them. There isn’t really a place for security to come into play. Since the CI/CD process was automated to allow for faster velocity, it would be counterintuitive for security to get in the middle of that process. Instead, security teams need to move earlier in the development cycle and be more closely associated with the development process—to better understand it—which is referred to as shift-left security.
That’s why it’s challenging to secure cloud-native applications: You cannot do it the way you’re used to.
Moving Toward a Holistic Approach
Kubernetes and cloud-native technologies can be very powerful for operating, deploying and securing your workloads. When it comes to implementing a holistic approach for security and observability in cloud-native environments, collaboration is key. There should be a shared responsibility for security. If you want to secure your container and Kubernetes deployments, you need to think about how your DevOps and security teams can work together—and the application team needs to be on board, too!
Remember, security should not be an isolated concern. You need to approach security and observability for cloud-native applications with a collaborative mindset because you and your teams are only going to succeed by working together—not by trying to bypass each other or by making assumptions that security is someone else’s problem. The characteristics that make cloud-native great are the same ones that necessitate a more holistic approach to security and observability to ensure your workloads are secure.
