Kubernetes security explained : We spoke to Cailyn Edwards, CNCF Ambassador and Senior Security Engineer at Shopify. Interview was recorded at Kubecon + CloudnNativeCon NA 2023. We asked her about the complexities of Kubernetes Network Security in a multi-tenant environment. During the interview, she shared the nuances of Kubernetes network security in multi-tenant setups, tools and tactics for securing Kubernetes environments, insights from her journey at Shopify and tips for advancing the security maturity of Kubernetes networks.
Thank you to our episode sponsor Vanta - You can check them out at vanta.com/cloud
Podcast Twitter - @CloudSecPod
If you want to watch videos of this LIVE STREAMED episode and past episodes
- Check out our other Cloud Security Social Channels:
- Cloud Security Newsletter
- Cloud Security BootCamp
Questions asked:
00:00 Introduction
02:25 A bit about Cailyn
03:08 How is Kubernetes Networking different?
04:20 Foundational pieces of Kubernetes Networking
06:21 Whats missing in Kubernetes Networking?
07:47 What is Multi Tenancy?
10:20 What are some of the common threat models?
13:16 How are people responding to threats?
14:41 Where to start learning about this?
16:26 Best practices for Kubernetes Networking
18:16 What becomes more important with maturity?
21:14 Resources to learn more about Kubernetes Security
22:30 The Fun Section
Resources shared during the episode:
Kubernetes Security Checklist
Pentesting your own cluster with Liz Rice
Ashish Rajan: [00:00:00] Are you thinking about doing network security in Kubernetes from a multi tenant perspective. There is a nuance to how you would do network security. There might be a few open source projects like Kyverno, Cilium that you might have to think about. But before you do that, in this episode, we have Cailyn from Shopify.
She's sharing how you can do threat modeling of a Kubernetes network, specifically in a multi tenant context. What are some of the nuances of running network security in a Kubernetes environment, in a multi tenant context? What kind of open source projects can you use? And what are some of the challenges you would get if you're trying to build a maturity curve around the whole Kubernetes security space?
If this is your second, third, or maybe even 10th, or maybe 50th episode that you're listening to of Cloud Security Podcasts, or maybe watching anotherYouTube channel, and you have been finding us valuable, I would really appreciate if you could take a few moments to drop us a review or rating on your popular podcast platform like iTunes or Spotify.
That is if you're listening to this, if you are watching this on YouTube or LinkedIn. Definitely give us a follow or subscribe. It definitely helps us spread the word and lets other people know as well that we have a community that we would love to welcome them into. [00:01:00] We are a growing community of about 50, 000 people so far.
So we would love to keep growing that and keep spreading the good message of cloud security and how to do that this was a conversation we had at KubeCon North America, where we were and thank you to everyone who came in and said hello and took pictures with us and took videos with us and was kind enough to come on my video of the LinkedIn videos that I post for my daily vlogs for conferences that we attend. Thank you for everyone who came and said hello to us at KubeCon.
If you yourself are working on building a Kubernetes network in your managed Kubernetes or know someone who's probably building a Kubernetes network, definitely share the episode with them. I'll see you in the next episode.
Peace.
We interrupt this episode for a message from our sponsor. A growing business likely means more tools, third party vendors, and data sharing. In other words, way more risk. Vanta brings GRC and security efforts together, integrate information from multiple systems, and reduce risk to your business and your brand, all without the need for additional staffing.
And because Vanta automates up to 90 percent of the work for SOC 2, ISO 27001, and more, you will be able to focus [00:02:00] on strategy and security, not maintaining compliance. Join 6, 000 fast growing companies like Chili Piper Patch, and Autodesk that use Vanta to manage risk and prove security in real time. You can try Vanta free for seven days by going to vanta. com slash cloud, that's V A N T A dot com slash C L O U D to start a free trial, no cost or obligations. Now let's get back to the episode.
Ashish Rajan: So thank you for coming in, Cailyn. Thanks for having me. For people who don't know, could you share a bit about yourself?
Cailyn Edwards: Yeah, for sure. My name is Cailyn. I work at Shopify. I'm a senior infrastructure engineer. Right now I'm doing a tech lead role handling multi tenancy concerns for the Infosec team at Shopify in general.
I'm also a CNCF ambassador and a contributing member of Kubernetes SIG security.
Ashish Rajan: Oh, you're almost like doing two roles. You have your actual job. And then you're volunteering for all these SIG security and everything else as well.
Cailyn Edwards: Yeah. Shopify has been pretty supportive of it over the years, but it's just can't get enough of it.
So I do spend a lot of my [00:03:00] personal time working with SIG security and doing tons of community outreach for cloud native in general. We're hosting our first Ottawa meetup right after this, which I'm super excited for.
Ashish Rajan: Oh, wow. There you go. Maybe for people, and the conversation today was going to be primarily on the whole Kubernetes networking space.
A good place to start that conversation probably is how traditionally networking is approached in a Kubernetes context. And why, we'll talk about why is it bad in the first place. But for people who don't understand kubernetes networking, how is that different from traditional networking?
Cailyn Edwards: Yeah, I would say, first off, It's not all the way different from traditional networking.
I think it's less that the networking is different and more that we think about a different part of the networking. So Kubernetes, you still have a network, like an external network, how you interface with the public internet, and that stays largely the same. Where it differs is internally. Kubernetes is a bit more of a flat network, and you have to manage a whole bunch of internal connections between resources.
And it's important to note that the way that Kubernetes networking is designed is not to be Secure by default. So it starts off very [00:04:00] open to allow all of the communication you need. And it's our responsibility to tell Kubernetes through lots and lots of YAML how exactly we want to lock it down and what our bespoke infrastructure looks like and how it needs to communicate.
Ashish Rajan: YAML is the language of the future.
Cailyn Edwards: I love YAML, I'm using YAML all day.
Ashish Rajan: I think it feels like everyone that I speak to loves talking about YAML for some reason, cloud native. But to add another layer to this as well, what are some of the foundational pieces that people need to understand? Because I feel even till today, we're still talking about foundational pieces of Kubernetes in general as well.
Asking people, what is a cloud native stack has different responses for different people. Yeah. So if we were to start the conversation about Kubernetes networking, what should be some of the components people should understand before we even go down into the whole network security thing? Are there any high level components that they should be aware of from a Kubernetes perspective to deep dive into it?
Cailyn Edwards: I think mostly if you understand the basic Kubernetes resources, that's the key. I think going deeper into what I said, initially, Kubernetes networking, when we talk about it, we're usually talking about it on a slightly smaller [00:05:00] level. So we've got like the really internal connections, we're talking like pods and nodes, and then we have the larger connections, we're talking clusters, and then we hit that more traditional level where we're talking any connections outside of our organizations to the public internet.
So as long as you understand it. Me, because I work on multi tenancy. I'm not as worried about people getting into our infrastructure, but I'm more worried about what happens once something is in our infrastructure and how it traverses between all of those components of Kubernetes.
Ashish Rajan: It should not be able to get out. Even if it gets in, it should just be isolated into a box.
Cailyn Edwards: Yeah, exactly. And that's a super fun concept that I think I am just starting to think about is, as security professionals, our go to is, okay, how do we stop it and lock it and isolate it? But the business thing that we need to be able to sell is how do we restore functionality as fast as possible?
We have that isolated, whatever it is, workload on the side where we can figure out what happened, how bad was it? What do we need to do? We can spend days and days doing that, but we need to restore service as soon as possible, which is where Kubernetes and [00:06:00] cloud native is awesome because you can rebuild.
You already have all of your specifications for what you need to replace it. And. Hopefully you can isolate it a little bit more while you solve whatever problem is over off to the side locked in its little box.
Ashish Rajan: Yeah, I love that analogy also because a of people do approach security in general as a phase that I'm going to lock everything in that's when we make enemies, unfortunately.
But so Network Security what are some of the, because you mentioned Kubernetes by default is not secure. So specifically focusing that on networking, what's missing?
Cailyn Edwards: A lot of things like, and it's not like Kubernetes isn't secure. Kubernetes isn't secure by design. We don't want to say, oh, don't worry, out of the box you get all of the protection that you need.
We want to say, you're going to get this infrastructure and you need to specify how you want that security to look because it's going to be different and not might. It will be different depending on the company and depending on your needs. And even within your company, it's going to be different depending on what kind of workload you're trying to secure.
Yeah. So I think, the basics that you want to [00:07:00] think about is what communication needs to happen. And can you block out everything except that? That is like where everyone should start. But I think understanding what you need is going to allow you to make the most out of Kubernetes.
And it's going to allow you to make the choices that you need to make to have a secure infrastructure. And right now, SIG security is working on what we call the Kubernetes Hardening Guide that's going to go through component by component. And there'll be a huge section on networking that'll say this is what you get out of the box.
This is the most extreme enforced version of security that you could possibly do. And here are all the steps to get in between and figure out exactly what's going to work for you. And so I run into this all the time when I'm talking to people where it's a really long answer because I need to know what's your infrastructure?
What are you trying to do? Okay. Then my recommendations change entirely.
Ashish Rajan: Yep. And because you mentioned multi tenancy earlier, cause a lot of people always think about Kubernetes and, Oh, there's one cluster. How would you describe multi tenancy to people who don't understand that?
Cailyn Edwards: So I feel like this is also a funny thing about when you talk to [00:08:00] Cailyn about Kubernetes, I have spent my entire technical career at Shopify and Shopify does not have one cluster. Spoiler. We have many, I think 700 or something was a number I saw. Maybe more than that. And so it wasn't until a KubeCon Google round table that I realized many large companies are operating in a single cluster world.
And that blew my mind. So what it means. When you have multiple clusters, and not even just multiple, like you can take multi tenancy down into a cluster if you want as well, depending on how you're running your infrastructure, but basically you can imagine having roommates, and so you have these roommates in your apartment building and they have different comfort levels and they are doing different things.
Maybe they're inviting different people over at different times. And if you leave your door open, your really risky roommate might bring over someone who decides to go look in your room and see what kind of goodies you have in your safe. And so when you are living in a multi tenant environment, you need to make sure that you're protecting yourself from any of the other entities that are sharing that space with you. So locking your doors a really good first step, [00:09:00] which is why, a common security practice for networks is like you shouldn't have cross namespace communication. That shouldn't be necessary. If it's necessary to find it in a network policy or define it in a proxy, whatever you need to do to say this is allowed and this is why.
Ashish Rajan: Yep. And would you say multi-currency is coming more from a, it's not the concept where I'm on AWS, I'm on Azure, I'm on Google Cloud, but it's more from the concept of I could have multiple clusters running on the same, cloud.
Cailyn Edwards: Yeah, it's multiple services sharing a network. And that's where it's like I was talking about before, where with Kubernetes, you have these layers of networks.
And like the easiest way to think about it is you have multiple services sharing an infrastructure. And if one service is a project that I spun up to be like Cailyn's goat milking application, and I wanted it to build it fast so that I could show that this is a really cool thing and I didn't do any security for it.
But on that same network is Cailyn's banking information app. And that is mostly secure, but maybe it's allowed to talk to all Kalin's other apps. And then this risky one gets [00:10:00] compromised. All of a sudden the traversal path leads to what I don't want someone to have access to. So it is like least privilege, but applied to services is you want to make sure that if you have.
Things existing in the same infrastructure, whether it's in the same cluster or it's across clusters that are connected, you don't want there to be traversal possible between workloads.
Ashish Rajan: And I guess maybe we should probably talk about threat modeling at this stage as well then. So when you think about threat modeling then, whether it's multi talent or whether its a single cluster. What are some of the common threats, people?
I guess, I think you like the stride model, is that right?
Cailyn Edwards: Yeah, to be honest, I only learned about threat modeling in the last few years. I didn't come to security from a traditional background. I find it most useful when I'm describing security concepts to new people. But overall, I don't typically follow in my head a threat modeling framework.
What I do is I say, what is the the network look like? What is, whatever I'm trying to secure, whatever I'm looking at, I want to map it out. I want to understand what does it need to do and for networking, that means what does it need to talk to? [00:11:00] What are its communication needs? And once I understand that and I understand like the good path, what are people doing?
What are people expecting? And if you're dealing with multi tenancy, it's very intimidating to look at a whole network, but you do want to get profiles for the different types of tenants or clusters that you're dealing with. And if you have. Compliant workloads and you have experimental sandboxy ones and you have just like your general product You probably have different security profiles for each of those So once you understand them you understand the good path I like to start with what I can restrict the most because that's easy, you know You can lock the stuff that doesn't have to talk your sandbox environment shouldn't need to talk to anything else because you are sandboxing there and the moment it needs to talk to something else I want the security team to be pulled in to help you make that transition right and then from there the threat model, again, is very specific to what you're looking at.
You want to minimize communication to only the things that it needs to talk to. So at Shopify, we manage that through only very recently, through a very awesome team. We manage it through Kubernetes network policies. We have an [00:12:00] ingress policy now, which allows a workload to say, These are the connections I will accept, which is a really powerful security tool, because if it were the other way, then you would have to be depending on those risky workloads to not alter that policy and allow them to reach over to the sensitive ones.
And so that's one way. We also do it through like pretty solid observability. tooling using lots and lots of CNCF stuff. We've been using Kyverno to ensure that people aren't creating custom network policies outside of an area that we can manage because network policies are additive. So it's very, you could just add whatever connections you want on your own end.
So that was a little bit of a tangly answer to say, like threat modeling, start with a data flow diagram and then pick the low hanging fruit. Pick what you can lock down the most, and then when you get over to the really fun stuff, which is okay, we have this workload, it needs to talk to the public internet, it also needs to reach out to databases, it also has this observability tooling, it has all these connections, how can you go piece by piece?
Control that traffic and lock it down. And then, and some of that might not be perfect, which is like what I [00:13:00] mentioned today on the keynote, is like sometimes we do need to say, okay, so this isn't an ideal thing. If something's talking to the public internet, there is a pathway there, and it's going to exist there.
We can't stop it from being there. How do we know if it's used? How do we minimize the impact if someone gets in, and how do we isolate?
Ashish Rajan: And maybe to add on the layer to this as well, is there anything natively available in Kubernetes that actually helps you with, I guess you mentioned you're using Kyverno, you're using other parts as well.
How are people normally responding to having known what the threats are? How are they responding to it? Are they using CNCF projects primarily? And obviously, you could share the examples. You had a few that you had spoken about in your talk as well. So are they primarily relying on cloud native features in Kubernetes or are they using an open source project from CNCF to address some of those threats that are specifically related to network security.
Cailyn Edwards: Yeah, I think it's a mix. Everyone here at KubeCon is definitely going to say Cilium, Isovalent, Service Mesh. They have done a really great job of being the tool that people are comfortable using, which is awesome.
Natively, network policies, and then you get a [00:14:00] CNI like cilium or Calico that adds a bunch of features to make it a little bit more useful to get a little bit more data about how the network policy is impacting traffic. I think I mentioned Inspector Gadget as well as a really good tool to understand your network.
Yeah, and then the, just like the very rich Kubernetes basics RBAC and IAM are also thinking about what happens when someone gets into the network and what can they access and what damage can they do I would say that's the best thing about CNCF is it's very much built around Kubernetes. Kubernetes is the big gem in the crown of CNCF tooling, but that means that we have all of these amazing options to secure to do anything else, to be honest, I mostly know about the security ones, but there are a whole bunch of tools.
Ashish Rajan: I guess to your point then, the idea behind, okay, you can use CNCF project, but you have a lot to choose from can be I guess overwhelming for some people to start off kicking it off. So is there anything from Kubernetes themselves? Because I imagine a lot of people will listen to this and go, Okay, I want to do Kubernetes networking security the right way. I want to learn about it as well. Usually people go to [00:15:00] kubernetes. io and try to start looking for it. But I think as you mentioned that the defaults are not always set to be secure. You have to enable them to be, is there like a practice guide or I think where I'm coming from is that there's two ways to react to any problem, reactive or proactive. And I think a lot of the industry works on the fact that detect the threat to respond to it.
Yeah. Is there like a proactive way for this as well?
Cailyn Edwards: Yeah, for sure. And so while Kubernetes isn't secure by default, Kubernetes has so many security measures baked in. You just have to decide where to turn them on and when. And we created a security checklist, which you can find on Kubernetes IO slash security slash something like that.
If you look up security checklists for Kubernetes, it'll come up. And that actually is exactly what you talked about. It's okay, you don't know anything about security. You have this Kubernetes cluster. What is the bare minimum that you should do? And it'll tell you exactly why each thing is risky.
And it'll tell you specifically about some of the this flag should not be this [00:16:00] value.
Ashish Rajan: Would that be like a CIS benchmark.
Cailyn Edwards: It's inspired by the CIS benchmark. So when we put it together, we went and looked at where there had been Kubernetes compromises because people left certain default settings and some of them we did decide like this is too high risk to leave turned off.
We're going to go ahead and turn it on, but some of them we can't just for the way that Kubernetes is built and so in this checklist is OK, you've built it. You should check all of these items to make sure that you're not putting something incredibly vulnerable out into the world.
Ashish Rajan: And to add to what you were saying earlier as well.
If you were to think about deploying a Kubernetes network as a best practice, obviously you have the threat model that you called out, where, what network can you deploy, what connections it would have. Is there, in your mind, I don't know, three or four best practices people should always look out for?
Because some people may already have a network in Kubernetes, and they're like, I don't know where to start on this, because I guess, should I get one of these open source CNCF projects? Try Inspector Gadget as you called out or what's the best practice like I think in my mind I'm going okay what are some of the two or three things or maybe even five things that you have in mind that I [00:17:00] can look at now In my network to see am I in the green or am I like an orange or a red?
Cailyn Edwards: Okay. Yeah, I would say network policies That's just like an easy one that you can start off and it also gives you the requirement of understanding the traffic needs of your network Which is like I work in a Kubernetes network all the time and that was a hard thing for me to do It is hard it is It's still hard when we ask someone to add a security control to be like, what traffic does your workload need?
I don't know what traffic's happening. What's gonna break if we block stuff? So I think starting with network policies and trying to start if you have the opportunity to start as restricted as possible and Add where you need to obviously if it's something that you know, you cannot afford to have downtime on do the opposite strategy, but preferably start very locked down and add in the connections you need.
I would also say limit cross namespace communication. If you can have your traffic routed through an ingress proxy or something so that you're, you have that one trusted contact that is. It's doing all of the verification for you. What [00:18:00] else? Access control, make sure that the Kubernetes resources themselves are not able to go access whatever they want within the cluster.
So locking things down, those would probably be my three like low hanging fruit.
Ashish Rajan: In terms of maturity, like another question a lot of people who may have been in the space for some time, specifically multi tenancy as well, what would be an example of a low maturity to a severe, not severe, but high maturity kind of thing?
How would you put that scale? Like I think where the leftmost being, oh you're in the beginning stages, you should at least have these best practices put in, but as you go towards the right and you're maturing more, what are some of the things that become important at that scale?
Cailyn Edwards: I think it's the same things, honestly.
I think, I talk about this a lot if you're starting a project, and you want to have a secure network, that's the best case ever, because you get to start very locked down, and open it up. And I actually find that those immature, fresh, Kubernetes projects, they A, they get to build off of all the mistakes that all of us who jumped on Kubernetes early and did all sorts of crazy stuff.
[00:19:00] And now we're dealing with, like you said earlier, like doing Kubernetes the right way. No one did it the right way. I'm not confident that anyone's doing it the right way still. And so that is there is no right way, but these new projects are able to use the best tools, use the experience of everyone else.
Listen to all these talks, get advice, start lockdown and open it up as they needed. I think. You often see the opposite is in a mature, not a mature in an aged network. You see a whole bunch of we're trying to be really secure. We're changing the way that we build things. This is like the cyclical software cycle where we're, everything's changing faster than we can keep up with it.
So we have the legacy stuff over there and the legacy stuff is really wide open because we need it to be, because there's this one thing that we did 20 years ago and we don't know how to get around it, but it's fine. And our new networks are better. So I would say what I would imagine. Having never seen one, a mature Kubernetes network to look like would be a strong understanding of what communication is necessary that actually limited in any way, like not just saying this is the easiest way to connect service [00:20:00] A to service B, but thinking about why do we need to make those connections?
Is there something that we can route that traffic through so that it's controlled and managed and like security controls in place so that the people managing the network and the developers building the projects and then writing the code just don't know or care about the security practices.
They are just there They're on that big wide. Yeah paved path with really nice It's pretty high guardrails in place and they feel safe to innovate and create and build things, take things down, muck around with Kubernetes, knowing that they are never, ever going to end up in something risky and, take down a crucial service or whatever.
Ashish Rajan: Because you were saying this one thought that struck me was in the traditional network security environment, a lot of people talk about data leakage and all of that, and that's where specifically when you called out the example about knowing what's going through the network, what communication is.
9 out of 10 times, there's no one really knows. Basically everything should be allowed. It's funny because a lot of people feel network has all IP addresses and networks and all of that, but there's a lot more now these [00:21:00] days. There's voice going in there. There's video going in there.
There's a lot more that goes in there as well. Even logs. Yeah, even logs as well. So depending on what application you're looking at, it could be looking at anything on the internet. Just put an asterisk onto it, could be anything. So it becomes a lot more challenging. And maybe I imagine people who are listening to this going, okay, that's a lot of overwhelming information.
But is there a starting point? Where do you send people to learn about Kubernetes and for security or maybe even how you learned it?
Cailyn Edwards: Still learning it every day, to be honest. Yeah, all the time. And I would say start off with the Kubernetes docs. Yeah. Go talk to people like Liz Rice Isovalent people who have spent a whole bunch of time building tools to secure Kubernetes networks, because somewhere in their mind exists this idea of doing Kubernetes right, and what the industry is imagining people are doing.
So go talk to them. Start small build some stuff, muck around with Kind, and play, and explore, and see. There's a fantastic, Liz Rice again, there's a fantastic video that she did. It's called like pentesting your own clusters and it really shows you the [00:22:00] risk of leaving your network open on Kubernetes and how easy it could be to like access the API and start actually changing and altering infrastructure that when.
I think was really, I watched that before I wrote my talk about networking, because it just really like shows why this is valuable. Maybe it's not as much leaning into the foundationals, but yeah, that would be my recommendation. Go to the SIG networking meetings if you really want to dig in and find out why and how people are building it, which is cool.
That might be overwhelming, but it's fine as
Ashish Rajan: well. I'll put the links in there. Thank you for sharing that. And it's the end of the technical question. I've got fun questions. We have the jelly beans questions. Okay, I'm ready. Right, you can take any three, and I'll take three as well.
Basically we're taking, oh, you just got excited. I got four, sorry. I'll take one for me, if you want. Which one do you want? I feel like this, I haven't tried this one yet. It looks like a good one. Could be you never know. This is suspiciously earwax looking. So go three, and she'll have one and then we'll answer the question, right?
Okay. This is grass. Oh, I don't know what it is, but it's not good. I got
Cailyn Edwards: grass. [00:23:00] Soap? No. I think it's soap. Oh, it's very bad.
Ashish Rajan: Alright, first question. What do you spend time on when you're not working on community security?
Cailyn Edwards: I like to collect hobbies. All right. Yeah, so I have lots and lots of hobbies. My most recent one is pottery.
So I've been spending like three to six hours a week making pots. I also sew, play squash, and run. Oh,
Ashish Rajan: I don't know how to do the second one. Okay. I think you and I have the same one. Oh, yeah. Mine is soft now. No, but actually it was cinnamon.
Cailyn Edwards: Cinnamon or soap, that's a funny one to mix up.
Ashish Rajan: It's like a mix of, maybe it's the previous one mixed with the next one now.
So it's become like a cinnamon soap now.
Cailyn Edwards: Yeah, I think mine was like strawberry jam, I feel like. Oh, so it was a pleasant one. It was pretty good. Okay, cool. Even with a soap aftertaste.
Ashish Rajan: So the second question was more around, If you could have a superpower, what would that be?
Cailyn Edwards: Teleport, for sure. Teleport.
Because I don't like flying. Oh, yes. And all the time, I'm having to go speak at places, and it's so much time on the plane. So it would be teleporting, but for a mundane reason. It wouldn't be like, oh, go see the top [00:24:00] of Mount Everest. It would be like, oh, get to KubeCon Chicago without having to wait for two hours.
Ashish Rajan: Or maybe next year, KubeCon
Cailyn Edwards: Utah, I think. Oh yeah, I heard. Utah. That would be interesting, yes.
Ashish Rajan: Alright, last one. What's the best part about it? Oh my god.
Cailyn Edwards: Oh, it's not good. I don't know what
Ashish Rajan: it is, but it's really not good. This is I think I've had the vegetable before. It's like a spice.
Cailyn Edwards: I think it's like a rotten apple.
It's like too sweet and a bit funky.
Ashish Rajan: I think mine is like a, some kind of a spice. But, it's mixed with the soap, it's mixed with the cinnamon. And it's there's this weird concoction of three different flavors in there.
Cailyn Edwards: Is it like working? Or, no. It's very gross.
Ashish Rajan: No, it's still pretty gross level. Cause now, I just imagine if I've eaten cinnamon, soap, and whatever this new thing is, which is like a spice as well, and I don't know if it's a previous one that's mixed into this one.
Should have a glass of water as well. Yeah, you gotta rinse it out. Rinse out the palate and do that. Final question. Okay. What is the best part about coming to KubeCon?
Cailyn Edwards: Oh, the people. 100%. Yeah. Catching up with friends, getting to meet new people, all the like, first timers, which is always so many, are just like [00:25:00] so excited, and as soon as you start doing talks and having people recognize you, like many people message me today, be like, oh, can I have a coffee?
I want to know how to get involved in the community, and that is just The coolest thing ever. So 100 percent the people. The talks are great. I usually watch a lot of recordings after to catch up with the ones that I missed because I got stuck in the hallway track, just having the best time catching up with people.
Ashish Rajan: That's awesome. And actually, talking about meeting up with people, where can people find you on the internet to talk more about the Kubernetes networking space? How to get involved in projects? How do they get involved in projects, by the way? How can people get involved in projects?
Cailyn Edwards: The best thing to do is find a SIG that aligns with your interests.
So for me, that SIG security, you can join their mailing list and then get invited to the meetings, come to the meetings, turn your camera on. And that is we will welcome you with open arms. We will pair with you on good first issues. If you're a little bit shy, you can show up in Slack and ask for Hey, where's the meeting invite?
Or does anyone have something they're working on? I'd love to help them, but just let us see you, let us talk to you and we will pull you in and give you all of the work that we have to do because there is so much and [00:26:00] we need help from everyone. And to find me, I'm cailyncodes on pretty much everything.
C A I L Y N. It's a unique enough name that if you just Google me, you'll find me pretty much anywhere, but cailyncodes on Kubernetes Slack, CNCF Slack, Cailyn on LinkedIn. This is pretty much it.
Ashish Rajan: I'll put that on the show as well, but thank you so much for coming on the show. Thanks so much for having me.
Thanks everyone. We'll see you next episode. Peace.