Armon Dadgar: [00:00:00] Where do you see the, Hey, you should probably start thinking about a platform team. And for almost every large enterprise, I think the answer is you should have a platform team from the beginning, because it's one of these things where it's like an ounce of prevention is worth a pound of cure. We work with a lot of companies who are like, we're going to go zero trust and do human identity.

But the way we do it is a human generates the certificate manually, SSHs in, and copies the certificate onto the machine. And they're like, this is our zero trust. And I'm like, okay, but you have very high trust of the user, the person who's SSHing in. So I'm like, this is actually a very high trust model.

There's a lot of people you're trusting. It's not zero trust at all. Because unless you're using something like infrastructure as code that you can automate the delivery of the secrets. Yeah. If a human has to manually log in, by definition, it's not going to be very secure. If your goals are, you want to get started and build experience in open source and you're trying to learn, then I actually think it's better to start contributing to an existing project than it is to start a new one.

Ashish Rajan: Terraform, IaC, and a lot more has changed the way cloud and cloud security is done today. And we got a chance to speak to Armon from HashiCorp, who created Terraform, the first open source language in [00:01:00] the IaC space. We spoke about how that is different than Jenkins and everything else that came in from the CICD perspective.

So at least for people who may not have been introduced to the concept of IaC, they get an intro, but we also spoke about. organizations on the challenges they face when they go on that automation journey. When do you actually need a platform team? Is that even helpful to have a platform team in your world?

We spoke about the organization challenges that people have and also the technical challenges people have in their environment from an infrastructure security perspective and a cloud security perspective and the whole lifecycle management of it. I hope you enjoyed this episode. If you know someone who's actually working on implementing or centralizing their IaC capability or talking about.

Infrastructure challenges and their security program. Definitely share this video with them. If you're watching or listening to this on your popular podcast platform, definitely give us a follow and leave us a five star review. But if you're listening to this or watching this on YouTube, definitely subscribe and I'll see the next one.

Enjoy the episode.

Welcome to Cloud Security Podcast. We are at Hashiday's London today. I've got Armon, welcome to the show. Thanks for being here. Great. I'm looking forward to this conversation, but could you tell us a bit about yourself where you are in your professional life at the moment?

So people get a [00:02:00] context for,

Armon Dadgar: So I'm one of the co founders of HashiCorp, started the company about 12 years ago now with Mitchell Hashimoto. And my role's always been CTO. So I've always been on the technical leadership side. In the early years, it was very much hands on keyboard, small startup.

You're helping build the products. So most of our early products, whether it's Terraform, console, vault, nomad, I wrote a lot of the early versions of those products. And then, last few years my role has evolved to be a lot more focused on product strategy roadmap. I do a lot of customer facing work, a lot of partner facing stuff, but still deeply involved in all the product roadmap technology and I love that stuff.

Ashish Rajan: That's awesome. And 'cause you've been in this space for a long time before people started talking about IaC as a thing. Since the time you started working in the infrastructure as code, before it was called infrastructure as code before it was just like, what's that thing people used to watch scripting?

Yeah. I used guys scripting so. How has it evolved? You've been talking about this for a while as well.

Armon Dadgar: In some weird way, I think we'll take a little bit of credit for almost like coining and bringing that phrase to market. I think Terraform was probably the first super broadly successful, infrastructure as code tool.

That's not to say there weren't great predecessors, [00:03:00] Chef and Puppet and a bunch of other tools that sort of had the same philosophy, but I think that concept of calling it infrastructure as code at the time they were really config management is what people called it. I think Terraform is what really brought infrastructure is code to the provisioning world and to thinking about it from a cloud perspective. So honestly, the funny part is for years and years in the early days, as we built products like Terraform, when we talk about it, people would have no idea what we were talking about when we said it's infrastructure is code.

It's provisioning, and so a lot of our early work was developer relations and speaking at developer conferences, user conferences to help educate the market on what is infrastructure is code? What is provisioning? So we had to in some sense, help create the market a little bit.

