Kubernetes: Vulnerabilities, efficiency and cloud security

[00:00:00] CS: Today on Cyber Work, Michael Foster from StackRox discusses Kubernetes and its possible vulnerabilities. We discuss intrinsic Kubernetes security issues as compared with those that come from improper use, the work of a cloud security advocate and evangelist, and Michael's time in the Chicago Cubs. That's all today on Cyber Work.

Also I want to tell you about a new hands-on training series called Cyber Work Applied. Every week expert infosec instructors and industry practitioners teach you a new cyber security skill and show you how that skill applies to real world scenarios. You'll learn how to carry out different cyber attacks, practice using common cyber security tools and follow along with walkthroughs of how major breaches occurred and more, and it's free. Go to infosecinstitute.com/learn or check out the link in the description and get started with hands-on training in a fun environment. It's a new way to learn crucial cyber security skills and keep the skills you have relevant. That's infosecinstitute.com/learn.

And now let's begin the show.

[00:01:04] CS: Welcome to this week's episode of the Cyber Work with Infosec podcast. Each week we talk with a different industry thought leader about security trends, the way those trends affect the work of infosec professionals while offering tips for breaking in or moving up the ladder in the cyber security industry.

Michael Foster is a passionate tech enthusiast and open source advocate with a multi-disciplinary background. As a cloud native advocate at StackRox, Michael understands the importance of building an inclusive community. Michael embraces all forms of automation focusing on Kubernetes security, DevOps and infrastructure as code. He is continually working to bridge the gap between tech and business and focus on sustainable solutions. Today's show is going to be all about Kubernetes and we were given the idea of having a whole talk about the hidden vulnerabilities in Kubernetes in some ways in which a system that's meant to increase efficiency and safety in the dev process can be made, well, more efficient and safe. So, Michael, welcome to Cyber Work.

[00:02:02] MF: Thank you for having me.

[00:02:04] CS: So let's start by getting some insights into your background. What first drew you to computers and tech and specifically cyber security?

[00:02:12] MF: It actually goes way back. I went to school as a chemical engineer. It was between computer science and chemical engineering, but at the time I just like chemistry coming out of high school. But one of the main things that drew me to tech was the ability to actually learn even when you weren't working. So not many careers do you have the –Like let's say you hit bad times, you get laid off. Do you get to go and contribute to a project and get a new skill that you can go and leverage to a new job?

So one was the constant learning instability, to me that was really one of the huge benefits of tech. Now being able to work from home, sneaky thing that has worked out.

[00:02:49] CS: Yeah. That has for sure changed the game, hasn't it?

[00:02:53] MF: Yeah. I’m just a big self-learner. I like to read. Do research on my own time. So IT gives me all those benefits.

[00:03:00] CS: Oh, that's great. Yeah. Yeah. So I was also a chemistry major in college until I hit a wall called calculus-based physics. That was a little out of my brain range. Because you graduated with chemical engineering and you said you always kind of had an eye towards computer science, were you sort of doing both at the same time when you were in school?

[00:03:22] MF: Yeah. My school was really good. We had intro programming classes, and I mean even process control classes. Like you look at some of the plan operating systems. They're very simple, right? Very secure off the grid. But I always had kind of an understanding and my family also works in IT. So I always kind of had that background. It was natural.

[00:03:40] CS: So you were joining the family profession sort of.

[00:03:42] MF: Yeah. It was good to have a sounding board when things are confused. And I always just played video games growing up. So it's natural. Just always playing it.

[00:03:51] CS: What was your first system?

[00:03:55] MF: Oh! Honestly, Halo was the first, because I’m a little younger. But 2000 Halo was first and then I got into PCs when I got a little older.

[00:04:03] CS: Got it. Yeah. I’m old enough to have started on a Commodore 64. So just as a side note, am I reading your bio correctly? Were you part of the Chicago Cubs for two years, 2015-2017?

[00:04:17] MF: Yes.

