Fresh from picking up $5.25 million in funding, CloudTruth CEO Greg Arnette talks with Mike Vizard on this episode of the View With Vizard about why configuration and secrets management need to converge. The video is below, followed by a transcript of the conversation.

Announcer: This is Digital Anarchist.

Mike Vizard: Thanks for the throw. We’re here with Greg Arnette, who’s the CEO for CloudTruth, they just raised $5.25 million to help us with these configuration issues that seem to plague us. Greg, welcome to the show.

Greg Arnette: Thank you. It’s great to be here, and thanks for the opportunity to tell your audience about CloudTruth.

Mike Vizard: So, what is the configuration problem, and why does it not seem to wanna go away? It’s been around for a while, things appear to be getting worse, and what’s to be done about it?

Greg Arnette: Exactly. So, that ties into the history of founding this company. Both myself and my Co-founder were prior CTOs and DevOps leaders for several cloud-based SaaS companies, and we saw that our DevOps teams were continuing to build internal tools to address issues around configuration sprawl and complexity. And these tools tend to be the weak links in terms of solid deployments, good up time, good security, and basically, slows teams down.

So, the history of kind configuration sprawl and what we see as the challenges is sort of driven by a number of macro trends—first, the fast rise of Kubernetes; everyone wants to get on the Kubernetes bandwagon. That introduces new complexities around configuration management, new sets of tools that haven’t been sort of well adopted inside of DevOps shops. Another trend is the breakup of monoliths to microservices adds lots of new dimensions on configuration complexity. And then there are the traditional needs around provisioning infrastructure, configuring your apps, and managing secrets are the sort of legacy challenges around configuration management. And as the cloud gets more mature and with more capabilities, configuration is not getting easier, but getting more difficult.

So, CloudTruth is here to address those concerns. We heard, during our product market fit research where I interviewed over 500 cloud and DevOps leaders on their challenges managing configuration, that this over reliance upon tribal knowledge in terms of how a system is configured and why it’s configured a certain way is just held in key team members’ heads, and that’s not a very durable strategy for going forward or for on boarding new folks. So, there’s an element of CloudTruth that provides collaboration and sharing around configuration settings and context to help reduce that need of, or that sort of burden of the cognitive load to keep track of how are things configured, where is the data, how can I change it, what changed recently—that type of thing.

Mike Vizard: You guys also acquired a company in this process in the secrets management space, so where does configuration and secrets management converge and how do we think about that?

Greg Arnette: That’s a great question. So, we acquired Tuono, we’re thrilled to bring in the Tuono team, including Jesse St. Laurent, who was the CTO, who joins us as our Chief Product Officer. Jim King, Mike Healey, Mike Stack all joined us, they were the founding engineers at Tuono.

And what we did was, we took the Tuono secret management engine, which was cloud native and we’ve now included that in the CloudTruth platform which rounds out our offering. So, CloudTruth, while it is also a configuration data hub to synchronize your configuration settings from all these multiple tools is also itself a parameter store and secret store that customers can use if they don’t already have existing parameter stores or secret stores in their environment.

Mike Vizard: And in that context, what does cloud native mean? Because some will people say, you know, it runs in the cloud; other people will say that it only runs on Kubernetes, it’s optimized for microservices and containers. Or is there some middle ground there and what do we think about cloud native—what context are we using that phrase?

Greg Arnette: Yeah, when we use cloud native, we mean or refer to the capabilities that are provided as part of core services at Amazon, Azure, and Google. So, an example is, Amazon themselves provide a parameter store, they call it AWS Parameter Store. Google and Azure provide the same kind of internal capabilities. Customers can also bring their own parameter store, like run something like Console on top of the cloud or using Vault sometimes as a general-purpose parameter store.

So, the cloud native offerings like AWS Parameter Store, Secret Manager, and the equivalent on the other clouds are things that customers can use, they have different price points. We provide a layer of management and visibility and observability to all that config data stored inside of all these different systems.