Ashish Rajan: Were we talking about DevOps already by then?

Armon Dadgar: We were, but I think people didn't know what it was., it was like a phrase

Ashish Rajan: They still don't know what it is, really know what DevOps is? Because I always remember this. When people started talking about infrastructure as code, people always started comparing it to Jenkins. Just to clarify, for others as well how would you differentiate like what the Jenkins of the world do and then what the Terraforms of the world like how they separate?

Armon Dadgar: Yeah, so to me I think about CICD so continuous integration continuous [00:04:00] testing and a continuous delivery, that's where I'd put sort of Jenkins. I'd put GitHub actions there. Maybe GitLab pipelines All those are really the CI tools. Then a tool like Terraform is used to describe declaratively and say Hey, here's what I want my whole cloud infrastructure to look like.

I'm declarative about saying here's the resources and then it's Terraform's job to figure out how to actually make that real. So I think a lot of users start by putting Terraform into like their Jenkins pipeline as an example. So they might be running it in Jenkins, but Jenkins is just the environment where it's running.

It's Terraform that's actually going and talking to cloud providers, doing the provisioning, managing the cloud environment. And so they start usually In a GitHub actions or Jenkins pipeline or something like that, right?

Ashish Rajan: So they almost like coexisting everywhere. Oh yeah, all the time everywhere.

Yeah, and would you say? Because I think at least for us, most of the conversation we're having with the cloud security engineers of the world or the platform engineers and platform security engineers as well. They're all using Terraform at the moment. They're all walking down that path as well.

Two words that keep coming up. Infrastructure lifecycle management and security lifecycle management. Those two, I kept calling in terms, but they're like more than two terms. And there's some [00:05:00] maybe whatever. Concepts. Yeah, concepts. That's right. Yeah. So these two concepts, infrastructure lifecycle management and security lifecycle management.

I think you've been talking about this as well. How would you describe it? Now that we've set the context for. Hey, Terraform, what that Terraform does and how it's different from CICD, what are those lifecycle management pieces?

Armon Dadgar: Totally, and to me, I think this is the distinction between maybe what I consider if you just think about Terraform as a provisioning tool, great.

Day one, I start using Terraform, I need to go spin up some VMs running in the cloud. I did the provisioning of those VMs. But then the life cycle management I think about is okay, you're never just done. I spun up my VMs, next month there's a Linux vulnerability and you have to go patch it.

Okay, so how do I think about now day two, I have to have an inventory of what are all my vulnerable assets? I have to have a patching workflow for that thing. How do I make sure everything stays up to date? Then, two months from now there's a new version of Java comes out because there's a security vulnerability.

Okay, I have the same problem now. So when I think about infrastructure life cycle management, to me it's that whole life cycle of, Yes, you have the provisioning, but then keeping it patched, keeping it secure, monitoring it, making sure it's performant, that you have certificates that don't [00:06:00] expire. All of that's as part of the lifecycle management.

That's how I think about it. Infrastructure, you're never done.

Ashish Rajan: Yeah. You

Armon Dadgar: there's the care and feeding. And I think on the security side, it's almost the same problem. People think about secrets. Great, I need a database credential, for example. That's fine. But then what happens when you're a regulated business that has to rotate that every 90 days?

Ashish Rajan: Yeah.

Armon Dadgar: Who's doing that rotation? Is it a manual process? Is it automated? Yeah. Do you have a paper trail of these things? And I think for a lot of organizations, they check the box, they make the database password, and then two years later, nobody's rotated that password, and oops, it gets compromised.

Ashish Rajan: Yeah, and then rotation of that password as well is part of the management in my say, yeah, because we have this thing, this provisioning, update, deprovisioning.

Armon Dadgar: And that's the whole life cycle. So that's the difference to me between when you think about just creating a secret versus a security life cycle, where it's okay, yeah, did you, do you deprovision it when you don't need it anymore?

