Documentation
Consul operations
Service networking
Enterprise solutions
Runtimes and platforms
Plugins, integrations, & extensions
Reference docs
Glossary

Secure service mesh overview

This topic provides an overview for securing service-to-service communication within a service mesh using Consul. You can configure an mTLS certificate authority and intentions based on service identity to secure intra-mesh communication.

For information about gossip encryption and securing your Consul deployment with the Access Control List (ACL) system, refer to Secure Consul in the Consul Operations section.

Introduction

With Consul, a fully configured service mesh is one that enforces zero-trust security by securing service-to-service communication in the following ways:

Sidecar proxies encrypt and decrypt a service's traffic using an mTLS certificate signed by Consul
Sidecar proxies deny incoming requests by default
Sidecar proxies authorize incoming requests according to explicitly defined service intentions

Certificate authority

Consul servers include a built-in certificate authority (CA) provider to centrally manage mTLS certificates and perform signing operations. When using the CA, sidecar proxies confirm that an incoming request includes a signed mTLS certificate before it forwards the request to a service.

To use the built-in CA, you must bootstrap it by generating a private key and root certificate that you can distribute to agents. You can also configure Consul agents to use other certificate authorities, such as HashiCorp Vault.

For more information, refer to certificate authority overview.

Service intentions

Service intentions control communication between services at the L4 (network) layer and the L7 (application) layer, depending on the protocol the services use to communicate. You can define service intentions in a configuration entry to automatically deny all service-to-service communication, and then configure more specific intentions to allow only defined traffic within the service mesh. You can also configure service intentions so that sidecar proxies must present a JSON Web Token (JWT) for authorization.

For more information, refer to service mesh intentions overview.

Guidance

To learn more about the workflows described in this topic, refer to the following tutorials:

Runtime-specific usage documentation

For runtime-specific guidance, refer to the following pages:

Reference documentation

For reference material related to Consul's service mesh security options, refer to the following pages:

Constraints, limitations, and troubleshooting

If you experience errors when securing service mesh communication, refer to the following list of technical constraints.

You must bootstrap Consul's built-in certificate authority in order to use it.