Oktane19 Interview with Mailchimp: Bringing Modern Identity to Infrastructure Access

Sneha: Thank you so much for joining us today, and we're looking forward to having you tell us all about your journey. To get started, did you want to just introduce yourself, as well as what MailChimp does?

Jordan: Sure, yeah. My name's Jordan Conner, and I'm a security operations engineer at MailChimp. And for anybody who doesn't know, MailChimp is a marketing automation platform for small business. We started with a lot of email products but have gone into multichannel avenues, as well.

Sneha: That's great!

Jordan: Yeah.

Sneha: We're really excited to get started, so the theme that Ivan left us on was automation. And if we think about automation, then something that's really important is, how do you get there using some of these products?

Sneha: What was that journey like for you?

Jordan: Yeah. Automation was obviously the biggest factor, or value add, for us at MailChimp. How we had managed keys before and access to our infrastructure was primarily through Puppet and configuration management. Having developers create keys on their laptops, and manually create a PR, and add that to our configuration management. Any time we had to onboard somebody, it was a whole thing. Big old page in the Wiki on how to do it.

Jordan: And so, bringing in ScaleFT completely removes ... or, bringing in advanced server access completely removes ... sorry.

Jordan: Completely removes that process, and it's a lot more streamlined. And MailChimp serves its core traffic out of over 2,000 servers and three data centers, so anything we can do to increase that automation is a big add for us.

Sneha: That's great.

Jordan: Yeah.

Sneha: With automation, was that something you were able to use for both your end users and administrators there?

Jordan: Yeah, absolutely. With advanced server access, we had ... Onboarding was a lot easier, not only for the end users but also for our admins, and also off-boarding, as well. If somebody left the company, there's no longer a ticket that had to be created, or anything like that. It was very seamless.

Sneha: Yeah. By using Okta and advanced server access, not only are you getting the features that Ivan just talked to us about, but we want to make that journey seamless. With everything that you do with Okta, extend that to everything that you do with your on-premise infrastructure.

Sneha: That brings us to, how did you manage access before you started using server access? And was that easy to do?

Jordan: Well, like I mentioned before, we used Puppet for all of our configuration management, and we did the traditional thing with static keys. Every developer would create one on their own laptop and store it on their own laptop, and we would give them instructions on how best to protect that key, but there was always some kind of trust there with the developer. And accidents happen, and having so many static keys existing for a long period of time is obviously a risk.

Jordan: When we were looking at improving that process, we were thinking, "What's a better way we can do this?" And obviously, certificate authentication is not only easier for our developers, for our sysadmins, but I think it's also probably more secure, as well.

Sneha: Yeah. By using certificates, these certificates are not just about making the end user experience easy, but this manages security and usability. It's tightly scoped to say who the user is, what server you're accessing at that time, really going back to that zero trust model of always being able to verify not just who you are, but who you need to be in this moment while accessing these resources. And we're glad you were able to use that.

Jordan: So was I.

Sneha: You've been using Okta for a while, and that's a different model when we think about shared accounts and things. Have you been able to solve some of those use cases with shared accounts?

Jordan: Yeah, absolutely. We try and have as many individual accounts as possible and remove shared accounts where we can, but obviously, some still have to exist, and being able to tie into Okta is a huge way for us to move further in that direction, and make sure that everybody has their own identity when they're performing actions on a server so that we can have audit record, a correct audit record of what they did and where. And make sure that not only do we have accountability for what's happening, but also that we are not sharing credentials, and keeping those as tight as possible.

Sneha: Yeah! And with using server access, the other thing you get is also, we have some built-in capabilities around service accounts, as well, outside of typical logins. And those can be integrated seamlessly. I know shared accounts sometimes are a lot more than service accounts, but we are trying our best to solve those use cases across the board.

Jordan: Yeah.

Sneha: Before we started using advanced server access or being able to log in, you must have had some kind of directories to log in. How has that change been?

Jordan: Yeah, absolutely. We try and limit AD or LDAP as much as possible, and luckily, we had a pretty good methodology with creating local accounts through a Puppet configuration management. Bring in ScaleFT and creating those local accounts worked seamlessly with our existing tools. Worked very well with all of the existing infrastructure that we already had.

Jordan: And before we were introduced to advanced server access, I was looking at different ways that we could tackle this problem, and one of the things we were looking at was free IPA and some ... that just wasn't a value add for us, having to manage all those directories and manage LDAP like that. It just wasn't what we wanted to do, and honestly, it was just a big risk for us, as well.

Jordan: That's just a huge target for those servers on our network. We keep it simple with local accounts, and it's worked really well for us.