Mike Vizard: And when you talk about unifying configuration, are we replacing Terraform and CloudFormation, or are we just finding some way to layer some form of abstraction around them that makes the whole process easier to manage? Walk me through that a little bit.

Greg Arnette: Yeah, you know, we’re not replacing Terraform or CloudFormation. We’re designed to coexist with the customers’ existing investments and their configuration tooling. So, whether it’s provisioning tools like Terraform, CloudFormation, Pulumi, or app config tools like Ansible, Puppet, Chef, Saltstack, or secret tools like Vault or the cloud native versions of those capabilities. We coexist and become a metadata wrapper around those different tools.

Now, if customers don’t have some of those capabilities, we have functionality in our platform that can fill the gap, but more and more customers already have these systems in place. They’re not looking to rip everything out and replace it, but they’re looking to address these issues around configuration sprawl that leads to a misconfiguration causing unplanned down time or a security incident.

Mike Vizard: We have been talking about DevOps and DevSecOps forever, and the idea has always been that we’re shifting more responsibility for the IT environment to the left of the developer. Sometimes they like that, sometimes they don’t.

But I wonder, are we not approaching some sort of concern or maybe a backlash where folks are saying, “Hey, you know what? This isn’t really working. We have all this misconfiguration out there, we’re maybe running faster, but things are less secure, and we have more risk than ever.” So, is there a balance to be struck, or what’s your sense of where are we on this journey?

Greg Arnette: That’s a very interesting question. This is something that we hear all the time in our outreach to our customer audience is what their journey looks like for adopting shift left or GitOps types of operating principles. We’ve seen a number of patterns emerge over our hundreds of interviews. Specifically, most teams do want to give developers more capabilities to do things themselves and reduce that burden on the Ops team, but they still want Ops or DevOps teams to have the overall sort of judgment and enforce the guardrails that were put in place by the security and compliance teams and by the other teams that are sort of deciding what are the best practices.

So, with CloudTruth, we’re kinda serving both audiences in a purposeful way. You have centralized control and visibility that DevOps wants. They wanna build and enforce lockdowns, enforce default settings that can only be overridden with a permission or an override that’s allowed as part of a workflow. But you also provide capabilities for core developers to manage the config for their own environments and to suggest configuration changes that then can be adopted more system wide.

So, we’re serving that duality that exists today. We’re gonna let the customer decide on where they ultimately land about developing shift left principles and moving that direction. But we see a lot of interest in that, and it helps to reduce that—you know, again, that cognitive load and that context switching on the DevOps professionals. Because so many times, they’re being bothered by other folks and other developer teams, like, “What’s the setting for this Redis cluster? Why is our Mongo configured this way? How do I tune my elastic search test cluster to match production?”

That information will all be self-serviceable and findable inside the CloudTruth platform. And our role based access control permissioning system allows view only, read only, read/write access to the appropriate areas, and then DevOps teams can sort of wall off the production systems from other people having chances of changing those settings.

Mike Vizard: Mm-hmm. What is the role of the security team as we go forward? It feels like, if we shift everything left to the developers, what are those guys doing?

Greg Arnette: They still need to be involved in terms of ensuring that no bad information gets in and no good information gets out. So, we provide a number of views into configuration data that are helpful to security teams. First is, what changed most recently in terms of your compliance management reports for SOC 2 and other requirements and keeping track of changes. That’s really hard in a dynamic environment, especially cloud-based where you have microservices firing left and right, coming up and down. The old traditional CMDBs that were popular in the on prem world don’t really fit well in the new way that we’re using the cloud.

And so, CloudTruth is a self-documenting change management control system that is, behind the scenes, keeping track of all the version settings of every configuration value that we’re monitoring, and then we provide views into that data that can be consumed by the security or compliance teams to get better insights for their needs without having to bother the DevOps teams.

