HashiCorp Extends Service Mesh To Address Security
HashiCorp has extended the reach of HashiCorp Consul, an open source service mesh for containers, into the realm of cybersecurity. The company made the announcement at this week at its HashiDays event.
Armon Dadgar, founder and co-CTO of HashiCorp, says HashiCorp Consul already provides a means to discover container use and registry as well as tools to configure them using DNS for discovery and a key/value store for configuration. The latest version adds a Consul Connect module, available in beta, which makes it possible to employ encrypted transport layer security (TLS) certificates as a mechanism to isolate services that prevents them from connecting to any service that they don’t have explicit permission to engage.
That approach eliminates the need to rely on expensive firewall software that is too rigid to keep pace with the rate of change that occurs in a microservices environment based on containers, Dadgar says. HashiCorp Consul also makes those microservices more secure because connections are based on rules defined by the certificates rather than IP addresses that can be reassigned without the knowledge of the DevOps teams. Secure communications can also be established between legacy and modern workloads using sidecar proxies.
Dadgar says HashiCorp Connect advances the state of DevSecOps in container environments because it provides a way to isolate services in a way that developers can easily implement within the application development process. That capability serves to eliminate the friction that naturally occurs between developers building dynamic microservices and cybersecurity teams that held accountable for securing them.
HashiCorp Consul has already been deployed on more than 5 million machines and is being downloaded at a rate of 1 million times a month, says Dadgar. That base provides a foundation which HashiCorp can extend the service mesh into areas such as security. In fact, Dadgar notes HashiCorp Consul eliminates the need to deploy three separate frameworks for discovering, configuring and now securing containers.
Dadgar says a service mesh is required because microservices make use of complex service-to-service communication patterns, dynamic IP addresses, ephemeral infrastructure and a low-trust network environment. These dynamic environments create the need for service mesh that allows users to discover, configure and connect services regardless of whether they run on-premises or in a public cloud. Previously, many of these requirements where handled by a load balancer running in a static environment. But legacy load balancers are not designed to handle highly dynamic interactions between microservices, he says.
HashiCorp is not only vendor building a service mesh for containers. There are already multiple open source projects. But HashiCorp is trying to combine service mesh capabilities with an IT automation framework that is accessible to developers and IT operations teams alike. It’s clear that as the complexity of microservices environments increases, most DevOps teams increasingly will need to rely on various forms of automation.
After all, there’s already a shortage of IT talent. Just because developers have embraced microservices based on containers doesn’t mean there will suddenly be more IT operations staff available to manage them. In fact, if anything, existing IT operations teams will continue to be asked to do more with either what they have to day or potentially even less.