Sneha: Yeah. We're glad! With local accounts, one thing that Ivan mentioned was, we wanted to take the Okta products to advanced server access. If we take a simple example of what Okta does with lifecycle management today, that shouldn't stop at cloud apps, and we wanted to take that to your on-premise infrastructure. This means being able to say, "Based on what you've done in your source of truth, be it AD or your HR source or anything in Okta, based on where they are, those are back permissions," will translate into, "If a user moves groups, that will resonate all the way down to your servers. If the user leaves the company, that's instant, as well." Really making sure it's not just secure, but you're also reducing a lot of admin overhead there.

Sneha: You've been using Okta for some of these processes, but before, with servers, even while using Okta, you still needed to do a lot of checkout processes. Do users like the way that they do it now?

Jordan: Yeah, absolutely. I think when we were first presenting this to the team, I think a lot of people were hesitant. The keys were something they were very familiar with, they could touch them, but I think ... I mean, our IT department had done a really great job of bringing Okta to some of our other applications at the company, and so, bringing this interface to infrastructure access just made a lot of sense.

Jordan: And now that our developers and our engineers have seen it, it translates really well and, I mean, everybody gets it.

Jordan: You come to recognize Okta as being your authentication, and translating that into infrastructure access is, it's great and seamless.

Sneha: Yeah, your one place to go!

Jordan: Exactly.

Sneha: Okay. I think PAM is something we all talk about, right? Privileged access, where users need to be, but how do you define how that works? How are we able to help you with who a user should be, outside of just logging in?

Jordan: Yeah. I mean, advanced server access brings us great knobs to tweak when we want to create different roles for our users. Before, in our configuration management, we started kind of those patterns when we were a very small company, and as we're over 1,000 people now at MailChimp, and obviously that ...

Jordan: We needed to scale those processes. Advanced server access brings us new opportunity to give the right role and the right access to the right developers. As we specialize more in the engineering departments, there's more need to give role-based access.

Sneha: Yeah. With role-based access, not only the demo you saw, somebody had user access, somebody had admin access. This is a huge area for us, and as we kind of develop the product, we want to make these permissions so granular that you're able to manage who a user should be on all these servers from this one dashboard, so we're just getting started there.

Sneha: A lot of times when we're setting up Linux servers, and access is great, but we have to have jump servers or bastion architectures. Is that something you have in your environment, you're looking to use?

Jordan: Yeah. Well, currently, we use a traditional VPN to manage our access to our servers, and it's all white IP, white list-based. And we're a growing company, and we're adding offices, so one of the problems that we see with VPN is whenever we need to go add new network equipment or even open a new office, that's a lot of overhead that we need to do to then go configure the VPN, and then configure accesses based on those new IP's.

Jordan: With removing that piece, I'd no longer have to worry about IP, or a firewall rule mis-configuration or any IP-based configuration like that.

Sneha: Yeah, making it easier for your users.

Jordan: Yeah, absolutely. And honestly, it keeps it a lot simpler, and that access point is grouped into advanced server access and that infrastructure, and it makes a lot more sense, and when you think about the architecture.

Sneha: Yeah. We want to enable you to use the architectures that you want to use, and not force any kind of architecture that we need for this product to work. So, one thing that you get with using bastion is we natively support the ability to translate that kind of authentication. If your user is trying to log in, they can directly try to access at the server that they need to reach, but that may be behind a bastion architecture, and we can translate that seamlessly within advanced server access.

Sneha: We hear about session recordings a lot. Is that the way that you keep track of what's happening, or what's the best way for you to see what's going on with your users?

Jordan: Yeah. How we have it currently is we have a bunch of audit D-logs that come into our ELK stack, and it's kind of how we parse through what's happening with our servers. But audit D-logs are not the easier thing to read, and they can get pretty messy, and there's ... I mean, it's more or less a fire hose when it comes to audit D-logs. Having the events page, it's easily human-readable, it's clear, and it's given us a lot more insight into kind of what's happening.

Jordan: And not only what's happening on the servers, but also we can see the end points that our users are connecting to our infrastructure with, as well.

Sneha: Absolutely. A lot of you use Okta today. As you know, the sys log populates everything that's happening with the user. This extend to what's happening in server access as well, which comes down to who the user is, what they're trying to access, what credential was minted to them; that's all being logged, and we want that to be presented in the way that you need.

Sneha: Thank you for sharing that with us. And with that, quickly, we hope that that was a good journey for you to see how a user goes from using everything they see in Okta, really identifying who they are with Okta's adaptive policies, transforming that to not just your cloud apps but your on-prem apps, and we'd like to thank you for being here with us today, and also being a customer who's always helping us out.

Jordan: You're welcome! Thanks for having me.

Sneha: Thanks.