Mike Vizard: Do you feel like the bad people, otherwise known as cyber criminals, are getting better at scanning for misconfigurations and looking for these vulnerabilities to exploit? And we hear a lot about software supply chains these days—it seems like, in a lot of cases, the root cause of the problem is just misconfigurations.

Greg Arnette: It’s true. We’ve found, in our own research, that 75 percent of unplanned down time or security incident was caused by a misconfiguration when you ultimately read the root cause analysis and do all the internal tracing.

So, what we wanna provide are the best practices as early as possible in the software development life cycle process to implement good config hygiene. And then secondary to that is, once config is out there in the wild, provide monitoring and insight into how it could affect security vulnerabilities or security posture. Since everything these days is defined as infrastructure as code, it’s all about analyzing all the different locations where config values are stored, making sure those are secure and locked down, and then being able to use any kind of pattern recognition to understand where certain areas can be vulnerable to being taken advantage of by the nefarious factors out there in the world.

Mike Vizard: Do you think we’ll get to the point where we can use automation to kinda get ourselves out of this mess? We have APIs and CLIs and everything else that’s out there—shouldn’t we, at some point, have enough intelligence in the work flows to say, “Hey, this thing you’re about to deploy is misconfigured, so don’t do it”?

Greg Arnette: That’s part of our goals down the road is, we have a very thoughtful strategy how we wanna launch CloudTruth as a full configuration data management platform. So, the first goal is to get inserted into a company’s work flows where we have access to the data and can provide value with reports and work flows. The second goal is then, once we’re now managing this data on behalf of the customer, to apply AI and ML, looking for patterns, recommending optimizations, best practices, vetting what we see from a customer perspective against best practices being published by other standards bodies that are looking at this from different perspectives.

One goal of CloudTruth is to be that configuration data layer management system that we think most companies using the cloud need these days.

Mike Vizard: We also hear a lot about artificial intelligence—will that get applied to this space? Is there any scenario where we’ll just have a bunch of machine learning algorithms running around, figuring out what’s going on?

Greg Arnette: We firmly believe that that is definitely gonna be happening a few years down the road. I think the maturity model is just getting started. The first act in getting that up and running is getting access to the data for trending the models and analyzing the trending results, optimizing the model. So, a full observe-orientate-decide-act OODA loop is involved here in terms of making sure those models are accurate, but we think that’s gonna be a big benefit in what we can provide down the road.

Mike Vizard: So, what’s your best advice to folks? What should they be focusing on today to get to that nirvana tomorrow? Is there same way I should be organized, is there some way I should be talking to my developers? What do you think?

Greg Arnette: There’s a couple themes that come to mind. The first is—which sounds almost obvious these days—is make sure you are able to do infrastructure as code ideas at all levels that you can, and that’s tied into automation. So, it’s a big portion to continuous deployment, CI/CD pipelines. Once you start the development of those types of workflows that accelerate getting what developers are creating out in front of the customers, whether it’s an internal app or external SaaS or mobile app, accelerating that team velocity is really a key element in terms of making that possible.

The other area is this notion that you wanna implement systems that reduce the amount of copy and paste. So, that’s what we call the Do Not Repeat Yourself, the DRY approach to infrastructure as code management. So, that’s a key theme behind CloudTruth is, we provide capabilities that let you manage your multiple environments with the faults, inheritances, and overrides from a centralized capability, but still allow flexibility in your environment tree to manage certain sub-environments in different ways as needed.

So, different developers can have their own custom environment, but they’re gonna inherit default values that are sanctioned by the architecture team or the security team. And then the overrides have to be allowed by a permission basis.

So, there’s a couple sort of themes that are coming together as we go through 2021 around automation, infrastructure as code, shift left, and the DRY approach to managing input values to all the IAC tools.

Mike Vizard: Hey, Greg, thanks for being on the show.

Greg Arnette: Thank you very much. Have a great day.

Mike Vizard: Alright, awesome. Hey, guys, we learned a lot about security there and things we didn’t know and—hey, there’s hope for the future. Back to you guys in the studio.

[End of Audio]