CloudTruth vs Vault and Consul

We're often asked, "What is the difference between CloudTruth, Consul, and Vault?"

They are vastly different, and all three play an important role in increasing deployment velocity. You can use all three together or piecemeal to get the configuration management, and secrets job handled across any environment, both in the cloud and on-prem.

This blog post will give you an in-depth breakdown of what each platform does, why it's important, and how they work together.

What is Consul

Consul is a Service Mesh that allows you to:

• Implement Service Discovery for things like Kubernetes Services, APIs, or MySQL
• Multi-datacenter support, so you don't have to worry about where your services are
• Secure communication between services
• Encrypted east-west traffic
• Network troubleshooting (for example, latency issues)
• Health checks to ensure applications are working as expected
• Key/Value store for dynamic configs, feature flagging, etc.

Although Service Mesh platforms have been around for a while, Kubernetes sort of "brought back" their popularity. The primary thing to remember when thinking about a Service Mesh is that it secures traffic between services.

What is Vault

Vault is a secrets store that allows you to:

• Have a secrets engine that integrates external systems
• Create any type of authentication method for cloud and on-prem services
• Rotate secrets on the fly
• Run Vault on-prem, in the cloud, or as a managed service

Vault is one of the top secret management platforms many engineers gravitate towards due to the HashiCorp stack being incredibly popular because Terraform is ubiquitous. It's a great solution if you're only concerned about managing secrets and not other configuration data.

What is CloudTruth

CloudTruth is centralized configuration management that handles any key/value pair, both plain-text and secret, you throw at it. That includes:

• Key/value pairs for Kubernetes Manifests
• Store Kubernetes Manifests as templates
• Pass in parameters at runtime in your development code
• Pass in parameters at runtime in your infrastructure code
• Store environment variables for application and infrastructure code
• Integrate with Azure, AWS, GitHub, and AWS SSM
• Store secrets to be used by any platform, both in the cloud and on-prem, from a centralized location

Essentially, CloudTruth is your configuration hub for literally any value that you need to use across your environments. It could be as simple as a Replica Count in a Kubernetes Manifest or as complex as several secrets having authentication and authorization for an application. CloudTruth allows you to have one location to manage all of this across any cloud and any on-prem environment.

Key point: CloudTruth decouples the management of configuration from how the data is consumed.

How They Work Together

Now that you know what each platform is, let's talk about how they work together. Conceptually, they are very different tools that can perform similar actions. However, you always want to use the right tool for the job.

Consul is always going to be separate from CloudTruth because they're doing two different things. One tool is for managing configuration data and the other tool is for securing service discovery and communication. Where CloudTruth can help with Consul is storing the Consul configuration as a template or storing the Consul configuration parameters.

When it comes to HashiCorp Vault and CloudTruth, there is still some amazing synergy there. CloudTruth can be implemented to store plain-text and application-specific configurations, like passing in application parameters at runtime, and Vault can be used to manage secrets for an environment. Because the configuration data and secrets space is so large, there doesn't need to be a one-size-fits-all. Engineers live in a world today where there isn't a "single pane of glass". Engineers are using multiple platforms to get the job done.

Configuration sprawl is a by-product of a perfect storm from the Kubernetes fast rise, breaking monoliths into microservices, and Gitops work flows. This is why a system that decouples the management of configuration data from how it is consumed is needed.