How to use infrastructure automation to improve Security, Velocity and Stability with Ben Goodman (DragonDrop)

Hello everybody and welcome back to this episode of Build Amazing Things Securely. My name is Laura Bell Main and I'm going to be your host today. Today we're meeting with Ben. Ben Goodman is joining us all the way from New York City today. He stayed late and everything. We're really grateful. Welcome, Ben. Thank you for coming on the show.

Thank you for having me, Laura.

Now, Ben, as we do with all of our guests I don't read out bios cause they're really boring. And most of us don't like writing good bios anyway. So who are you, the human?

Yeah. I am, my name is Ben. I'm currently the founder and CEO of a company called drag and drop that cloud and the maintainer of an open source tool called cloud concierge really focused on automating developer best practices when they use an infrastructure as code tool like terraform.

Awesome. Now I'll share with the audience how we crossed paths cause it's a bit of a weird story. I found myself in the US last in the last few months and I had some time to kill between two very big conferences. And so as you do, I got on a plane to a place I'd never even heard of called Buffalo in upper New York state, right on the edge of Canada. And I went to. An amazing little conference, DevOps Days in Buffalo. So if anyone's listening from that space, hello, you were lovely people. And at that conference, there was this little company who had a stand with the most adorable little red dragon on it. And I have a child who is obsessed with dragons. So I came and took a picture of the dragon and I wanted to know more because not only did they have a dragon, but their name is a pun. It's not drag and drop, as you would expect. It's a dragon. Who, what's not to love here. So anywho we're here today because. Of a dragon. So tell me about the software that you're building what problem it solves, and then let's dig into, how we think about security in that space.

Yeah, absolutely. And so I think the, we can start very early thinking about security with the idea of infrastructure as code, right? Because one of the key problems infrastructure as code solves is providing a document, basically built in documentation for what's happening in your cloud environment. anD the other piece of provides is a mechanism for organizations to you. In a more controlled manner, deploy, manage, update, delete, basically control the whole life cycle of their cloud infrastructure.

Absolutely. So I'm going to have to step back a bit. How on earth did you become the CEO and founder of a company that does this? What's your background that led to

yeah, I guess the background is a bit unconventional in that my undergraduate education was in economics and I just minored in computer science. And I started as a data scientist right out of school. And, um, I guess it was on the borderline with machine learning engineering. And from there saw that there were a lot of manual tasks that people on the team of the startup I was on at the time were having to continuously deal with in regards to infrastructure as code. And I could see that infrastructure as code was growing really quickly and figured someone is going to try to automate this. at some point soon. When I have a little adventure and see if

I love it. I love it. I love it for two reasons. I love that you've got an unconventional background. A lot of our guests have been on the show, have got all sorts of crazy backgrounds and we love that. But also I love that you were like, this is tedious and boring and we can automate this and somebody else is going to do it. So why don't I do it? I love that. So if any of you at home listening to this, I'll have a problem that's annoying you and you're like, yeah, one day somebody will solve this. Be that somebody. Be Ben. That's how he ended up in a fancy office in New York. Who knew? So we've started a company. We've got this technology that's helping us create correct me if I'm wrong here, but these reusable and kind of repeatable infrastructure as code. Templates, if you will,

yeah, in a sense. So I think where we fit into the space is a key problem that in talking to potential customers while developing the initial product was essentially people have their infrastructure as code, but then they also have changes happening to their cloud outside of their infrastructure as code. And so That could be either editing a resource that was deployed using infrastructure as code, or just creating resources completely outside of. Your infrastructure is code workflow.

you're destroying my dreams here, Ben, because I was told by DevOps people that we never log into production anymore and we certainly don't mess around with our servers when they're live. Are you telling me that's still happening?

