The increasing adoption of microservice architecture has led developers towards cloud native environments. However, this transition comes with its fair share of security challenges.
Michael Chenetz, Head of Technical Product Marketing for Cisco’s* Emerging Technologies and Incubation, joins us to talk through his experiences in the cloud native ecosystem and how he approaches Kubernetes* security.
Katherine Druckman: I needed a guide like Michael a couple of years ago when I found myself on an engineering team learning Kubernetes as a beginner and working on a microservice and going from that very monolithic old way of doing things to suddenly: “Oh, here I am in the cloud.”
Michael Chenetz: We'll call it the “classique” way.
Katherine Druckman: Oh yes, from “classique” application development to learning Kubernetes and pods and clusters and Helm* and logs and Argo* and all these things and… oh my. I bet everyone listening has seen “THAT” diagram: The giant diagram of the cloud native ecosystem.
So, Michael is our tour guide today.
Michael Chenetz: I often think about that...The people who have been here for a while take for granted that we've grown along with it. The problem is that there's a huge ecosystem around this whole cloud native thing these days. There are so many options! I often think that if I were new right now coming into this ecosystem, I’d be massively overwhelmed...
Where do I even start? Typically, your CTO says: “Hey, we want to modernize this app... Maybe we want to put it in the cloud.” And then it rolls downhill. Then somebody else says, “Hey, I was told that I need to do this thing called microservices and rebuild this app and blow it up and….” It's almost like that deconstructed dessert that you eat. We're deconstructing this whole thing. I have to figure out what my dev environment will look like, how people will interact with that dev environment, but also how to implement it in this thing called Kubernetes.
So, you go to the Kubernetes website first, maybe, or the Cloud Native Computing Foundation* (CNCF), depending on your entry point. But if you go to Kubernetes, you start by looking at all the requirements. First, will you do bare metal? Are you going to do it on the cloud? If you do bare metal, how will you implement it? What kind of container network interface (CNI)? What kind of container storage interface (CSI)? Do you need a load balancer? And by the way, what about security? Oh, that's an add-on too. Typically, most people just getting into Kubernetes don't care about security first. They care about getting that application up and running...
After that, you've got this application that was supposed get out the door three weeks ago, and you go to your team (dev ops or platform engineering) and say, “Hey, I have to get this up now.” And they ask, “Well, did you meet all these security requirements?” You're like, “Security requirements? Uh…”
Then you have to dig even further into a plethora of documentation about how to configure Kubernetes securely or how to configure all the other elements that you're thinking about. And that's really the difficult part.
Katherine Druckman: People don't necessarily have a security first mindset...Most developers are trying to make things happen, period. You're on deadline and trying to make it work.
Michael Chenetz: Yeah, that's what they're paid for and what they're meant to do. You don't want to disturb that because that makes you money. So, you want developers to develop, but you want to create an ecosystem or whether it's standards or different tooling or whatever so they can do it securely.
Chris Norman: Is there too much choice now? Do people get decision paralysis because there are so many different components to pick and mix from?
Michael Chenetz: I do think there is. People get overwhelmed...The CNCF does a lot there, but there needs to be more of a curated view: “Here are different levels of things that you might need to do. If you need to do this, then maybe try these couple of options.” It's hard because there are a lot of different companies and things like that. But it would be nice to just say, “Here are the things you should look at if you're doing an X, Y, and Z.”
Chris Norman: A recipe book.
Michael Chenetz: Yeah, because people don't even know where to start. It's legitimately overwhelming, even for people who've been in it for years...
Katherine Druckman: The more you get into this work, the more you’re focused on your little bubble of whatever project or functionality you’re working on. Meanwhile, there's this grand ecosystem out there and there's all this other stuff, and progress is being made but maybe you can't keep track of it. This is an issue for everyone, just beginners.
Michael Chenetz: It's a huge issue. It's funny that you mentioned “working in your little bubble.” There’ve been so many times where I've gone headfirst into one piece of the technology surrounding Kubernetes, learned everything about it, came back like four months later and totally forgot everything I've learned.
Katherine Druckman: Yeah, that's all of us.
Michael Chenetz: So, there's that issue too, where you're just working in your own bubble. Typically, I spend a significant amount of time focusing on it, but then there can be long periods where I’m not actively working on it. This can create numerous security risks because there might be new people involved who are unfamiliar with security protocols, or those who aren’t security experts but are tasked with managing it. They're not security experts, but they know something about their domain and do what they think is right. All of these factors lead to different kinds of security vulnerabilities and issues.
Katherine Druckman: Where do you look for these points of potential vulnerability? If you're not coming in with a lot of security expertise, which you can't expect everyone to have, where should you be looking?
Michael Chenetz: For starters, the Kubernetes site has a great page on cloud native security.
That gives you some guidelines. It talks about the Four Cs of cloud native security: code, containers, clusters, and cloud...They break it down into what to do if you're using infrastructure, what you have to do if you want policies between your nodes, and all the different capabilities that you need, like role-based access control, Transport Layer Security (TLS) and applications. Those are just a few examples, but for each one they give you the best practices.
There are also tools that can help...Tools for policies and things like that, so you don't have to do it all yourself. The way that I like to see it, developers do what they do and develop and try and create secure code. They know how to create secure code in the best way they can.
There are obviously all kinds of fuzzers you can use to validate all those things, and analytics and analysis... But then put in these stop gaps or gates that would actually check to see, “Okay, does that image have a vulnerability? Does that layer in an image have a vulnerability, that can go down to the layers?” So, there are a lot of different things to do.
Some of those apps are even open source and they can rate where the highest vulnerabilities are. Supply chain's a thing these days because we're developers and we want to develop fast. I always say we're lazy in a good way - we want to get our job done in the fastest way possible, which means that we're going to pull down from the quickest API to get the job done. We'll worry about the security, and the ramifications later. But now what we have to consider is things like supply chain security, API security. All these other layers of security. So, depending on what you're doing, there's not really a good answer because you may need some of these pieces of security or all these pieces of security, depending on how your app is constructed.
For more of this conversation and others, subscribe to the Open at Intel podcast:
- Openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Or your favorite podcast player (RSS).
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.