luxolus/open-consul
2
0
Fork 0
Code Issues 1 Pull requests Packages Releases Wiki Activity

website: how it works

Browse source
This commit is contained in:
Mitchell Hashimoto 2018-05-30 20:57:42 -07:00 committed by Jack Pearkes
parent 8dbe0017bb
commit ce984e57d2
1 changed files with 46 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
website/source/docs/connect/index.html.md
View file

@ -16,9 +16,54 @@ without being aware of Connect at all. Applications may also
[natively integrate with Connect](/docs/connect/native.html)
for optimal performance and security.
Connect enables deployment best-practices with service-to-service encryption
everywhere and identity-based authorization. Rather than authorizing host-based
access with IP address access rules, Connect uses the registered service
identity to enforce access control with [intentions](/docs/connect/intentions.html).
This makes it much easier to reason about access control and also enables
services to freely move, such as in a scheduled environment with software
such as Kubernetes or Nomad. Additionally, intention enforcement can be done
regardless of the underlying network, so Connect works with physical networks,
cloud networks, software-defined networks, cross-cloud, and more.
## How it Works
TODO
The core of Connect is based on [mutual TLS](https://en.wikipedia.org/wiki/Mutual_authentication).
Connect provides each service with an identity encoded as a TLS certificate.
This certificate is used to establish and accept connections to and from other
services. The identity is encoded in the TLS certificate in compliance with
the [SPIFFE X.509 Identity Document](https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md).
This enables Connect services to establish and accept connections with
other SPIFFE-compliant systems.
The client service verifies the destination service certificate
against the [public CA bundle](/api/connect/ca.html#list-ca-root-certificates).
This is very similar to a typical HTTPS web browser connection. In addition
to this, the client provides its own client certificate to show its
identity to the destination service. If the connection handshake succeeds,
the connection is encrypted and authorized.
The destination service verifies the client certificate
against the [public CA bundle](/api/connect/ca.html#list-ca-root-certificates).
After verifying the certificate, it must also call the
[authorization API](/api/agent/connect.html#authorize) to authorize
the connection against the configured set of Consul intentions.
If the authorization API responds successfully, the connection is established.
Otherwise, the connection is rejected.
To generate and distribute certificates, Consul has a built-in CA that
requires no other dependencies, and
also ships with built-in support for [Vault](#). The PKI system is pluggable
and can be [extended](#) to support any system.
All APIs required for Connect typically respond in microseconds and impose
minimal overhead to existing services. This is because the Connect-related
APIs are all made to the local Consul agent over a loopback interface, and all
[agent Connect endpoints](/api/agent/connect.html) implement
local caching, background updating, and support blocking queries. As a result,
most API calls operate on purely local in-memory data and can respond
in microseconds.
## Eliminating East-West Firewalls