Believe it or not. Yes. That, that does happen from time to time. And so as you can imagine when that happens, you lose basically all of the benefits of infrastructure as code, all of the security scanning, potentially that you're running on infrastructure as code, all of your controls that you have pre deployment and so we'll do is actually identify proactively when those changes have occurred. And if you created a resource outside of Terraform control will actually identify it generate the corresponding Terraform for that resource and will also run a static security scans across the entire state of your cloud, both controlled by Terraform and not controlled by Terraform.

nice. So you're like an alarm system, really. Are you quite opinionated? Do you send out the Slack messages and things and say, Hey, did you know somebody who's being a Muppet? Please stop

Yeah, I think perhaps even stronger than a slack message will actually open directly a pull request with the codified resources and tag a reviewer of your choice.

Oh, so we're going to tell your boss on you at the same time. Fabulous. Love

if you want your boss to be alerted, maybe they're not the best person to review Terraform, but yeah,

Awesome. Okay. I love this because one of the things that we're all embracing, we're trying to put our security checks into our CITC ICD pipelines where we have them. But the reality is most of us have a bit of cloud infrastructure that is under. good control and some that perhaps is more legacy or more foundational that isn't or isn't an experimental area. And so that's giving you that cohesion, that coherence between the two.

yep.

So what's the worst that could happen then? If we were theoretical, if we weren't doing all this magic, if we weren't telling you boss when you made a change, what do you think the worst Outcome could be if an organization is getting these kind of stealthy changes into their production environments and not spotting them.

Yeah. So I think the damage occurs across three dimensions. One is from velocity perspective, which I'll come back to last actually, but then there's also cost and security. So cost. is fairly straightforward in that you have a change outside of Terraform. Say someone wholesale creates new database or, increases the size in the EC two instance. No one's aware of it. Suddenly your cloud costs are spiking for that resource. So that's one. The second is around security. So someone is clicking through or using the CLI to make changes and manually touch cloud resources. The, even if they're the best intention, most knowledgeable engineer, the likelihood of a, a fat finger mistake or an error, and, say this load balancer is accidentally exposed to the internet, something like that probably don't want that. Or, Oh, I allowed HTTP connections to this. In addition to HTTPS, I really should only allow HTTPS. SO security mistakes like that are very easy to introduce when clicking around and manually touching the cloud console.

Yeah, and I think if we were to challenge some of the assumptions that we see out there, a lot of the conversation about security is about these outside attackers, right? Oh, they got into my infrastructure and made changes and get, don't get me wrong. If a Bitcoin miner gets into your EC2, you're going to be mining Bitcoin and spending a lot of money very quickly. But, how many of us as engineers haven't made a mistake at some point? Hit the wrong config option, not read the text properly, assumed it was turning it off and it was turning it on. And so the security issues we inherit just by being human and not being perfect all the time they're not sexy, but they're definitely things we have to look at. So you mentioned velocity as well. What was that about?

Yeah. So essentially you can imagine, if I'm making changes to my cloud environment manually, if it's comes time to, build upon those changes or build Terraform. Or even just simply, move from a development environment to a staging or production environment with those changes that becomes much, much slower and difficult to do in a stable way when not using infrastructure as code. However, if we're fully managed using Terraform, then we can use some of the techniques that you had mentioned earlier, templatization, it's easier to say, Oh, I want a new version of this database. Let me just use my existing Terraform module. So that's the velocity side of things.

Yeah, I, this is really cool. Cause I think every technology we have has the potential to help us as an efficiency tool, help us go faster, do more things to save us money. But a lot of them have these added security bonuses that we don't really think about. And I'm a big fan of securing systems by doing the stuff you're already doing, because actually it does the security. You just haven't thought about it. And so guarding those configurations, keeping those environments in sync, monitoring for change, running those scans, everything you're doing there. It's not the reason you're using infrastructure as a code, as code, but the added advantage of any sort of coded infrastructure thing are huge for security and that's really exciting.

absolutely.

So what's the hardest bit of all of this? So you've built a thing and kudos to that founder to founder, like that's, it's not something you wake up on a Tuesday and go, I'm going to just do a thing today. What's the hardest bit of all of this from a technology point of view?

