Starting Docs (#46)

* website: first stab at Connect docs * website: lots more various stuff (bad commit messages) * website: getting started page for Connect * website: intentions * website: intention APIs * website: agent API docs * website: document agent/catalog proxy kind service values * website: /v1/catalog/connect/:service * website: intention CLI docs * website: custom proxy docs * website: remove dedicated getting started guide * website: add docs for CA API endpoints * website: add docs for connect ca commands * website: add proxy CLI docs * website: clean up proxy command, add dev docs * website: todo pages * website: connect security
2018-05-29 14:07:40 -07:00 · 2018-05-29 14:07:40 -07:00 · 097856c515
parent ab4a9a94f4
commit 097856c515
31 changed files with 2383 additions and 6 deletions
--- a/website/report.xml
+++ b/website/report.xml
@ -0,0 +1,36 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <dfxml xmloutputversion='1.0'>
  <metadata 
  xmlns='http://afflib.org/tcpflow/' 
  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' 
  xmlns:dc='http://purl.org/dc/elements/1.1/'>
    <dc:type>Feature Extraction</dc:type>
  </metadata>
  <creator version='1.0'>
    <program>TCPFLOW</program>
    <version>1.4.5</version>
    <build_environment>
      <compiler>4.2.1 (4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37))</compiler>
      <CPPFLAGS>-D_THREAD_SAFE -pthread -I/usr/local/include -I/usr/local/include  -DUTC_OFFSET=+0100 </CPPFLAGS>
      <CFLAGS>-g   -D_THREAD_SAFE -pthread -g -O3 -MD -Wpointer-arith -Wmissing-declarations -Wmissing-prototypes -Wshadow -Wwrite-strings -Wcast-align -Waggregate-return -Wbad-function-cast -Wcast-qual -Wundef -Wredundant-decls -Wdisabled-optimization -Wfloat-equal -Wmultichar -Wc++-compat -Wmissing-noreturn -Wall -Wstrict-prototypes -MD -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wmissing-declarations -Wmissing-prototypes -Wshadow -Wwrite-strings -Wcast-align -Waggregate-return -Wbad-function-cast -Wcast-qual -Wundef -Wredundant-decls -Wdisabled-optimization -Wfloat-equal -Wmultichar -Wc++-compat -Wmissing-noreturn -Wall -Wstrict-prototypes</CFLAGS>
      <CXXFLAGS>-g -D_THREAD_SAFE -pthread -g -O3 -Wall -MD -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wshadow -Wwrite-strings -Wcast-align -Wredundant-decls -Wdisabled-optimization -Wfloat-equal -Wmultichar -Wmissing-noreturn -Woverloaded-virtual -Wsign-promo -funit-at-a-time -Weffc++ -std=c++11 -Wall -MD -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wshadow -Wwrite-strings -Wcast-align -Wredundant-decls -Wdisabled-optimization -Wfloat-equal -Wmultichar -Wmissing-noreturn -Woverloaded-virtual -Wsign-promo -funit-at-a-time -Weffc++ </CXXFLAGS>
      <LDFLAGS>-L/usr/local/lib -L/usr/local/lib </LDFLAGS>
      <LIBS>-lpcap -lbz2 -lexpat  -lsqlite3 -lssl -lcrypto -lssl -lcrypto -ldl -lz </LIBS>
      <compilation_date>2017-09-21T17:38:31</compilation_date>
      <library name="boost" version="106501"/>
      <library name="sqlite" version="3.19.3" source_id="2017-06-27 16:48:08 2b0954060fe10d6de6d479287dd88890f1bef6cc1beca11bc6cdb79f72e2377b"/>
    </build_environment>
    <execution_environment>
      <os_sysname>Darwin</os_sysname>
      <os_release>17.5.0</os_release>
      <os_version>Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64</os_version>
      <host>Mitchells-MacBook-Pro.local</host>
      <arch>x86_64</arch>
      <command_line>tcpflow -i lo0 -c port 8181</command_line>
      <uid>0</uid>
      <start_time>2018-05-23T20:06:07Z</start_time>
    </execution_environment>
  </creator>
  <configuration>
  </configuration>
  <tdelta>0</tdelta>
