Configuration Management in a Service Mesh World
In the IT space one could say that kubernetes is eating the IT world and it’s bringing an entire ecosystem to the table. One of the dinner guests is service mesh.
In a world with kubernetes and containers and microservices, why would we need configuration management?
Many organizations are embarking on the journey to kubernetes nirvana and taking advantage of all the many benefits that a service mesh can provide. Similar to a public cloud journey it’s when you get past the low hanging fruit or net new applications that the sheer complexity starts to become apparent.
We need to have our kubernetes workloads integrate with our “legacy” applications in a meaningful way.
Applications running on bare metal and virtual machines will now need to be connected to the service mesh to take advantage of all the benefits we love about service mesh. Integrating these workloads into the service mesh can be as simple as installing the service mesh agents on the VM or bare metal machine or involve standing up service mesh infrastructure for the non-kubernetes workloads and federating the two environments.
Many of the major service mesh projects already have non-kubernetes support to varying degrees.
Great, we can just install the service mesh agent on the virtual machine or bare metal machine. No reason for configuration management.
Unfortunately the process to bootstrap a VM or bare metal machine isn’t that simple for most service meshes. There are a number of operations to bootstrap the agent that are automagically done for workloads running on kubernetes but not for non-kubernetes workloads. Configuration management tools such as Puppet, Chef and Ansible are ideally suited to help with automating the bootstrap process.
Certificate management
Mutual TLS or mTLS between service endpoints is one of the major benefits of service meshes. This enables encrypted communication between services as well as the ability to restrict which services can talk based upon their identity. Many of the service meshes come with a built-in Certificate Authority (CA) to handle the certificate management process. Most are integrated with the assumption that the primary use case is kubernetes workloads and certificate distribution for non-kubernetes workloads is a manual process. Additionally, external certificate authorities are also supported but then there’s a completely different certificate bootstrap process that needs to be automated.
Configuration Management’s Role
Configuration management tools can help with the automated generation and distribution of the certificates used with the service mesh. It also can make integration with external certificate authorities like HashiCorp Vault simpler with the various existing integration with configuration management tools.
Micro segmentation
Micro segmentation is essentially granting workloads or services the ability to talk to other services on a need to communicate basis. The common example is a three tier application stack with web, app and database tiers. The web servers don’t need to send traffic to one another or the database servers. Similarly the database server shouldn’t need to send traffic to the web servers. This helps mitigate unfettered lateral movement in the event of a security breach.
Service Mesh Policies
Service meshes enable the ability to restrict which services are allowed to communicate with another service. In this way we can ensure that a particular service can communicate with its database. This is but it only controls service to service communication and not what pods can communicate within the environment.
Kubernetes Network Policy
In order to achieve micro segmentation for kubernetes workloads we need to leverage kubernetes network policies or a similar construct to ensure we’ve restricted ingress and egress traffic from the pod to only what is absolutely necessary. This helps ensure that all our kubernetes pods are able to communicate with the oracle production database that’s running on bare metal hardware.
VM/Bare Metal Host Firewall
The ability to do this has been available for years with host based firewalls like the windows firewall and IP Tables for linux along with third party host firewalls. The challenge has always been the willingness to manage the necessary rules. Public cloud has made this much more appealing with security groups along with network policies in Kubernetes.
Configuration Management’s Role
Managing host firewall rules at some level of scale is nearly impossible without some management tool. Configuration management tools can be used to define the appropriate firewall rules in a manner similar to kubernetes network policies and lock down east-west traffic in an environment.
The use of configuration management to help bridge kubernetes and non-kubernetes services makes the adoption of kubernetes in a hybrid world much easier.
Top comments (0)