Yeah. So one of the things that we were really, focused on from the beginning was how can we make our tool by default self hosted because I'm sure you and many people listening have seen a plethora of. Tools. I'll optimize your cloud environment. But the first step is essentially granting them full read access to your entire cloud environment.

What could possibly go wrong?

AnD of course, you're just basically every time you bring on one of these new tools, you're increasing your potential attack surface. By that much more by someone else having full read only access to your web. So a big challenge for us was how can we get as close to that sass like experience of easily getting started while at the same time being self hosted for all users of the tool. so A lot of engineering effort and an energy went into to making that possible,

that's really, it's so important, right? So what's the consequence if you don't get that right? I, if you if you screw that bit up. What happens?

Yeah, so Certainly from our side, there's the liability perspective if we have all this information on our servers and, now we have to go through, we basically, if we've been hacked, then all of our customers are visible to that hacker as well, if we have read only access, essentially

Yeah.

yeah, and then obviously on the flip side of that, if you're a customer and we're hacked, then suddenly you have to worry about a nefarious actor has read only access. CoachingBadminton. com To your entire cloud.

Yeah. Terrifying stuff. Okay. So that's where we're at. That's the problem you're solving. It sounds like you're having a ball doing it. So where is this space headed then? So if we're at where we are now, many of us embracing the cloud, we've You've got some, if not all infrastructure as code, hopefully fingers crossed. And we know that we don't make changes in production anymore because our boss is going to get tagged in a pull request. So what's the next stage? How do we make this even more amazing?

Yeah, so there's the way of approaching things where you're retroactively scanning your cloud for when these cost overruns or drift has happened or security vulnerabilities are in your cloud. The ultimate goal is that you almost get CI CD pipeline like a cloud checkout. pRior to deploying changes to your cloud and essentially uh, because terraform has such a large community and it's declaratively written, there's been a lot of really interesting tools out there that will statically scan your terraform configuration and give you a sense of what's going to happen in your cloud prior to uh, those changes taking place. So you can actually say I'm opening this pull request and now it. Just as, with application code where you're running unit tests. Now you can run cost assessments and security scans proactively prior to merging in your Terraform.

That's pretty

very that's like the most mature cloud operation, uh, setup using Terraform today.

Wow. That, I'm sure there's folks who are listening who are like, yeah, we can totally do that. And there'll be a lot of folks listening who were like, that's a lot of work. I don't even know where to start with that. So that will be exciting to see how that plays out. I'm going to ask you a bit of a question cause I was asked it the other day and I think it might be relevant. There's quite a few companies, mainly bigger ones, if I'm honest, but who are they're going back in time. They're going back on prem they're abandoning cloud and have decided to heat their own data centers for a while. Do you think this is going to be a trend? Do you think that's going to be more common or do you think we're seeing a blip?

Yeah, I think at the end of the day, companies are always looking to have higher profit margins. And when you're using the cloud at a really high scale. You're paying a lot of margin dollars to AWS, Azure and Google to operate their cloud. And they've, if you look at their public financial statements, those are very profitable business segments for them all. So if you're at a certain scale where it makes sense, you can certainly recoup certain amounts of margin dollars by running your own data center staffing that engineers yourself and taking back that, 66, 70 percent gross margin that you'd otherwise are sending to AWS. So I think that trend certainly uh, there will always be companies that is valuable for them to do. But it really depends case by case. Maybe you get a ton of value out of managed services that are harder to build yourself. But if you're just running virtual machines in AWS, maybe it makes sense to repatriate some of those workloads if you're at a sufficient scale.

That's a very diplomatic answer. That's very well done. What about security perspective? I I speak to a lot of organizations. I love them all dearly. And there's still folks AWS. And they're secure. They do their thing. Is that the case, Ben? Is AWS taking care of it all for us or are the things that our teams at home need to be really paying attention to here?