Or oops, is that thing still in the environment and an attacker can find it basically. Yeah. And

Ashish Rajan: I think it's even to your point, it's funny. I think earlier before I saw it. Work in the cloud security space. I always used to think secret to just username password, right? Yeah. And it's Oh, password to the [00:07:00] database password to Ashish's user account.

But the more you look into it, it's so complex. These days, there's a whole API tokens access keys. The list is certificate certificates as well. The list just goes on. If you were to paint an ideal picture for people who are, because you're getting to talk to a lot of people that these days, these I guess environments a lot more complex, perhaps way more complex than what 10 years ago used to be.

Yeah. We have multi cloud, hybrid cloud, data center, only containers, serverless, cloud data, kubernetes, just throw everything you can find in the sink. If you had an opportunity to describe like what an ideal infrastructure lifecycle management or a security lifecycle management should be like, because I guess people always make, I guess this makes sense for me.

They would go down that path with the gut feeling. I'm curious if you found patterns that kind of say, Oh, this is a good way. If someone's trying to find what that should look like, what would you recommend that to be?

Armon Dadgar: I think we definitely see the patterns. One of the fun parts, I think of the role we get a place, we work with literally thousands of customers across different countries and industries.

So we've seen, I'll call it the good, bad, and ugly. We've seen the whole [00:08:00] mix, to me, I think it's a few things. What people always forget is it what developers love is they love to chase and play with the newest, shiniest thing versus in reality, the problem is that creates a bunch of mess for most organizations, right? Cause if you're fine, you're a tiny startup. Okay. That's one thing. You're a large bank with thousands of applications. You can't have every team do it a different way. It just doesn't work because now your problem, if you're the CISO or CIO, it becomes great. I have 5, 000 apps and I have 5, 000 unique ways that they're deployed, secured, configured, managed.

It's impossible to do that in an efficient and secure way. So I think the best organizations I've seen really focus on high levels of platform, high levels of standardization to say, okay, great. I have 500 job apps, but I'm going to run them all exactly the same way. Because now when there's a Java vulnerability, I can patch all 500 of them in a common, consistent pattern.

To me, on the infrastructure side, I think the best organizations we work with are ones that have strong platform teams that are very opinionated about what are the key patterns we support. Maybe it's Java, C sharp, Python, whatever it is. And they say, okay, here's the 10, 20 patterns. We're going to be really prescriptive about how these things run.

And then the platform [00:09:00] team has high ownership over how it's delivered and managed that whole life cycle. And then the app teams are shielded. They just focus on, I'm building my job app. I focus on my features, my bug fixes, whatever. I don't have to think about how it runs. I think the same thing's true on the security side.

The really good security organizations we work with, they're really focused on how do we provide this as a central shared service, whether it's secret management, key management, certificate management. And then offloading it from the developers so they're not concerned with how does it work. It's great, just use the vault service, for example.

You don't need to care how this thing works. We, the security team, own it. I think where it gets to be a mess, on both sides, is when you just give a mandate to developers. It's do something in cloud and make it secure. And then every team figures out a different, unique pattern. And you're like, now it's a mess.

Ashish Rajan: Another question on this then. Because a lot of people don't even have platform teams. And this is not small organizations. These are like large enterprise, would not have platform teams. How would you describe the role of platform teams for people? Because I think I'm just very, it's probably a good point to talk about that as well.

Because we're talking about platform teams, like we're like, what is a platform team?

So what would that be?

Armon Dadgar: I think there's a whole maturity curve happening here. Like even if I'd say in the U. S. where maybe [00:10:00] it's a little bit more cloud mature. If you asked me last year what percent of big enterprises had a platform team, maybe I would have said 25%.

This year, maybe I'd tell you 35%. That's still a long way from 100%. Yeah. And then I think the rest of the world is, maybe a little bit behind where the U. S. is. So to me, I think it's almost this natural pattern of people started with cloud. They told all the app teams, go do whatever you want.