[00:04:18] CS: In what capacity?

[00:04:19] MF: I was just in the minor leagues.

[00:04:21] CS: Okay.

[00:04:21] MF: Yeah. I went to school. I was a chemical engineer but then I also played for the baseball team while I was there. I ended up getting drafted. I actually got drafted to the Astros the year before. Passed on that and wasn't part of the cheating scandal. So I missed that. And then –

[00:04:34] CS: Make a note of it.

[00:04:35] MF: Yeah. I got to play the minors for the Cubs for two years. And yeah, luck, unfortunately I had an injury that forced me to retire. Just big shoulder injury. But, yeah.

[00:04:47] CS: Got it. Okay. So you move pretty quickly from baseball to 2017 becoming a quality control analyst and then cloud solutions in 2018. Can you walk me through some project, studies or other knowledge shifts that happened in this time that caused you to pivot into cloud security? Or was this something you were interested in even before this?

[00:05:05] MF: Yeah. I can actually take you along that path. Thanks for asking. So when I first got injured, 2015-2016, data science and ML really was just kind of starting to be a huge hot topic issue. So that kind of naturally drew me and I started doing Python code and some basic courses and things like that. And then once I was forced out of baseball I was like, “Okay. Well, what is the transition path?” And luckily some people point me in the right direction. They said, “Why don't you go and set up a server? Because, really, you got to work infrastructure up especially if you're getting into big data and big data processing. It really helps to know how you're processing down.” That was the advice that was given to me.

And so I bought a server and I started you know getting set up with Ubuntu and CentOS. And then obviously I ran into issues. How do I make this repeatable? Okay. Well, I got introduced to Terraform. And then it's, “Okay. How do you scale it?” Got introduced to containers and Kubernetes. And this was all on my own time, but just through external resources and being pointed in the right direction.

Luckily, I’m in Toronto, so I got an internship to a company called CloudOps based in Montreal. And they were doing a research project focused around introducing Kubernetes to data scientists. And that was my internship. And then I got brought in as a consultant for the better half of two years before StackRox found me.

[00:06:25] CS: Okay. So you were sort of living two lives at once. You were doing the day job stuff. But like you said, you were always kind of learning in the evening. Can you can you talk about that? Like how did you know where – Were you just sort of learning things based on personal interest and just where your sort of obsessions took you?

[00:06:43] MF: Yeah. I find that getting hands-on with things helps me learn a lot more. Internet and Google is a great resource, right? So I’ve found that once I had the server – And I had a little bit of help as well just in terms of pointing me in the right direction, which is huge. It's why I’m a big fan of mentorship and advocacy because you can just save people a lot of time, right? So I had that help. And then just getting dirty and figuring out what solutions worked really just helped me kind of go through that learning process. And then eventually I kind of gave up on the machine learning craze and I got more into you know infrastructure as code, DevOps and being part of a consulting team. It was more about implementation of different cloud native technologies.

[00:07:27] CS: What was it that sort of cooled you off on machine learning? You said you felt like it was kind of a dead end. Like can you talk a little more about that?

[00:07:35] MF: Yeah. So what I’ve found is I think that there are really good jobs for people who are data analysts or who come out with a specific like statistics background with a background in coding that can be useful for companies. I mean there're a lot of good tools that are out there in the cloud. But when you're talking about the like big kind of changing roles, you're looking at higher education, Ph.Ds, research papers, like those are the jobs that really move the needle on it. And to be honest, I just kind of got roped into DevOps and kind of that culture and I really like the fit.

[00:08:07] CS: Okay. Nice. So yeah, to our topic today, we're going to be talking about vulnerabilities in Kubernetes. And this is a name that people have trouble pronouncing or knowing sort of where to start with it. So because a lot of our listeners are new to some of cyber security concepts and stuff, I want to talk from the ground up a little bit about some basic concepts. So to start right at the beginning, what is what is Kubernetes? What is its purpose? And what in its optimal configurations are the problems that it helps to solve?