--- a/website/source/api/agent/connect.html.md
+++ b/website/source/api/agent/connect.html.md
@ -0,0 +1,293 @@
 ---
 layout: api
 page_title: Connect - Agent - HTTP API
 sidebar_current: api-agent-connect
 description: |-
  The /agent/connect endpoints interact with Connect with agent-local operations.
 ---
 # Connect - Agent HTTP API
 The `/agent/connect` endpoints interact with [Connect](/docs/connect/index.html)
 with agent-local operations.
 These endpoints may mirror the [non-agent Connect endpoints](/api/connect.html)
 in some cases. Almost all agent-local Connect endpoints perform local caching
 to optimize performance of Connect without having to make requests to the server.
 ## Authorize
 This endpoint tests whether a connection attempt is authorized between
 two services. This is the primary API that must be implemented by
 [proxies](/docs/connect/proxies.html) or
 [native integrations](/docs/connect/native.html)
 that wish to integrate with Connect. Prior to calling this API, it is expected
 that the client TLS certificate has been properly verified against the
 current CA roots.
 The implementation of this API uses locally cached data
 and doesn't require any request forwarding to a server. Therefore, the
 response typically occurs in microseconds to impose minimal overhead on the
 connection attempt.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `POST`  | `/agent/connect/authorize`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required             |
 | ---------------- | ----------------- | ------------------------ |
 | `NO`             | `none`            | `service:write` |
 ### Parameters
 - `Target` `(string: <required>)` - The name of the service that is being
  requested.
 - `ClientCertURI` `(string: <required>)` - The unique identifier for the
  requesting client. This is currently the URI SAN from the TLS client
  certificate.
 - `ClientCertSerial` `(string: <required>)` - The colon-hex-encoded serial
  number for the requesting client cert. This is used to check against
  revocation lists.
 ### Sample Payload
 ```json
 {
  "Target": "db",
  "ClientCertURI": "spiffe://dc1-7e567ac2-551d-463f-8497-f78972856fc1.consul/ns/default/dc/dc1/svc/web",
  "ClientCertSerial": "04:00:00:00:00:01:15:4b:5a:c3:94"
 }
 ```
 ### Sample Request
 ```text
 $ curl \
   --request POST \
   --data @payload.json \
    https://consul.rocks/v1/agent/connect/authorize
 ```
 ### Sample Response
 ```json
 {
  "Authorized": true,
  "Reason": "Matched intention: web => db (allow)"
 }
 ```
 ## Certificate Authority (CA) Roots
 This endpoint returns the trusted certificate authority (CA) root certificates.
 This is used by [proxies](/docs/connect/proxies.html) or
 [native integrations](/docs/connect/native.html) to verify served client
 or server certificates are valid.
 This is equivalent to the [non-Agent Connect endpoint](/api/connect.html),
 but the response of this request is cached locally at the agent. This allows
 for very fast response times and for fail open behavior if the server is
 unavailable. This endpoint should be used by proxies and native integrations.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/agent/connect/ca/roots`    | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required               |
 | ---------------- | ----------------- | -------------------------- |
 | `YES`             | `all`            | `none` |
 ### Sample Request
 ```text
 $ curl \
   https://consul.rocks/v1/connect/ca/roots
 ```
 ### Sample Response
 ```json
 {
  "ActiveRootID": "15:bf:3a:7d:ff:ea:c1:8c:46:67:6c:db:b8:81:18:36:ad:e5:d0:c7",
  "Roots": [
    {
      "ID": "15:bf:3a:7d:ff:ea:c1:8c:46:67:6c:db:b8:81:18:36:ad:e5:d0:c7",
      "Name": "Consul CA Root Cert",
      "SerialNumber": 7,
      "SigningKeyID": "31:66:3a:39:31:3a:63:61:3a:34:31:3a:38:66:3a:61:63:3a:36:37:3a:62:66:3a:35:39:3a:63:32:3a:66:61:3a:34:65:3a:37:35:3a:35:63:3a:64:38:3a:66:30:3a:35:35:3a:64:65:3a:62:65:3a:37:35:3a:62:38:3a:33:33:3a:33:31:3a:64:35:3a:32:34:3a:62:30:3a:30:34:3a:62:33:3a:65:38:3a:39:37:3a:35:62:3a:37:65",
      "NotBefore": "2018-05-21T16:33:28Z",
      "NotAfter": "2028-05-18T16:33:28Z",
      "RootCert": "-----BEGIN CERTIFICATE-----\nMIICmDCCAj6gAwIBAgIBBzAKBggqhkjOPQQDAjAWMRQwEgYDVQQDEwtDb25zdWwg\nQ0EgNzAeFw0xODA1MjExNjMzMjhaFw0yODA1MTgxNjMzMjhaMBYxFDASBgNVBAMT\nC0NvbnN1bCBDQSA3MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAER0qlxjnRcMEr\niSGlH7G7dYU7lzBEmLUSMZkyBbClmyV8+e8WANemjn+PLnCr40If9cmpr7RnC9Qk\nGTaLnLiF16OCAXswggF3MA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/\nMGgGA1UdDgRhBF8xZjo5MTpjYTo0MTo4ZjphYzo2NzpiZjo1OTpjMjpmYTo0ZTo3\nNTo1YzpkODpmMDo1NTpkZTpiZTo3NTpiODozMzozMTpkNToyNDpiMDowNDpiMzpl\nODo5Nzo1Yjo3ZTBqBgNVHSMEYzBhgF8xZjo5MTpjYTo0MTo4ZjphYzo2NzpiZjo1\nOTpjMjpmYTo0ZTo3NTo1YzpkODpmMDo1NTpkZTpiZTo3NTpiODozMzozMTpkNToy\nNDpiMDowNDpiMzplODo5Nzo1Yjo3ZTA/BgNVHREEODA2hjRzcGlmZmU6Ly8xMjRk\nZjVhMC05ODIwLTc2YzMtOWFhOS02ZjYyMTY0YmExYzIuY29uc3VsMD0GA1UdHgEB\n/wQzMDGgLzAtgisxMjRkZjVhMC05ODIwLTc2YzMtOWFhOS02ZjYyMTY0YmExYzIu\nY29uc3VsMAoGCCqGSM49BAMCA0gAMEUCIQDzkkI7R+0U12a+zq2EQhP/n2mHmta+\nfs2hBxWIELGwTAIgLdO7RRw+z9nnxCIA6kNl//mIQb+PGItespiHZKAz74Q=\n-----END CERTIFICATE-----\n",
      "IntermediateCerts": null,
      "Active": true,
      "CreateIndex": 8,
      "ModifyIndex": 8
    }
  ]
 }
 ```
 ## Service Leaf Certificate
 This endpoint returns the leaf certificate representing a single service.
 This certificate is used as a server certificate for accepting inbound
 connections and is also used as the client certificate for establishing
 outbound connections to other services.
 The agent generates a CSR locally and calls the
 [CA sign API](/api/connect/ca.html) to sign it. The resulting certificate
 is cached and returned by this API until it is near expiry or the root
 certificates change.
 This API supports blocking queries. The blocking query will block until
 a new certificate is necessary because the existing certificate will expire
 or the root certificate is being rotated. This blocking behavior allows
 clients to efficiently wait for certificate rotations.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/agent/connect/ca/leaf/:service`    | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required               |
 | ---------------- | ----------------- | -------------------------- |
 | `YES`             | `all`            | `service:write` |
 ### Parameters
 - `Service` `(string: <required>)` - The name of the service for the leaf
  certificate. This is specified in the URL. The service does not need to
  exist in the catalog, but the proper ACL permissions must be available.
 ### Sample Request
 ```text
 $ curl \
   https://consul.rocks/v1/connect/ca/leaf/web
 ```
 ### Sample Response
 ```json
 {
  "SerialNumber": "08",
  "CertPEM": "-----BEGIN CERTIFICATE-----\nMIIChjCCAi2gAwIBAgIBCDAKBggqhkjOPQQDAjAWMRQwEgYDVQQDEwtDb25zdWwg\nQ0EgNzAeFw0xODA1MjExNjMzMjhaFw0xODA1MjQxNjMzMjhaMA4xDDAKBgNVBAMT\nA3dlYjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJdLqRKd1SRycFOFceMHOBZK\nQW8HHO8jZ5C8dRswD+IwTd/otJPiaPrVzGOAi4MsaEUgDMemvN1jiywHt3II08mj\nggFyMIIBbjAOBgNVHQ8BAf8EBAMCA7gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG\nAQUFBwMBMAwGA1UdEwEB/wQCMAAwaAYDVR0OBGEEXzFmOjkxOmNhOjQxOjhmOmFj\nOjY3OmJmOjU5OmMyOmZhOjRlOjc1OjVjOmQ4OmYwOjU1OmRlOmJlOjc1OmI4OjMz\nOjMxOmQ1OjI0OmIwOjA0OmIzOmU4Ojk3OjViOjdlMGoGA1UdIwRjMGGAXzFmOjkx\nOmNhOjQxOjhmOmFjOjY3OmJmOjU5OmMyOmZhOjRlOjc1OjVjOmQ4OmYwOjU1OmRl\nOmJlOjc1OmI4OjMzOjMxOmQ1OjI0OmIwOjA0OmIzOmU4Ojk3OjViOjdlMFkGA1Ud\nEQRSMFCGTnNwaWZmZTovLzExMTExMTExLTIyMjItMzMzMy00NDQ0LTU1NTU1NTU1\nNTU1NS5jb25zdWwvbnMvZGVmYXVsdC9kYy9kYzEvc3ZjL3dlYjAKBggqhkjOPQQD\nAgNHADBEAiBS8kH3UERhBPHM/CQV/jXKLr0kReLqCdq1jZxc8Aq7hQIgFIus/ZX0\nOM/X3Yc1xb/qJiiEVzXcaz3oVFULOzrNAwk=\n-----END CERTIFICATE-----\n",
  "PrivateKeyPEM": "-----BEGIN EC PRIVATE KEY-----\nMHcCAQEEIAOGglbwY8HdD3LFX6Bc94co2pzeFTto8ebWoML5E+QfoAoGCCqGSM49\nAwEHoUQDQgAEl0upEp3VJHJwU4Vx4wc4FkpBbwcc7yNnkLx1GzAP4jBN3+i0k+Jo\n+tXMY4CLgyxoRSAMx6a83WOLLAe3cgjTyQ==\n-----END EC PRIVATE KEY-----\n",
  "Service": "web",
  "ServiceURI": "spiffe://11111111-2222-3333-4444-555555555555.consul/ns/default/dc/dc1/svc/web",
  "ValidAfter": "2018-05-21T16:33:28Z",
  "ValidBefore": "2018-05-24T16:33:28Z",
  "CreateIndex": 5,
  "ModifyIndex": 5
 }
 ```
 - `SerialNumber` `string` - Monotonically increasing 64-bit serial number
  representing all certificates issued by this Consul cluster.
 - `CertPEM` `(string)` - The PEM-encoded certificate.
 - `PrivateKeyPEM` `(string)` - The PEM-encoded private key for this certificate.
 - `Service` `(string)` - The name of the service that this certificate identifies.
 - `ServiceURI` `(string)` - The URI SAN for this service.
 - `ValidAfter` `(string)` - The time after which the certificate is valid.
  Used with `ValidBefore` this can determine the validity period of the certificate.
 - `ValidBefore` `(string)` - The time before which the certificate is valid.
  Used with `ValidAfter` this can determine the validity period of the certificate.
 ## Managed Proxy Configuration
 This endpoint returns the configuration for a
 [managed proxy](/docs/connect/proxies.html).
 Ths endpoint is only useful for _managed proxies_ and not relevant
 for unmanaged proxies.
 Managed proxy configuration is set in the service definition. When Consul
 starts the managed proxy, it provides the service ID and ACL token. The proxy
 is expected to call this endpoint to retrieve its configuration. It may use
 a blocking query to detect any configuration changes.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/agent/connect/proxy/:id`    | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required               |
 | ---------------- | ----------------- | -------------------------- |
 | `YES`             | `all`            | `service:write, proxy token` |
 ### Parameters
 - `ID` `(string: <required>)` - The ID (not the name) of the proxy service
  in the local agent catalog. For managed proxies, this is provided in the
  `CONSUL_PROXY_ID` environment variable by Consul.
 ### Sample Request
 ```text
 $ curl \
   https://consul.rocks/v1/connect/proxy/web-proxy
 ```
 ### Sample Response
 ```json
 {
  "ProxyServiceID": "web-proxy",
  "TargetServiceID": "web",
  "TargetServiceName": "web",
  "ContentHash": "cffa5f4635b134b9",
  "ExecMode": "daemon",
  "Command": [
    "/usr/local/bin/consul",
    "connect",
    "proxy"
  ],
  "Config": {
    "bind_address": "127.0.0.1",
    "bind_port": 20199,
    "local_service_address": "127.0.0.1:8181"
  }
 }
 ```
 - `ProxyServiceID` `string` - The ID of the proxy service.
 - `TargetServiceID` `(string)` - The ID of the target service the proxy represents.
 - `TargetServiceName` `(string)` - The name of the target service the proxy represents.
 - `ContentHash` `(string)` - The content hash of the response used for hash-based
  blocking queries.
 - `ExecMode` `(string)` - The execution mode of the managed proxy.
 - `Command` `(array<string>)` - The command for the managed proxy.
 - `Config` `(map<string|any>)` - The configuration for the managed proxy. This
  is a map of primitive values (including arrays and maps) that is set by the
  user.
--- a/website/source/api/agent/service.html.md
+++ b/website/source/api/agent/service.html.md
@ -70,6 +70,9 @@ The agent is responsible for managing the status of its local services, and for
 sending updates about its local services to the servers to keep the global
 catalog in sync.
 For "connect-proxy" kind services, the `service:write` ACL for the
 `ProxyDestination` value is also required to register the service.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `PUT`  | `/agent/service/register`    | `application/json`         |
@ -104,6 +107,16 @@ The table below shows this endpoint's support for
 - `Port` `(int: 0)` - Specifies the port of the service.
 - `Kind` `(string: "")` - The kind of service. Defaults to "" which is a
  typical Consul service. This value may also be "connect-proxy" for
  services that are [Connect-capable](/docs/connect/index.html)
  proxies representing another service.
 - `ProxyDestination` `(string: "")` - For "connect-proxy" `Kind` services,
  this must be set to the name of the service that the proxy represents. This
  service doesn't need to be registered, but the caller must have an ACL token
  with permissions for this service.
 - `Check` `(Check: nil)` - Specifies a check. Please see the
  [check documentation](/api/agent/check.html) for more information about the
  accepted fields. If you don't provide a name or id for the check then they
--- a/website/source/api/catalog.html.md
+++ b/website/source/api/catalog.html.md
@ -479,6 +479,86 @@ $ curl \
 - `ServiceTags` is a list of tags for the service
 - `ServiceKind` is the kind of service, usually "". See the Agent
  registration API for more information.
 - `ServiceProxyDestination` is the name of the service that is being proxied,
  for "connect-proxy" type services.
 ## List Nodes for Connect-capable Service
 This endpoint returns the nodes providing a
 [Connect-capable](/docs/connect/index.html) service in a given datacenter.
 This will include both proxies and native integrations. A service may
 register both Connect-capable and incapable services at the same time,
 so this endpoint may be used to filter only the Connect-capable endpoints.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/catalog/connect/:service`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required             |
 | ---------------- | ----------------- | ------------------------ |
 | `YES`            | `all`             | `node:read,service:read` |
 ### Parameters
 - `service` `(string: <required>)` - Specifies the name of the service for which
  to list nodes. This is specified as part of the URL.
 - `dc` `(string: "")` - Specifies the datacenter to query. This will default to
  the datacenter of the agent being queried. This is specified as part of the
  URL as a query parameter.
 ### Sample Request
 ```text
 $ curl \
    https://consul.rocks/v1/catalog/connect/my-service
 ```
 ### Sample Response
 ```json
 [
  {
    "ID": "40e4a748-2192-161a-0510-9bf59fe950b5",
    "Node": "foobar",
    "Address": "192.168.10.10",
    "Datacenter": "dc1",
    "TaggedAddresses": {
      "lan": "192.168.10.10",
      "wan": "10.0.10.10"
    },
    "NodeMeta": {
      "somekey": "somevalue"
    },
    "CreateIndex": 51,
    "ModifyIndex": 51,
    "ServiceAddress": "172.17.0.3",
    "ServiceEnableTagOverride": false,
    "ServiceID": "32a2a47f7992:nodea:5000",
    "ServiceName": "foobar",
 	"ServiceKind": "connect-proxy",
 	"ServiceProxyDestination": "my-service",
    "ServicePort": 5000,
    "ServiceMeta": {
        "foobar_meta_value": "baz"
    },
    "ServiceTags": [
      "tacos"
    ]
  }
 ]
 ```
 The fields are the same as listing nodes for a service.
 ## List Services for Node
 This endpoint returns the node's registered services.