Yeah. And then the teams inevitably create a mess because every team does exactly what they want. And now you have 500 versions of everything. And so then these organizations realize it creates this day 2 inefficiency. And so the, really the role of the platform team is to look across what are the common things you need in delivering an application in a cloud.

So it might be my standard GitHub environment. So I'm going to have a common GitHub, common CI environment, common tests. And then you might say, I'm going to standardize on Terraform for how I do provisioning, I'm going to standardize on Vault, I'm going to standardize on Palo Alto, Prisma cloud. Whatever those things.

Datadog is maybe for monitoring. Yeah. So you're gonna create a set of these shared services that are basically common across all of those apps, going to cloud, and it's really the platforms team to build those, run those, and deliver them as a service to the rest of the application teams. That's how I think about the role of a platform team.

They're almost operating in [00:11:00] internal set of services. Yeah. For their application teams.

Ashish Rajan: I think some people describe also it as like this, the next evolution of Sys admins, as it used to be. Yeah. Like I think a lot of people used to work in data centers where. Like they would know the service by, this is Harry, this is Tom, this is like whoever, it's like the platform teams, so we were abstracted by, I did not know the IP address of Harry or Megan or whoever, but at least now that role is transformed for the platform people in the cloud space, I feel like not everyone needs a platform team as well, unless there's complexity, but I don't know where you stand on the whole, at what point is an enterprise ready to have obviously to what you said, it's a mess everywhere, coding, secrets, everyone has different ways, But if you were to look at the ugly or the not so ugly.

Where do you see the, Hey, you should probably start thinking about a platform team at this point

Armon Dadgar: For almost every large enterprise. I think the answer is you should have a platform team from the beginning. Yeah, because it's one of these things where it's like an ounce of prevention is worth a pound of cure.

Yeah, right? Because we often will come into these environments where they're like, Hey, we realized we have 1000 apps running in cloud and it's a [00:12:00] total mess. And now we're trying to clean it up. And you're like now it's gonna take you a year plus to do the cleanup. Or in some of these cases might be multiple years versus Okay, if you just didn't make the mess to begin with, you didn't have a big cleanup project, right?

Ashish Rajan: Yeah.

Armon Dadgar: So to me, I think there's almost no time that's too early to do a platform team. Now, I think the flip side of that is It's almost helpful to have the first 10, 20 applications in cloud because it helps establish a set of patterns. So that's where I'd say maybe it's too early to have it if you have nothing running in the cloud, probably, because you don't even have any sense of what your patterns are.

But once you have the first 10, 20 applications, you're well on the way to you should have the platform team. If you're at hundreds or thousands, you've waited too long.

Ashish Rajan: There was also a gap between security working with the platform team because traditionally security people have not been the coding people, even from an infrastructure perspective.

Yep. There's been a pattern coming up where a lot of the high growth kind of tech companies like your Roblox of the world, all of them, Netflix of the world as well. They're all starting to work with platform engineers to create. What's our security blueprint look like for the platform you're creating that I can actually make [00:13:00] it easy.

Yellow brick road for lack of a better word.

Armon Dadgar: Exactly. Yep.

Ashish Rajan: Leading on to that, there's another concept that you guys have been talking about and the industry has been talking about Zero Trust as well. I guess you guys have an identity centric view and I believe that makes sense to me because in the cloud world identity is the most important thing.

Correct. How do you describe Zero Trust I guess?

Armon Dadgar: So to me I think about it as, I almost contrast it with the previous approaches to network security. So when I think about traditional network security, it's very much castle and moat.

Ashish Rajan: Yeah,

Armon Dadgar: we were we focused on IPS. We focused on perimeters. You talked about subnets and cider blocks and things like that, right?

So you had this almost physical network model of the world where you're like, Oh, I have a literal firewall that prevents my north, south. And then I have segment gate east, west with some, VLANs or firewalls or whatever. And generally we had a very high trust approach to our networks. You're like, Hey, the outside is bad.

