diff --git a/agent/agent_endpoint.go b/agent/agent_endpoint.go index 9092dbe48..b7be62f67 100644 --- a/agent/agent_endpoint.go +++ b/agent/agent_endpoint.go @@ -1480,8 +1480,7 @@ func (s *HTTPServer) AgentHost(resp http.ResponseWriter, req *http.Request) (int if err != nil { return nil, err } - // TODO(pearkes): Is agent:read appropriate here? There could be relatively - // sensitive information made available in this API + if rule != nil && !rule.OperatorRead() { return nil, acl.ErrPermissionDenied } diff --git a/command/acl/token/token.go b/command/acl/token/token.go index db222d45a..078c27e42 100644 --- a/command/acl/token/token.go +++ b/command/acl/token/token.go @@ -27,11 +27,30 @@ const synopsis = "Manage Consul's ACL Tokens" const help = ` Usage: consul acl token [options] [args] - This command has subcommands for managing Consul's ACL Policies. + This command has subcommands for managing Consul ACL tokens. Here are some simple examples, and more detailed examples are available in the subcommands or the documentation. - TODO - more docs + Create a new ACL Token: + + $ consul acl token create \ + -description "This is an example token" \ + -policy-id 06acc965 + List all tokens: + + $ consul acl token list + + Update a token: + + $ consul acl token update -id 986193 -description "WonderToken" + + Read a token with an accessor ID: + + $ consul acl token read -id 986193 + + Delete a token + + $ consul acl token delete -id 986193 For more examples, ask for subcommand help or view the documentation. ` diff --git a/website/source/docs/commands/debug.html.markdown.erb b/website/source/docs/commands/debug.html.markdown.erb index c210697be..2f1457b19 100644 --- a/website/source/docs/commands/debug.html.markdown.erb +++ b/website/source/docs/commands/debug.html.markdown.erb @@ -6,8 +6,6 @@ sidebar_current: "docs-commands-debug" # Consul Debug --> **1.4.0+:** This command is only available in Consul versions 1.4.0 and later. - Command: `consul debug` The `consul debug` command monitors a Consul agent for the specified period of diff --git a/website/source/docs/connect/index.html.md b/website/source/docs/connect/index.html.md index fecbe9796..de6828477 100644 --- a/website/source/docs/connect/index.html.md +++ b/website/source/docs/connect/index.html.md @@ -124,14 +124,15 @@ a long period of inactivity (3 days by default), the cache will empty itself. ## Multi-Datacenter -Connect currently only works for service-to-service connections within a -single Consul datacenter. Connect may be enabled on multiple Consul datacenters, -but only services within the same datacenters can establish Connect-based -connections. -CA configurations and intentions are both local to their respective datacenters; +Using Connect for service-to-service communications across multiple datacenters +requires Consul Enterprise. + +With Open Source Consul, Connect may be enabled on multiple Consul datacenters, +but only services within the same datacenter can establish Connect-based, +Authenticated and Authorized connections. In this version, Certificate Authority +configurations and intentions are both local to their respective datacenters; they are not replicated across datacenters. -Multi-datacenter support for Connect is under development and will be -released as a feature of Consul Enterprise in late 2018. This feature will -facilitate intention replication, datacenter constraints on intentions, -CA state replication, multi-datacenter certificate rotations, and more. +Full multi-datacenter support for Connect is available in +[Consul Enterprise](/docs/enterprise/connect-multi-datacenter/index.html). + diff --git a/website/source/docs/enterprise/connect-multi-datacenter/index.html.md b/website/source/docs/enterprise/connect-multi-datacenter/index.html.md new file mode 100644 index 000000000..65ad8ba16 --- /dev/null +++ b/website/source/docs/enterprise/connect-multi-datacenter/index.html.md @@ -0,0 +1,53 @@ +--- +layout: "docs" +page_title: "Consul Enterprise Multi-Datacenter Connect" +sidebar_current: "docs-enterprise-connect-multi-datacenter" +description: |- + Consul Enterprise supports cross datacenter connections using Consul Connect. +--- + +# Consul Connect Multi-Datacenter + +[Consul Enterprise](https://www.hashicorp.com/consul.html) enables service-to-service +connections across multiple Consul datacenters. This includes replication of intentions +and federation of Certificate Authority trust. + +Sidecar proxy's [upstream configuration](/docs/connect/proxies.html#upstream-configuration-reference) +may specify an alternative datacenter or a prepared query that can address services +in multiple datacenters (such as the [geo failover](/docs/guides/geo-failover.html) pattern). + +[Intentions](/docs/connect/intentions.html) verify connections between services by +source and destination name seamlessly across datacenters. Support for constraining Intentions +by source or destination datacenter is planned for the near future. + +It is assumed that workloads can communicate between datacenters via existing network +routes and VPN tunnels, potentially using Consul's +[`translate_wan_addrs`](/docs/agent/options.html#translate_wan_addrs) to ensure remote +workloads discover an externally routable IP. + +# Replication + +Intention replication happens automatically but requires the [`primary_datacenter`](/docs/agent/options.html#primary_datacenter) +configuration to be set to specify a datacenter that is authorative +for intentions. In production setups with ACLs enabled, the [replication token](/docs/agent/options.html#acl_tokens_replication) +must also be set in secondary datacenter server's configuration. + +# Certificate Authority Federation + +The primary datacenter also acts as the root Certificate Authority (CA) for Connect. +The primary datacenter generates a trust-domain UUID and obtains a root certificate +from the configured CA provider which defaults to the built-in one. + +Secondary datacenters fetch the root CA public key and trust-domain ID from the primary and +generate their own key and Certificate Signing Request (CSR) for an intermediate CA certificate. +This CSR is signed by the root in the primary datacenter and the certificate is returned. +The secondary datacenter can now use this intermediate to sign new Connect certificates +in the secondary datacenter without WAN communication. CA keys are never replicated between +datacenters. + +The secondary maintains watches on the root CA certificate in the primary. If the CA root +changes for any reason such as rotation or migration to a new CA, the secondary automatically +generates new keys and has them signed by the primary datacenter's new root before initiating +an automatic rotation of all issued certificates in use throughout the secondary datacenter. +This makes CA root key rotation fully automatic and with zero downtime across multiple data +centers. diff --git a/website/source/docs/guides/acl-legacy.html.md b/website/source/docs/guides/acl-legacy.html.md index 2c3a16d59..bc618d566 100644 --- a/website/source/docs/guides/acl-legacy.html.md +++ b/website/source/docs/guides/acl-legacy.html.md @@ -6,7 +6,7 @@ description: |- Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them. It is very similar to AWS IAM in many ways. --- --> **1.3.0 and earlier:** This guide only applies in Consul versions 1.3.0 and before. If you are using the 1.4.0 RC please use the updated guide [here](/docs/guides/acl.html) +-> **1.3.0 and earlier:** This guide only applies in Consul versions 1.3.0 and before. If you are using the 1.4.0 or later please use the updated guide [here](/docs/guides/acl.html) # Deprecation Notice diff --git a/website/source/docs/guides/acl.html.md b/website/source/docs/guides/acl.html.md index 1eec661ec..4ae14a3f7 100644 --- a/website/source/docs/guides/acl.html.md +++ b/website/source/docs/guides/acl.html.md @@ -6,7 +6,7 @@ description: |- Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them. It is very similar to AWS IAM in many ways. --- --> **1.4.0+:** This guide only applies in Consul versions 1.4.0 and later. The documentation for the legacy ACL system [here](/docs/guides/acl-legacy.html) +-> **1.4.0 and later:** This guide only applies in Consul versions 1.4.0 and later. The documentation for the legacy ACL system is [here](/docs/guides/acl-legacy.html) # ACL System diff --git a/website/source/downloads.html.erb b/website/source/downloads.html.erb index dbcf67d49..6c79b43e2 100644 --- a/website/source/downloads.html.erb +++ b/website/source/downloads.html.erb @@ -8,12 +8,6 @@ description: |-

Download Consul

- -
diff --git a/website/source/index.html.erb b/website/source/index.html.erb index d6ef2153b..90a0491e8 100644 --- a/website/source/index.html.erb +++ b/website/source/index.html.erb @@ -11,9 +11,6 @@ description: |-