443 lines
15 KiB
Plaintext
443 lines
15 KiB
Plaintext
---
|
|
name: Secure Service-to-Service Communication
|
|
content_length: 12
|
|
id: connect-services
|
|
products_used:
|
|
- Consul
|
|
description: This guide demonstrates Consul Connect using internal proxies as sidecars.
|
|
level: Implementation
|
|
---
|
|
|
|
Consul Connect secures service-to-service communication with authorization and
|
|
encryption. Applications can use sidecar proxies in a service mesh
|
|
configuration to automatically establish TLS connections for inbound and
|
|
outbound connections without being aware of Connect at all. In addition to
|
|
securing your services, Connect can also intercept [data about service-to-service
|
|
communications][consul-l7] and surface it to monitoring tools.
|
|
|
|
In this guide, you will register two services and their [sidecar] proxies in
|
|
the Consul catalog. You will then start the services and sidecar proxies.
|
|
Finally, you will demonstrate that the service-to-service communication is going
|
|
through the proxies by stopping traffic with an "[intention]".
|
|
|
|
[![Flow diagram showing end user traffic being sent to the Dashboard Service at
|
|
port 9002. The dashboard service makes requests for the counting service to the
|
|
local Connect Proxy at port 5000. This traffic then traverses the Connect mesh
|
|
over dynamic ports. The traffic exits the Connect mesh from the counting service's
|
|
local proxy. The proxy sends this traffic to the counting service itself at port
|
|
9003.][img-flow]][img-flow]
|
|
|
|
While this guide uses elements that are not suitable for production
|
|
environments—Consul dev agents, internal proxies, and mock services—it will
|
|
teach you the common process for deploying your own services using Consul
|
|
Connect. At the end of this guide, we also present additional information
|
|
about adapting this process to more production-like environments.
|
|
|
|
## Prerequisites
|
|
|
|
To complete this guide, you will need a local [dev agent], which enables
|
|
Connect by default.
|
|
|
|
This guide uses the following example service applications. Download and unzip
|
|
the executables to follow along.
|
|
|
|
- [Counting Service]
|
|
- [Dashboard Service]
|
|
|
|
### Verify your Consul agent health
|
|
|
|
To ensure that Consul is running and accessible from the command line, use the
|
|
`consul members` command to verify your agent status.
|
|
|
|
```shell-session
|
|
$ consul members
|
|
Node Address Status Type Build Protocol DC Segment
|
|
hostname.local 127.0.0.1:8301 alive server 1.6.1 2 dc1 <all>
|
|
```
|
|
|
|
If you receive an error message, verify that you have a local Consul dev agent
|
|
running and try again.
|
|
|
|
## Register the services and sidecar proxies
|
|
|
|
Services have to be registered with Consul. Consul shares this information
|
|
around the cluster so that operators or other services can determine the
|
|
location of a service. Connect also uses service registrations to determine
|
|
where to send proxied traffic to.
|
|
|
|
There are several ways to register services in Consul:
|
|
|
|
- directly from a Consul-aware application
|
|
|
|
- from an orchestrator, like [Nomad][services-nomad] or [Kubernetes][services-k8s]
|
|
|
|
- [using configuration files][services-config] that are loaded at node startup
|
|
|
|
- [using the API][services-api] to register them with a JSON or HCL
|
|
specification
|
|
|
|
- [using the CLI][services-cli] to simplify this submission process
|
|
|
|
For this guide, we will use the [`consul service register`][services-cli] CLI
|
|
command to load them into the catalog.
|
|
|
|
### Create the counting service definition
|
|
|
|
First, define the Counting service and its sidecar proxy in a file named
|
|
`counting.hcl`. The definition should include the name of the service, the port
|
|
the service listens on, and a [connect] block with the [sidecar_service] block.
|
|
This block is empty so Consul will use default parameters. The definition also
|
|
includes an optional service health check.
|
|
|
|
```hcl
|
|
service {
|
|
name = "counting"
|
|
id = "counting-1"
|
|
port = 9003
|
|
|
|
connect {
|
|
sidecar_service {}
|
|
}
|
|
|
|
check {
|
|
id = "counting-check"
|
|
http = "http://localhost:9003/health"
|
|
method = "GET"
|
|
interval = "1s"
|
|
timeout = "1s"
|
|
}
|
|
}
|
|
```
|
|
|
|
Services and sidecar proxies can be defined in either HCL or JSON. There is a
|
|
[JSON version][counting-1.json] version of the service definition in the
|
|
[demo-consul-101 project].
|
|
|
|
### Create the dashboard service definition
|
|
|
|
Create the Dashboard service and proxy definition in the same way. First,
|
|
create a file named `dashboard.hcl`.
|
|
|
|
```hcl
|
|
service {
|
|
name = "dashboard"
|
|
port = 9002
|
|
|
|
connect {
|
|
sidecar_service {
|
|
proxy {
|
|
upstreams = [
|
|
{
|
|
destination_name = "counting"
|
|
local_bind_port = 5000
|
|
}
|
|
]
|
|
}
|
|
}
|
|
}
|
|
|
|
check {
|
|
id = "dashboard-check"
|
|
http = "http://localhost:9002/health"
|
|
method = "GET"
|
|
interval = "1s"
|
|
timeout = "1s"
|
|
}
|
|
}
|
|
```
|
|
|
|
There is a [JSON version][dashboard.json] of the service definition in the
|
|
[demo-consul-101 project].
|
|
|
|
Notice that the dashboard definition also includes an upstream block. Upstreams
|
|
are ports on the local host that will be proxied to the destination service.
|
|
The upstream block's local_bind_port value is the port your service will
|
|
communicate with to reach the service you depend on. The destination name is
|
|
the Consul service name that the local_bind_port will proxy to.
|
|
|
|
In our scenario, the dashboard service depends on the counting service. With
|
|
this configuration, when dashboard service connects to localhost:5000 it is
|
|
proxied across the service mesh to the counting service.
|
|
|
|
### Register the services and proxies
|
|
|
|
Finally, you can submit the service definitions to your Consul agent. If you
|
|
are using the JSON definitions, ensure that the filenames end in ".json"
|
|
instead of ".hcl".
|
|
|
|
```shell-session
|
|
$ consul services register counting.hcl
|
|
Registered service: counting
|
|
```
|
|
|
|
```shell-session
|
|
$ consul services register dashboard.hcl
|
|
Registered service: dashboard
|
|
```
|
|
|
|
-> **Challenge:** After completing the guide, try doing it again using one of
|
|
the other service registration mechanisms mentioned earlier in the guide to
|
|
register the services.
|
|
|
|
### Verify the services are registered
|
|
|
|
Now that you have registered your services and sidecar proxies, run `consul catalog services` to verify that they are present.
|
|
|
|
```shell-session
|
|
$ consul catalog services
|
|
consul
|
|
counting
|
|
counting-sidecar-proxy
|
|
dashboard
|
|
dashboard-sidecar-proxy
|
|
```
|
|
|
|
### Create a Connect intention
|
|
|
|
Intentions define access control for services via Connect and are used to
|
|
control which services may establish connections. The default intention
|
|
behavior is defined by the [default ACL policy].
|
|
|
|
In this guide, this step is not necessary since the default ACL policy of the
|
|
dev agent is "allow all", so Connect connections are automatically allowed as
|
|
well. However, we will create explicit intentions as a part of deploying
|
|
Connect-enabled services.
|
|
|
|
-> **Best Practice:** Creating an explicit intention helps protect your
|
|
service against changes to the implied permissions. For example, a change in
|
|
`default_policy` or the introduction of a global deny-all intention would
|
|
impact services without explicit intentions defined.
|
|
|
|
```shell-session
|
|
$ consul intention create dashboard counting
|
|
Created: dashboard => counting (allow)
|
|
```
|
|
|
|
## Start the services and sidecar proxies
|
|
|
|
Now that you have created all the necessary configuration to describe your
|
|
service's connections, it's time to start your services and their sidecar
|
|
proxies. We are using the `&` operator to run the services as background tasks.
|
|
However, because they write to the console, it's best to run them in their own
|
|
shell session.
|
|
|
|
Run these commands to start the applications:
|
|
|
|
```shell-session
|
|
$ PORT=9002 COUNTING_SERVICE_URL="http://localhost:5000" ./dashboard-service &
|
|
$ PORT=9003 ./counting-service &
|
|
```
|
|
|
|
Next, start the sidecar proxies that will run as [sidecar] processes along with
|
|
the service applications.
|
|
|
|
We are using the Consul Connect's built-in proxy for this guide. In a
|
|
production deployment, we recommend using Envoy instead.
|
|
|
|
```shell-session
|
|
$ consul connect proxy -sidecar-for counting > counting-proxy.log &
|
|
$ consul connect proxy -sidecar-for dashboard > dashboard-proxy.log &
|
|
```
|
|
|
|
### Check the dashboard interface
|
|
|
|
Open a browser and navigate to `http://localhost:9002`.
|
|
|
|
You should see a screen similar to the following. There is a connection
|
|
indicator in the top right that will turn green and say "Connected" when the
|
|
dashboard service is in communication with the counting service.
|
|
|
|
[![Image of Dashboard UI. There is white text on a magenta background, with the
|
|
page title "Dashboard" at the top left. There is a green indicator in the top
|
|
right with the word connected in white. There is a large number 19 to show
|
|
sample counting output. The node name that the counting service is running on,
|
|
host01, is in very small monospaced type underneath the large
|
|
numbers.][img-screenshot1]][img-screenshot1]
|
|
|
|
If your application is not connected, check that the Counting service is
|
|
running and healthy by viewing it in the Consul UI at `http://localhost:8500`.
|
|
|
|
## Test the sidecar proxy connections
|
|
|
|
To test that traffic is flowing through the sidecar proxies, you will control
|
|
traffic with an intention.
|
|
|
|
First, deny the Dashboard service access to the Counting service.
|
|
|
|
```shell-session
|
|
$ consul intention create -deny -replace dashboard counting
|
|
Created: dashboard => counting (deny)
|
|
```
|
|
|
|
Refresh your browser, the connection indicator in the Dashboard ui will now say
|
|
"Disconnected"
|
|
|
|
[![Image of Dashboard UI. There is white text on a magenta background, with the
|
|
page title "Dashboard" at the top left. There is a red indicator in the top
|
|
right with the words "Counting Service is Unreachable" in white. There is a
|
|
large number -1 to show sample counting output. The word "Unreachable"
|
|
surrounded by square brackets is in monospaced type underneath the large
|
|
numbers.][img-screenshot2]][img-screenshot2]
|
|
|
|
You can restore communication between the services by replacing the `deny`
|
|
intention with an `allow`.
|
|
|
|
```shell-session
|
|
$ consul intention create -allow -replace dashboard counting
|
|
```
|
|
|
|
Back in the browser, verify that the dashboard reconnects to the counting
|
|
service.
|
|
|
|
## Clean up
|
|
|
|
Once you are done with this guide, you can begin cleaning up by closing the
|
|
terminal in which your counting-service, dashboard-service, and proxies are
|
|
running. This should automatically stop these processes.
|
|
|
|
Delete the intention from Consul.
|
|
|
|
```shell-session
|
|
$ consul intention delete dashboard counting
|
|
Intention deleted.
|
|
```
|
|
|
|
Deregister the services.
|
|
|
|
```shell-session
|
|
$ consul services deregister counting.hcl
|
|
Deregistered service: counting
|
|
|
|
$ consul services deregister dashboard.hcl
|
|
Deregistered service: dashboard
|
|
```
|
|
|
|
## Extend these concepts
|
|
|
|
When you want to apply this learning to a proof-of-concept or production
|
|
environment, there are some additional considerations.
|
|
|
|
### Enable Connect and gRPC
|
|
|
|
When Consul is started with the `-dev` flag, it will automatically enable
|
|
Consul Connect and provide a default port for gRPC communication. These have to
|
|
be configured explicitly for regular Consul agents.
|
|
|
|
```hcl
|
|
# ...
|
|
|
|
ports {
|
|
"grpc" = 8502
|
|
}
|
|
|
|
connect {
|
|
enabled = true
|
|
}
|
|
|
|
```
|
|
|
|
For JSON configurations:
|
|
|
|
```json
|
|
{
|
|
// ...
|
|
"ports": {
|
|
"grpc": 8502
|
|
},
|
|
"connect": {
|
|
"enabled": true
|
|
}
|
|
}
|
|
```
|
|
|
|
### Download Envoy
|
|
|
|
In this guide we used the built-in Connect proxy. For production deployments
|
|
and to enable L7 features, you should use Envoy.
|
|
|
|
You can obtain container-based builds of Envoy directly from the [Envoy
|
|
Website], or you can obtain a packages of Envoy binary builds from a
|
|
third-party project, [getenvoy.io].
|
|
|
|
Consul will need to be able to find the "envoy" binary on the path. You can
|
|
extract the binary from the official Envoy Docker containers.
|
|
|
|
To do this, create a container named "envoy-extract" based on the
|
|
"envoyproxy/envoy" container.
|
|
|
|
```shell-session
|
|
$ docker create --name "envoy-extract" "envoyproxy/envoy"
|
|
docker create --name "envoy-extract" "envoyproxy/envoy"
|
|
Unable to find image 'envoyproxy/envoy:latest' locally
|
|
latest: Pulling from envoyproxy/envoy
|
|
16c48d79e9cc: Pull complete
|
|
3c654ad3ed7d: Pull complete
|
|
6276f4f9c29d: Pull complete
|
|
a4bd43ad48ce: Pull complete
|
|
ef9506777d3e: Pull complete
|
|
2e7ad8d4ceb7: Pull complete
|
|
d9e379d45dad: Pull complete
|
|
b283a3f5aebc: Pull complete
|
|
095fe71f6465: Pull complete
|
|
Digest: sha256:a7769160c9c1a55bb8d07a3b71ce5d64f72b1f665f10d81aa1581bc3cf850d09
|
|
Status: Downloaded newer image for envoyproxy/envoy:latest
|
|
8d7bb45ea75f4344c6e050e5e1d3423937c4a1a51700ce34c3cf62a5ce3960dd
|
|
```
|
|
|
|
Use the `docker cp` command to copy the envoy file out of the container into
|
|
the current directory.
|
|
|
|
```shell-session
|
|
$ docker cp "envoy-extract:/usr/local/bin/envoy" "envoy"
|
|
```
|
|
|
|
Now that you have the binary, you can remove the "envoy-extract" container.
|
|
|
|
```shell-session
|
|
$ docker rm "envoy-extract"
|
|
envoy-extract
|
|
```
|
|
|
|
Once you have the binary extracted and in your path, Consul will automatically
|
|
use it when you run the `consul connect envoy` command. The following examples
|
|
demonstrate how to start the service sidecar proxies with Envoy.
|
|
|
|
```shell-session
|
|
$ consul connect envoy -sidecar-for counting > counting-proxy.log &
|
|
$ consul connect envoy -sidecar-for dashboard > dashboard-proxy.log &
|
|
```
|
|
|
|
## Summary
|
|
|
|
Now that you have completed this guide, you have familiarized yourself with a
|
|
basic Connect-enabled service deployment. You created and registered Consul
|
|
service definitions that describe how two services communicate with each other.
|
|
After starting the application and sidecar proxies, you used Consul Connect
|
|
intentions to control traffic flow between services. Finally, you learned about
|
|
additional requirements required to take the concepts to a proof-of-concept
|
|
environment.
|
|
|
|
[connect]: https://www.consul.io/docs/connect
|
|
[consul-l7]: https://learn.hashicorp.com/consul/developer-mesh/l7-observability-k8s
|
|
[counting service]: https://github.com/hashicorp/demo-consul-101/releases/download/0.0.2/counting-service_linux_amd64.zip
|
|
[counting-1.json]: https://raw.githubusercontent.com/hashicorp/demo-consul-101/master/demo-config-localhost/counting-1.json
|
|
[dashboard service]: https://github.com/hashicorp/demo-consul-101/releases/download/0.0.2/dashboard-service_linux_amd64.zip
|
|
[dashboard.json]: https://raw.githubusercontent.com/hashicorp/demo-consul-101/master/demo-config-localhost/dashboard.json
|
|
[default acl policy]: https://www.consul.io/docs/agent/options.html#acl_default_policy
|
|
[demo-consul-101 project]: https://github.com/hashicorp/demo-consul-101
|
|
[dev agent]: https://learn.hashicorp.com/consul/getting-started/agent
|
|
[docker guide]: https://learn.hashicorp.com/consul/day-0/containers-guide
|
|
[envoy website]: https://www.envoyproxy.io/docs/envoy/latest/install/building#pre-built-binaries
|
|
[getenvoy.io]: https://www.getenvoy.io/
|
|
[img-flow]: /static/img/consul/connect-getting-started/consul_connect_demo_service_flow.png
|
|
[img-screenshot1]: /static/img/consul/connect-getting-started/screenshot1.png
|
|
[img-screenshot2]: /static/img/consul/connect-getting-started/screenshot2.png
|
|
[intention]: https://www.consul.io/docs/connect/intentions.html
|
|
[services-api]: https://www.consul.io/api/agent/service.html#register-service
|
|
[services-cli]: https://www.consul.io/docs/commands/services.html
|
|
[services-config]: https://www.consul.io/docs/agent/services.html#service-definition
|
|
[services-nomad]: https://www.nomadproject.io/docs/job-specification/service.html
|
|
[sidecar]: https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
|
|
[sidecar_service]: https://www.consul.io/docs/connect/registration/sidecar-service.html
|
|
[services-k8s]: https://www.consul.io/docs/platform/k8s/connect.html#installation-and-configuration
|