I think AWS makes it possible for you to get it right, but by default, it is not going to be fully secure in the way things should be. I would say it would be my answer. Yeah.

Yeah. And for the lawyers listening, we make equally strong statements about every cloud provider, just to be fair.

Yes, absolutely. Yeah. And they give everyone gives you the tools to do it, but at the end of the day, you still need to be cognizant and responsible for, the workloads you're running and managing. See, even something as simple in air quotes here, as simple as, secret management. AWS isn't going to manage maybe some of your more sensitive credentials that you need to pass between applications in a default way.

So if a company was listening to this and they're starting out, they've got maybe a bit of infrastructure as code, they're using one of the major cloud platforms. Let's not pick a fight with any of them in particular today. What advice would you give them getting started that would improve their world, make them more secure, um, make it less expensive or faster? What would you tell them?

yeah, I think, because of all the tools that exist around Terraform, um, or other infrastructure as code tools, I'd recommend getting started with those sooner rather than later. And then. dRiving all changes through your cloud through those tools and using those tools as a basis for a cost optimization and security analysis would be the first thing I'd recommend. And the reason why it's important to get started early is because the tech that really quickly compounds in this area. Both from a tangible, Oh, this is going to take a while to write up into Terraform or identify these resources and bring them under Terraform control, but also from a cultural perspective, if you're developing a culture where people in your company are clicking through the cloud or configuring things manually to the CLI, that can be really costly and burdensome to swing back towards, towards the best practice environment.

I love this because that message really reinforces the idea that you're not too small to do it right and to do security. In fact, it's going to be easier for you in the long run to do it from when you're little. So if you are listening to this and you're like, Oh, we haven't got started on that yet. You're not too late. Get started now. Better to do

And yeah, and it's not just like a, compliance checkbox or something like that. As mentioned earlier, it does unlock a lot of benefits in terms of velocity and cost controls as well.

Yeah. Who doesn't like saving money, right? So you've invented technology. You've got a company that you're growing. Where's next for you? We, we don't do. Big product placement plugs type things here, but I'm intrigued because as somebody who's building technology that's what you have to decide, you've you're building it as well as, selling it out into the world.

Yeah. So the foundation of our product is an open source container called Cloud Concierge. And that's basically what open source users can run locally on their machine. As well as what is running self hosted within customers environments within their own cloud. And so really that repository and feedback we get on that repository is where we drive new feature development. And then, of course, within our managed offering that coordinates the self hosted executions that builds upon, supporting the full functionality of that open source container.

Amazing. So what he was very polite and he's smiling a little here. He's been very well behaved for a CEO. So kudos to Ben. And what he's saying is team, he needs a lot of testers. He needs people using this stuff. He needs people out in the open source doing what they do and giving them lots of feedback because that's how products grow and get better and stronger. So it doesn't matter what you're building. Never be shy to ask for somebody to come and have a look at the open source thing and have a play. So I'm going to ask on Ben's behalf. Ben, it's been wonderful to chat with you. If a team listening at home was to try and follow up with you afterwards, where's the best place to catch up with you?

Yeah best place would probably be on LinkedIn.

They will try and hunt you down like an aggressive headhunter. You'll be full of them. They're not recruiters this time, just eager techies. Fantastic. Look it's been a pleasure to talk to you today. I'm definitely, really now powerfully aware of how much infrastructure as a code has those three benefits not just for velocity and going fast, not just for reducing your cost, but also making your security more predictable and more coherent across. All of your infrastructure, whatever that looks like. So thank you so much for your time and coming on as a guest.

Thank you, Laura. It was great speaking to you.

Awesome. Right team, you know the drill. This is a podcast, so share the link with your friends, even if they don't want it. It's the gift that keeps on giving every single episode. Please leave a comment or subscribe. You never know. These things could help us out and grow our audience. Now, if you have a guest that you would like to recommend, or you are that potential future guest, please get in touch. We'd love to talk to you. Take care and we'll speak to you again soon.