[00:08:42] MF: Sure. Kubernetes is a container orchestration system. Really, containers are at the heart of it. So if you're just starting out, you're used to traditional infrastructure virtual machines, containers is kind of the natural next evolutionary step. They're not like VMs though. So that's the other thing. And really it's just how do we operationalize? We spent the better half of 20 years operationalizing VMs, and that turned into your basic cloud architecture and the rise of Amazon and companies of that sort. And then now it's, “Okay. Well, we have this new technology containers. We need to operationalize that too. Scale it, grow it, network it, secure it. How do we do that?” Kubernetes was the answer to that, and it was also based off of Google System, Borg, right? So Google already had a system in place for operationalizing VMs. And Kubernetes was the offshoot of that project.

So natural evolution, it's really there for I'll say not for every use case. That's I think the issue with Kubernetes and the documentation is it's like, “Oh, containers are these awesome things,” and people jump right into it without – There's just a significant knowledge gap involved I think over versus setting up a VM and working in there. I think the payoffs when done when done right you see a massive increase in velocity and developer speed when it's actually implemented in the correct way.

Now, one of the things that I see too is companies wanting to make the jump but then not actually structuring their teams and responsibilities correctly, which also can be an issue. But back to the original question of what is Kubernetes. Really, it's a management platform for orchestrating containers that can scale to an insane size for management. And really that's what we're looking at. When you're looking at Kubernetes, you're talking about how do we manage and deploy hundreds of containers on a single on instance and then scale it to a just massive amount across different regions and zones. That's what Kubernetes is designed to do. So that's a great place to start.

[00:10:43] CS: Just to jump on something you said there, namely that some people – That some companies are either sort of hesitant to use it or what ends up happening is they do implement it, but they don't – They said sort of reshuffle their team appropriately. What are some common issues in terms of misuse or not taking full advantage of it that you see?

[00:11:08] MF: Yeah. So maybe you have operations teams and you have developer teams and you have a couple different products. The different products are going to have different security needs. Some might need more sys calls than others. Some might need more ports open than others. And what happens is if you don't have them structured properly you might get them using the same name space or on the same cluster, but then you haven't actually separated and used those Kubernetes native tools to separate them properly, right?

And then honestly what happens is operations will then try to push back and say, “Hey, you have to implement these security controls. Otherwise your two applications are going to conflict.” And then you get the natural pushback of your hampering developer speed. Developers are hitting a wall. So there's there're this constant back and forth. And really that's the cultural-wise towards DevOps was to break down that wall.

I think DevOps is somewhat of a hot topic because it's used properly but not always implemented in the correct sense of the term.

[00:12:07] CS: Yeah, and it is still sort of – There are these sort of fine gradation, SecOps and DevOps and DevSecOps and so forth that – And there's no real sort of universal system. People saying like do it this way.

[00:12:21] MF: Yeah, it’s a cultural change.

[00:12:21] CS: And a lot of it has to be kind of implemented on the fly too. I imagine like you can't really break your day-to-day operations to sort of like implement an entire new system like that. So I think a lot of people are just like, “All right. Just put it in there and we'll figure it out on the go.” And then you get too used to using it in the haphazard way.

[00:12:39] MF: Yeah. At least when people come at my previous job and StockRox as well when people ask how do we get started with Kubernetes? It's a year, two-year journey, right? Especially for corporations to make that shift. Individuals can make it a lot quicker, but there's a whole road map of technologies you have to get used to. So it's not just like a lift and shift, right? It's nothing like that. And even just taking monoliths and then trying to put them into containers, it's not the same, and you're not really taking advantage of that architecture.

So one of the issues that I have is just dispelling that myth of like Kubernetes is the next hottest thing. It's the best thing in the market. No. There's proper ways to do it, and I think that the CNCF and the community is coming around to recognizing that.

