Upgrading to Enterprise & Service Mesh

Welcome to the third and final phase of our Consul training series. You have installed Consul locally in Phase 1 and constructed a highly available server cluster in Phase 2. Now, we will elevate this infrastructure to enterprise-grade compliance.

In this advanced tutorial, we will transition our running cluster to Consul Enterprise, configure multi-tenant administrative Namespaces to segregate development teams, deploy an Envoy sidecar proxy alongside a microservice, and enforce mutual TLS (mTLS) zero-trust communication using secure Intentions.

🏗️ Enterprise Service Mesh Pipeline

The application networking layout flows through local container network interfaces managed by sidecar proxies:

Step 1: Upgrading to Consul Enterprise

Consul Enterprise is binary-compatible with the open-source version, making the upgrade seamless.

1. Download the Enterprise Package

Instead of the standard package, install consul-enterprise from the HashiCorp repository:

sudo apt update && sudo apt install consul-enterprise -y

2. Apply your Enterprise License

Enterprise features require a license file. Write your license string to a file and point your HCL config to it:

# Add this parameter to /etc/consul.d/consul.hcl
license_path = "/etc/consul.d/consul.lic"

Save your license file to /etc/consul.d/consul.lic, set correct file permissions, and reboot:

sudo chown consul:consul /etc/consul.d/consul.lic
sudo systemctl restart consul

Step 2: Creating Admin Namespaces for Multi-Tenancy

Namespaces isolate services, policies, and KV pairs within a single physical cluster—perfect for multi-team configurations.

Use the Consul CLI to register a secure namespace for your billing team:

consul namespace create -name billing -description "PCI-Compliant Billing Ingress"

Verify that the namespace is active in the cluster:

consul namespace list

You will see the default namespace along with your newly registered billing namespace.

Step 3: Registering a Service Mesh & Injecting Envoy Sidecars

To route traffic through our service mesh, we register our microservices with a connect block, which instructs Consul to attach an Envoy sidecar proxy.

1. Create a Service definition

Write a service configuration file for your Database service inside the /etc/consul.d/ directory:

# /etc/consul.d/db-service.hcl
service {
  name      = "payment-db"
  namespace = "billing"
  port      = 5432

  connect {
    sidecar_service {}
  }
}

Register the service configuration file with Consul:

consul services register /etc/consul.d/db-service.hcl

2. Start the Envoy Sidecar Proxy

Envoy acts as the data plane interceptor. Launch the sidecar proxy instance from the shell of your app server:

consul connect envoy -sidecar-for=payment-db -namespace=billing &

Envoy automatically retrieves local root certificate authorities from Consul, spins up an encrypted TLS listener on dynamic local ports, and proxies incoming requests to your database on port 5432.

Step 4: Enforcing Zero-Trust Access Intentions

By default, in a secure Consul Service Mesh, communication is restricted. To permit your Web service to query the Database service, you must explicitly declare an Access Intention:

1. Create an Intention file

Create a declarative intentions definition file:

# db-intentions.hcl
Kind = "service-intentions"
Name = "payment-db"
Namespace = "billing"

Sources = [
  {
    Name      = "web-portal"
    Namespace = "billing"
    Action    = "allow"
  }
]

2. Apply the Intention

Apply the access policy to your cluster:

consul config write db-intentions.hcl

Consul immediately propagates this policy to the Envoy sidecar proxies. Envoy will now accept mutual TLS connections from web-portal while dropping any traffic originating from other services, safeguarding your production database!

🏁 Summary of the Training Journey

You have successfully traveled the complete Consul engineering path!

1. Phase 1: Learned local binary installations and single-node agent configurations.
2. Phase 2: Scaled to high-availability 3-node clusters using Raft consensus and gossip encryption.
3. Phase 3: Upgraded to Consul Enterprise, deployed multi-tenant administrative namespaces, injected Envoy sidecars, and enforced cryptographically secure mTLS communication.

You now possess the advanced engineering expertise required to construct resilient, enterprise-grade service meshes in distributed microservice clouds!