Bart Farrell: Sarah, welcome to KubeFM. For folks who don't know you, who are you? What's your role and where do you work?
Sarah Christoff: Hi, I'm Sarah. I work at Buoyant. I'm a tech evangelist alongside Flynn, who's been in the community for the last decade. I've been in the community since 2017.
Bart Farrell: In regulated environments, security teams often want stronger workload identity, encryption, and policy enforcement, while platform teams, on the other hand, want to avoid adding unnecessary complexity. So how do you decide when an extra infrastructure layer is actually reducing risk rather than just moving it somewhere else?
Sarah Christoff: It's a great question. I think how you figure out if you're just moving it somewhere else versus if you're actually solving the problem depends on like your decision making process. So I'm really familiar with like PRDs, RFCs, all of these like three letter acronyms, POCs. And basically, these are like steps that you take when you're trying to make a decision whether we're going to adopt new software or build it in house, if we're actually solving the problem. So instead of going like, okay, we're gonna just do straight POC proof of concept, try it out in our staging environment and see if it works. And then adopt it, we're actually like taking time to document, make a decision. Okay, does this solve the issue? What is the issue? And going forward, like how much will it cost to adopt? And if we decide to back out of the decision we make, what does it cost to back out? And that way we make sure that we're actually solving a problem, not just a feeling.
Bart Farrell: Banks care a lot about proving that controls are working, not just having them configured. So when you think about service to service communication in Kubernetes, what should teams be able to demonstrate around identity, encryption, policy enforcement, and auditability?
Sarah Christoff: Those are four really big ones. Luckily, since I work in the service mesh space, I can talk a lot about service to service communication because service meshes provide all of those four things you talked about. And a lot of this comes down to logging, tracing, auditability, those types of things. And so one thing that I see a lot is people really care about mTLS being throughout the entire cluster. And the question is, how do we prove that like everything is leveraging mTLS? How do we make sure that everything is actually end-to-end encrypted like this. And most modern service meshes will store the certificate data in memory on each pod. You can check it yourself. But if you want to get your hands a little bit more dirty and really show somebody on your team, then you can use things like tcpdump or Wireshark to actually inspect each packet in transit. Basically, to answer your question, if you really care about showing whoever it is, identity, policy enforcement, encryption, and auditability, get yourself a service mesh. A lot of them are free to use at first. And then you can show via these audit logs and telemetry data and stuff like that, these things that you need to have for these audits are being enforced.
Bart Farrell: Now, last but not least, one of the hardest parts of platform engineering is getting security, compliance, and engineering to agree on what's good enough, what that actually means. In a regulated Kubernetes environment, where do you think most teams often over-engineer controls? And where do they tend to underestimate the risk?
Sarah Christoff: I've worked at a lot of larger enterprises and a lot of the, like, traps I've seen people fall into is they go, well, our environment or production environment is so complicated, we need to build our own DIY solution. And sometimes this is just because, you know, you're in that thought process, like you're holding all of the pieces, and you can't see how one solution could fit into it. But also, the other part is that it's usually more fun to build something. And it looks really good on your resume. I know I've done that myself. So basically, when you fall into that trap of like, hey, we should go into DIY mode. I think you're underestimating like the cost of what DIY mode is. So not only does it create basically a long term job for you forever, you're shoehorning yourself into like taking care of whatever you've created or somebody else will. But you're dealing with problems of like long term, you're going to be dealing with like CVEs and updates and integrations into new pieces. And so as you shoehorn yourself into that one job or create this like forever job, you're also kind of like shooting yourself in the foot. Because you don't get to do more fun stuff after you did the one fun thing. So basically, do you really want to work in that job forever? Or if you don't, then maybe you should take the risk and put it somewhere else by purchasing a software license or looking into open source and seeing if you can migrate that risk elsewhere onto somebody else's plate so you can do more fun things.
Bart Farrell: So Sarah, if people want to get in touch with you, what's the best way to do that?
Sarah Christoff: I am S Christoff, spelled Christ off on every platform available. And if it's not me, it's my sister and you can bug her. So LinkedIn, GitHub, I don't know what else I'm on. There you go.
Bart Farrell: You're easy to find. You're very visible, well-established in the community. Sarah, thanks so much for your time today. Looking forward to speaking to you in the future. Take care.