[00:13:22] CS: So when you said that there's a one to two-year shift needed, what are some of the milestones along that way? What should you be doing after three months? After six months? After a year that you're not doing now or whatever?

[00:13:35] MF: Yeah. The CNCF actually has a roadmap that they put out, which is pretty good. It goes through their technologies a little bit more because Kubernetes is so pluggable. So you get your container set up. Then you get Kubernetes operationalize now. What do you do? Now you need visibility tools, right? Now you need to monitor. You need logging. You need tracing. Might need like an APM that you need to go by or something like that.

There are specific kind of you know different applications that you need to add. Maybe it's ingress security, right? And you can do it at different times depending on where you are as a company and what the timeline looks like to production.

What I tend to see is companies that either never get off the ground with Kubernetes because they don't know how to secure it, right? Companies are just like, “We don't even know how to secure containers,” and they don't know the technologies out there. So they just don't even jump. And then there's the, “Let's go into containers.” They move a monolith in and then they just slowly try to piece it off and then it's patching the logging and it's patching the metrics. And then finally when they operationalize it and try to push the production, it's, “Oh, wait. Yeah. We have security things that we need to go.” And then when they're implementing security at the tail end of it, they're coming back and it's kind of breaking a little bit of their pipelines to say, “Hey, we can't do that in production,” right?

[00:14:49] CS: That's great, because obviously that leads us right into our topic for today, Kubernetes vulnerabilities. So can we start by dividing them, if it's possible, between say vulnerabilities that can be solved with patching or just correct usage that might not be or dividing it on the other side into problems that are maybe just inherent to the product?

[00:15:09] MF: Yeah. So there're a couple layers there. I guess I probably shouldn't use layers, but when we’re talking about Kubernetes, we're talking about containers right? So containers and the application code that's running in the containers have their own vulnerabilities and that is something that we need to scan for using something like an image scanner. We need to make sure that the containers themselves aren't old, right? So making sure that we're updating. Even internalizing the containers and managing them ourselves. That's also a conversation, right? Moving them off Docker hub and rate limits and things like that.

So the containers is one part. Then there is, “Okay. Well, we have our containers. How are we setting up the configuration around the containers?” And that's more of a Kubernetes problem where most of the Kubernetes security issues are misconfigurations of the Kubernetes features, right? It's not necessarily Kubernetes itself that's having the issues. It's just there's RBAC controls. There's ingress and things just aren't set up in a proper way. You get multi-tenant issues, things of that sort. Then there's Kubernetes. So you'll have – The new one is the man in the middle attack that came out, which really only affects multi-tenant issues, but it's a significant. Then there was the laughing attacks last year. So too many calls to the API server causing it to shut down. Those things normally are patched pretty quickly. And especially since you have cloud providers, the average cloud provider and the average usage I think is for using version 115, which is pretty stable. It's one of the more stable versions, but you're also missing out on all the new functionality that's in 119. So it's one of those you're using the stable version. You can't upgrade to take advantage of the new ones. But then if you upgrade to the new ones, then you're introducing new features that may cause vulnerabilities with the misconfigurations, right? So there's this – It's one of those things where the knowledge gap needs to be solved first before people take the leap into Kubernetes and implementation.

[00:16:58] CS: Okay. That's great. Yeah. So that was give me my next question, was what are some aspects about the inherent insecurity aspects of Kubernetes that users aren't well aware enough of. So you basically just said it there. You're jumping forward to new interesting versions, but you might not be aware that they might not be quite as secure as they could be in the tried and true version. Is there anything else like that?

[00:17:23] MF: Yeah. Kubernetes is very complicated, but it's designed to be open by default, right? Permissions are open. You come in with cluster admin. The default service accounts are basically like, “Hey, if you create a pod, it's going have a default service account. You can do whatever you want with it.” Designed like that, because had they actually implemented proper security controls, nobody would use the thing. So it's about knowing those defaults. So you default service account. Really, we should be removing those. And every single deployment should have its own service account that's tailored to it in its own namespace, right?