The inside is good. Yeah, it's the simplified approach, right? And I think now when you go to cloud, you're like, your networks are A, too complicated. IPs are too dynamic. Things are coming and going. And the reality is the perimeter model was always broken. It was always a lie, is the way I put [00:14:00] it.

Ashish Rajan: Falsified security, yeah.

Armon Dadgar: Yeah, it was always like it was a comfortable blanket, but it was not real security. So to me, when you make that flip and say, Okay, if I don't trust IP and I don't trust my network, and the physical perimeter doesn't really exist, Then the question is what do you hang your hat on in terms of defining controls?

And so what I think becomes left in a cloud world is identity, right? We talk about human identity, you talk about application identity. And so then really to me, the heart of Zero Trust is really only a few things. It's identity centric controls. It's a default deny posture, right? So if we really think about least privilege, I should deny you by default.

And it's fundamentally assuming that your network's compromised. So it's don't take a high trust approach to your network. Assume anything on a network that you're talking to has been compromised. Now It sounds simple, but the implication of those three things is that there's a lot of complexity for application teams for network engineers for security teams for infrastructure.

So it's complex to deal with that. But I think the underlying assumptions are pretty simple.

Ashish Rajan: I 100 percent agree with you. I also wanted to probably put some challenges in there as well. To your point about the uglies, what are some of the challenges people face as [00:15:00] they go down this journey of, Hey, I'm going to do what Armon said makes sense.

I'm going to go full on into this automation space and start writing IaC, what do you see as challenges that enterprise face, like the remaining 65 percent that's looking at this and hearing this conversation, what are some of the challenges they might face as they walk that path of, you Like, we're gonna go IAC.

Armon Dadgar: I think most organizations have a good handle on human identity. They have an identity provider, they have SailPoint and Okta and Azure AD or whatever, right? I think human identity is well understood because it's an old problem. I think machine identity is the really hard one. Application or machine, I use the same.

Because the challenge is organizations haven't thought about that problem ever. And a lot of the way the structure of the even the teams work within most organizations is they have a human IAM team. And so oftentimes they'll go to that team and be like, Hey, you now own machine identity. And this is a team that's never thought about applications and machines.

They don't even talk to the developers or platform team.

Ashish Rajan: Yeah, they

Armon Dadgar: do. They talk to HR to onboard employees. And so all of a sudden you're giving these IAM teams and saying you own application identity now, and they have no idea what that even means. I think the second problem with owning app identity, though, is [00:16:00] unless you have automation to be able to securely deliver the identities to the application. So maybe you're using certificates, for example. We work with a lot of companies who are like, we're going to go zero trust and do human identity. But the way we do it is a human generates the certificate manually, SSH is in and copies the certificate onto the machine.

And they're like, this is our zero trust. And I'm like, okay, but you're, you have very high trust of the user, the person who's SSHing in. By the way, every machine has the same SSH key. You're manually generating these certificates. So I'm like, this is actually a very high trust model. There's a lot of people you're trusting.

It's not zero trust at all. Yeah. So I think to really do it well, you actually have to have pretty strong automation on an infrastructure level so that you can deliver things like credentials and secrets in a zero touch way. Yeah, and then you have to start managing application identity, which I think is a big cognitive shift for a lot of people, right?

They're not used to thinking about that. Certainly a lot of security teams aren't. So to me, I think those are some of the biggest blockers I see. And I think you can see why infrastructure as code is so closely associated with this. It's if you're not using infrastructure as code and you're manually provisioning your infrastructure.

[00:17:00] So we have customers who talk to me who are like, Hey, we want to adopt Vault. And I'm like, great, tell me how you manage your infrastructure. Oh, everything's manually orchestrated.

Ashish Rajan: And

Armon Dadgar: you're like there's no secure way to use Vault then. Because unless you're using something like infrastructure as code that you can automate the delivery of the secrets, if a human has to manually log in, by definition, it's not going to be very secure.