--- a/website/source/api/connect.html.md
+++ b/website/source/api/connect.html.md
@ -0,0 +1,21 @@
 ---
 layout: api
 page_title: Connect - HTTP API
 sidebar_current: api-connect
 description: |-
  The `/connect` endpoints provide access to Connect-related operations for intentions and the certificate authority.
 ---
 # Connect HTTP Endpoint
 The `/connect` endpoints provide access to
 [Connect-related](/docs/connect/index.html) operations for
 intentions and the certificate authority.
 There are also Connect-related endpoints in the
 [Agent](/api/agent.html) and [Catalog](/api/catalog.html) APIs. For example,
 the API for requesting a TLS certificate for a service is part of the agent
 APIs. And the catalog API has an endpoint for finding all Connect-capable
 services in the catalog.
 Please choose a sub-section in the navigation for more information.
--- a/website/source/api/connect/ca.html.md
+++ b/website/source/api/connect/ca.html.md
@ -0,0 +1,150 @@
 ---
 layout: api
 page_title: Certificate Authority - Connect - HTTP API
 sidebar_current: api-connect-ca
 description: |-
  The /connect/ca endpoints provide tools for interacting with Connect's
  Certificate Authority mechanism via Consul's HTTP API.
 ---
 # Certificate Authority (CA) - Connect HTTP API
 The `/connect/ca` endpoints provide tools for interacting with Connect's
 Certificate Authority mechanism.
 ## List CA Root Certificates
 This endpoint returns the current list of trusted CA root certificates in 
 the cluster.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/connect/ca/roots`          | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required     |
 | ---------------- | ----------------- | ---------------- |
 | `YES`            | `all`             | `operator:read`  |
 ### Sample Request
 ```text
 $ curl \
    https://consul.rocks/v1/connect/ca/roots
 ```
 ### Sample Response
 ```json
 {
    "ActiveRootID": "c7:bd:55:4b:64:80:14:51:10:a4:b9:b9:d7:e0:75:3f:86:ba:bb:24",
    "TrustDomain": "7f42f496-fbc7-8692-05ed-334aa5340c1e.consul",
    "Roots": [
        {
            "ID": "c7:bd:55:4b:64:80:14:51:10:a4:b9:b9:d7:e0:75:3f:86:ba:bb:24",
            "Name": "Consul CA Root Cert",
            "SerialNumber": 7,
            "SigningKeyID": "32:64:3a:30:39:3a:35:64:3a:38:34:3a:62:39:3a:38:39:3a:34:62:3a:64:64:3a:65:33:3a:38:38:3a:62:62:3a:39:63:3a:65:32:3a:62:32:3a:36:39:3a:38:31:3a:31:66:3a:34:62:3a:61:36:3a:66:64:3a:34:64:3a:64:66:3a:65:65:3a:37:34:3a:36:33:3a:66:33:3a:37:34:3a:35:35:3a:63:61:3a:62:30:3a:62:35:3a:36:35",
            "NotBefore": "2018-05-25T21:39:23Z",
            "NotAfter": "2028-05-22T21:39:23Z",
            "RootCert": "-----BEGIN CERTIFICATE-----\nMIICmDCCAj6gAwIBAgIBBzAKBggqhkjOPQQDAjAWMRQwEgYDVQQDEwtDb25zdWwg\nQ0EgNzAeFw0xODA1MjUyMTM5MjNaFw0yODA1MjIyMTM5MjNaMBYxFDASBgNVBAMT\nC0NvbnN1bCBDQSA3MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEq4S32Pu0/VL4\nG75gvdyQuAhqMZFsfBRwD3pgvblgZMeJc9KDosxnPR+W34NXtMD/860NNVJIILln\n9lLhIjWPQqOCAXswggF3MA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/\nMGgGA1UdDgRhBF8yZDowOTo1ZDo4NDpiOTo4OTo0YjpkZDplMzo4ODpiYjo5Yzpl\nMjpiMjo2OTo4MToxZjo0YjphNjpmZDo0ZDpkZjplZTo3NDo2MzpmMzo3NDo1NTpj\nYTpiMDpiNTo2NTBqBgNVHSMEYzBhgF8yZDowOTo1ZDo4NDpiOTo4OTo0YjpkZDpl\nMzo4ODpiYjo5YzplMjpiMjo2OTo4MToxZjo0YjphNjpmZDo0ZDpkZjplZTo3NDo2\nMzpmMzo3NDo1NTpjYTpiMDpiNTo2NTA/BgNVHREEODA2hjRzcGlmZmU6Ly83ZjQy\nZjQ5Ni1mYmM3LTg2OTItMDVlZC0zMzRhYTUzNDBjMWUuY29uc3VsMD0GA1UdHgEB\n/wQzMDGgLzAtgis3ZjQyZjQ5Ni1mYmM3LTg2OTItMDVlZC0zMzRhYTUzNDBjMWUu\nY29uc3VsMAoGCCqGSM49BAMCA0gAMEUCIBBBDOWXWApx4S6bHJ49AW87Nw8uQ/gJ\nJ6lvm3HzEQw2AiEA4PVqWt+z8fsQht0cACM42kghL97SgDSf8rgCqfLYMng=\n-----END CERTIFICATE-----\n",
            "IntermediateCerts": null,
            "Active": true,
            "CreateIndex": 8,
            "ModifyIndex": 8
        }
    ]
 }
 ```
 ## Get CA Configuration
 This endpoint returns the current CA configuration.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/connect/ca/configuration`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required    |
 | ---------------- | ----------------- | --------------- |
 | `YES`            | `all`             | `operator:read` |
 ### Sample Request
 ```text
 $ curl \
    https://consul.rocks/v1/connect/ca/configuration
 ```
 ### Sample Response
 ```json
 {
    "Provider": "consul",
    "Config": {
        "PrivateKey": null,
        "RootCert": null,
        "RotationPeriod": "2160h"
    },
    "CreateIndex": 5,
    "ModifyIndex": 5
 }
 ```
 ## Update CA Configuration
 This endpoint updates the configuration for the CA. If this results in a
 new root certificate being used, the [Root Rotation]
 (/docs/guides/connect-ca.html#rotation) process will be triggered.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `PUT`  | `/connect/ca/configuration`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required    |
 | ---------------- | ----------------- | --------------- |
 | `NO`             | `none`            | `operator:write`|
 ### Parameters
 - `Provider` `(string: <required>)` - Specifies the CA provider type to use.
 - `Config` `(map[string]string: <required>)` - The raw configuration to use
 for the chosen provider. For more information on configuring the Connect CA
 providers, see [Provider Config](/docs/connect/ca.html).
 ### Sample Payload
 ```json
 {
    "Provider": "consul",
    "Config": {
        "PrivateKey": "-----BEGIN RSA PRIVATE KEY-----...",
        "RootCert": "-----BEGIN CERTIFICATE-----...",
        "RotationPeriod": "720h"
    }
 }
 ```
 ### Sample Request
 ```text
 $ curl \
    --request PUT \
    --data @payload.json \
    https://consul.rocks/v1/connect/ca/configuration
 ```
--- a/website/source/api/connect/intentions.html.md
+++ b/website/source/api/connect/intentions.html.md
@ -0,0 +1,383 @@
 ---
 layout: api
 page_title: Intentions - Connect - HTTP API
 sidebar_current: api-connect-intentions
 description: |-
  The /connect/intentions endpoint provide tools for managing intentions via
  Consul's HTTP API.
 ---
 # Intentions - Connect HTTP API
 The `/connect/intentions` endpoint provide tools for managing
 [intentions](/docs/connect/intentions.html).
 ## Create Intention
 This endpoint creates a new intention and returns its ID if it was created
 successfully.
 The name and destination pair must be unique. If another intention matches
 the name and destination, the creation will fail. You must either update the
 existing intention or delete it prior to creating a new one.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `POST` | `/connect/intentions`        | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required     |
 | ---------------- | ----------------- | ---------------- |
 | `NO`             | `none`            | `service:write` |
 ### Parameters
 - `SourceName` `(string: <required>)` - The source of the intention.
  For a `SourceType` of `consul` this is the name of a Consul service. The
  service doesn't need to be registered.
 - `DestinationName` `(string: <required>)` - The destination of the intention.
  The intention destination is always a Consul service, unlike the source.
  The service doesn't need to be registered.
 - `SourceType` `(string: <required>)` - The type for the `SourceName` value.
  This can be only "consul" today to represent a Consul service.
 - `Action` `(string: <required>)` - This is one of "allow" or "deny" for
  the action that should be taken if this intention matches a request.
 - `Description` `(string: nil)` - Description for the intention. This is not
  used for anything by Consul, but is presented in API responses to assist
  tooling.
 - `Meta` `(map<string|string>: nil)` - Specifies arbitrary KV metadata pairs.
 ### Sample Payload
 ```json
 {
  "SourceName": "web",
  "DestinationName": "db",
  "SourceType": "consul",
  "Action": "allow"
 }
 ```
 ### Sample Request
 ```text
 $ curl \
    --request POST \
    --data @payload.json \
    https://consul.rocks/v1/connect/intentions
 ```
 ### Sample Response
 ```json
 {
  "ID": "8f246b77-f3e1-ff88-5b48-8ec93abf3e05"
 }
 ```
 ## Read Specific Intention
 This endpoint reads a specific intention.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/connect/intentions/:uuid`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required    |
 | ---------------- | ----------------- | --------------- |
 | `YES`            | `all`             | `service:read` |
 ### Parameters
 - `uuid` `(string: <required>)` - Specifies the UUID of the intention to read. This
  is specified as part of the URL.
 ### Sample Request
 ```text
 $ curl \
    https://consul.rocks/v1/connect/intentions/e9ebc19f-d481-42b1-4871-4d298d3acd5c
 ```
 ### Sample Response
 ```json
 {
  "ID": "e9ebc19f-d481-42b1-4871-4d298d3acd5c",
  "Description": "",
  "SourceNS": "default",
  "SourceName": "web",
  "DestinationNS": "default",
  "DestinationName": "db",
  "SourceType": "consul",
  "Action": "allow",
  "DefaultAddr": "",
  "DefaultPort": 0,
  "Meta": {},
  "CreatedAt": "2018-05-21T16:41:27.977155457Z",
  "UpdatedAt": "2018-05-21T16:41:27.977157724Z",
  "CreateIndex": 11,
  "ModifyIndex": 11
 }
 ```
 ## List Intentions
 This endpoint lists all intentions.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/connect/intentions`        | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required    |
 | ---------------- | ----------------- | --------------- |
 | `YES`            | `all`             | `service:read` |
 ### Sample Request
 ```text
 $ curl \
    https://consul.rocks/v1/connect/intentions
 ```
 ### Sample Response
 ```json
 [
  {
    "ID": "e9ebc19f-d481-42b1-4871-4d298d3acd5c",
    "Description": "",
    "SourceNS": "default",
    "SourceName": "web",
    "DestinationNS": "default",
    "DestinationName": "db",
    "SourceType": "consul",
    "Action": "allow",
    "DefaultAddr": "",
    "DefaultPort": 0,
    "Meta": {},
    "CreatedAt": "2018-05-21T16:41:27.977155457Z",
    "UpdatedAt": "2018-05-21T16:41:27.977157724Z",
    "CreateIndex": 11,
    "ModifyIndex": 11
  }
 ]
 ```
 ## Update Intention
 This endpoint updates an intention with the given values.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `PUT`  | `/connect/intentions/:uuid`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required     |
 | ---------------- | ----------------- | ---------------- |
 | `NO`             | `none`            | `service:write` |
 ### Parameters
 - `uuid` `(string: <required>)` - Specifies the UUID of the intention to update. This
  is specified as part of the URL.
 - Other parameters are identical to creating an intention.
 ### Sample Payload
 ```json
 {
  "SourceName": "web",
  "DestinationName": "other-db",
  "SourceType": "consul",
  "Action": "allow"
 }
 ```
 ### Sample Request
 ```text
 $ curl \
    --request PUT \
    --data @payload.json \
    https://consul.rocks/v1/connect/intentions/e9ebc19f-d481-42b1-4871-4d298d3acd5c
 ```
 ## Delete Intention
 This endpoint deletes a specific intention.
 | Method   | Path                         | Produces                   |
 | -------- | ---------------------------- | -------------------------- |
 | `DELETE` | `/connect/intentions/:uuid`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required     |
 | ---------------- | ----------------- | ---------------- |
 | `NO`             | `none`            | `service:write` |
 ### Parameters
 - `uuid` `(string: <required>)` - Specifies the UUID of the intention to delete. This
  is specified as part of the URL.
 ### Sample Request
 ```text
 $ curl \
    --request DELETE \
    https://consul.rocks/v1/connect/intentions/e9ebc19f-d481-42b1-4871-4d298d3acd5c
 ```
 ## Check Intention Result
 This endpoint evaluates the intentions for a specific source and destination
 and returns whether the connection would be authorized or not given the
 current Consul configuration and set of intentions.
 This endpoint will work even if the destination service has
 `intention = "deny"` specifically set, because the resulting API response
 does not contain any information about the intention itself.
 | Method | Path                         | Produces                   |
 | ------ | ---------------------------- | -------------------------- |
 | `GET`  | `/connect/intentions/check`  | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required     |
 | ---------------- | ----------------- | ---------------- |
 | `NO`             | `none`            | `service:read` |
 ### Parameters
 - `source` `(string: <required>)` - Specifies the source service. This
  is specified as part of the URL.
 - `destination` `(string: <required>)` - Specifies the destination service. This
  is specified as part of the URL.
 ### Sample Request
 ```text
 $ curl \
    https://consul.rocks/v1/connect/intentions/check?source=web&destination=db
 ```
 ### Sample Response
 ```json
 {
  "Allowed": true
 }
 ```
 - `Allowed` is true if the connection would be allowed, false otherwise.
 ## List Matching Intentions
 This endpoint lists the intentions that match a given source or destination.
 The intentions in the response are in evaluation order.
 | Method | Path                           | Produces                   |
 | ------ | ------------------------------ | -------------------------- |
 | `GET`  | `/connect/intentions/match`    | `application/json`         |
 The table below shows this endpoint's support for
 [blocking queries](/api/index.html#blocking-queries),
 [consistency modes](/api/index.html#consistency-modes), and
 [required ACLs](/api/index.html#acls).
 | Blocking Queries | Consistency Modes | ACL Required    |
 | ---------------- | ----------------- | --------------- |
 | `NO`             | `none`            | `service:read` |
 ### Parameters
 - `by` `(string: <required>)` - Specifies whether to match the "name" value
  by "source" or "destination".
 - `name` `(string: <required>)` - Specifies a name to match. This parameter
  can be repeated for batching multiple matches.
 ### Sample Request
 ```text
 $ curl \
    https://consul.rocks/v1/connect/intentions/match?by=source&name=web
 ```
 ### Sample Response
 ```json
 {
  "web": [
    {
      "ID": "ed16f6a6-d863-1bec-af45-96bbdcbe02be",
      "Description": "",
      "SourceNS": "default",
      "SourceName": "web",
      "DestinationNS": "default",
      "DestinationName": "db",
      "SourceType": "consul",
      "Action": "deny",
      "DefaultAddr": "",
      "DefaultPort": 0,
      "Meta": {},
      "CreatedAt": "2018-05-21T16:41:33.296693825Z",
      "UpdatedAt": "2018-05-21T16:41:33.296694288Z",
      "CreateIndex": 12,
      "ModifyIndex": 12
    },
    {
      "ID": "e9ebc19f-d481-42b1-4871-4d298d3acd5c",
      "Description": "",
      "SourceNS": "default",
      "SourceName": "web",
      "DestinationNS": "default",
      "DestinationName": "*",
      "SourceType": "consul",
      "Action": "allow",
      "DefaultAddr": "",
      "DefaultPort": 0,
      "Meta": {},
      "CreatedAt": "2018-05-21T16:41:27.977155457Z",
      "UpdatedAt": "2018-05-21T16:41:27.977157724Z",
      "CreateIndex": 11,
      "ModifyIndex": 11
    }
  ]
 }
 ```
--- a/website/source/assets/stylesheets/_inner.scss
+++ b/website/source/assets/stylesheets/_inner.scss
@ -60,7 +60,7 @@
  h3,
  h4 {
    color: $body-font-color;
-    margin-top: 54px;
+    margin-top: 35px;
    margin-bottom: $font-size;
    line-height: 1.3;
  }
--- a/website/source/docs/agent/dns.html.md
+++ b/website/source/docs/agent/dns.html.md
@ -207,6 +207,27 @@ Both A and SRV records are supported. SRV records provide the port that a servic
 registered on, enabling clients to avoid relying on well-known ports. SRV records are
 only served if the client specifically requests them.
 ### Connect-Capable Service Lookups
 To find Connect-capable services:
    <service>.connect.<domain>
 This will find all [Connect-capable](/docs/connect/index.html)
 endpoints for the given `service`. A Connect-capable endpoint may be
 both a proxy for a service or a natively integrated Connect application.
 The DNS interface does not differentiate the two.
 Most services will use a [proxy](/docs/connect/proxies.html) that handles
 service discovery automatically and therefore won't use this DNS format.
 This DNS format is primarily useful for [Connect-native](/docs/connect/native.html)
 applications.
 This endpoint currently only finds services within the same datacenter
 and doesn't support tags. This DNS interface will be expanded over time.
 If you need more complex behavior, please use the
 [catalog API](/api/catalog.html).
 ### UDP Based DNS Queries
 When the DNS query is performed using UDP, Consul will truncate the results
--- a/website/source/docs/commands/connect.html.md
+++ b/website/source/docs/commands/connect.html.md
@ -0,0 +1,43 @@
 ---
 layout: "docs"
 page_title: "Commands: Connect"
 sidebar_current: "docs-commands-connect"
 ---
 # Consul Connect
 Command: `consul connect`
 The `connect` command is used to interact with Connect
 [Connect](/docs/connect/intentions.html) subsystems. It exposes commands for
 running the built-in mTLS proxy and viewing/updating the Certificate Authority
 (CA) configuration. This command is available in Consul 1.2 and later.
 ## Usage
 Usage: `consul connect <subcommand>`
 For the exact documentation for your Consul version, run `consul connect -h` to view
 the complete list of subcommands.
 ```text
 Usage: consul connect <subcommand> [options] [args]
  This command has subcommands for interacting with Consul Connect.
  Here are some simple examples, and more detailed examples are available
  in the subcommands or the documentation.
  Run the built-in Connect mTLS proxy
      $ consul connect proxy
  For more examples, ask for subcommand help or view the documentation.
 Subcommands:
    ca       Interact with the Consul Connect Certificate Authority (CA)
    proxy    Runs a Consul Connect proxy
 ```
 For more information, examples, and usage about a subcommand, click on the name
 of the subcommand in the sidebar.
--- a/website/source/docs/commands/connect/ca.html.md.erb
+++ b/website/source/docs/commands/connect/ca.html.md.erb
@ -0,0 +1,91 @@
 ---
 layout: "docs"
 page_title: "Commands: Connect CA"
 sidebar_current: "docs-commands-connect-ca"
 description: >
  The connect CA subcommand is used to view and modify the Connect Certificate
  Authority (CA) configuration.
 ---
 # Consul Connect Certificate Authority (CA)
 Command: `consul connect ca`
 The CA connect command is used to interact with Consul Connect's Certificate Authority
 subsystem. The command can be used to view or modify the current CA configuration. See the
 [Connect CA Guide](/docs/guides/connect-ca.html) for more information.
 ```text
 Usage: consul connect ca <subcommand> [options] [args]
  This command has subcommands for interacting with Consul Connect's
  Certificate Authority (CA).
  Here are some simple examples, and more detailed examples are available
  in the subcommands or the documentation.
  Get the configuration:
      $ consul connect ca get-config
  Update the configuration:
      $ consul connect ca set-config -config-file ca.json
  For more examples, ask for subcommand help or view the documentation.
 Subcommands:
    get-config    Display the current Connect Certificate Authority (CA) configuration
    set-config    Modify the current Connect CA configuration
 ```
 ## get-config
 This command displays the current CA configuration.
 Usage: `consul connect ca get-config [options]`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 <%= partial "docs/commands/http_api_options_server" %>
 The output looks like this:
 ```
 {
 	"Provider": "consul",
 	"Config": {
 		"PrivateKey": null,
 		"RootCert": null,
 		"RotationPeriod": "2160h"
 	},
 	"CreateIndex": 5,
 	"ModifyIndex": 197
 }
 ```
 ## set-config
 Modifies the current CA configuration. If this results in a new root certificate
 being used, the [Root Rotation](/docs/guides/connect-ca.html#rotation) process 
 will be triggered.
 Usage: `consul connect ca set-config [options]`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 <%= partial "docs/commands/http_api_options_server" %>
 #### Command Options
 * `-config-file` - (required) Specifies a JSON-formatted file to use for the new configuration.
 The output looks like this:
 ```
 Configuration updated!
 ```
 The return code will indicate success or failure.
--- a/website/source/docs/commands/connect/proxy.html.md.erb
+++ b/website/source/docs/commands/connect/proxy.html.md.erb
@ -0,0 +1,82 @@
 ---
 layout: "docs"
 page_title: "Commands: Connect Proxy"
 sidebar_current: "docs-commands-connect-proxy"
 description: >
  The connect proxy subcommand is used to run the built-in mTLS proxy for Connect.
 ---
 # Consul Connect Proxy
 Command: `consul connect proxy`
 The connect proxy command is used to run Consul's built-in mTLS proxy for
 use with Connect. This can be used in production to enable a Connect-unaware
 application to accept and establish Connect-based connections. This proxy
 can also be used in development to establish Connect-based connections.
 ## Usage
 Usage: `consul connect proxy [options]`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 <%= partial "docs/commands/http_api_options_server" %>
 #### Proxy Options
 * `-service` - Name of the service this proxy is representing. This service
  doesn't need to actually exist in the Consul catalog, but proper ACL
  permissions (`service:write`) are required.
 * `-upstream` - Upstream service to support connecting to. The format should be
  'name:addr', such as 'db:8181'. This will make 'db' available on port 8181.
  When a regular TCP connection is made to port 8181, the proxy will service
  discover "db" and establish a Connect mTLS connection identifying as
  the `-service` value. This flag can be repeated multiple times.
 * `-listen` - Address to listen for inbound connections to the proxied service.
  Must be specified with -service and -service-addr. If this isn't specified,
  an inbound listener is not started.
 * `-service-addr` - Address of the local service to proxy. Required for
  `-listen`.
 * `-register` - Self-register with the local Consul agent, making this
  proxy available as Connect-capable service in the catalog. This is only
  useful with `-listen`.
 * `-register-id` - Optional ID suffix for the service when `-register` is set
  to disambiguate the service ID. By default the service ID is "<service>-proxy"
  where `<service>` is the `-service` value.
 * `-log-level` - Specifies the log level.
 * `-pprof-addr` - Enable debugging via pprof. Providing a host:port (or just ':port')
  enables profiling HTTP endpoints on that address.
 * `-proxy-id` - The proxy's ID on the local agent. This is only useful to
  test the managed proxy mode.
 ## Examples
 The example below shows how to start a local proxy for establishing outbound
 connections to "db" representing the frontend service. Once running, any
 process that creates a TCP connection to the specified port (8181) will
 establish a mutual TLS connection to "db" identified as "frontend".
 ```text
 $ consul connect proxy -service frontend -upstream db:8181
 ```
 The next example starts a local proxy that also accepts inbound connections
 on port 8443, authorizes the connection, then proxies it to port 8080:
 ```text
 $ consul connect proxy \
    -service frontend \
    -service-addr 127.0.0.1:8080 \
    -listen ':8443'
 ```
--- a/website/source/docs/commands/intention.html.md
+++ b/website/source/docs/commands/intention.html.md
@ -0,0 +1,54 @@
 ---
 layout: "docs"
 page_title: "Commands: Intention"
 sidebar_current: "docs-commands-intention"
 ---
 # Consul Intention
 Command: `consul intention`
 The `intention` command is used to interact with Connect
 [intentions](/docs/connect/intentions.html). It exposes commands for
 creating, updating, reading, deleting, checking, and managing intentions.
 This command is available in Consul 1.2 and later.
 Intentions may also be managed via the [HTTP API](/api/connect/intentions.html).
 ## Usage
 Usage: `consul intention <subcommand>`
 For the exact documentation for your Consul version, run `consul intention -h` to view
 the complete list of subcommands.
 ```text
 Usage: consul intention <subcommand> [options] [args]
  ...
 Subcommands:
    check     Check whether a connection between two services is allowed.
    create    Create intentions for service connections.
    delete    Delete an intention.
    get       Show information about an intention.
    match     Show intentions that match a source or destination.
 ```
 For more information, examples, and usage about a subcommand, click on the name
 of the subcommand in the sidebar.
 ## Basic Examples
 Create an intention to allow "web" to talk to "db":
    $ consul intention create web db
 Test whether a "web" is allowed to connect to "db":
    $ consul intention check web db
 Find all intentions for communicating to the "db" service:
    $ consul intention match db
--- a/website/source/docs/commands/intention/check.html.md.erb
+++ b/website/source/docs/commands/intention/check.html.md.erb
@ -0,0 +1,37 @@
 ---
 layout: "docs"
 page_title: "Commands: Intention Check"
 sidebar_current: "docs-commands-intention-check"
 ---
 # Consul Intention Check
 Command: `consul intention check`
 The `intention check` command checks whether a connection attempt between
 two services would be authorized given the current set of intentions and
 Consul configuration.
 This command requires less ACL permissions than other intention-related
 tasks because no information about the intention is revealed. Therefore,
 callers only need to have `service:read` access for the destination. Richer
 commands like [match](/docs/commands/intention/match.html) require full
 intention read permissions and don't evaluate the result.
 ## Usage
 Usage: `consul intention check [options] SRC DST`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 ## Examples
 ```text
 $ consul intention check web db
 Denied
 $ consul intention check web billing
 Allowed
 ```
--- a/website/source/docs/commands/intention/create.html.md.erb
+++ b/website/source/docs/commands/intention/create.html.md.erb
@ -0,0 +1,51 @@
 ---
 layout: "docs"
 page_title: "Commands: Intention Create"
 sidebar_current: "docs-commands-intention-create"
 ---
 # Consul Intention Create
 Command: `consul intention create`
 The `intention create` command creates or updates an intention.
 ## Usage
 Usage: `consul intention create [options] SRC DST`
 Usage: `consul intention create [options] -f FILE...`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 #### Intention Create Options
 * `-allow` - Set the action to "allow" for intentions. This is the default.
 * `-deny` - Set the action to "deny" for intentions. This cannot be specified
  with `-allow`.
 * `-file` - Read intention data one or more files specified by the command
  line arguments, instead of source/destination pairs.
 * `-meta key=value` - Specify arbitrary KV metadata to associate with the
  intention.
 * `-replace` - Replace any matching intention. The replacement is done
  atomically per intention.
 ## Examples
 Create an intention `web => db`:
    $ consul intention create web db
 Create intentions from a set of files:
    $ consul intention create -file one.json two.json
 Create intentions from a directory using shell expansion:
    $ consul intention create -file intentions/*.json
--- a/website/source/docs/commands/intention/delete.html.md.erb
+++ b/website/source/docs/commands/intention/delete.html.md.erb
@ -0,0 +1,36 @@
 ---
 layout: "docs"
 page_title: "Commands: Intention Delete"
 sidebar_current: "docs-commands-intention-delete"
 ---
 # Consul Intention Delete
 Command: `consul intention delete`
 The `intention delete` command deletes a matching intention.
 ## Usage
 Usage:
  * `consul intention delete [options] SRC DST`
  * `consul intention delete [options] ID`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 ## Examples
 Delete an intention from "web" to "db" with any action:
 ```text
 $ consul intention delete web db
 ```
 Delete an intention by unique ID:
 ```text
 $ consul intention delete 4ffed935-439c-695d-4f51-f4fc0b12a7a7
 ```
--- a/website/source/docs/commands/intention/get.html.md.erb
+++ b/website/source/docs/commands/intention/get.html.md.erb
@ -0,0 +1,33 @@
 ---
 layout: "docs"
 page_title: "Commands: Intention Get"
 sidebar_current: "docs-commands-intention-get"
 ---
 # Consul Intention Get
 Command: `consul intention get`
 The `intention get` command shows a single intention.
 ## Usage
 Usage:
  * `consul intention get [options] SRC DST`
  * `consul intention get [options] ID`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 ## Examples
 ```text
 $ consul intention get web db
 Source:       web
 Destination:  db
 Action:       deny
 ID:           20edfa56-9cd4-51db-8c22-db09fdec61ef
 Created At:   Thursday, 24-May-18 17:07:49 PDT
 ```
--- a/website/source/docs/commands/intention/match.html.md.erb
+++ b/website/source/docs/commands/intention/match.html.md.erb
@ -0,0 +1,38 @@
 ---
 layout: "docs"
 page_title: "Commands: Intention Match"
 sidebar_current: "docs-commands-intention-match"
 ---
 # Consul Intention Match
 Command: `consul intention match`
 The `intention match` command shows the list of intentions that match
 a given source or destination. The list of intentions is listed in evaluation
 order: the first intention that matches a request would be evaluated.
 The [check](/docs/commands/intention/check.html) command can be used to
 check whether a connection would be authorized between any two services.
 ## Usage
 Usage: `consul intention match [options] SRC_OR_DST`
 #### API Options
 <%= partial "docs/commands/http_api_options_client" %>
 #### Intention Match Options
 * `-destination` - Match by destination.
 * `-source` - Match by source.
 ## Examples
 ```text
 $ consul intention match -source web
 web => db (deny)
 web => * (allow)
 ```
--- a/website/source/docs/connect/ca.html.md
+++ b/website/source/docs/connect/ca.html.md
@ -0,0 +1,11 @@
 ---
 layout: "docs"
 page_title: "Connect - Certificate Management"
 sidebar_current: "docs-connect-ca"
 description: |-
  TODO
 ---
 # Connect Certificate Management
 TODO
--- a/website/source/docs/connect/configuration.html.md
+++ b/website/source/docs/connect/configuration.html.md
@ -0,0 +1,41 @@
 ---
 layout: "docs"
 page_title: "Connect - Configuration"
 sidebar_current: "docs-connect-config"
 description: |-
  A Connect-aware proxy enables unmodified applications to use Connect. A per-service proxy sidecar transparently handles inbound and outbound service connections, automatically wrapping and verifying TLS connections.
 ---
 # Connect Configuration
 There are many configuration options exposed for Connect. The only option
 that must be set is the "enabled" option on Consul Servers to enable Connect.
 All other configurations are optional and have reasonable defaults.
 ## Enable Connect on the Cluster
 The first step to use Connect is to enable Connect for your Consul
 cluster. By default, Connect is disabled. Enabling Connect requires changing
 the configuration of only your Consul _servers_ (not client agents). To enable
 Connect, add the following to a new or existing
 [server configuration file](/docs/agent/options.html). In HCL:
 ```hcl
 connect {
  enabled = true
 }
 ```
 This will enable Connect and configure your Consul cluster to use the
 built-in certificate authority for creating and managing certificates.
 You may also configure Consul to use an external
 [certificate management system](/docs/connect/ca.html), such as
 [Vault](https://vaultproject.io).
 No agent-wide configuration is necessary for non-server agents. Services
 and proxies may always register with Connect settings, but they will fail to
 retrieve or verify any TLS certificates. This causes all Connect-based
 connection attempts to fail until Connect is enabled on the server agents.
 -> **Note:** Connect is enabled by default when running Consul in
 dev mode with `consul agent -dev`.
--- a/website/source/docs/connect/dev.html.md
+++ b/website/source/docs/connect/dev.html.md
@ -0,0 +1,67 @@
 ---
 layout: "docs"
 page_title: "Connect - Development and Debugging"
 sidebar_current: "docs-connect-dev"
 description: |-
  It is often necessary to connect to a service for development or debugging. If a service only exposes a Connect listener, then we need a way to establish a mutual TLS connection to the service. The `consul connect proxy` command can be used for this task on any machine with access to a Consul agent (local or remote).
 ---
 # Developing and Debugging Connect Services
 It is often necessary to connect to a service for development or debugging.
 If a service only exposes a Connect listener, then we need a way to establish
 a mutual TLS connection to the service. The
 [`consul connect proxy` command](/docs/commands/connect/proxy.html) can be used
 for this task on any machine with access to a Consul agent (local or remote).
 Restricting access to services only via Connect ensures that the only way to
 connect to a service is through valid authorization of the
 [intentions](/docs/connect/intentions.html). This can extend to developers
 and operators, too.
 ## Connecting to Connect-only Services
 As an example, let's assume that we have a PostgreSQL database running that
 we want to connect to via `psql`, but the only non-loopback listener is
 via Connect. Let's also assume that we have an ACL token to identify as
 `operator-mitchellh`. We can start a local proxy:
 ```sh
 $ consul connect proxy \
  -service operator-mitchellh \
  -upstream postgresql:8181
 ```
 This works because the source `-service` does not need to be registered
 in the local Consul catalog. However, to retrieve a valid identifying
 certificate, the ACL token must have `service:write` permissions. This
 can be used as a sort of "virtual service" to represent people, too. In
 the example above, the proxy is identifying as `operator-mitchellh`.
 With the proxy running, we can now use `psql` like normal:
 ```
 $ psql -h 127.0.0.1 -p 8181 -U mitchellh mydb
 >
 ```
 This `psql` session is now happening through our local proxy via an
 authorized mutual TLS connection to the PostgreSQL service in our Consul
 catalog.
 ### Masquerading as a Service
 You can also easily masquerade as any source service by setting the
 `-service` value to any service. Note that the proper ACL permissions are
 required to perform this task.
 For example, if you have an ACL token that allows `service:write` for
 `web` and you want to connect to the `postgresql` service as "web", you
 can start a proxy like so:
 ```sh
 $ consul connect proxy \
  -service web \
  -upstream postgresql:8181
 ```
--- a/website/source/docs/connect/index.html.md
+++ b/website/source/docs/connect/index.html.md
@ -0,0 +1,43 @@
 ---
 layout: "docs"
 page_title: "Connect (Service Segmentation)"
 sidebar_current: "docs-connect-index"
 description: |-
  Consul Connect provides service-to-service connection authorization and encryption using mutual TLS.
 ---
 # Connect
 Consul Connect provides service-to-service connection authorization
 and encryption using mutual TLS. Applications can use
 [sidecar proxies](/docs/connect/proxies.html)
 to automatically establish TLS connections for inbound and outbound connections
 without being aware of Connect at all. Applications may also
 [natively integrate with Connect](/docs/connect/native.html)
 for optimal performance and security.
 ## How it Works
 TODO
 ## Eliminating East-West Firewalls
 East-west firewalls are the typical tool for network security in a static world.
 East-west is the transfer of data from server to server within a datacenter,
 versus North-south traffic which describes end user to server communications.
 These firewalls wrap services with ingress/egress policies. This perimeter-based
 approach is difficult to scale in a dynamic world with dozens or hundreds of
 services or where machines may be frequently created or destroyed. Firewalls
 create a sprawl of rules for each service instance that quickly becomes
 overly difficult to maintain.
 Service security in a dynamic world is best solved through service-to-service
 authentication and authorization. Instead of IP-based network security,
 services can be deployed to low-trust networks and rely on service-identity
 based security over in-transit data encryption.
 Connect enables service segmentation by securing service-to-service
 communications through mutual TLS and transparent proxying on zero-trust
 networks. This allows direct service communication without relying on firewalls
 for east-west traffic security.
--- a/website/source/docs/connect/intentions.html.md
+++ b/website/source/docs/connect/intentions.html.md
@ -0,0 +1,134 @@
 ---
 layout: "docs"
 page_title: "Connect - Intentions"
 sidebar_current: "docs-connect-intentions"
 description: |-
  Intentions define access control for services via Connect and are used to control which services may establish connections. Intentions can be managed via the API, CLI, or UI.
 ---
 # Intentions
 Intentions define access control for services via Connect and are used
 to control which services may establish connections. Intentions can be
 managed via the API, CLI, or UI.
 Intentions are enforced by the [proxy](/docs/connect/proxies.html)
 or [natively integrated application](/docs/connect/native.html) on
 inbound connections. After verifying the TLS client certificate, the
 [authorize API endpoint](#) is called which verifies the connection
 is allowed by testing the intentions. If authorize returns false the
 connection must be terminated.
 The default intention behavior is defined by the default
 [ACL policy](/docs/guides/acls.html). If the default ACL policy is "allow all",
 then all Connect connections are allowed by deafult. If the default ACL policy
 is "deny all", then all Connect connections are denied by default.
 ## Intention Basics
 Intentions can be managed via the
 [API](#),
 [CLI](#),
 or UI. Please see the respective documentation for each for full details
 on options, flags, etc.
 Below is an example of a basic intention to show the basic attributes
 of an intention. The full data model of an intention can be found in the
 [API documentation](#).
 ```
 $ consul intention create -deny web db
 Created: web => db (deny)
 ```
 The intention above is a deny intention with a source of "web" and
 destination of "db". This says that connections from web to db are not
 allowed and the connection will be rejected.
 ### Wildcard Intentions
 An intention source or destination may also be the special wildcard
 value `*`. This matches _any_ value and is used as a catch-all. Example:
 ```
 $ consul intention create -deny web '*'
 Created: web => * (deny)
 ```
 This example says that the "web" service cannot connect to _any_ service.
 ### Metadata
 Arbitrary string key/value data may be associated with intentions. This
 is unused by Consul but can be used by external systems or for visibility
 in the UI.
 ```
 $ consul intention create \
  -deny \
  -meta description='Hello there' \
  web db
 ...
 $ consul intention get web db
 Source:             web
 Destination:        db
 Action:             deny
 ID:                 31449e02-c787-f7f4-aa92-72b5d9b0d9ec
 Meta[description]:  Hello there
 Created At:         Friday, 25-May-18 02:07:51 CEST
 ```
 ## Precedence and Match Order
 Intentions are matched in an implicit order based on specificity, preferring
 deny over allow. The full precedence table is shown below and is evaluated
 top to bottom.
 TODO
 ## Intention Management Permissions
 Intention management can be protected by [ACLs](/docs/guides/acls.html).
 Permissions for intentions are _destination-oriented_, meaning the ACLs
 for managing intentions are looked up based on the destination value
 of the intention, not the source.
 Intention permissions are first inherited from `service` management permissions.
 For example, the ACL below would allow _read_ access to intentions with a
 destination starting with "web":
 ```hcl
 service "web" {
  policy = "read"
 }
 ```
 ACLs may also specify service-specific intention permissions. In the example
 below, the ACL token may register a "web"-prefixed service but _may not_ read or write
 intentions:
 ```hcl
 service "web" {
  policy = "read"
  intention = "deny"
 }
 ```
 ## Performance and Intention Updates
 The intentions for services registered with a Consul agent are cached
 locally on that agent. They are then updated via a background blocking query
 against the Consul servers.
 Connect connection attempts require only local agent
 communication for authorization and generally impose only impose microseconds
 of latency to the connection. All actions in the data path of connections
 require only local data to ensure minimal performance overhead.
 Updates to intentions are propagated nearly instantly to agents since agents
 maintain a continuous blocking query in the background for intention updates
 for registered services.
 Because all the intention data is cached locally, the agents can fail open.
 Even if the agents are severed completely from the Consul servers, inbound
 connection authorization continues to work for a configured amount of time.
--- a/website/source/docs/connect/native.html.md
+++ b/website/source/docs/connect/native.html.md
@ -0,0 +1,11 @@
 ---
 layout: "docs"
 page_title: "Connect - Native Application Integration"
 sidebar_current: "docs-connect-native"
 description: |-
  TODO
 ---
 # Connect-Native App Integration
 TODO
--- a/website/source/docs/connect/proxies.html.md
+++ b/website/source/docs/connect/proxies.html.md
@ -0,0 +1,176 @@
 ---
 layout: "docs"
 page_title: "Connect - Proxies"
 sidebar_current: "docs-connect-proxies"
 description: |-
  A Connect-aware proxy enables unmodified applications to use Connect. A per-service proxy sidecar transparently handles inbound and outbound service connections, automatically wrapping and verifying TLS connections.
 ---
 # Connect Proxies
 A Connect-aware proxy enables unmodified applications to use Connect.
 A per-service proxy sidecar transparently handles inbound and outbound
 service connections, automatically wrapping and verifying TLS connections.
 When a proxy is used, the actual service being proxied should only accept
 connections on a loopback address. This requires all external connections
 to be established via the Connect protocol to provide authentication and
 authorization.
 Consul supports both _managed_ and _unmanaged_ proxies. A managed proxy
 is started, configured, and stopped by Consul. An unmanaged proxy is the
 responsibility of the user, like any other Consul service.
 ## Managed Proxies
 Managed proxies are started, configured, and stopped by Consul. They are
 enabled via basic configurations within the
 [service definition](/docs/agent/services.html).
 This is the easiest way to start a proxy and allows Consul users to begin
 using Connect with only a small configuration change.
 Managed proxies also offer the best security. Managed proxies are given
 a unique proxy-specific ACL token that allows read-only access to Connect
 information for the specific service the proxy is representing. This ACL
 token is more restrictive than can be currently expressed manually in
 an ACL policy.
 The default managed proxy is a basic proxy built-in to Consul and written
 in Go. Having a basic built-in proxy allows Consul to have a sane default
 with performance that is good enough for most workloads. In some basic
 benchmarks, the service-to-service communication over the built-in proxy
 could sustain 5 Gbps with a per-hop latency of less than X microseconds. Therefore,
 the performance impact of even the basic built-in proxy is minimal.
 Consul will be
 integrating with advanced proxies in the near future to support more complex
 configurations and higher performance. The configuration below is all for
 the built-in proxy.
 ### Minimal Configuration
 Managed proxies are configured within a
 [service definition](/docs/agent/services.html). The simplest possible
 managed proxy configuration is an empty configuration. This enables the
 default managed proxy and starts a listener for that service:
 ```json
 {
  "service": "redis",
  "connect": { "proxy": {} }
 }
 ```
 The listener is started on random port within the configured Connect
 port range. It can be discovered using the
 [DNS interface](/docs/agent/dns.html#connect-capable-service-lookups)
 or
 [Catalog API](#).
 In most cases, service-to-service communication is established by
 a proxy configured with upstreams (described below), which handle the
 discovery transparently.
 ### Upstream Configuration
 To transparently discover and establish Connect-based connections to
 dependencies, they must be configured with a static port on the managed
 proxy configuration:
 ```json
 {
  "service": "web",
  "connect": {
    "proxy": {
      "config": {
        "upstreams": [{
            "destination_name": "redis",
            "local_bind_port": 1234
        }]
      }
    }
  }
 }
 ```
 In the example above,
 "redis" is configured as an upstream with static port 1234 for service "web".
 When a TCP connection is established on port 1234, the proxy
 will find Connect-compatible "redis" services via Consul service discovery
 and establish a TLS connection identifying as "web".
 ~> **Security:** Any application that can communicate to the configured
 static port will be able to masquerade as the source service ("web" in the
 example above). You must either trust any loopback access on that port or
 use namespacing techniques provided by your operating system.
 ### Prepared Query Upstreams
 The upstream destination may also be a
 [prepared query](/api/query.html).
 This allows complex service discovery behavior such as connecting to
 the nearest neighbor or filtering by tags.
 For example, given a prepared query named "nearest-redis" that is
 configured to route to the nearest Redis instance, an upstream can be
 configured to route to this query. In the example below, any TCP connection
 to port 1234 will attempt a Connect-based connection to the nearest Redis
 service.
 ```json
 {
  "service": "web",
  "connect": {
    "proxy": {
      "config": {
        "upstreams": [{
            "destination_name": "nearest-redis",
 			"destination_type": "prepared_query",
            "local_bind_port": 1234
        }]
      }
    }
  }
 }
 ```
 ### Dynamic Upstreams
 If an application requires dynamic dependencies that are only available
 at runtime, it must currently [natively integrate](/docs/connect/native.html)
 with Connect. After natively integrating, the HTTP API or
 [DNS interface](/docs/agent/dns.html#connect-capable-service-lookups)
 can be used.
 ## Unmanaged Proxies
 Unmanaged proxies are regular Consul services that are registered as a
 proxy type and declare the service they represent. The proxy process must
 be started, configured, and stopped manually by some external process such
 as an operator or scheduler.
 To declare a service as a proxy, the service definition must contain
 at least two additional fields:
  * `Kind` (string) must be set to `connect-proxy`. This declares that the
    service is a proxy type.
  * `ProxyDestination` (string) must be set to the service that this proxy
    is representing.
  * `Port` must be set so that other Connect services can discover the exact
    address for connections. `Address` is optional if the service is being
    registered against an agent, since it'll inherit the node address.
 Example:
 ```json
 {
  "Name": "redis-proxy",
  "Kind": "connect-proxy",
  "ProxyDestination": "redis",
  "Port": 8181
 }
 ```
 With this service registered, any Connect proxies searching for a
 Connect-capable endpoint for "redis" will find this proxy.
--- a/website/source/docs/connect/proxies/integrate.html.md
+++ b/website/source/docs/connect/proxies/integrate.html.md
@ -0,0 +1,63 @@
 ---
 layout: "docs"
 page_title: "Connect - Proxy Integration"
 sidebar_current: "docs-connect-proxies-integrate"
 description: |-
  A Connect-aware proxy enables unmodified applications to use Connect. A per-service proxy sidecar transparently handles inbound and outbound service connections, automatically wrapping and verifying TLS connections.
 ---
 # Connect Custom Proxy Integration
 Any proxy can be extended to support Connect. Consul ships with a built-in
 proxy for a good development and out of the box experience, but understand
 that production users will require other proxy solutions.
 A proxy must serve one or both of the following two roles: it must accept
 inbound connections or establish outbound connections identified as a
 particular service. One or both of these may be implemented depending on
 the case, although generally both must be supported.
 ## Accepting Inbound Connections
 For inbound connections, the proxy must accept TLS connections on some port.
 The certificate served should be created by the
 [`/v1/agent/connect/ca/leaf/`](/api/agent/connect.html) API endpoint.
 The client certificate should be validated against the root certificates
 provided by the
 [`/v1/agent/connect/ca/roots`](/api/agent/connect.html) endpoint.
 After validating the client certificate from the caller, the proxy should
 call the
 [`/v1/agent/connect/authorize`](/api/agent/connect.html) endpoint to
 authorize the connection.
 All of these API endpoints operate on agent-local data that is updated
 in the background. The leaf and roots should be updated in the background
 by the proxy, but the authorize endpoint is expected to be called in the
 connection path. The endpoints introduce only microseconds of additional
 latency on the connection.
 The leaf and root cert endpoints support blocking queries. These should be
 used if possible to get near-immediate updates for root cert rotations,
 leaf expiry, etc.
 ## Establishing Outbound Connections
 For outbound connections, the proxy should communicate to a
 Connect-capable endpoint for a service and provide a client certificate
 from the
 [`/v1/agent/connect/ca/leaf/`](/api/agent/connect.html) API endpoint.
 The certificate served by the remote endpoint can be verified against the
 root certificates from the
 [`/v1/agent/connect/ca/roots`](/api/agent/connect.html) endpoint.
 ## Managed Mode Support
 If the proxy could run as a managed proxy, then it should accept the following
 two environment variables that Consul populates on process startup. These
 are both required to make the necessary API requests for configuration.
  * `CONSUL_PROXY_TOKEN` - The ACL token to use for all requests to proxy-related
    API endpoints.
  * `CONSUL_PROXY_ID` - The service ID for requesting configuration for the
    proxy from [`/v1/agent/connect/proxy/`](/api/agent/connect.html).
--- a/website/source/docs/connect/security.html.md
+++ b/website/source/docs/connect/security.html.md
@ -0,0 +1,96 @@
 ---
 layout: "docs"
 page_title: "Connect - Security"
 sidebar_current: "docs-connect-security"
 description: |-
  TODO
 ---
 # Connect Security
 Connect enables secure service-to-service communication over mutual TLS. This
 provides both in-transit data encryption as well as authorization. This page
 will document how to secure Connect. For a full security model reference,
 see the dedicated [Consul security model](/docs/internals/security.html) page.
 Connect will function in any Consul configuration. However, unless the checklist
 below is satisfied, Connect is not providing the security guarantees it was
 built for. The checklist below can be incrementally adopted towards full
 security if you prefer to operate in less secure models initially.
 ~> **Warning**: The checklist below should not be considered exhaustive. Please
 read and understand the [Consul security model](/docs/internals/security.html)
 in depth to assess whether your deployment satisfies the security requirements
 of Consul.
 ## Checklist
 ### ACLs Enabled with Default Deny
 Consul must be configured to use ACLs with a default deny policy. This forces
 all requests to have explicit anonymous access or provide an ACL token. The
 configuration also forces all service-to-service communication to be explicitly
 whitelisted via an allow [intention](/docs/connect/intentions.html).
 To learn how to enable ACLs, please see the
 [guide on ACLs](/docs/guides/acl.html).
 **If ACLs are enabled but are in default allow mode**, then services will be
 able to communicate by default. Additionally, if a proper anonymous token
 is not configured, this may allow anyone to edit intentions. We do not recommend
 this. **If ACLs are not enabled**, deny intentions will still be enforced, but anyone
 may edit intentions. This renders the security of the created intentions
 effectively useless.
 ### TCP and UDP Encryption Enabled
 TCP and UDP encryption must be enabled to prevent plaintext communication
 between Consul agents. At a minimum, `verify_outgoing` should be enabled
 to verify server authenticity with each server having a unique TLS certificate.
 `verify_incoming` provides additional agent verification, but doesn't directly
 affect Connect since requests must also always contain a valid ACL token.
 Clients calling Consul APIs should be forced over encrypted connections.
 See the [Consul agent encryption page](/docs/agent/encryption.html) to
 learn more about configuring agent encryption.
 **If encryption is not enabled**, a malicious actor can sniff network
 traffic or perform a man-in-the-middle attack to steal ACL tokens, always
 authorize connections, etc.
 ### Prevent Unauthorized Access to the Config and Data Directories
 The configuration and data directories of the Consul agent on both
 clients and servers should be protected from unauthorized access. This
 protection must be done outside of Consul via access control systems provided
 by your target operating system.
 The [full Consul security model](/docs/internals/security.html) explains the
 risk of unauthorized access for both client agents and server agents. In
 general, the blast radius of unauthorized access for client agent directories
 is much smaller than servers. However, both must be protected against
 unauthorized access.
 ### Prevent Non-Connect Traffic to Services
 For services that are using
 [proxies](/docs/connect/proxies.html)
 (are not [natively integrated](/docs/connect/native.html)),
 network access via their unencrypted listeners must be restricted
 to only the proxy. This requires at a minimum restricting the listener
 to bind to loopback only. More complex solutions may involve using
 network namespacing techniques provided by the underlying operating system.
 For scenarios where multiple services are running on the same machine
 without isolation, these services must all be trusted. We call this the
 **trusted multi-tenenacy** deployment model. Any service could theoretically
 connect to any other service via the loopback listener, bypassing Connect
 completely. In this scenario, all services must be trusted _or_ isolation
 mechanisms must be used.
 For developer or operator access to a service, we recommend
 using a local Connect proxy. This is documented in the
 [development and debugging guide](/docs/connect/dev.html).
 **If non-proxy traffic can communicate with the service**, this traffic
 will not be encrypted or authorized via Connect.
--- a/website/source/intro/getting-started/connect.html.md
+++ b/website/source/intro/getting-started/connect.html.md
@ -0,0 +1,192 @@
 ---
 layout: "intro"
 page_title: "Consul Connect"
 sidebar_current: "gettingstarted-connect"
 description: |-
  Connect is a feature of Consul that provides service-to-service connection authorization and encryption using mutual TLS. This ensures that all service communication in your datacenter is encrypted and that the rules of what services can communicate is centrally managed with Consul.
 ---
 # Connect
 We've now registered our first service with Consul and we've shown how you
 can use the HTTP API or DNS interface to query the address and directly connect
 to that service. Consul also provides a feature called **Connect** for
 automatically connecting via an encrypted TLS connection and authorizing
 which services are allowed to connect to each other.
 Applications do not need to be modified at all to use Connect.
 [Sidecar proxies](/docs/connect/proxies.html) can be used
 to automatically establish TLS connections for inbound and outbound connections
 without being aware of Connect at all. Applications may also
 [natively integrate with Connect](/docs/connect/native.html)
 for optimal performance and security.
 -> **Security note:** The getting started guide will show Connect features
 and focus on ease of use with a dev-mode agent. We will _not setup_ Connect in a
 production-recommended secure way. Please read the Connect reference
 documentation on security best practices to understand the tradeoffs.
 ## Starting a Connect-unaware Service
 Let's begin by starting a service that is unaware of Connect all. To
 keep it simple, let's just use `socat` to start a basic echo service. This
 service will accept TCP connections and echo back any data sent to it. If
 `socat` isn't installed on your machine, it should be easily available via
 a package manager.
 ```sh
 $ socat -v tcp-l:8181,fork exec:"/bin/cat"
 ```
 You can verify it is working by using `nc` to connect directly to it. Once
 connected, type some text and press enter. The text you typed should be
 echoed back:
 ```
 $ nc 127.0.0.1 8181
 hello
 hello
 echo
 echo
 ```
 `socat` is a decades-old Unix utility and our process is configured to
 only accept a basic TCP connection. It has no concept of encryption, the
 TLS protocol, etc. This can be representative of an existing service in
 your datacenter such as a database, backend web service, etc.
 ## Registering the Service with Consul and Connect
 Next, let's register the service with Consul. We'll do this by writing
 a new service definition. This is the same as the previous step in the
 getting started guide, except this time we'll also configure Connect.
 ```sh
 $ cat <<EOF | sudo tee /etc/consul.d/socat.json
 {
  "service": {
    "name": "socat",
    "port": 8181,
    "connect": { "proxy": {} }
  }
 }
 EOF
 ```
 After saving this, run `consul reload` or send a `SIGHUP` signal to Consul
 so it reads the new configuration.
 Notice the only difference is the line starting with `"connect"`. The
 existence of this empty configuration notifies Consul to manage a
 proxy process for this process.
 The proxy process represents that specific service. It accepts inbound
 connections on a dynamically allocated port, verifies and authorizes the TLS
 connection, and proxies back a standard TCP connection to the process.
 ## Connecting to the Service
 Next, let's connect to the service. We'll first do this by using the
 `consul connect proxy` command directly. This command manually runs a local
 proxy that can represent a service. This is a useful tool for development
 since it'll let you masquerade as any service (that you have permissions for)
 and establish connections to other services via Connect.
 The command below starts a proxy representing a service "web". We request
 an upstream dependency of "socat" (the service we previously registered)
 on port 9191. With this configuration, all TCP connections to 9191 will
 perform service discovery for a Connect-capable "socat" endpoint and establish
 a mutual TLS connection identifying as the service "web".
 ```sh
 $ consul connect proxy -service web -upstream socat:9191
 ==> Consul Connect proxy starting...
    Configuration mode: Flags
               Service: web
              Upstream: socat => :9191
       Public listener: Disabled
 ...
 ```
 With that running, we can verify it works by establishing a connection:
 ```
 $ nc 127.0.0.1 9191
 hello
 hello
 ```
 **The connection between proxies is now encrypted and authorized.**
 We're now communicating to the "socat" service via a TLS connection.
 The local connections to/from the proxy are unencrypted, but in production
 these will be loopback-only connections. Any traffic in and out of the
 machine is always encrypted.
 ## Registering a Dependent Service
 We previously established a connection by directly running
 `consul connect proxy`. Realistically, services need to establish connections
 to dependencies over Connect. Let's register a service "web" that registers
 "socat" as an upstream dependency:
 ```sh
 $ cat <<EOF | sudo tee /etc/consul.d/web.json
 {
  "service": {
    "name": "web",
    "connect": {
      "proxy": {
        "config": {
          "upstreams": [{
             "destination_name": "db",
             "local_bind_port": 9191
          }]
        }
      }
    }
  }
 }
 EOF
 ```
 This configures a Consul-managed proxy for the service "web" that
 is listening on port 9191 to establish connects to "db" as "web". The
 "web" service should then use that local port to talk to the DB rather than
 directly attempting to connect.
 -> **Security note:** The Connect security model requires trusting
 loopback connections when proxies are in use. To further secure this,
 tools like network namespacing may be used.
 ## Controlling Access with Intentions
 Intentions are used to define which services may communicate. Our connections
 above succeeded because in a development mode agent, the ACL system is "allow
 all" by default.
 Let's insert a rule to deny access from web to socat:
 ```sh
 $ consul intention create -deny web db
 Created: web => socat (deny)
 ```
 With the proxy processes running that we setup previously, connection
 attempts now fail:
 ```sh
 $ nc 127.0.0.1 9191
 $
 ```
 Try deleting the intention (or updating it to allow) and attempting the
 connection again. Intentions allow services to be segmented via a centralized
 control plane (Consul). To learn more, read the reference documentation on
 [intentions](/docs/connect/intentions.html).
 ## Next Steps
 We've now configured a service on a single agent and used Connect for
 automatic connection authorization and encryption. This is a great feature
 highlight but let's explore the full value of Consul by [setting up our
 first cluster](/intro/getting-started/join.html)!
--- a/website/source/layouts/api.erb
+++ b/website/source/layouts/api.erb
@ -22,11 +22,25 @@
          <li<%= sidebar_current("api-agent-service") %>>
            <a href="/api/agent/service.html">Services</a>
          </li>
          <li<%= sidebar_current("api-agent-connect") %>>
            <a href="/api/agent/connect.html">Connect</a>
          </li>
        </ul>
      </li>
      <li<%= sidebar_current("api-catalog") %>>
        <a href="/api/catalog.html">Catalog</a>
      </li>
      <li<%= sidebar_current("api-connect") %>>
        <a href="/api/connect.html">Connect</a>
        <ul class="nav">
          <li<%= sidebar_current("api-connect-ca") %>>
            <a href="/api/connect/ca.html">Certificate Authority (CA)</a>
          </li>
          <li<%= sidebar_current("api-connect-intentions") %>>
            <a href="/api/connect/intentions.html">Intentions</a>
          </li>
        </ul>
      </li>
      <li<%= sidebar_current("api-coordinate") %>>
        <a href="/api/coordinate.html">Coordinates</a>
      </li>
--- a/website/source/layouts/docs.erb
+++ b/website/source/layouts/docs.erb
@ -70,6 +70,17 @@
              </li>
            </ul>
          </li>
          <li<%= sidebar_current("docs-commands-connect") %>>
            <a href="/docs/commands/connect.html">connect</a>
            <ul class="nav">
              <li<%= sidebar_current("docs-commands-connect-ca") %>>
                <a href="/docs/commands/connect/ca.html">ca</a>
              </li>
              <li<%= sidebar_current("docs-commands-connect-proxy") %>>
                <a href="/docs/commands/connect/proxy.html">proxy</a>
              </li>
            </ul>
          </li>
          <li<%= sidebar_current("docs-commands-event") %>>
            <a href="/docs/commands/event.html">event</a>
          </li>
@ -82,6 +93,27 @@
          <li<%= sidebar_current("docs-commands-info") %>>
            <a href="/docs/commands/info.html">info</a>
          </li>
          <li<%= sidebar_current("docs-commands-intention") %>>
            <a href="/docs/commands/intention.html">intention</a>
            <ul class="nav">
              <li<%= sidebar_current("docs-commands-intention-check") %>>
                <a href="/docs/commands/intention/check.html">check</a>
              </li>
              <li<%= sidebar_current("docs-commands-intention-create") %>>
                <a href="/docs/commands/intention/create.html">create</a>
              </li>
              <li<%= sidebar_current("docs-commands-intention-delete") %>>
                <a href="/docs/commands/intention/delete.html">delete</a>
              </li>
              <li<%= sidebar_current("docs-commands-intention-get") %>>
                <a href="/docs/commands/intention/get.html">get</a>
              </li>
              <li<%= sidebar_current("docs-commands-intention-match") %>>
                <a href="/docs/commands/intention/match.html">match</a>
              </li>
            </ul>
          </li>
          <li<%= sidebar_current("docs-commands-join") %>>
            <a href="/docs/commands/join.html">join</a>
          </li>
@ -216,6 +248,38 @@
        </ul>
      </li>
      <li<%= sidebar_current("docs-connect") %>>
        <a href="/docs/connect/index.html">Connect (Service Segmentation)</a>
        <ul class="nav">
          <li<%= sidebar_current("docs-connect-config") %>>
            <a href="/docs/connect/configuration.html">Configuration</a>
          </li>
          <li<%= sidebar_current("docs-connect-proxies") %>>
            <a href="/docs/connect/proxies.html">Proxies</a>
            <ul class="nav">
              <li<%= sidebar_current("docs-connect-proxies-integrate") %>>
                <a href="/docs/connect/proxies/integrate.html">Proxy Integration</a>
              </li>
            </ul>
          </li>
          <li<%= sidebar_current("docs-connect-intentions") %>>
            <a href="/docs/connect/intentions.html">Intentions</a>
          </li>
          <li<%= sidebar_current("docs-connect-ca") %>>
            <a href="/docs/connect/ca.html">Certificate Management</a>
          </li>
          <li<%= sidebar_current("docs-connect-native") %>>
            <a href="/docs/connect/native.html">Native App Integration</a>
          </li>
          <li<%= sidebar_current("docs-connect-dev") %>>
            <a href="/docs/connect/dev.html">Develop and Debug</a>
          </li>
          <li<%= sidebar_current("docs-connect-security") %>>
            <a href="/docs/connect/security.html">Security</a>
          </li>
        </ul>
      </li>
      <hr>
      <li<%= sidebar_current("docs-guides") %>>
--- a/website/source/layouts/intro.erb
+++ b/website/source/layouts/intro.erb
@ -47,6 +47,9 @@
          <li<%= sidebar_current("gettingstarted-services") %>>
            <a href="/intro/getting-started/services.html">Services</a>
          </li>
          <li<%= sidebar_current("gettingstarted-connect") %>>
            <a href="/intro/getting-started/connect.html">Connect</a>
          </li>
          <li<%= sidebar_current("gettingstarted-join") %>>
            <a href="/intro/getting-started/join.html">Consul Cluster</a>
          </li>