RBAC control is same thing, is if you have a service account, it needs to be properly tailored. Networks. So network policy, open by default. Really, there's a couple different ways to implement it, but because networks – Because it's an additive policy, right? So it's either open. But then as soon as you implement one policy, it shuts everything down and only that one specific port will be open, for example, for that service for that pod, right?

So I remember, I was actually at a conversation with a meet-up with Microsoft and they spent 30 minutes talking about the default deny option for network policies, right? Just even as part of test, right? Just turn it on, turn it off. See what works. See what doesn't. Just shut down the networks in the namespace. And then adjust accordingly.

But one of the biggest issues that I find, and it's more of a cultural issue, is just visibility into the cluster. And you're really starting to see these different projects take off in the Kubernetes community. But a lot of people, they start running and they get on kubectl, kubectl, however you want to call it, and you just get a list of deployments and services and you just don't really know how to visualize it. What's interacting with what? And so the different projects with Prometheus, Grafana, Elastic and stuff like that I think are really helpful as a starting place to understand what's going on in your cluster.

[00:19:11] CS: Okay. So what is your Kubernetes security checklist? Are there things that people should be doing with it straight out of the box to make it more secure? You were mentioning that a little bit with turning on and off privileges and what have you.

[00:19:23] MF: Yeah. I’m actually working right now with SIG security docs. We just had a meeting about it today, and actually there's nothing like that in the Kubernetes documentation for – There's like your basic learn how to do stuff, but there really isn't a checklist. There's a map for technologies, but yeah, anyways.

[00:19:39] CS: Yeah. I think you say, basically, they want it to be as open as possible. So they're not necessarily going to like tell you what to do in that regard, but it might be worth it.

[00:19:47] MF: Yeah. No. I agree. You really need to know the basics of Kubernetes first before. Like really go and play with Kubernetes. Don't put into production. Don't – take your time. Get to know it. Go and get the certs. Learn. Then what you want to be looking at is – I like to work on the pod level. So if you're a developer, for example, and you're going to start and you're going to containerize it, you need to know what's going on in your container. So that means you need to know how much resource it needs. How much CPU? How much memory? What privilege does it need? Does it need syscalls? All of that can be configured in the deployment spec, right? And that's going to cover most of your use cases, right? Is it a stateful application? Really, we should not be writing to the host. So learning that also helps you learn to be a better developer in Kubernetes, because, really it’s designed for – Originally it was designed for stateless applications and less stateful applications. It seems like statefulness was more of an afterthought.

So I think if you're a developer, you're working containers. Start at the pod spec. Start with deployments with security context, user IDs and group IDs specifically, because that's another issue. And then you can kind of understand, “Okay, now I know what my application needs. Now I can actively communicate that to a DevOps team or to the infrastructure team to say, “Okay, you can firewall off these ports. This is all my application needs,” right? So if I was going to answer for the checklist, I'd say start at the deployment level. Learn what's going on in the container. Learn the vulnerabilities of the container and then shut everything down using the deployment spec that you can. And then after that, hopefully, then you get more into an operationalizing and more DevOps specific team. I think it really depends on it. Yeah, it depends on hopefully you can hand that problem off to somebody else.

[00:21:32] CS: Okay. There you go. That's always my favorite piece of advice. So to move sort of one level up from there, what are some ways you'd recommend that Kubernetes be made more safe in the future? I mean as long as we're writing letters to Santa right now, what open letter would you give on that level? What are some things that are known about and either being worked on or not known about or not being given enough attention to? What do you think?

[00:21:56] MF: I mean, I’m trying to help with this. I think documentation and actually vocalizing the value of doing these things especially earlier on. I’m part of the business value subcommittee, because I think you're starting to realize that Kubernetes itself needs to actually vocalize the actual value of it, because sometimes there's just so much information out there. So that'd be one.