Ashish Rajan: It describes the challenge most people have as well. I think we probably one part of the organization may think that, Hey, we want to be more mature. And I guess maybe that's also a challenge where you might be, I guess what people are thinking, about IaC, they should probably consider the fact that are they the only ones talking about this or less as an organization try and move this conversation forward for what could it look like?

Another hot topic that has been top of mind for everyone 2024 has been Gen AI. So we have to talk about that as well. There's obviously, I was surprised that in all the Gen AI conversations that has happened so far past 2023, suddenly people forgot Zero Trust. Now everyone's hey, what can I do with Gen AI?

So I have to ask you the question. How do you see the IAC space evolve now that Gen AI is into the picture as well? And how do you guys approach it as [00:18:00] well?

Armon Dadgar: So I think there's a bunch of interesting angles to it, right? On one hand, I think it will lower the bar to enter into IaC. Meaning you can use tools like ChatGPT pick your favorite, Code Whisper to write infrastructure as code. So you can go and say, hey, write me a Terraform module to provision something on Amazon or Google or whatever. And these tools can actually write Terraform that's 95 percent correct. So I think that lowers the barrier quite substantially. Now, the flip side of this is you're already starting to see some of these supply chain attacks that are taking place.

Where people know this, so they're poisoning the training data to introduce security vulnerabilities or backdoors or whatever. And so I think in the same way that it's going to lower the barrier to generate infrastructure as code, it creates even more pressure to do security scanning around infrastructure as code.

Cause you're like how do I make sure that a developer didn't auto generate code that's insecure that has a backdoor in it or leaves a firewall open or whatever.

Ashish Rajan: Yeah.

Armon Dadgar: So I think that brings in things like policy as code to really be able to govern that and be able to automatically check, Hey, no, you can't run this because you opened a firewall or you're gonna create a security issue for us, whatever. Yeah. If it gets 10 x easier to write [00:19:00] infrastructures code, it needs to get 10 x easier to govern that security, because otherwise you're gonna create a bunch of vulnerabilities. So I think that's one side of it. I think the reverse side of it is how do you make these environments more understandable?

. Because especially you think about a large enterprise, you have millions of resources, thousands of applications having to manually sit there and read a bunch of infrastructures, code tedious. So if you could talk to through a language interface to say, Hey. This job application, tell me where it's running.

And I tell you, oh, okay, this app is running on Go Cloud. And you're like, oh tell me what are its dependencies. Oh, it has a Mongo database and a Redis and this and that. So I think those kind of conversational interfaces will make it a lot easier to interact with infrastructure at scale.

Ashish Rajan: Like to your point about lowering the bar to get into the IaC space, but also maybe who are experienced people, they can also use it for their advantage too.

I guess the first thing that I thought of, as you mentioned, that is like how often they get dropped into a company and you have no idea on the legacy you're carrying on. Is that an existing piece of code? That's what depends on

Armon Dadgar: what? Yeah.

Ashish Rajan: Like the dependency is like the craziest part and it's Oh, you just switch off something next to, team A is like, [00:20:00] Whoa, what's going on here?

And you're like, Oh, sorry. Exactly. Day one here. Exactly. But I love how you share the two sides of it as well. I also wanted to talk about the whole, the hashicorp journey as well. Cause obviously you were in the beginning 10 years ago when people still discovering what IaC was. I'm curious doing open source projects is like a very popular thing for people now trying to get into this technology space because that's how you like the chicken and egg thing.

Like how do you show experience without a thing? So people start doing a lot of open source projects. There's obviously challenges with open source project of life happens for a lot of people. What would your recommendation be for people who are trying to start a open source project today? They could go all the way to a Terraform or maybe Vagrant or whatever, but what would your advice be to them who's starting today for that space?

Armon Dadgar: I think I would start with what are your goals, right? If your goals are, you want to get started and build experience in open source and you're trying to learn, then I actually think it's better to start contributing to an existing project than it is to start a new one.