I know they're working on multi-tenant, multi-tenancy. I haven't really looked too much into that project. But starting with research and starting with a bunch of researchers working in Kubernetes, that can get hairy real fast when you're talking about stateful applications and using POSIX and UIDs and GIDs and what happens when people want to switch groups? And it can get somewhat hairy. So I would love to see something where research became more useful, because I think that it has exponential gains in the research community especially to be able for a researcher to have their container that they run their applications on and just go and drop it anywhere.

The other thing too is if you're running parallel workloads, a lot of the code for research is not necessarily optimized for large-scale infrastructure. So you actually end up getting a lot of wasted CPU time. I think Kubernetes would be able to take more advantage of that. I just haven't really seen as much of a push in research because there is such a big knowledge gap and researchers really are focused on their work. So I would love it if I had a wish list.

[00:23:25] CS: Sounds all right. We're going to mail that off and see what happens. So I want to pivot a little bit. We want talk about things happening in cybersecurity, but also we want to talk about the work of it, Cyber Work. So I want to pivot to your role at StackRox specifically. That of, as it says, cloud native advocate and evangelist. So can you tell me a little bit about the aspects of your day-to-day job as an evangelist and an advocate for cloud security?

[00:23:53] MF: Yeah. Sure. It kind of is an interesting role, because I’m in between sales marketing and the devs, right? So developers have different projects that they're working on and sometimes we need to vocalize this in terms of what is the product doing that's differentiating? Like how are we really enabling security in Kubernetes, right? And how are we doing in a reasonable way?

So when I’m interacting with the devs and the product team, it's interesting just to see what they're trying to do for the different customers and how they're planning on implementing it. And then it's my job to kind of vocalize that to the customer as well as sales and engineering. Sales engineers, they do that too.

On the evangelism side, I’m also interacting with the community because it's interesting to see the community's developments, right? So my pod security policies are aimed to be deprecated soon, right? How does that react or how does that influence our product and do we need to adjust some of our risk management tools or anything like that accordingly, right? There is this constant feedback with the community and with enterprise right now especially with Kubernetes, because Kubernetes is seen as more upstream, right? Especially the CNCF 120 gets released. And then it'll get adopted in a year from now after all the different cloud providers have done their checks.

So, really, it's about just interacting and being involved in the community, creating awareness and pushing for, I guess, I want to say content that can actually bring people in to the fold in a reasonable way trying to cut down on buzzwords.

[00:25:28] CS: To that end, I mean if people want to do the kind of work you do and work in cloud security and work as a tech advocate or an evangelist, to that end, what are some hard and soft skills that they should have to make them desirable to potential employers? It sounds like communication is obviously a huge part of it, but you can't just communicate if you don't know the tech. So it sounds like you really have to know a lot from both worlds, right?

[00:25:49] MF: Yes. There's that. Unfortunately, there is speaking the language a little bit and it's understandable with tech. I came into to more cloud native softwares and Kubernetes and I actually had to work backwards to understand more legacy systems. So the consulting side actually really allowed me to do that. Not everybody gets that privilege though. So I would say like I think the CNCF is a great starting point for people even if it's just get on a Zoom call. Like the meetings are all public. Get on a Zoom call and just listen to what people have to say. And I found that extremely useful for just understanding the thought process of what's going on. And then like documentation is a great place to start, because you're starting with the simple workflow and you're explaining the thought process so that when you go and actually build these tools later you're going to understand that thought process and be able to communicate it effectively too, right? I think that's a great starting point for people and it's something you can do on your own time. And that's honestly why I really like the CNCF. It's one of the reasons you know why I do what I do today.

[00:26:51] CS: Yeah. Are there things that you can put on your – I mean, legitimately, you can put on your resume to let people know that you know these backgrounds. Are there are there skills or projects or ways that you can sort of communicate that you understand this sort of thing and that you have some history with it especially if you're just getting out of school or just starting in the field?

[00:27:11] MF: Yeah. I mean, I personally can – You can just record videos and stuff like that even if it's a YouTube channel. I mean when I applied to StackRox, I had some content and educational content that I created and I forwarded it to them, right? So even if you're let's say studying for the CK, for the Certified Kubernetes administrator to get that base level knowledge, create a study guide on GitHub. Fork an existing one and then talk your way through the technologies that you're using. Honestly, a lot of IT – I think if you can get over the imposter syndrome and actually just get dirty and get out there and start working on projects, people will see that initiative and they really appreciate that and they appreciate you trying to work through these different problems, right?

[00:27:57] CS: Right. Yeah. And they can see you – If you're good and afraid, they can see you sort of thinking through the problems in real time too I imagine.

[00:28:05] MF: Yeah, because it's so hard when you get into like at the interview process to distill down your life into 45 minutes, right? So here you can go on your own time and look at some YouTube videos I posted or some projects even if they're half-done projects. Just do the project, but then also do like a little bit of documentation just explaining what you're trying to do on the project, right? That communication, if just saying, “Hey, this is what I was trying to accomplish. I got stuck on this problem and I abandoned this. Somebody else feel free to pick it up or let me know,” right?

If you look at some of the cloud native technologies that are out there, a lot of the new stuff is just based off of stuff that people worked on in 2017 and they took a couple pieces of functionality out and they merged it into like a framework or something like that, right? It's a very Darwinian space, I want to say. And also it's reliant on people's time. So you never know.

[00:29:02] CS: Okay. Well, I mean you mentioned before that you're still sort of at the start of your security journey here in cloud security and tech and so forth. So can you talk a little bit about like what types of projects or job positions or opportunities you're trying to make happen in the next, say, five to ten years? Where does something like cloud security advocate or tech evangelist go next?

[00:29:25] MF: Yeah. That's an interesting one. That's a good question.

[00:29:29] CS: I’m not interviewing you for a job here per se, but I am asking you the five-year question.

[00:29:35] MF: Yeah. Well if you asked me five years ago where I'd be, I would not say this role.

[00:29:38] CS: Right. Oh, yeah.

[00:29:40] MF: But I will say that –

[00:29:41] CS: Hitting dingers in Wrigleyville. Anyway –

[00:29:49] MF: Look, because I came from consulting. There is always a place in IT for people who can communicate business value from developers to the business, because developers, they want to work on projects and it's buying them time into the things that they think are going to impact the business and also somewhat sometimes steering them the other way too, right? There's always going to be that glue. I kind of see myself more as an operations implementation type of person, because that's my background where I’ve come up from.

That being said, who knows? I could get on a side project with the CNCF and maybe I’m a maintainer in a side project there. So I personally just look to continue to evolve my and then see where it takes me. But, yeah, I could see consultants, DevOps engineer. Even DevOps engineer, I don't even think was a role five years.

[00:30:38] CS: Yeah. You could springboard in a lot of directions then it sounds like. This isn't like a straight ladder where you definitely are going to go from here to here to here. You're still in a developmental point where you can sort of fork off in different directions I imagine.

[00:30:52] MF: Yeah. I’ve seen people go from advocate to like cloud transformation specialists, right? Because the company wants to go into Kubernetes, what's the roadmap? And I’ve seen the roadmap over 10 times now. Well, actually somewhat implemented over 10 times. So it’s one of those things that you just kind of continue moving.

And luckily with the speed – Kubernetes really has showcased the speed of developers and now there's the whole meme of Kubernetes, like all the different applications that are out there. So there's always people trying to make sense of it all and figure out the use case for that specific application. I don't think people are going to – It's just going to be interesting to see where Kubernetes comes out in the next three years, I'll say that.

[00:31:35] CS: Okay. Yeah. Would you like to speculate on that?