Ashish Rajan: Yeah.

Armon Dadgar: Like for me.

Yeah. A lot of my early, career went back to learning web development with frameworks like NPHP or [00:21:00] Django and Python, things like that. You're definitely aging yourself there. I know,

Ashish Rajan: exactly. I'm glad you didn't say Java. Yeah,

Armon Dadgar: I did some Java too. I've even done some Perl. Oh, sorry to hear that.

And so I think it was actually getting started with those open source communities where it was like, you find an issue or you're adding a feature and I think it's, you're learning how to work with an open source community. An established product is actually a better way to learn than if you start your own, because there's nobody else working on it you're not going to learn anything.

So I would start there. I think in terms of if you have an idea and you're really trying to bring it to a developer audience, then I think starting an open source project is a great way to do it. Or if you have a library you want to build. I think the downsides are really real, though. I think people are now talking about it more with you see a lot of these, a lot of burnout among open source maintainers, because people expect you to have, why aren't you responding to my issue?

Why aren't you adding this feature I want? Why don't you fix this bug? And you're like, for a lot of people this is a passion project and they're doing it for free. It's not their job to solve features for you. So I think you have to be careful in terms of setting the right expectation for people, right?

And I think a lot of people are getting better at saying, hey, this is a hobby project, and they'll put it in their readme. [00:22:00] Or, We're developing this as part of HashiCorp, and it's professionally maintained. Those are two very different type of projects. Because great, if it's a professional project that HashiCorp is maintaining, we have paid committers on it.

Versus, is it a hobby project, and it's in my personal GitHub, and I do it on nights and weekends?

Ashish Rajan: Yeah.

Armon Dadgar: There should be a separate expectation from those projects, because they're not going to be the same.

Ashish Rajan: People also may have to consider life, like life instead, because you may start an open source project to get a job.

You get a job, and you're like I guess that was great. But people start using your library, correct? And now you're like I did that to get a job. Now I have a job. So cya, that also is a downside that to your point about the burnout, because people will keep getting requests from people to, hey, I have raised a PR, you haven't responded for two months, they go on Twitter, they start talking about it.

And you're like, okay, I've went through all of this cycle. If someone wants that open source project to go all the way, like in terms of whatever the idea may be. And I know I'm fortunate that in the cloud security space, people have done that. Yeah, but it took them years to get there. It wasn't like what you guys did.

There was no community for IaC you guys are create the community. Yeah, what was that? Because I [00:23:00] imagine. And would you say that would still work today?

Armon Dadgar: So I think a lot of what we did was boots on the ground developer evangelism to create these communities, right? There's a lot of conferences, look even now, we're doing Hashi Days London, we do HashiConf.

Ashish Rajan: Yeah.

Armon Dadgar: So every year we do a big focus on our user conferences. We spend a lot of time on our meetup groups, we call them Hugs, HashiGroup user groups. We do a lot of virtual events, so we have our virtual HashiTalks. And even before that, like, when we would go, me and Mitchell and our DevRel teams would speak at conferences, user events, meetup groups all the time.

So it was really a big focus on building these communities. And it's a lot of work. I think people think you just put it on GitHub, open source, and it happens. It doesn't work like that.

Ashish Rajan: Let me tweet that as well. Just so that everyone, oh my god, internet is amazing. Okay, that doesn't happen.

Armon Dadgar: No, it's a ton of work to build these communities. And, so the second part of your question, which is would it work today? I think, yes, a lot of, you see it happening today even around a lot of the AI tooling spaces. A lot of it's built in open source and people are building these organic communities around it.

I think at the same time, the expectation for a lot of developers has changed. Where it used to be, Give me open [00:24:00] source software that I can download and I'll run it myself. To now, it's a lot more SaaS driven. A lot of it is like, Hey, I just want to sign up for a free account and start playing with this thing.