[00:31:37] MF: I think it's going to continue to mature. I think as more and more – As the product starts to stabilize I think a little bit, you're going to see more adoption from companies, especially the ones that need to scale and scale quickly. I see the edge computing case being really big especially with data protection and like the more political sense coming into play. Like you're seeing things like Anthos and Azure Arc and Amazon everywhere kind of thing where you need a hub to control your clusters, but then you might have a cluster in Europe, a cluster in North America and a cluster in Asia all with different data protections, right? So regulation really does come into that too, and I could see that playing a factor for where you host your Kubernetes services.

[00:32:19] CS: I mean this is unfortunately the question in 2020 all the time, but have you seen the sort of process accelerate or decelerate due to COVID and the sort of decentralizing of offices and banks in the office and things like that?

[00:32:38] MF: In terms of functionality, Kubernetes really hasn't slowed down in terms of like added functionality and the different things that they're doing. They slowed their release cycle to three releases a year. I actually really agree with it. I think four is a lot for enterprise to keep up with, and that is one of my criticisms. Open source is support and understanding the kind of how slow businesses are to some extent. It's just my two cents. But, yeah. I think the three releases is good. I think it allows us to analyze more and more chunks, but there obviously is the tradeoff of now each release is going to be more feature-heavy. So you're also going to not necessarily be able to communicate those features as well. Again, in terms of release cycle, it's good. Features I don't really see it slowing down, and adoption really has not slowed down either.

[00:33:26] CS: Right. All right, as we as we wrap up today, um tell me a little bit about StackRox and your current offerings and some projects on the horizons that you're excited to talk about.

[00:33:35] MF: Yeah. So StackRox was actually one of the companies at the beginning who banked on Kubernetes. They saw Kubernetes scaling and being kind of the main container orchestrator, I mean main player. So it's good to see people kind of catch on that that is the way to go. StackRox, it basically handles risk management, configuration management, networking. It can create network policies for. You can do it all. We have a 30 minute demo that you can easily just install to look at your clusters and get started, and in 10 minutes we'll show you all your vulnerabilities.

The one thing that StackRox does really well is it follows kind of that Kubernetes mindset. And one of the main reasons why like it fallows the Kubernetes mindset where it doesn't shut down anything by default. It's there to give you the information. Companies look at risk differently. So it's not there to say, “Hey, this is the high riskiest things, or this is the riskiest things.” It's there to show you, “Here are the container vulnerabilities. Here's the configuration issues that you have,” right? And then allow you to pick off the first three, right?

Really, you want a solution that sticks and not one where your developers are just going to throw at the window, because really that's who you're designing the application for. But yeah, and installs into your cluster. Nothing comes to us, although we are looking at different ways for implementation for different use cases. So stay tuned in 2021, and you can easily check it out at stackrox.com on the internet.

[00:34:56] CS: Oh! You scooped my last question. If our listeners want to learn more about Michael Foster or StackRox, where can they go online?

[00:35:03] MF: Yeah. So stackrox.com. StackRox, our GitHub. We also have a new open source tool. So if you're looking to get started, and especially some of these configuration issues, we created KubeLinter. So open source tool. You just KubeLinter lint your files and it'll show you – If you have privilege escalation and the different issues in your deployments. Nice easy tool on the command line. Recommend it especially for people getting started. And then for myself, Twitter, Michael Foster, and LinkedIn. And feel free to email me at michael.foster@stackrox.com.

[00:35:34] CS: Perfect. Michael, thank you so much for being my guest today on Cyber Work. This was a lot of fun.

[00:35:39] MF: Yeah, thanks for having me. I enjoyed it.

[00:35:40] CS: And thank you all as ever for listening and watching. New episodes of the Cyber Work podcast are available every Monday at 1 PM Central both on video, at our YouTube page and on audio wherever fine podcasts are downloaded. And don't forget to check out our hands-on training series titled Cyber Work Applied. Each week, expert infosec instructors teach you a new cyber security skill and show you how that skill applies to real world scenarios. Go to infosecinstitute.com/learn to stay up to date on all things Cyber Work.

Thank you once again to Michael Foster and StackRox, and thank you all again for watching and listening. We'll speak to you next week.