Yeah. I don't necessarily want to have to spin up infrastructure and run it and manage it, deploy it. Yeah. Just give me a free account and let me go play with it.

Ashish Rajan: Yeah.

Armon Dadgar: So I think it is shifting a little bit from self managed open source into more sort of SaaS driven experiences. And I think if you look at Datadog or Snyk some of these companies that are much more SaaS focused, that's how they came to market, was really as a free tier SaaS for developers.

Ashish Rajan: Yeah, that's right. Finding vulnerability with a free account and then, Bob's your uncle after that,

Armon Dadgar: exactly. Versus here's a bunch of software, you have to run a database and EC2 and containers and people are like, I don't want to deal with all this.

Ashish Rajan: Oh, actually, yeah. And I think that maybe that's a really good way to piss off a developer as well, but I have to build infrastructure for this.

Correct. I need to know what Harry and Meghan's IP addresses are, I'm like, no, don't care. Exactly. Yeah. It's just give it to me as a service and let me go. Yeah. Yeah. Fair. Okay. And maybe I guess that's most of the, I guess the technical interview questions I have. I've got three fun questions for you as well.

The first one being, what do you [00:25:00] spend most time on when you're not working on HashiCorp problems to solve?

Armon Dadgar: I'm a big reader so I love fiction. I don't, I'm not a non fiction person because I feel like I do enough of that for my work. But it's like I do love like science fiction and a bunch of the classics and things like that.

Ashish Rajan: What is something that you're proud of that is not on your social media?

Armon Dadgar: So one of the things that, me and my husband care a lot about is being able to give back to our community. So we spend a lot of time with a few charitable organizations in the Seattle area. One of them is actually focused on helping foster kids.

There's a great group that we really love called Treehouse for Kids. So we try and spend a lot of time with those guys. I think that's just a great group and a great cause.

Ashish Rajan: Oh, awesome. And Hopefully that also takes it. What's that called? The Seattle freeze or whatever. What's that thing called?

When people just give you that cold shoulder. I got free Seattle freeze. Yeah, hopefully we pay your value guys are working with the kids. At least they're taking that away as well. So they've been becoming more warmer like you are as well. So hopefully we're already up for a better future. Final questions, What's your favorite cuisine or restaurant that you can share?

Armon Dadgar: Indian. I've gone to Dishoom already twice on this trip and I've only been here for two days.

Ashish Rajan: I went for dinner and [00:26:00] then breakfast the next day.

Where can people find you on the internet to connect and talk more about IaC and the things you guys are doing with HashiCorp? Because you guys started as open source and you still have a lot of open source still available and You're contributing on the enterprise side.

There's a lot of education happening as well, but if people wanted to know more about any of these, where can they find more info? Even a

Armon Dadgar: bunch of different areas. I'm easy to find on Twitter and LinkedIn and everything. There's not a lot of Armons in HashiCorp. So you'll find me pretty easily.

But I would say the HashiCorp. YouTube is a great place. We do a lot of like really great like whiteboard videos that break down zero trust just by you as well. I do a lot, a fair amount, but so does our DevRel team and other people. Nice. So I'd say the HashiCorp YouTube is great. Obviously, you can find us on LinkedIn and, and Twitter and X, I guess now.

Yeah. Those are probably like, the best places.

Ashish Rajan: Awesome. I'll put those links in the description. But so much for coming on the show, by the way. Yeah, so much. I want to do a special plug in for a suit as well, by the way. For people who, definitely comment on what you think about a suit. Ha. Thanks so much for coming in.

Thanks so much. Appreciate it. Thank you. Thanks everyone. See you next time. Peace. Thank you for listening or watching this episode of Cloud Security Podcast. We have been running for the past five years, so I'm sure we haven't covered [00:27:00] everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast, or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast. tv By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister AI Cybersecurity, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT and everything else continues.

If you have any other suggestions, definitely drop them on info at cloudsecuritypodcast. tv. I'll drop them in the description and the show notes as well. So you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.

‍