diff --git a/website/components/footer/index.jsx b/website/components/footer/index.jsx index d62a9b8950..86d72cb193 100644 --- a/website/components/footer/index.jsx +++ b/website/components/footer/index.jsx @@ -8,7 +8,7 @@ export default function Footer({ openConsentManager }) { Intro - + Guides diff --git a/website/content/api-docs/acl/auth-methods.mdx b/website/content/api-docs/acl/auth-methods.mdx index 1cd27be616..2e662213b9 100644 --- a/website/content/api-docs/acl/auth-methods.mdx +++ b/website/content/api-docs/acl/auth-methods.mdx @@ -44,7 +44,7 @@ The corresponding CLI command is [`consul acl auth-method create`](/commands/acl - `Type` `(string: )` - The type of auth method being configured. This field is immutable. For allowed values see the [auth method - documentation](/docs/acl/auth-methods). + documentation](/docs/security/acl/auth-methods). - `Description` `(string: "")` - Free form human readable description of the auth method. @@ -69,7 +69,7 @@ The corresponding CLI command is [`consul acl auth-method create`](/commands/acl - `Config` `(map[string]string: )` - The raw configuration to use for the chosen auth method. Contents will vary depending upon the type chosen. For more information on configuring specific auth method types, see the [auth - method documentation](/docs/acl/auth-methods). + method documentation](/docs/security/acl/auth-methods). - `Namespace` `(string: "")` - Specifies the namespace to create the auth method within. If not provided in the JSON body, the value of @@ -252,7 +252,7 @@ The corresponding CLI command is [`consul acl auth-method update`](/commands/acl - `Config` `(map[string]string: )` - The raw configuration to use for the chosen auth method. Contents will vary depending upon the type chosen. For more information on configuring specific auth method types, see the [auth - method documentation](/docs/acl/auth-methods). + method documentation](/docs/security/acl/auth-methods). - `Namespace` `(string: "")` - Specifies the namespace of the auth method to update. If not provided in the JSON body, the value of diff --git a/website/content/api-docs/acl/index.mdx b/website/content/api-docs/acl/index.mdx index f6df49bc73..3445d233d9 100644 --- a/website/content/api-docs/acl/index.mdx +++ b/website/content/api-docs/acl/index.mdx @@ -276,7 +276,7 @@ agent_prefix "" { ## Login to Auth Method This endpoint was added in Consul 1.5.0 and is used to exchange an [auth -method](/docs/acl/auth-methods) bearer token for a newly-created +method](/docs/security/acl/auth-methods) bearer token for a newly-created Consul ACL token. | Method | Path | Produces | @@ -407,7 +407,7 @@ $ curl \ This endpoint was added in Consul 1.8.0 and is used to obtain an authorization -URL from Consul to start an [OIDC login flow](/docs/acl/auth-methods/oidc). +URL from Consul to start an [OIDC login flow](/docs/security/acl/auth-methods/oidc). | Method | Path | Produces | | ------ | -------------------- | ------------------ | @@ -433,10 +433,10 @@ replication enabled. ### Parameters - `AuthMethod` `(string: )` - The name of the auth method to use for - login. This must be of type [`oidc`](/docs/acl/auth-methods/oidc). + login. This must be of type [`oidc`](/docs/security/acl/auth-methods/oidc). - `RedirectURI` `(string: )` - See [Redirect - URIs](/docs/acl/auth-methods/oidc#redirect-uris) for more information. + URIs](/docs/security/acl/auth-methods/oidc#redirect-uris) for more information. - `ClientNonce` `(string: "")` - Optional client-provided nonce that must match during callback, if present. @@ -513,7 +513,7 @@ replication enabled. ### Parameters - `AuthMethod` `(string: )` - The name of the auth method to use for - login. This must be of type [`oidc`](/docs/acl/auth-methods/oidc). + login. This must be of type [`oidc`](/docs/security/acl/auth-methods/oidc). - `State` `(string: )` - Opaque state ID that is part of the Authorization URL and will be included in the the redirect following diff --git a/website/content/api-docs/acl/legacy.mdx b/website/content/api-docs/acl/legacy.mdx index 27d54d38bc..ab3bbb70f5 100644 --- a/website/content/api-docs/acl/legacy.mdx +++ b/website/content/api-docs/acl/legacy.mdx @@ -45,7 +45,7 @@ The table below shows this endpoint's support for are: `client` and `management`. - `Rules` `(string: "")` - Specifies rules for this ACL token. The format of the - `Rules` property is detailed in the [ACL Rule documentation](/docs/acl/acl-rules). + `Rules` property is detailed in the [ACL Rule documentation](/docs/security/acl/acl-rules). ### Sample Payload @@ -296,4 +296,4 @@ $ curl \ ## Check ACL Replication -The check ACL replication endpoint has not changed between the legacy system and the new system. Review the [latest documentation](/api/acl/acl#check-acl-replication) to learn more about this endpoint. +The check ACL replication endpoint has not changed between the legacy system and the new system. Review the [latest documentation](/api-docs/acl#check-acl-replication) to learn more about this endpoint. diff --git a/website/content/api-docs/acl/policies.mdx b/website/content/api-docs/acl/policies.mdx index a33bd2ea8e..f5ef0a38d6 100644 --- a/website/content/api-docs/acl/policies.mdx +++ b/website/content/api-docs/acl/policies.mdx @@ -44,7 +44,7 @@ The corresponding CLI command is [`consul acl policy create`](/commands/acl/poli - `Description` `(string: "")` - Free form human readable description of the policy. - `Rules` `(string: "")` - Specifies rules for the ACL policy. The format of the - `Rules` property is detailed in the [ACL Rules documentation](/docs/acl/acl-rules). + `Rules` property is detailed in the [ACL Rules documentation](/docs/security/acl/acl-rules). - `Datacenters` `(array)` - Specifies the datacenters the policy is valid within. When no datacenters are provided the policy is valid in all datacenters including @@ -227,7 +227,7 @@ The corresponding CLI command is [`consul acl policy update`](/commands/acl/poli - `Description` `(string: "")` - Free form human readable description of this policy. - `Rules` `(string: "")` - Specifies rules for this ACL policy. The format of the - `Rules` property is detailed in the [ACL Rules documentation](/docs/acl/acl-rules). + `Rules` property is detailed in the [ACL Rules documentation](/docs/security/acl/acl-rules). - `Datacenters` `(array)` - Specifies the datacenters this policy is valid within. When no datacenters are provided the policy is valid in all datacenters including diff --git a/website/content/api-docs/acl/roles.mdx b/website/content/api-docs/acl/roles.mdx index e6496bd64c..5b73c7325f 100644 --- a/website/content/api-docs/acl/roles.mdx +++ b/website/content/api-docs/acl/roles.mdx @@ -50,7 +50,7 @@ The corresponding CLI command is [`consul acl role create`](/commands/acl/role/c breaking tokens. - `ServiceIdentities` `(array)` - The list of [service - identities](/docs/acl/acl-system#acl-service-identities) that should be + identities](/docs/security/acl/acl-system#acl-service-identities) that should be applied to the role. Added in Consul 1.5.0. - `ServiceName` `(string: )` - The name of the service. The name @@ -64,7 +64,7 @@ The corresponding CLI command is [`consul acl role create`](/commands/acl/role/c but may in the future. - `NodeIdentities` `(array)` - The list of [node - identities](/docs/acl/acl-system#acl-node-identities) that should be + identities](/docs/security/acl/acl-system#acl-node-identities) that should be applied to the role. Added in Consul 1.8.1. - `NodeName` `(string: )` - The name of the node. The name @@ -339,11 +339,11 @@ The corresponding CLI command is [`consul acl role update`](/commands/acl/role/u breaking tokens. - `ServiceIdentities` `(array)` - The list of [service - identities](/docs/acl/acl-system#acl-service-identities) that should be + identities](/docs/security/acl/acl-system#acl-service-identities) that should be applied to the role. Added in Consul 1.5.0. - `NodeIdentities` `(array)` - The list of [node - identities](/docs/acl/acl-system#acl-node-identities) that should be + identities](/docs/security/acl/acl-system#acl-node-identities) that should be applied to the role. Added in Consul 1.8.1. - `Namespace` `(string: "")` - Specifies the namespace of diff --git a/website/content/api-docs/acl/tokens.mdx b/website/content/api-docs/acl/tokens.mdx index 2f352af9ab..31456965d1 100644 --- a/website/content/api-docs/acl/tokens.mdx +++ b/website/content/api-docs/acl/tokens.mdx @@ -62,7 +62,7 @@ The corresponding CLI command is [`consul acl token create`](/commands/acl/token enables role renaming without breaking tokens. Added in Consul 1.5.0. - `ServiceIdentities` `(array)` - The list of [service - identities](/docs/acl/acl-system#acl-service-identities) that should be + identities](/docs/security/acl/acl-system#acl-service-identities) that should be applied to the token. Added in Consul 1.5.0. - `ServiceName` `(string: )` - The name of the service. The name @@ -76,7 +76,7 @@ The corresponding CLI command is [`consul acl token create`](/commands/acl/token but may in the future. - `NodeIdentities` `(array)` - The list of [node - identities](/docs/acl/acl-system#acl-node-identities) that should be + identities](/docs/security/acl/acl-system#acl-node-identities) that should be applied to the token. Added in Consul 1.8.1. - `NodeName` `(string: )` - The name of the node. The name @@ -329,7 +329,7 @@ The corresponding CLI command is [`consul acl token update`](/commands/acl/token enables role renaming without breaking tokens. - `ServiceIdentities` `(array)` - The list of [service - identities](/docs/acl/acl-system#acl-service-identities) that should be + identities](/docs/security/acl/acl-system#acl-service-identities) that should be applied to the token. Added in Consul 1.5.0. - `ServiceName` `(string: )` - The name of the service. The name @@ -343,7 +343,7 @@ The corresponding CLI command is [`consul acl token update`](/commands/acl/token but may in the future. - `NodeIdentities` `(array)` - The list of [node - identities](/docs/acl/acl-system#acl-node-identities) that should be + identities](/docs/security/acl/acl-system#acl-node-identities) that should be applied to the token. Added in Consul 1.8.1. - `NodeName` `(string: )` - The name of the node. The name diff --git a/website/content/api-docs/agent/check.mdx b/website/content/api-docs/agent/check.mdx index ec97e31d11..05fc3f43ea 100644 --- a/website/content/api-docs/agent/check.mdx +++ b/website/content/api-docs/agent/check.mdx @@ -18,7 +18,7 @@ using the HTTP API. It is important to note that the checks known by the agent may be different from those reported by the catalog. This is usually due to changes being made while there is no leader elected. The agent performs active -[anti-entropy](/docs/internals/anti-entropy), so in most situations +[anti-entropy](/docs/architecture/anti-entropy), so in most situations everything will be in sync within a few seconds. | Method | Path | Produces | diff --git a/website/content/api-docs/agent/index.mdx b/website/content/api-docs/agent/index.mdx index 899949f372..853e071190 100644 --- a/website/content/api-docs/agent/index.mdx +++ b/website/content/api-docs/agent/index.mdx @@ -12,7 +12,7 @@ The `/agent` endpoints are used to interact with the local Consul agent. Usually, services and checks are registered with an agent which then takes on the burden of keeping that data synchronized with the cluster. For example, the agent registers services and checks with the Catalog and performs -[anti-entropy](/docs/internals/anti-entropy) to recover from outages. +[anti-entropy](/docs/architecture/anti-entropy) to recover from outages. In addition to these endpoints, additional endpoints are grouped in the navigation for `Checks` and `Services`. diff --git a/website/content/api-docs/agent/service.mdx b/website/content/api-docs/agent/service.mdx index dfd0c90597..09223a9db6 100644 --- a/website/content/api-docs/agent/service.mdx +++ b/website/content/api-docs/agent/service.mdx @@ -20,7 +20,7 @@ or added dynamically using the HTTP API. It is important to note that the services known by the agent may be different from those reported by the catalog. This is usually due to changes being made while there is no leader elected. The agent performs active -[anti-entropy](/docs/internals/anti-entropy), so in most situations +[anti-entropy](/docs/architecture/anti-entropy), so in most situations everything will be in sync within a few seconds. | Method | Path | Produces | @@ -137,7 +137,7 @@ configuration that was registered with the instance. It is important to note that the services known by the agent may be different from those reported by the catalog. This is usually due to changes being made while there is no leader elected. The agent performs active -[anti-entropy](/docs/internals/anti-entropy), so in most situations +[anti-entropy](/docs/architecture/anti-entropy), so in most situations everything will be in sync within a few seconds. | Method | Path | Produces | @@ -231,7 +231,7 @@ $ curl \ ``` The response has the same structure as the [service -definition](/docs/agent/services) with one extra field `ContentHash` which +definition](/docs/discovery/services) with one extra field `ContentHash` which contains the [hash-based blocking query](/api/features/blocking#hash-based-blocking-queries) hash for the result. The same hash is also present in `X-Consul-ContentHash`. @@ -601,13 +601,13 @@ The corresponding CLI command is [`consul services register`](/commands/services ### Parameters -Note that this endpoint, unlike most also [supports `snake_case`](/docs/agent/services#service-definition-parameter-case) +Note that this endpoint, unlike most also [supports `snake_case`](/docs/discovery/services#service-definition-parameter-case) service definition keys for compatibility with the config file format. - `Name` `(string: )` - Specifies the logical name of the service. Many service instances may share the same logical service name. We recommend using [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames) - for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns). + for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns). - `ID` `(string: "")` - Specifies a unique ID for this service. This must be unique per _agent_. This defaults to the `Name` parameter if not provided. @@ -615,7 +615,7 @@ service definition keys for compatibility with the config file format. - `Tags` `(array: nil)` - Specifies a list of tags to assign to the service. These tags can be used for later filtering and are exposed via the APIs. We recommend using [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames) - for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns) + for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns) - `Address` `(string: "")` - Specifies the address of the service. If not provided, the agent's address is used as the address for the service during @@ -639,9 +639,9 @@ service definition keys for compatibility with the config file format. - `Kind` `(string: "")` - The kind of service. Defaults to "" which is a typical Consul service. This value may also be "connect-proxy" for [Connect](/docs/connect) proxies representing another service, - "mesh-gateway" for instances of a [mesh gateway](/docs/connect/mesh-gateway), - "terminating-gateway" for instances of a [terminating gateway](/docs/connect/terminating-gateway), - or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/ingress-gateway). + "mesh-gateway" for instances of a [mesh gateway](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters), + "terminating-gateway" for instances of a [terminating gateway](/docs/connect/gateways/terminating-gateway), + or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/gateways/ingress-gateway). - `Proxy` `(Proxy: nil)` - From 1.2.3 on, specifies the configuration for a Connect service proxy instance. This is only valid if `Kind` defines a proxy or gateway. @@ -681,7 +681,7 @@ service definition keys for compatibility with the config file format. modifications would be lost. - `Weights` `(Weights: nil)` - Specifies weights for the service. Please see the - [service documentation](/docs/agent/services) for more information about + [service documentation](/docs/discovery/services) for more information about weights. If this field is not provided weights will default to `{"Passing": 1, "Warning": 1}`. @@ -691,7 +691,7 @@ service definition keys for compatibility with the config file format. are independent of one another. Updating the tags for the service registered on one node is independent of the same service (by name) registered on another node. If `EnableTagOverride` is not specified the default value is - `false`. See [anti-entropy syncs](/docs/internals/anti-entropy) for + `false`. See [anti-entropy syncs](/docs/architecture/anti-entropy) for more info. #### Connect Structure diff --git a/website/content/api-docs/catalog.mdx b/website/content/api-docs/catalog.mdx index c269ed0f8b..f24b2e9c07 100644 --- a/website/content/api-docs/catalog.mdx +++ b/website/content/api-docs/catalog.mdx @@ -17,7 +17,7 @@ API methods look similar. This endpoint is a low-level mechanism for registering or updating entries in the catalog. It is usually preferable to instead use the [agent endpoints](/api/agent) for registration as they are simpler and -perform [anti-entropy](/docs/internals/anti-entropy). +perform [anti-entropy](/docs/architecture/anti-entropy). | Method | Path | Produces | | ------ | ------------------- | ------------------ | @@ -54,7 +54,7 @@ The table below shows this endpoint's support for provided, it will be defaulted to the value of the `Service.Service` property. Only one service with a given `ID` may be present per node. We recommend using [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames) - for service definition names for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns). + for service definition names for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns). The service `Tags`, `Address`, `Meta`, and `Port` fields are all optional. For more information about these fields and the implications of setting them, see the [Service - Agent API](/api/agent/service) page @@ -74,7 +74,7 @@ The table below shows this endpoint's support for check. The `Status` must be one of `passing`, `warning`, or `critical`. The `Definition` field can be provided with details for a TCP or HTTP health - check. For more information, see the [Health Checks](/docs/agent/checks) page. + check. For more information, see the [Health Checks](/docs/discovery/checks) page. Multiple checks can be provided by replacing `Check` with `Checks` and sending an array of `Check` objects. @@ -168,7 +168,7 @@ $ curl \ This endpoint is a low-level mechanism for directly removing entries from the Catalog. It is usually preferable to instead use the [agent endpoints](/api/agent) for deregistration as they are simpler and -perform [anti-entropy](/docs/internals/anti-entropy). +perform [anti-entropy](/docs/architecture/anti-entropy). | Method | Path | Produces | | ------ | --------------------- | ------------------ | diff --git a/website/content/api-docs/coordinate.mdx b/website/content/api-docs/coordinate.mdx index f3328d5515..52d6c1ffeb 100644 --- a/website/content/api-docs/coordinate.mdx +++ b/website/content/api-docs/coordinate.mdx @@ -13,7 +13,7 @@ The `/coordinate` endpoints query for the network coordinates for nodes in the local datacenter as well as Consul servers in the local datacenter and remote datacenters. -Please see the [Network Coordinates](/docs/internals/coordinates) internals +Please see the [Network Coordinates](/docs/architecture/coordinates) internals guide for more information on how these coordinates are computed, and for details on how to perform calculations with them. diff --git a/website/content/api-docs/discovery-chain.mdx b/website/content/api-docs/discovery-chain.mdx index 8115271d65..e7e2de6e5e 100644 --- a/website/content/api-docs/discovery-chain.mdx +++ b/website/content/api-docs/discovery-chain.mdx @@ -13,13 +13,13 @@ description: The /discovery-chain endpoints are for interacting with the discove high-level proxy integration APIs may obviate the need for this API over time. The `/discovery-chain` endpoint returns the compiled [discovery -chain](/docs/internals/discovery-chain) for a service. +chain](/docs/connect/l7-traffic/discovery-chain) for a service. This will fetch all related [configuration entries](/docs/agent/config-entries) and render them into a form suitable for use by a [connect proxy](/docs/connect/proxies) implementation. This is a key component of [L7 Traffic -Management](/docs/connect/l7-traffic-management). +Management](/docs/connect/l7-traffic). ## Read Compiled Discovery Chain @@ -95,7 +95,7 @@ The table below shows this endpoint's support for parameter. - `OverrideMeshGateway` `(MeshGatewayConfig: )` - Overrides the final - [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) for this any service resolved in the compiled chain. This value comes from either the [proxy @@ -111,7 +111,7 @@ The table below shows this endpoint's support for ### Sample Compilations Full documentation for the output fields is found on the [discovery chain -internals](/docs/internals/discovery-chain#compileddiscoverychain) +internals](/docs/connect/l7-traffic/discovery-chain#compileddiscoverychain) page. #### Multi-Datacenter Failover diff --git a/website/content/api-docs/event.mdx b/website/content/api-docs/event.mdx index 47ec7345d8..f322c7b422 100644 --- a/website/content/api-docs/event.mdx +++ b/website/content/api-docs/event.mdx @@ -90,7 +90,7 @@ $ curl \ This endpoint returns the most recent events (up to 256) known by the agent. As a consequence of how the [event command](/commands/event) works, each agent may have a different view of the events. Events are broadcast using the -[gossip protocol](/docs/internals/gossip), so they have no global ordering +[gossip protocol](/docs/architecture/gossip), so they have no global ordering nor do they make a promise of delivery. | Method | Path | Produces | @@ -150,7 +150,7 @@ $ curl \ The semantics of this endpoint's blocking queries are slightly different. Most blocking queries provide a monotonic index and block until a newer index is available. This can be supported as a consequence of the total ordering of the -[consensus protocol](/docs/internals/consensus). With gossip, there is no +[consensus protocol](/docs/architecture/consensus). With gossip, there is no ordering, and instead `X-Consul-Index` maps to the newest event that matches the query. diff --git a/website/content/api-docs/health.mdx b/website/content/api-docs/health.mdx index 82e42b4f37..cc4fc72bad 100644 --- a/website/content/api-docs/health.mdx +++ b/website/content/api-docs/health.mdx @@ -421,7 +421,7 @@ Parameters and response format are the same as -> **1.8.0+:** This API is available in Consul versions 1.8.0 and later. This endpoint returns the service instances providing an [ingress -gateway](/docs/connect/ingress-gateway) for a service in a given datacenter. +gateway](/docs/connect/gateways/ingress-gateway) for a service in a given datacenter. | Method | Path | Produces | | ------ | -------------------------- | ------------------ | diff --git a/website/content/api-docs/index.mdx b/website/content/api-docs/index.mdx index d57d86b18a..768e3865ab 100644 --- a/website/content/api-docs/index.mdx +++ b/website/content/api-docs/index.mdx @@ -40,7 +40,7 @@ Previously this was provided via a `?token=` query parameter. This functionality exists on many endpoints for backwards compatibility, but its use is **highly discouraged**, since it can show up in access logs as part of the URL. -To learn more about the ACL system read the [documentation](/docs/acl/acl-system). +To learn more about the ACL system read the [documentation](/docs/security/acl/acl-system). ## Version Prefix diff --git a/website/content/api-docs/operator/area.mdx b/website/content/api-docs/operator/area.mdx index d4333503d5..5050576664 100644 --- a/website/content/api-docs/operator/area.mdx +++ b/website/content/api-docs/operator/area.mdx @@ -425,4 +425,4 @@ $ curl \ - `RTT` is an estimated network round trip time from the server answering the query to the given server, in nanoseconds. This is computed using [network - coordinates](/docs/internals/coordinates). + coordinates](/docs/architecture/coordinates). diff --git a/website/content/api-docs/operator/index.mdx b/website/content/api-docs/operator/index.mdx index 84efd335c1..6bfaf034d2 100644 --- a/website/content/api-docs/operator/index.mdx +++ b/website/content/api-docs/operator/index.mdx @@ -14,7 +14,7 @@ operations manually, please check the documentation for the [`consul operator`](/commands/operator) command. If ACLs are enabled then a token with operator privileges may be required in -order to use this interface. Check the [ACL Rules documentation](/docs/acl/acl-rules#operator-rules) +order to use this interface. Check the [ACL Rules documentation](/docs/security/acl/acl-rules#operator-rules) for more information. Check the [Outage Recovery](https://learn.hashicorp.com/tutorials/consul/recovery-outage) tutorial for some examples of diff --git a/website/content/api-docs/operator/keyring.mdx b/website/content/api-docs/operator/keyring.mdx index f493ad336b..2994db35cd 100644 --- a/website/content/api-docs/operator/keyring.mdx +++ b/website/content/api-docs/operator/keyring.mdx @@ -9,7 +9,7 @@ description: |- # Keyring Operator HTTP API The `/operator/keyring` endpoints allow for management of the gossip encryption -keyring. Please see the [Gossip Protocol Guide](/docs/internals/gossip) for +keyring. Please see the [Gossip Protocol Guide](/docs/architecture/gossip) for more details on the gossip protocol and its use. ## List Gossip Encryption Keys diff --git a/website/content/api-docs/operator/raft.mdx b/website/content/api-docs/operator/raft.mdx index 6eee9365b5..5225208a3b 100644 --- a/website/content/api-docs/operator/raft.mdx +++ b/website/content/api-docs/operator/raft.mdx @@ -11,7 +11,7 @@ description: |- The `/operator/raft` endpoints provide tools for management of Raft the consensus subsystem and cluster quorum. -Please see the [Consensus Protocol Guide](/docs/internals/consensus) for +Please see the [Consensus Protocol Guide](/docs/architecture/consensus) for more information about Raft consensus protocol and its use. ## Read Configuration diff --git a/website/content/api-docs/query.mdx b/website/content/api-docs/query.mdx index d16ed07e8b..b5e608b6ee 100644 --- a/website/content/api-docs/query.mdx +++ b/website/content/api-docs/query.mdx @@ -17,7 +17,7 @@ would be possible given the limited entry points exposed by DNS. Check the [Geo Failover tutorial](https://learn.hashicorp.com/tutorials/consul/automate-geo-failover) for details and examples for using prepared queries to implement geo failover for services. -Check the [prepared query rules](/docs/agent/acl-rules#prepared-query-rules) +Check the [prepared query rules](/docs/security/acl/acl-rules#prepared-query-rules) section of the agent ACL documentation for more details about how prepared queries work with Consul's ACL system. @@ -187,7 +187,7 @@ The table below shows this endpoint's support for - `NearestN` `(int: 0)` - Specifies that the query will be forwarded to up to `NearestN` other datacenters based on their estimated network round - trip time using [Network Coordinates](/docs/internals/coordinates) + trip time using [Network Coordinates](/docs/architecture/coordinates) from the WAN gossip pool. The median round trip time from the server handling the query to the servers in the remote datacenter is used to determine the priority. @@ -214,7 +214,7 @@ The table below shows this endpoint's support for true, only nodes with checks in the passing state will be returned. - `Near` `(string: "")` - Specifies a node to sort near based on distance - sorting using [Network Coordinates](/docs/internals/coordinates). The + sorting using [Network Coordinates](/docs/architecture/coordinates). The nearest instance to the specified node will be returned first, and subsequent nodes in the response will be sorted in ascending order of estimated round-trip times. If the node given does not exist, the nodes in the response diff --git a/website/content/api-docs/snapshot.mdx b/website/content/api-docs/snapshot.mdx index af990ae108..885cdd0a3f 100644 --- a/website/content/api-docs/snapshot.mdx +++ b/website/content/api-docs/snapshot.mdx @@ -10,7 +10,7 @@ description: |- The `/snapshot` endpoints save and restore the state of the Consul servers for disaster recovery. Snapshots include all state managed by Consul's -Raft [consensus protocol](/docs/internals/consensus). +Raft [consensus protocol](/docs/architecture/consensus). ## Generate Snapshot diff --git a/website/content/commands/acl/index.mdx b/website/content/commands/acl/index.mdx index 94dd015de1..93547bc341 100644 --- a/website/content/commands/acl/index.mdx +++ b/website/content/commands/acl/index.mdx @@ -12,7 +12,7 @@ line. It exposes top-level commands for bootstrapping the ACL system, managing tokens and policies, translating legacy rules, and setting the tokens for use by an agent. -ACLs are also accessible via the [HTTP API](/api/acl/acl). +ACLs are also accessible via the [HTTP API](/api-docs/acl). Bootstrap Consul's ACLs: diff --git a/website/content/commands/agent.mdx b/website/content/commands/agent.mdx index 771954e4ab..cfdbdc47b7 100644 --- a/website/content/commands/agent.mdx +++ b/website/content/commands/agent.mdx @@ -14,6 +14,6 @@ performs the important task of maintaining membership information, running checks, announcing services, handling queries, etc. Due to the power and flexibility of this command, the Consul agent -is documented in its own section. See the [Consul Agent](/docs/agent/basics) +is documented in its own section. See the [Consul Agent](/docs/agent) section for more information on how to use this command and the options it has. diff --git a/website/content/commands/connect/expose.mdx b/website/content/commands/connect/expose.mdx index dc802355e9..9657ebec04 100644 --- a/website/content/commands/connect/expose.mdx +++ b/website/content/commands/connect/expose.mdx @@ -14,7 +14,7 @@ Command: `consul connect expose` The connect expose subcommand is used to expose a Connect-enabled service through an Ingress gateway by modifying the gateway's configuration and adding an intention to allow traffic from the gateway to the service. See the -[Ingress gateway documentation](/docs/connect/ingress-gateway) for more information +[Ingress gateway documentation](/docs/connect/gateways/ingress-gateway) for more information about Ingress gateways. ```text diff --git a/website/content/commands/event.mdx b/website/content/commands/event.mdx index 2ca668049b..96edc4d34c 100644 --- a/website/content/commands/event.mdx +++ b/website/content/commands/event.mdx @@ -19,14 +19,14 @@ The `event` command provides a mechanism to fire a custom user event to an entire datacenter. These events are opaque to Consul, but they can be used to build scripting infrastructure to do automated deploys, restart services, or perform any other orchestration action. Events can be handled by -[using a watch](/docs/agent/watches). +[using a watch](/docs/dynamic-app-config/watches). -Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip). +Under the hood, events are propagated using the [gossip protocol](/docs/architecture/gossip). While the details are not important for using events, an understanding of the semantics is useful. The gossip layer will make a best-effort to deliver the event, but there is **no guaranteed delivery**. Unlike most Consul data, which is -replicated using [consensus](/docs/internals/consensus), event data +replicated using [consensus](/docs/architecture/consensus), event data is purely peer-to-peer over gossip. This means it is not persisted and does not have a total ordering. In practice, this means you cannot rely on the order of message delivery. An advantage however is that events can still diff --git a/website/content/commands/exec.mdx b/website/content/commands/exec.mdx index 2244a7d6eb..8f91b6c915 100644 --- a/website/content/commands/exec.mdx +++ b/website/content/commands/exec.mdx @@ -17,7 +17,7 @@ the `web` service. Remote execution works by specifying a job, which is stored in the KV store. Agents are informed about the new job using the [event system](/commands/event), -which propagates messages via the [gossip protocol](/docs/internals/gossip). +which propagates messages via the [gossip protocol](/docs/architecture/gossip). As a result, delivery is best-effort, and there is **no guarantee** of execution. While events are purely gossip driven, remote execution relies on the KV store diff --git a/website/content/commands/index.mdx b/website/content/commands/index.mdx index c8144530a9..75e2a19e17 100644 --- a/website/content/commands/index.mdx +++ b/website/content/commands/index.mdx @@ -239,7 +239,7 @@ CONSUL_GRPC_ADDR=unix://var/run/consul_grpc.sock ``` If the agent is [configured with TLS -certificates](/docs/agent/encryption#rpc-encryption-with-tls), then the +certificates](/docs/security/encryption#rpc-encryption-with-tls), then the gRPC listener will require TLS and present the same certificate as the https listener. As with `CONSUL_HTTP_ADDR`, if TLS is enabled either the `https://` scheme should be used, or `CONSUL_HTTP_SSL` set. diff --git a/website/content/commands/info.mdx b/website/content/commands/info.mdx index bc8e78f66a..3ffb69556f 100644 --- a/website/content/commands/info.mdx +++ b/website/content/commands/info.mdx @@ -19,9 +19,9 @@ There are currently the top-level keys for: - agent: Provides information about the agent - consul: Information about the consul library (client or server) -- raft: Provides info about the Raft [consensus library](/docs/internals/consensus) -- serf_lan: Provides info about the LAN [gossip pool](/docs/internals/gossip) -- serf_wan: Provides info about the WAN [gossip pool](/docs/internals/gossip) +- raft: Provides info about the Raft [consensus library](/docs/architecture/consensus) +- serf_lan: Provides info about the LAN [gossip pool](/docs/architecture/gossip) +- serf_wan: Provides info about the WAN [gossip pool](/docs/architecture/gossip) Here is an example output: diff --git a/website/content/commands/keygen.mdx b/website/content/commands/keygen.mdx index 531efb1364..15ba9418db 100644 --- a/website/content/commands/keygen.mdx +++ b/website/content/commands/keygen.mdx @@ -12,6 +12,6 @@ description: >- Command: `consul keygen` The `keygen` command generates an encryption key that can be used for -[Consul agent traffic encryption](/docs/agent/encryption). +[Consul agent traffic encryption](/docs/security/encryption). The keygen command uses a cryptographically strong pseudo-random number generator to generate the key. diff --git a/website/content/commands/keyring.mdx b/website/content/commands/keyring.mdx index 0d50260f9e..0dbcb98b40 100644 --- a/website/content/commands/keyring.mdx +++ b/website/content/commands/keyring.mdx @@ -10,7 +10,7 @@ Command: `consul keyring` Corresponding HTTP API Endpoints: [\[VARIES\] /v1/operator/keyring](/api-docs/operator/keyring) The `keyring` command is used to examine and modify the encryption keys used in -Consul's [Gossip Pools](/docs/internals/gossip). It is capable of +Consul's [Gossip Pools](/docs/architecture/gossip). It is capable of distributing new encryption keys to the cluster, retiring old encryption keys, and changing the keys used by the cluster to encrypt messages. diff --git a/website/content/commands/operator/area.mdx b/website/content/commands/operator/area.mdx index 0bd927e24f..17f2881f5d 100644 --- a/website/content/commands/operator/area.mdx +++ b/website/content/commands/operator/area.mdx @@ -269,7 +269,7 @@ spoken by the node. `RTT` is an estimated network round trip time from the server answering the query to the given server, in a human-readable format. This is computed using -[network coordinates](/docs/internals/coordinates). +[network coordinates](/docs/architecture/coordinates). The return code will indicate success or failure. diff --git a/website/content/commands/rtt.mdx b/website/content/commands/rtt.mdx index 9eed062c9f..4f7fd6e3aa 100644 --- a/website/content/commands/rtt.mdx +++ b/website/content/commands/rtt.mdx @@ -14,7 +14,7 @@ Corresponding HTTP API Endpoints: [\[GET\] /v1/coordinate/datacenters](/api-docs The `rtt` command estimates the network round trip time between two nodes using Consul's network coordinate model of the cluster. -See the [Network Coordinates](/docs/internals/coordinates) internals guide +See the [Network Coordinates](/docs/architecture/coordinates) internals guide for more information on how these coordinates are computed. The table below shows this command's [required ACLs](/api#authentication). Configuration of diff --git a/website/content/commands/services/deregister.mdx b/website/content/commands/services/deregister.mdx index d3442d8d39..7b3afb0662 100644 --- a/website/content/commands/services/deregister.mdx +++ b/website/content/commands/services/deregister.mdx @@ -17,7 +17,7 @@ be paired with `services register`. This is just one method for service deregistration. If the service was registered with a configuration file, then deleting that file and [reloading](/commands/reload) Consul is the correct method to -deregister. See [Service Definition](/docs/agent/services) for more +deregister. See [Service Definition](/docs/discovery/services) for more information about registering services generally. The table below shows this command's [required ACLs](/api#authentication). Configuration of diff --git a/website/content/commands/services/index.mdx b/website/content/commands/services/index.mdx index 5998e36acc..95c3f868e4 100644 --- a/website/content/commands/services/index.mdx +++ b/website/content/commands/services/index.mdx @@ -8,7 +8,7 @@ page_title: 'Commands: Services' Command: `consul services` The `services` command has subcommands for interacting with Consul services -registered with the [local agent](/docs/agent/basics). These provide +registered with the [local agent](/docs/agent). These provide useful commands such as `register` and `deregister` for easily registering services in scripts, dev mode, etc. To view all services in the catalog, instead of only agent-local services, diff --git a/website/content/commands/services/register.mdx b/website/content/commands/services/register.mdx index 27b7494df6..22a9603251 100644 --- a/website/content/commands/services/register.mdx +++ b/website/content/commands/services/register.mdx @@ -15,7 +15,7 @@ service deregistration. This command simplifies service registration from scripts, in dev mode, etc. This is just one method of service registration. Services can also be -registered by placing a [service definition](/docs/agent/services) +registered by placing a [service definition](/docs/discovery/services) in the Consul agent configuration directory and issuing a [reload](/commands/reload). This approach is easiest for configuration management systems that other systems that have access to @@ -74,7 +74,7 @@ arguments are given, the flags below can be used to register a single service. Note that the behavior of each of the fields below is exactly the same -as when constructing a standard [service definition](/docs/agent/services). +as when constructing a standard [service definition](/docs/discovery/services). Please refer to that documentation for full details. - `-id` - The ID of the service. This will default to `-name` if not set. diff --git a/website/content/commands/watch.mdx b/website/content/commands/watch.mdx index 0aa8845175..3be6bfd2da 100644 --- a/website/content/commands/watch.mdx +++ b/website/content/commands/watch.mdx @@ -19,7 +19,7 @@ a process with the latest values of the view. If no process is specified, the current values are dumped to STDOUT which can be a useful way to inspect data in Consul. -There is more [documentation on watches here](/docs/agent/watches). +There is more [documentation on watches here](/docs/dynamic-app-config/watches). ## Usage @@ -28,7 +28,7 @@ Usage: `consul watch [options] [child...]` The only required option is `-type` which specifies the particular data view. Depending on the type, various options may be required or optionally provided. There is more documentation on watch -[specifications here](/docs/agent/watches). +[specifications here](/docs/dynamic-app-config/watches). #### API Options diff --git a/website/content/docs/agent/index.mdx b/website/content/docs/agent/index.mdx index c54c1b0935..6d38969516 100644 --- a/website/content/docs/agent/index.mdx +++ b/website/content/docs/agent/index.mdx @@ -17,7 +17,7 @@ Agents run in either client or server mode. Client nodes are lightweight process They interface with the server nodes for most operations and maintain very little state of their own. Clients run on every node where services are running. -In addition to the core agent operations, server nodes participate in the [consensus quorum](/docs/internals/consensus). +In addition to the core agent operations, server nodes participate in the [consensus quorum](/docs/architecture/consensus). The quorum is based on the Raft protocol, which provides strong consistency and availability in the case of failure. Server nodes should run on dedicated instances because they are more resource intensive than client nodes. @@ -46,7 +46,7 @@ As a result, agent crashes are handled in the same manner is network failures. Once a node is marked as failed, this information is updated in the service catalog. --> **Note:** Updating the catalog is only possible if the servers can still [form a quorum](/docs/internals/consensus). +-> **Note:** Updating the catalog is only possible if the servers can still [form a quorum](/docs/architecture/consensus). Once the network recovers or a crashed agent restarts, the cluster will repair itself and unmark a node as failed. The health check in the catalog will also be updated to reflect the current state. diff --git a/website/content/docs/agent/options.mdx b/website/content/docs/agent/options.mdx index c0d4efc5e7..69d622d74f 100644 --- a/website/content/docs/agent/options.mdx +++ b/website/content/docs/agent/options.mdx @@ -49,7 +49,7 @@ Environment variables **cannot** be used to configure the Consul client. They _can_ be used when running other `consul` CLI commands that connect with a running agent, e.g. `CONSUL_HTTP_ADDR=192.168.0.1:8500 consul members`. -See [Consul Commands](/docs/commands#environment-variables) for more +See [Consul Commands](/commands#environment-variables) for more information. ## Command-line Options ((#commandline_options)) @@ -260,7 +260,7 @@ The options below are all specified on the command-line. PTR query responses will always use `-domain`, since the desired domain cannot be included in the query. - `-enable-script-checks` ((#\_enable_script_checks)) This controls whether - [health checks that execute scripts](/docs/agent/checks) are enabled on this + [health checks that execute scripts](/docs/discovery/checks) are enabled on this agent, and defaults to `false` so operators must opt-in to allowing these. This was added in Consul 0.9.0. @@ -414,7 +414,7 @@ The options below are all specified on the command-line. As of Consul 0.9.1, `retry-join` accepts a unified interface using the [go-discover](https://github.com/hashicorp/go-discover) library for doing automatic cluster joining using cloud metadata. For more information, see - the [Cloud Auto-join page](/docs/agent/cloud-auto-join). + the [Cloud Auto-join page](/docs/install/cloud-auto-join). @@ -506,7 +506,7 @@ The options below are all specified on the command-line. - `-raft-protocol` ((#\_raft_protocol)) - This controls the internal version of the Raft consensus protocol used for server communications. This must be set - to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/docs/upgrade-specific#raft-protocol-version-compatibility) for more details. + to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for more details. - `-recursor` ((#\_recursor)) - Specifies the address of an upstream DNS server. This option may be provided multiple times, and is functionally equivalent @@ -710,7 +710,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'." secondary Consul datacenters will perform replication of only ACL policies and roles. Setting this configuration will will enable ACL token replication and allow for the creation of both [local tokens](/api/acl/tokens#local) and - [auth methods](/docs/acl/auth-methods) in connected secondary datacenters. + [auth methods](/docs/security/acl/auth-methods) in connected secondary datacenters. ~> **Warning:** When enabling ACL token replication on the secondary datacenter, global tokens already present in the secondary datacenter will be lost. For @@ -1102,7 +1102,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'." - `static` This object controls configuring the static authorizer setup in the Consul configuration file. Almost all sub-keys are identical to those provided by the [JWT - Auth Method](/docs/acl/auth-methods/jwt). + Auth Method](/docs/security/acl/auth-methods/jwt). - `jwt_validation_pub_keys` (Defaults to `[]`) A list of PEM-encoded public keys to use to authenticate signatures locally. @@ -1634,13 +1634,13 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr - `encrypt_verify_incoming` - This is an optional parameter that can be used to disable enforcing encryption for incoming gossip in order to upshift from unencrypted to encrypted gossip on a running cluster. - See [this section](/docs/agent/encryption#configuring-gossip-encryption-on-an-existing-cluster) + See [this section](/docs/security/encryption#configuring-gossip-encryption-on-an-existing-cluster) for more information. Defaults to true. - `encrypt_verify_outgoing` - This is an optional parameter that can be used to disable enforcing encryption for outgoing gossip in order to upshift from unencrypted to encrypted gossip on a running cluster. - See [this section](/docs/agent/encryption#configuring-gossip-encryption-on-an-existing-cluster) + See [this section](/docs/security/encryption#configuring-gossip-encryption-on-an-existing-cluster) for more information. Defaults to true. - `disable_keyring_file` - Equivalent to the @@ -2423,7 +2423,7 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr - `watches` - Watches is a list of watch specifications which allow an external process to be automatically invoked when a particular data view - is updated. See the [watch documentation](/docs/agent/watches) for more detail. + is updated. See the [watch documentation](/docs/dynamic-app-config/watches) for more detail. Watches can be modified when the configuration is reloaded. ## TLS Configuration Reference diff --git a/website/content/docs/agent/sentinel.mdx b/website/content/docs/agent/sentinel.mdx index 8344ee9957..b86e129426 100644 --- a/website/content/docs/agent/sentinel.mdx +++ b/website/content/docs/agent/sentinel.mdx @@ -19,7 +19,7 @@ policies to support full conditional logic and integration with external systems Sentinel policies are applied during writes to the KV Store. -An optional `sentinel` field specifying code and enforcement level can be added to [ACL policy definitions](/docs/agent/acl-rules#sentinel-integration) for Consul KV. The following policy ensures that the value written during a KV update must end with "dc1". +An optional `sentinel` field specifying code and enforcement level can be added to [ACL policy definitions](/docs/security/acl/acl-rules#sentinel-integration) for Consul KV. The following policy ensures that the value written during a KV update must end with "dc1". diff --git a/website/content/docs/architecture/anti-entropy.mdx b/website/content/docs/architecture/anti-entropy.mdx index ca9c1c5017..7530fae7a5 100644 --- a/website/content/docs/architecture/anti-entropy.mdx +++ b/website/content/docs/architecture/anti-entropy.mdx @@ -26,7 +26,7 @@ health checks and updating their local state. Services and checks within the context of an agent have a rich set of configuration options available. This is because the agent is responsible for generating information about its services and their health through the use of -[health checks](/docs/agent/checks). +[health checks](/docs/discovery/checks). #### Catalog @@ -43,7 +43,7 @@ responsible for recording and returning information _about_ services, nodes, and health. The catalog is maintained only by server nodes. This is because the catalog is -replicated via the [Raft log](/docs/internals/consensus) to provide a +replicated via the [Raft log](/docs/architecture/consensus) to provide a consolidated and consistent view of the cluster. ### Anti-Entropy @@ -118,7 +118,7 @@ database and its monitoring service Redis Sentinel have this kind of relationship. Redis instances are responsible for much of their configuration, but Sentinels determine whether the Redis instance is a primary or a secondary. Using the Consul service configuration item -[enable_tag_override](/docs/agent/services) you can instruct the +[enable_tag_override](/docs/discovery/services) you can instruct the Consul agent on which the Redis database is running to NOT update the tags during anti-entropy synchronization. For more information see -[Services](/docs/agent/services#enable-tag-override-and-anti-entropy) page. +[Services](/docs/discovery/services#enable-tag-override-and-anti-entropy) page. diff --git a/website/content/docs/architecture/index.mdx b/website/content/docs/architecture/index.mdx index f722a40b92..61decaba27 100644 --- a/website/content/docs/architecture/index.mdx +++ b/website/content/docs/architecture/index.mdx @@ -14,7 +14,7 @@ users and developers of Consul form a mental model of how it works, this page documents the system architecture. -> Before describing the architecture, we recommend reading the -[glossary](/docs/glossary) of terms to help +[glossary](/docs/install/glossary) of terms to help clarify what is being discussed. The architecture concepts in this document can be used with the [Reference Architecture guide](https://learn.hashicorp.com/tutorials/consul/reference-architecture?utm_source=consul.io&utm_medium=docs) when deploying Consul in production. @@ -36,7 +36,7 @@ availability in the case of failure and performance, as consensus gets progressi slower as more machines are added. However, there is no limit to the number of clients, and they can easily scale into the thousands or tens of thousands. -All the agents that are in a datacenter participate in a [gossip protocol](/docs/internals/gossip). +All the agents that are in a datacenter participate in a [gossip protocol](/docs/architecture/gossip). This means there is a gossip pool that contains all the agents for a given datacenter. This serves a few purposes: first, there is no need to configure clients with the addresses of servers; discovery is done automatically. Second, the work of detecting agent failures @@ -47,7 +47,7 @@ when important events such as leader election take place. The servers in each datacenter are all part of a single Raft peer set. This means that they work together to elect a single leader, a selected server which has extra duties. The leader is responsible for processing all queries and transactions. Transactions must also be replicated to -all peers as part of the [consensus protocol](/docs/internals/consensus). Because of this +all peers as part of the [consensus protocol](/docs/architecture/consensus). Because of this requirement, when a non-leader server receives an RPC request, it forwards it to the cluster leader. The server agents also operate as part of a WAN gossip pool. This pool is different from the LAN pool @@ -82,8 +82,8 @@ disrupted or the servers are temporarily unavailable. ## Getting in depth At this point we've covered the high level architecture of Consul, but there are many -more details for each of the subsystems. The [consensus protocol](/docs/internals/consensus) is -documented in detail as is the [gossip protocol](/docs/internals/gossip). The [documentation](/docs/internals/security) +more details for each of the subsystems. The [consensus protocol](/docs/architecture/consensus) is +documented in detail as is the [gossip protocol](/docs/architecture/gossip). The [documentation](/docs/security) for the security model and protocols used are also available. For other details, either consult the code, ask in IRC, or reach out to the mailing list. diff --git a/website/content/docs/connect/config-entries/ingress-gateway.mdx b/website/content/docs/connect/config-entries/ingress-gateway.mdx index fdd1f73759..e539001d1f 100644 --- a/website/content/docs/connect/config-entries/ingress-gateway.mdx +++ b/website/content/docs/connect/config-entries/ingress-gateway.mdx @@ -1038,7 +1038,7 @@ You can specify the following parameters to configure ingress gateway configurat type: 'string: ""', description: `The name of the service that should be exposed through this listener. This can be either a service registered in the - catalog, or a service defined only by [other config entries](/docs/connect/l7-traffic-management). If the wildcard specifier, + catalog, or a service defined only by [other config entries](/docs/connect/l7-traffic). If the wildcard specifier, \`*\`, is provided, then ALL services will be exposed through the listener. This is not supported for listeners with protocol \`tcp\`.`, }, diff --git a/website/content/docs/connect/config-entries/proxy-defaults.mdx b/website/content/docs/connect/config-entries/proxy-defaults.mdx index d00dd21a48..cd87af7fc2 100644 --- a/website/content/docs/connect/config-entries/proxy-defaults.mdx +++ b/website/content/docs/connect/config-entries/proxy-defaults.mdx @@ -285,7 +285,7 @@ spec: name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) for all proxies. Added in v1.6.0.`, children: [ { diff --git a/website/content/docs/connect/config-entries/service-defaults.mdx b/website/content/docs/connect/config-entries/service-defaults.mdx index 621259d342..86ce364b6d 100644 --- a/website/content/docs/connect/config-entries/service-defaults.mdx +++ b/website/content/docs/connect/config-entries/service-defaults.mdx @@ -359,7 +359,7 @@ spec: [\`service-defaults\`](/docs/connect/config-entries/service-defaults) config entry for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some - [L7 features](/docs/connect/l7-traffic-management). + [L7 features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. `, }, @@ -374,7 +374,7 @@ spec: [\`service-resolver\`](/docs/connect/config-entries/service-resolver) config entry for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some - [L7 features](/docs/connect/l7-traffic-management). + [L7 features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. `, yaml: `The number of milliseconds to allow when making upstream connections before timing out.

@@ -384,7 +384,7 @@ spec: [\`ServiceResolver\`](/docs/connect/config-entries/service-resolver) CRD for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some - [L7 features](/docs/connect/l7-traffic-management). + [L7 features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. `, }, @@ -393,8 +393,8 @@ spec: name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration) - for this upstream.`, + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) + for this upstream.`, children: [ { name: 'Mode', @@ -480,7 +480,7 @@ spec: [\`service-defaults\`](/docs/connect/config-entries/service-defaults) config entry for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some - [L7 features](/docs/connect/l7-traffic-management). + [L7 features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. `, yaml: `The protocol for the upstream listener.

@@ -490,7 +490,7 @@ spec: [\`ServiceDefaults\`](/docs/connect/config-entries/service-defaults) CRD for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some - [L7 features](/docs/connect/l7-traffic-management). + [L7 features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. `, }, @@ -506,7 +506,7 @@ spec: [\`service-resolver\`](/docs/connect/config-entries/service-resolver) config entry for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some - [L7 features](/docs/connect/l7-traffic-management). + [L7 features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. `, yaml: `The number of milliseconds to allow when making upstream connections before timing out.

@@ -516,7 +516,7 @@ spec: [\`ServiceResolver\`](/docs/connect/config-entries/service-resolver) CRD for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some - [L7 features](/docs/connect/l7-traffic-management). + [L7 features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. `, }, @@ -525,7 +525,7 @@ spec: name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) for this upstream.`, children: [ { @@ -629,7 +629,7 @@ spec: name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) for this service. Added in v1.6.0.`, children: [ { diff --git a/website/content/docs/connect/config-entries/service-resolver.mdx b/website/content/docs/connect/config-entries/service-resolver.mdx index 93ac1e8d30..da4f24e0c3 100644 --- a/website/content/docs/connect/config-entries/service-resolver.mdx +++ b/website/content/docs/connect/config-entries/service-resolver.mdx @@ -21,7 +21,7 @@ and discovery terminates. ## Interaction with other Config Entries - Service resolver config entries are a component of [L7 Traffic - Management](/docs/connect/l7-traffic-management). + Management](/docs/connect/l7-traffic). ## UI diff --git a/website/content/docs/connect/config-entries/service-router.mdx b/website/content/docs/connect/config-entries/service-router.mdx index aef3ecede6..5814173045 100644 --- a/website/content/docs/connect/config-entries/service-router.mdx +++ b/website/content/docs/connect/config-entries/service-router.mdx @@ -21,7 +21,7 @@ service of the same name. ## Interaction with other Config Entries - Service router config entries are a component of [L7 Traffic - Management](/docs/connect/l7-traffic-management). + Management](/docs/connect/l7-traffic). - Service router config entries are restricted to only services that define their protocol as HTTP-based via a corresponding diff --git a/website/content/docs/connect/config-entries/service-splitter.mdx b/website/content/docs/connect/config-entries/service-splitter.mdx index ac1e135551..cf279dbf2c 100644 --- a/website/content/docs/connect/config-entries/service-splitter.mdx +++ b/website/content/docs/connect/config-entries/service-splitter.mdx @@ -25,7 +25,7 @@ resolution stage. ## Interaction with other Config Entries - Service splitter config entries are a component of [L7 Traffic - Management](/docs/connect/l7-traffic-management). + Management](/docs/connect/l7-traffic). - Service splitter config entries are restricted to only services that define their protocol as http-based via a corresponding diff --git a/website/content/docs/connect/config-entries/terminating-gateway.mdx b/website/content/docs/connect/config-entries/terminating-gateway.mdx index b89fcc1c68..c5efc511a8 100644 --- a/website/content/docs/connect/config-entries/terminating-gateway.mdx +++ b/website/content/docs/connect/config-entries/terminating-gateway.mdx @@ -20,7 +20,7 @@ and will apply to all instances of the gateway with that name. across all federated Consul datacenters. If terminating gateways in different Consul datacenters need to route to different sets of services within their datacenter then the terminating gateways **must** be registered with different names. -See [Terminating Gateway](/docs/connect/terminating-gateway) for more information. +See [Terminating Gateway](/docs/connect/gateways/terminating-gateway) for more information. ## TLS Origination diff --git a/website/content/docs/connect/configuration.mdx b/website/content/docs/connect/configuration.mdx index a60ddf78f1..ba6a607406 100644 --- a/website/content/docs/connect/configuration.mdx +++ b/website/content/docs/connect/configuration.mdx @@ -76,7 +76,7 @@ You can override centralized configurations for individual proxy instances in their [sidecar service definitions](/docs/connect/registration/sidecar-service), and the default protocols for service instances in their [service -registrations](/docs/agent/services). +registrations](/docs/discovery/services). ## Schedulers @@ -92,7 +92,7 @@ Connect can be used with Nomad to provide secure service-to-service communication between Nomad jobs and task groups. The ability to use the dynamic port feature of Nomad makes Connect particularly easy to use. Learn about how to configure Connect on Nomad by reading the -[integration documentation](/docs/connect/platform/nomad) +[integration documentation](/docs/connect/nomad) ### Kubernetes diff --git a/website/content/docs/connect/connectivity-tasks.mdx b/website/content/docs/connect/connectivity-tasks.mdx index aa9318e6ed..dbf77d5820 100644 --- a/website/content/docs/connect/connectivity-tasks.mdx +++ b/website/content/docs/connect/connectivity-tasks.mdx @@ -23,9 +23,9 @@ appropriate destination based on the server name requested. The data within the the Gateway. As of Consul 1.8.0, mesh gateways can also forward gossip and RPC traffic between Consul servers. -This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways). +This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). -For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway) +For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways). ![Mesh Gateway Architecture](/img/mesh-gateways.png) diff --git a/website/content/docs/connect/gateways/index.mdx b/website/content/docs/connect/gateways/index.mdx index eed33af644..c7afa60896 100644 --- a/website/content/docs/connect/gateways/index.mdx +++ b/website/content/docs/connect/gateways/index.mdx @@ -27,7 +27,7 @@ They operate by sniffing and extracting the server name indication (SNI) header Mesh gateways enable the following scenarios: -- **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways) for additional information. +* **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) for additional information. - **Service-to-service communication across datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information. - **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployments called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Across Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information. diff --git a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx index 6add2cee0a..ad04052317 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx @@ -26,7 +26,7 @@ The following diagram describes the architecture for using mesh gateways for cro Ensure that your Consul environment meets the following requirements. -### Consul +### Consul * Consul version 1.6.0 or newer. * A local Consul agent is required to manage its configuration. @@ -35,18 +35,18 @@ Ensure that your Consul environment meets the following requirements. * Each datacenters must be [WAN joined](https://learn.hashicorp.com/tutorials/consul/federarion-gossip-wan). * The [primary datacenter](/docs/agent/options#primary_datacenter) must be set to the same value in both datacenters. This specifies which datacenter is the authority for Connect certificates and is required for services in all datacenters to establish mutual TLS with each other. * [gRPC](/docs/agent/options#grpc_port) must be enabled. -* If you want to [enable gateways globally](/docs/connect/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config). +* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config). ### Network * General network connectivity to all services within its local Consul datacenter. * General network connectivity to all mesh gateways within remote Consul datacenters. -### Proxy +### Proxy Envoy is the only proxy with mesh gateway capabilities in Consul. -Mesh gateway proxies receive their configuration through Consul, which automatically generates it based on the proxy's registration. +Mesh gateway proxies receive their configuration through Consul, which automatically generates it based on the proxy's registration. Consul can only translate mesh gateway registration information into Envoy configuration. Sidecar proxies that send traffic to an upstream service through a gateway need to know the location of that gateway. They discover the gateway based on their sidecar proxy registrations. Consul can only translate the gateway registration information into Envoy configuration. @@ -264,4 +264,4 @@ service: mesh_gateway: - mode: none ``` - \ No newline at end of file + diff --git a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx index 39b10675df..93df03b71b 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx @@ -26,9 +26,9 @@ Ensure that your Consul environment meets the following requirements. * A local Consul agent is required to manage its configuration. * Consul service mesh must be enabled in all partitions. Refer to the [`connect` documentation](/docs/agent/options#connect) for details. * Each partition must have a unique name. Refer to the [admin partitions documentation](/docs/enteprise/admin-partitions) for details. -* If you want to [enable gateways globally](/docs/connect/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config). +* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config). -### Proxy +### Proxy Envoy is the only proxy with mesh gateway capabilities in Consul. diff --git a/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx b/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx index 8c5aa2c4b1..425c73b564 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx @@ -9,7 +9,7 @@ description: |- -> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher -~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway). +~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters). WAN federation via mesh gateways allows for Consul servers in different datacenters to be federated exclusively through mesh gateways. @@ -38,7 +38,7 @@ Sometimes this prerequisite is difficult or undesirable to meet: Operators looking to simplify their WAN deployment and minimize the exposed security surface area can elect to join these datacenters together using [mesh -gateways](/docs/connect/gateways/mesh-gateway) to do so. +gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) to do so. [![WAN federation with mesh gateways](/img/wan-federation-connectivity-mesh-gateways.png)](/img/wan-federation-connectivity-mesh-gateways.png) diff --git a/website/content/docs/connect/gateways/terminating-gateway.mdx b/website/content/docs/connect/gateways/terminating-gateway.mdx index 650af5f7f3..31aeddc414 100644 --- a/website/content/docs/connect/gateways/terminating-gateway.mdx +++ b/website/content/docs/connect/gateways/terminating-gateway.mdx @@ -22,14 +22,14 @@ For additional use cases and usage patterns, review the tutorial for [understanding terminating gateways](https://learn.hashicorp.com/tutorials/consul/service-mesh-terminating-gateways). ~> **Known limitations:** Terminating gateways currently do not support targeting service subsets with -[L7 configuration](/docs/connect/l7-traffic-management). They route to all instances of a service with no capabilities +[L7 configuration](/docs/connect/l7-traffic). They route to all instances of a service with no capabilities for filtering by instance. ## Security Considerations ~> We recommend that terminating gateways are not exposed to the WAN or open internet. This is because terminating gateways hold certificates to decrypt Consul Connect traffic directed at them and may be configured with credentials to connect -to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/mesh-gateway) +to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) whenever possible since they are not capable of decrypting traffic or connecting directly to services. By specifying a path to a [CA file](/docs/connect/config-entries/terminating-gateway#cafile) connections @@ -120,7 +120,7 @@ All services registered in the Consul catalog must be associated with a node, ev not managed by a Consul client agent. All agent-less services with the same address can be registered under the same node name and address. However, ensure that the [node name](/api/catalog#node) for external services registered directly in the catalog does not match the node name of any Consul client agent node. If the node name overlaps with the node name of a Consul client agent, -Consul's [anti-entropy sync](/docs/internals/anti-entropy) will delete the services registered via the `/catalog/register` HTTP API endpoint. +Consul's [anti-entropy sync](/docs/architecture/anti-entropy) will delete the services registered via the `/catalog/register` HTTP API endpoint. For a complete example of how to register external services review the [external services tutorial](https://learn.hashicorp.com/tutorials/consul/service-registration-external-services). diff --git a/website/content/docs/connect/l7-traffic/discovery-chain.mdx b/website/content/docs/connect/l7-traffic/discovery-chain.mdx index a8402850d8..807c92b983 100644 --- a/website/content/docs/connect/l7-traffic/discovery-chain.mdx +++ b/website/content/docs/connect/l7-traffic/discovery-chain.mdx @@ -224,7 +224,7 @@ A single node in the compiled discovery chain. be considered healthy. - `MeshGateway` `(MeshGatewayConfig)` - The [mesh gateway - configuration](/docs/connect/mesh-gateway#connect-proxy-configuration) + configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) to use when connecting to this target's service instances. - `Mode` `(string: "")` - One of `none`, `local`, or `remote`. diff --git a/website/content/docs/connect/native/index.mdx b/website/content/docs/connect/native/index.mdx index 62db534960..e90d833b9f 100644 --- a/website/content/docs/connect/native/index.mdx +++ b/website/content/docs/connect/native/index.mdx @@ -138,7 +138,7 @@ natively. This enables the service to be returned as part of service discovery for Connect-capable services, used by other Connect-native applications and client [proxies](/docs/connect/proxies). -This can be specified directly in the [service definition](/docs/agent/services): +This can be specified directly in the [service definition](/docs/discovery/services): ```json { diff --git a/website/content/docs/connect/observability/index.mdx b/website/content/docs/connect/observability/index.mdx index dda5e782e3..8b5073c5e6 100644 --- a/website/content/docs/connect/observability/index.mdx +++ b/website/content/docs/connect/observability/index.mdx @@ -46,7 +46,7 @@ Find other possible metrics syncs in the [Connect Envoy documentation](/docs/con You can specify the [service protocol](/docs/connect/config-entries/service-defaults#protocol) in the `service-defaults` configuration entry. You can override it in the -[service registration](/docs/agent/services). By default, proxies only give +[service registration](/docs/discovery/services). By default, proxies only give you L4 metrics. This protocol allows proxies to handle requests at the right L7 protocol and emit richer L7 metrics. It also allows proxies to make per-request load balancing and routing decisions. diff --git a/website/content/docs/connect/proxies/envoy.mdx b/website/content/docs/connect/proxies/envoy.mdx index 52c1f14713..f2eddc6c95 100644 --- a/website/content/docs/connect/proxies/envoy.mdx +++ b/website/content/docs/connect/proxies/envoy.mdx @@ -23,7 +23,7 @@ Consul can configure Envoy sidecars to proxy traffic over the following protocol On Consul 1.5.0 and older, Envoy proxies can only proxy TCP traffic at L4. -Some [L7 features](/docs/connect/l7-traffic-management) can be configured using [configuration entries](/docs/agent/config-entries). You can add [custom Envoy configurations](#advanced-configuration) to the [proxy service definition](/docs/connect/registration/service-registration) to use Envoy features that are not currently exposed through configuration entries. Adding custom Envoy configurations to the service definition is an interim solution that enables you to use the more powerful features of Envoy. +Some [L7 features](/docs/connect/l7-traffic) can be configured using [configuration entries](/docs/agent/config-entries). You can add [custom Envoy configurations](#advanced-configuration) to the [proxy service definition](/docs/connect/registration/service-registration) to use Envoy features that are not currently exposed through configuration entries. Adding custom Envoy configurations to the service definition is an interim solution that enables you to use the more powerful features of Envoy. ~> **Note:** When using Envoy with Consul and not using the [`consul connect envoy` command](/commands/connect/envoy) Envoy must be run with the `--max-obj-name-len` option set to `256` or greater for Envoy versions prior to 1.11.0. @@ -240,7 +240,7 @@ defaults that are inherited by all services. [`service-defaults`](/docs/connect/config-entries/service-defaults) config entry for the service. Configuring it in a proxy config will not fully enable some [L7 - features](/docs/connect/l7-traffic-management). + features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. - `bind_address` - Override the address Envoy's public listener binds to. By @@ -274,7 +274,7 @@ definition](/docs/connect/registration/service-registration) or [`service-defaults`](/docs/connect/config-entries/service-defaults) config entry for the upstream destination service. Configuring it in a proxy upstream config will not fully enable some [L7 - features](/docs/connect/l7-traffic-management). + features](/docs/connect/l7-traffic). It is supported here for backwards compatibility with Consul versions prior to 1.6.0. - `connect_timeout_ms` - The number of milliseconds to allow when making upstream diff --git a/website/content/docs/connect/proxies/integrate.mdx b/website/content/docs/connect/proxies/integrate.mdx index f57cc22349..bdf59a1af4 100644 --- a/website/content/docs/connect/proxies/integrate.mdx +++ b/website/content/docs/connect/proxies/integrate.mdx @@ -127,7 +127,7 @@ If you are only implementing L4 support in your proxy, set the fetching the discovery chain so that L7 features, such as HTTP routing rules, are not returned. -For each [target](/docs/internals/discovery-chain#targets) in the resulting +For each [target](/docs/connect/l7-traffic/discovery-chain#targets) in the resulting discovery chain, a list of healthy, Connect-capable endpoints may be fetched from the [`/v1/health/connect/:service_id`] API endpoint as described in the [Service Discovery](#service-discovery) section. diff --git a/website/content/docs/connect/proxies/managed-deprecated.mdx b/website/content/docs/connect/proxies/managed-deprecated.mdx index 1fd49ff023..a1d9187729 100644 --- a/website/content/docs/connect/proxies/managed-deprecated.mdx +++ b/website/content/docs/connect/proxies/managed-deprecated.mdx @@ -18,7 +18,7 @@ definition. !> **Consul 1.6.0 removes Managed Proxies completely.** This documentation is provided for prior versions only. You may consider using [sidecar service -registrations](/docs/connect/proxies/sidecar-service) instead. +registrations](/docs/connect/registration/sidecar-service) instead. Managed proxies have been deprecated since Consul 1.3 and have been fully removed in Consul 1.6. Anyone using Managed Proxies should aim to change their workflow @@ -42,7 +42,7 @@ with other workloads. So the high implementation cost of building robust process supervision didn't actually benefit most real use-cases. Instead of this Connect 1.3.0 introduces the concept of [sidecar service -registrations](/docs/connect/proxies/sidecar-service) which +registrations](/docs/connect/registration/sidecar-service) which have almost all of the benefits of simpler configuration but without any of the additional process management complexity. As a result they can be used to simplify configuration in both container-based and realistic production @@ -55,7 +55,7 @@ page will document how they work in the interim. -> **Deprecation Note:** It's _strongly_ recommended you do not build anything using Managed proxies and consider using [sidecar service -registrations](/docs/connect/proxies/sidecar-service) instead. +registrations](/docs/connect/registration/sidecar-service) instead. Managed proxies are given a unique proxy-specific ACL token that allows read-only access to Connect @@ -103,7 +103,7 @@ to re-adopt them on restart. ### Minimal Configuration Managed proxies are configured within a -[service definition](/docs/agent/services). The simplest possible +[service definition](/docs/discovery/services). The simplest possible managed proxy configuration is an empty configuration. This enables the default managed proxy and starts a listener for that service: diff --git a/website/content/docs/connect/registration/index.mdx b/website/content/docs/connect/registration/index.mdx index 58cf1666b0..0ca1f65ee2 100644 --- a/website/content/docs/connect/registration/index.mdx +++ b/website/content/docs/connect/registration/index.mdx @@ -10,7 +10,7 @@ description: >- # Proxy Registration To make Connect aware of proxies you will need to register them in a [service -definition](/docs/agent/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations. +definition](/docs/discovery/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations. ## Proxy Service Registration diff --git a/website/content/docs/connect/registration/service-registration.mdx b/website/content/docs/connect/registration/service-registration.mdx index 32ced2d3a7..d579b9867a 100644 --- a/website/content/docs/connect/registration/service-registration.mdx +++ b/website/content/docs/connect/registration/service-registration.mdx @@ -193,7 +193,7 @@ You can configure the service mesh proxy to create listeners for upstream servic Upstreams support multiple destination types. The following examples include information about each implementation. --> **Snake case**: The examples in this topic use `snake_case` because the syntax is supported in configuration files and API registrations. See [Service Definition Parameter Case](/docs/agent/services#service-definition-parameter-case) for additional information. +-> **Snake case**: The examples in this topic use `snake_case` because the syntax is supported in configuration files and API registrations. See [Service Definition Parameter Case](/docs/discovery/services#service-definition-parameter-case) for additional information. @@ -306,7 +306,7 @@ The following examples show additional configuration for transparent proxies. Added in v1.10.0. -> Note that `snake_case` is used here as it works in both [config file and API -registrations](/docs/agent/services#service-definition-parameter-case). +registrations](/docs/discovery/services#service-definition-parameter-case). #### Configure a proxy listener for outbound traffic on port 22500 @@ -332,7 +332,7 @@ registrations](/docs/agent/services#service-definition-parameter-case). The following examples show all possible mesh gateway configurations. -> Note that `snake_case` is used here as it works in both [config file and API -registrations](/docs/agent/services#service-definition-parameter-case). +registrations](/docs/discovery/services#service-definition-parameter-case). #### Using a Local/Egress Gateway in the Local Datacenter @@ -390,7 +390,7 @@ non-Connect-enabled applications to contact an HTTP endpoint. Some examples include: exposing a `/metrics` path for Prometheus or `/healthz` for kubelet liveness checks. -> Note that `snake_case` is used here as it works in both [config file and API -registrations](/docs/agent/services#service-definition-parameter-case). +registrations](/docs/discovery/services#service-definition-parameter-case). #### Expose listeners in Envoy for HTTP and GRPC checks registered with the local Consul agent diff --git a/website/content/docs/connect/registration/sidecar-service.mdx b/website/content/docs/connect/registration/sidecar-service.mdx index 88bf58d62f..850d954b3d 100644 --- a/website/content/docs/connect/registration/sidecar-service.mdx +++ b/website/content/docs/connect/registration/sidecar-service.mdx @@ -14,7 +14,7 @@ the same VM or running as a separate container in the same network namespace. To simplify the configuration experience when deploying a sidecar for a service instance, Consul 1.3 introduced a new field in the Connect block of the [service -definition](/docs/agent/services). +definition](/docs/discovery/services). To deploy a service and sidecar proxy locally, complete the [Getting Started guide](https://learn.hashicorp.com/tutorials/consul/get-started-service-networking?utm_source=consul.io&utm_medium=docs). @@ -136,7 +136,7 @@ proxy. - `kind` - Defaults to `connect-proxy`. This can't be overridden currently. - `check`, `checks` - By default we add a TCP check on the local address and port for the proxy, and a [service alias - check](/docs/agent/checks#alias) for the parent service. If either + check](/docs/discovery/checks#alias) for the parent service. If either `check` or `checks` fields are set, only the provided checks are registered. - `proxy.destination_service_name` - Defaults to the parent service name. - `proxy.destination_service_id` - Defaults to the parent service ID. @@ -145,7 +145,7 @@ proxy. ## Limitations -Almost all fields in a [service definition](/docs/agent/services) may be +Almost all fields in a [service definition](/docs/discovery/services) may be set on the `connect.sidecar_service` except for the following: - `id` - Sidecar services get an ID assigned and it is an error to override diff --git a/website/content/docs/connect/security.mdx b/website/content/docs/connect/security.mdx index 1c93858111..7c6e8d009c 100644 --- a/website/content/docs/connect/security.mdx +++ b/website/content/docs/connect/security.mdx @@ -13,7 +13,7 @@ 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. To try Connect locally, complete the [Getting Started guide](https://learn.hashicorp.com/tutorials/consul/service-mesh?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) or for a full security model reference, -see the dedicated [Consul security model](/docs/internals/security) page. When +see the dedicated [Consul security model](/docs/security) page. When setting up Connect in production, review this [tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-production-checklist?utm_source=consul.io&utm_medium=docs). Connect will function in any Consul configuration. However, unless the checklist @@ -22,7 +22,7 @@ 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) +read and understand the [Consul security model](/docs/security) in depth to assess whether your deployment satisfies the security requirements of Consul. @@ -54,7 +54,7 @@ to verify server authenticity with each server having a unique TLS certificate. 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) to +See the [Consul agent encryption page](/docs/security/encryption) to learn more about configuring agent encryption. **If encryption is not enabled**, a malicious actor can sniff network @@ -68,7 +68,7 @@ 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) explains the +The [full Consul security model](/docs/security) 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 diff --git a/website/content/docs/discovery/checks.mdx b/website/content/docs/discovery/checks.mdx index defed5d4e7..bd16177954 100644 --- a/website/content/docs/discovery/checks.mdx +++ b/website/content/docs/discovery/checks.mdx @@ -420,7 +420,7 @@ updating a TTL check via the HTTP interface can set the `notes` value. Checks may also contain a `token` field to provide an ACL token. This token is used for any interaction with the catalog for the check, including -[anti-entropy syncs](/docs/internals/anti-entropy) and deregistration. +[anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration. For Alias checks, this token is used if a remote blocking query is necessary to watch the state of the aliased node or service. diff --git a/website/content/docs/discovery/dns.mdx b/website/content/docs/discovery/dns.mdx index 9670ebdf62..47807e62fa 100644 --- a/website/content/docs/discovery/dns.mdx +++ b/website/content/docs/discovery/dns.mdx @@ -102,7 +102,7 @@ A service lookup is used to query for service providers. Service queries support two lookup methods: standard and strict [RFC 2782](https://tools.ietf.org/html/rfc2782). By default, SRV weights are all set at 1, but changing weights is supported using the -`Weights` attribute of the [service definition](/docs/agent/services). +`Weights` attribute of the [service definition](/docs/discovery/services). Note that DNS is limited in size per request, even when performing DNS TCP queries. @@ -394,7 +394,7 @@ To find ingress-enabled services: .ingress. ``` -This will find all [ingress gateway](/docs/connect/ingress-gateway) +This will find all [ingress gateway](/docs/connect/gateways/ingress-gateway) endpoints for the given `service`. This endpoint currently only finds services within the same datacenter diff --git a/website/content/docs/discovery/services.mdx b/website/content/docs/discovery/services.mdx index 213a38229d..bb0068b1ab 100644 --- a/website/content/docs/discovery/services.mdx +++ b/website/content/docs/discovery/services.mdx @@ -212,7 +212,7 @@ This is the root-level parameter that defines the service. You can specify the p | `tagged_addresses` | Tagged addresses are additional addresses that may be defined for a node or service. See [Tagged Addresses](#tagged-addresses) for details. | None | Optional | | `port` | Integer value that specifies a service-specific port number. The port number should be specified when the `address` parameter is defined to improve service discoverability. | Optional | | `socket_path` | String value that specifies the path to the service socket.
Specify this parameter to expose the service to the mesh if the service listens on a Unix Domain socket. | None | Optional | -| `enable_tag_override` | Boolean value that determines if the anti-entropy feature for the service is enabled.
If set to `true`, then external agents can update this service in the catalog and modify the tags.
Subsequent local sync operations by this agent will ignore the updated tags.
This parameter only applies to the locally-registered service. If multiple nodes register the same service, the `enable_tag_override` configuration, and all other service configuration items, operate independently.
Updating the tags for services registered on one node is independent from the same service (by name) registered on another node.
See [anti-entropy syncs](/docs/internals/anti-entropy) for additional information.
| False | Optional | +| `enable_tag_override` | Boolean value that determines if the anti-entropy feature for the service is enabled.
If set to `true`, then external agents can update this service in the catalog and modify the tags.
Subsequent local sync operations by this agent will ignore the updated tags.
This parameter only applies to the locally-registered service. If multiple nodes register the same service, the `enable_tag_override` configuration, and all other service configuration items, operate independently.
Updating the tags for services registered on one node is independent from the same service (by name) registered on another node.
See [anti-entropy syncs](/docs/architecture/anti-entropy) for additional information.
| False | Optional | | `checks` | Array of objects that define health checks for the service. See [Health Checks](#health-checks) for details. | None | Optional | | `kind` | String value that identifies the service as a Connect proxy. See [Connect](#connect) for details. | None | Optional | | `proxy_destination` | String value that specifies the _name_ of the destination service that the service currently being configured proxies to.
This parameter is deprecated. Use `proxy.destination_service` instead.
See [Connect](#connect) for additional information. | None | Optional | @@ -233,7 +233,7 @@ You can add semantic meta data to the service using the `meta` parameter. This p ### Security Configurations If the ACL system is enabled, specify a value for the `token` parameter to provide an ACL token. This token is -used for any interaction with the catalog for the service, including [anti-entropy syncs](/docs/internals/anti-entropy) and deregistration. +used for any interaction with the catalog for the service, including [anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration. Services registered in Consul clusters where both [Consul Namespaces](/docs/enterprise/namespaces) and the ACL system are enabled can be registered to specific namespaces that are associated with @@ -252,7 +252,7 @@ The health check name is automatically generated as `service:`. If t registered, the ID will be generated as `service::` where `` is an incrementing number starting from `1`. -Consul includes several check types with different options. Refer to the [health checks documentation](/docs/agent/checks) for details. +Consul includes several check types with different options. Refer to the [health checks documentation](/docs/discovery/checks) for details. ### Proxy @@ -319,7 +319,7 @@ is present in the agent DNS configuration or the `passing` query parameter is us Services may also contain a `token` field to provide an ACL token. This token is used for any interaction with the catalog for the service, including -[anti-entropy syncs](/docs/internals/anti-entropy) and deregistration. +[anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration. You can optionally disable the anti-entropy feature for this service using the `enable_tag_override` flag. External agents can modify tags on services in the @@ -336,7 +336,7 @@ configuration items are independent of one another. Updating the tags for the service registered on one node is independent of the same service (by name) registered on another node. If `enable_tag_override` is not specified the default value is false. See [anti-entropy -syncs](/docs/internals/anti-entropy) for more info. +syncs](/docs/architecture/anti-entropy) for more info. For Consul 0.9.3 and earlier you need to use `enableTagOverride`. Consul 1.0 supports both `enable_tag_override` and `enableTagOverride` but the latter is diff --git a/website/content/docs/dynamic-app-config/kv.mdx b/website/content/docs/dynamic-app-config/kv.mdx index 6ec4f24561..2e9a7b94c7 100644 --- a/website/content/docs/dynamic-app-config/kv.mdx +++ b/website/content/docs/dynamic-app-config/kv.mdx @@ -15,7 +15,7 @@ similarities to one. The Consul KV datastore is located on the servers, but can be accessed by any agent (client or server). The natively integrated [RPC -functionality](/docs/internals/architecture) allows clients to forward +functionality](/docs/architecture) allows clients to forward requests to servers, including key/value reads and writes. Part of Consul’s core design allows data to be replicated automatically across all the servers. Having a quorum of servers will decrease the risk of data loss if an outage @@ -32,7 +32,7 @@ subcommands](/commands/kv), [HTTP API](/api/kv), and Consul UI. To restrict access, enable and configure [ACLs](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production). Once the ACL system has been bootstrapped, users and services, will need a -valid token with KV [privileges](/docs/agent/acl-rules#key-value-rules) to +valid token with KV [privileges](/docs/security/acl/acl-rules#key-value-rules) to access the the data store, this includes even reads. We recommend creating a token with limited privileges, for example, you could create a token with write privileges on one key for developers to update the value related to their @@ -75,9 +75,9 @@ to be initiated on value changes to a Consul key. ### Watches Consul KV can also be extended with the use of watches. -[Watches](/docs/agent/watches) are a way to monitor data for updates. When +[Watches](/docs/dynamic-app-config/watches) are a way to monitor data for updates. When an update is detected, an external handler is invoked. To use watches with the -KV store the [key](/docs/agent/watches#key) watch type should be used. +KV store the [key](/docs/dynamic-app-config/watches#key) watch type should be used. ### Consul Sessions @@ -87,7 +87,7 @@ API supports an `acquire` and `release` operation. The `acquire` operation acts like a Check-And-Set operation. On success, there is a key update and an increment to the `LockIndex` and the session value is updated to reflect the session holding the lock. Review the session documentation for more information -on the [integration](/docs/internals/sessions#k-v-integration). +on the [integration](/docs/dynamic-app-config/sessions#k-v-integration). Review the following tutorials to learn how to use Consul sessions for [application leader election](https://learn.hashicorp.com/tutorials/consul/application-leader-elections) and to [build distributed semaphores](https://learn.hashicorp.com/tutorials/consul/distributed-semaphore). diff --git a/website/content/docs/dynamic-app-config/sessions.mdx b/website/content/docs/dynamic-app-config/sessions.mdx index b7715289eb..05251d3886 100644 --- a/website/content/docs/dynamic-app-config/sessions.mdx +++ b/website/content/docs/dynamic-app-config/sessions.mdx @@ -51,7 +51,7 @@ deleted by Consul. While this is a simple design, it enables a multitude of usage patterns. By default, the -[gossip based failure detector](/docs/internals/gossip) +[gossip based failure detector](/docs/architecture/gossip) is used as the associated health check. This failure detector allows Consul to detect when a node that is holding a lock has failed and to automatically release the lock. This ability provides **liveness** to diff --git a/website/content/docs/enterprise/index.mdx b/website/content/docs/enterprise/index.mdx index ed876c4b30..e46583300f 100644 --- a/website/content/docs/enterprise/index.mdx +++ b/website/content/docs/enterprise/index.mdx @@ -23,7 +23,7 @@ Features include: - [Namespaces](/docs/enterprise/namespaces) - [NIA with Terraform Enterprise](/docs/nia/enterprise) - [Sentinel](/docs/enterprise/sentinel) -- [OIDC Auth Method](/docs/acl/auth-methods/oidc) +- [OIDC Auth Method](/docs/security/acl/auth-methods/oidc) These features are part of [Consul Enterprise](https://www.hashicorp.com/consul). diff --git a/website/content/docs/enterprise/license/faq.mdx b/website/content/docs/enterprise/license/faq.mdx index 360d8ed8ac..f7657a9139 100644 --- a/website/content/docs/enterprise/license/faq.mdx +++ b/website/content/docs/enterprise/license/faq.mdx @@ -37,7 +37,7 @@ The list below is a great starting point for learning more about the license cha - [Consul Enterprise Upgrade Documentation](https://www.consul.io/docs/enterprise/upgrades) -- [Consul License Documentation](/docs/enterprise/license) +- [Consul License Documentation](/docs/enterprise/license/overview) - [License configuration values documentation](/docs/enterprise/license/overview#binaries-without-built-in-licenses) diff --git a/website/content/docs/enterprise/network-segments.mdx b/website/content/docs/enterprise/network-segments.mdx index 001cb6f7ee..e769a60a3d 100644 --- a/website/content/docs/enterprise/network-segments.mdx +++ b/website/content/docs/enterprise/network-segments.mdx @@ -142,7 +142,7 @@ segments are: Each client agent can only be a member of one segment at a time. This will be the `` segment unless otherwise specified in the agent's -[`segment`](/docs/agent/options.html#_segment) agent configuration option. +[`segment`](/docs/agent/options#_segment) agent configuration option. ### Join a Client to a Segment ((#join_a_client_to_a_segment)) diff --git a/website/content/docs/install/bootstrapping.mdx b/website/content/docs/install/bootstrapping.mdx index 7f9c355763..107d2be0ae 100644 --- a/website/content/docs/install/bootstrapping.mdx +++ b/website/content/docs/install/bootstrapping.mdx @@ -12,18 +12,18 @@ description: >- # Bootstrapping a Datacenter An agent can run in either client or server mode. Server nodes are responsible for running the -[consensus protocol](/docs/internals/consensus) and storing the cluster state. +[consensus protocol](/docs/architecture/consensus) and storing the cluster state. The client nodes are mostly stateless and rely heavily on the server nodes. Before a Consul cluster can begin to service requests, a server node must be elected leader. Bootstrapping is the process of joining these initial server nodes into a cluster. Read the -[architecture documentation](/docs/internals/architecture) to learn more about +[architecture documentation](/docs/architecture) to learn more about the internals of Consul. It is recommended to have three or five total servers per datacenter. A single server deployment is _highly_ discouraged as data loss is inevitable in a failure scenario. Please refer to the -[deployment table](/docs/internals/consensus#deployment-table) for more detail. +[deployment table](/docs/architecture/consensus#deployment-table) for more detail. ~> **Note**: In versions of Consul prior to 0.4, bootstrapping was a manual process. For details on using the `-bootstrap` flag directly, see the [manual bootstrapping documentation](/docs/install/bootstrapping#manually-join-the-servers). diff --git a/website/content/docs/install/glossary.mdx b/website/content/docs/install/glossary.mdx index 2ad344f402..a71f3b4fe8 100644 --- a/website/content/docs/install/glossary.mdx +++ b/website/content/docs/install/glossary.mdx @@ -48,14 +48,14 @@ transactions are applied to a [finite-state machine](https://en.wikipedia.org/wiki/Finite-state_machine), our definition of consensus implies the consistency of a replicated state machine. Consensus is described in more detail on [Wikipedia](), -and our implementation is described [here](/docs/internals/consensus). +and our implementation is described [here](/docs/architecture/consensus). ## Gossip Consul is built on top of [Serf](https://www.serf.io/) which provides a full [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) that is used for multiple purposes. Serf provides membership, failure detection, and event broadcast. Our use of these -is described more in the [gossip documentation](/docs/internals/gossip). It is enough to know +is described more in the [gossip documentation](/docs/architecture/gossip). It is enough to know that gossip involves random node-to-node communication, primarily over UDP. ## LAN Gossip diff --git a/website/content/docs/install/index.mdx b/website/content/docs/install/index.mdx index 7be522fb68..f85405f96a 100644 --- a/website/content/docs/install/index.mdx +++ b/website/content/docs/install/index.mdx @@ -79,4 +79,4 @@ $ consul version Consul currently supports all 'evergreen' browsers, as they are generally on up-to-date versions. For more information on supported browsers, please see our -[FAQ](/docs/faq) +[FAQ](/docs/troubleshoot/faq) diff --git a/website/content/docs/install/manual-bootstrap.mdx b/website/content/docs/install/manual-bootstrap.mdx index 63c238456f..1bb1797862 100644 --- a/website/content/docs/install/manual-bootstrap.mdx +++ b/website/content/docs/install/manual-bootstrap.mdx @@ -12,13 +12,13 @@ description: >- When deploying Consul to a datacenter for the first time, there is an initial bootstrapping that must be done. As of Consul 0.4, an -[automatic bootstrapping](/docs/guides/bootstrapping) is available and is +[automatic bootstrapping](/docs/install/bootstrapping) is available and is the recommended approach. However, older versions only support a manual bootstrap that is documented here. Generally, the first nodes that are started are the server nodes. Remember that an agent can run in both client and server mode. Server nodes are responsible -for running the [consensus protocol](/docs/internals/consensus), and +for running the [consensus protocol](/docs/architecture/consensus), and storing the cluster state. The client nodes are mostly stateless and rely on the server nodes, so they can be started easily. @@ -35,7 +35,7 @@ something like the following will be logged: ``` Once `Node A` is running, we can start the next set of servers. There is a -[deployment table](/docs/internals/consensus#toc_4) that covers various +[deployment table](/docs/architecture/consensus#deployment_table) that covers various options, but it is recommended to have 3 or 5 total servers per datacenter. A single server deployment is _**highly**_ discouraged as data loss is inevitable in a failure scenario. We start the next servers **without** specifying diff --git a/website/content/docs/install/performance.mdx b/website/content/docs/install/performance.mdx index 85fa3161c7..a2d30e369f 100644 --- a/website/content/docs/install/performance.mdx +++ b/website/content/docs/install/performance.mdx @@ -9,7 +9,7 @@ description: >- # Server Performance -Since Consul servers run a [consensus protocol](/docs/internals/consensus) to +Since Consul servers run a [consensus protocol](/docs/architecture/consensus) to process all write operations and are contacted on nearly all read operations, server performance is critical for overall throughput and health of a Consul cluster. Servers are generally I/O bound for writes because the underlying Raft log store performs a sync diff --git a/website/content/docs/internals/acl.mdx b/website/content/docs/internals/acl.mdx index 9f85926dd2..391ee45031 100644 --- a/website/content/docs/internals/acl.mdx +++ b/website/content/docs/internals/acl.mdx @@ -12,5 +12,5 @@ description: >- This content has been moved into the [ACL Guide](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production). -See [Complete ACL Coverage in Consul 0.8](/docs/acl/acl-legacy) for details +See [Complete ACL Coverage in Consul 0.8](/docs/security/acl/acl-legacy) for details about ACL changes in Consul 0.8 and later. diff --git a/website/content/docs/internals/index.mdx b/website/content/docs/internals/index.mdx index 32fe3ce47e..ca353c2e66 100644 --- a/website/content/docs/internals/index.mdx +++ b/website/content/docs/internals/index.mdx @@ -13,14 +13,14 @@ use it in production. Please review the following documentation to understand how Consul works. -- [Architecture](/docs/internals/architecture) -- [Consensus Protocol](/docs/internals/consensus) -- [Gossip Protocol](/docs/internals/gossip) -- [Network Coordinates](/docs/internals/coordinates) -- [Sessions](/docs/internals/sessions) -- [Anti-Entropy](/docs/internals/anti-entropy) -- [Security Model](/docs/internals/security) -- [Discovery Chain](/docs/internals/discovery-chain) +- [Architecture](/docs/architecture) +- [Consensus Protocol](/docs/architecture/consensus) +- [Gossip Protocol](/docs/architecture/gossip) +- [Network Coordinates](/docs/architecture/coordinates) +- [Sessions](/docs/security/acl/auth-methods/oidc) +- [Anti-Entropy](/docs/architecture/anti-entropy) +- [Security Model](/docs/security) +- [Discovery Chain](/docs/connect/l7-traffic/discovery-chain) -You should also be familiar with [Jepsen testing](/docs/internals/jepsen), before deploying +You should also be familiar with [Jepsen testing](/docs/architecture/jepsen), before deploying a production datacenter. diff --git a/website/content/docs/intro/index.mdx b/website/content/docs/intro/index.mdx index febb4e0956..fe1fe65a15 100644 --- a/website/content/docs/intro/index.mdx +++ b/website/content/docs/intro/index.mdx @@ -86,7 +86,7 @@ application developers, making it perfect for modern, elastic infrastructures. Consul is a distributed, highly available system. This section will cover the basics, purposely omitting some unnecessary detail, so you can get a quick understanding of how Consul works. For more detail, please refer to the -[in-depth architecture overview](/docs/internals/architecture). +[in-depth architecture overview](/docs/architecture). Every node that provides services to Consul runs a _Consul agent_. Running an agent is not required for discovering other services or getting/setting @@ -103,7 +103,7 @@ The servers maintain a _catalog_, which is formed by aggregating information submitted by the agents. The catalog maintains the high-level view of the cluster, including which services are available, which nodes run those services, health information, and more. How agents and the catalog interact can be found -[here](/docs/internals/anti-entropy#catalog). +[here](/docs/architecture/anti-entropy#catalog). Components of your infrastructure that need to discover other services or nodes can query any of the Consul servers _or_ any of the Consul agents. @@ -115,7 +115,7 @@ forward the request to the remote datacenter and return the result. ## Next Steps -- See [how Consul compares to other software](/intro/vs) to assess how it fits into your +- See [how Consul compares to other software](/docs/intro/vs) to assess how it fits into your existing infrastructure. - Continue onwards with [HashiCorp Learn](https://learn.hashicorp.com/tutorials/consul/get-started-install) to learn more about Consul and how to get Consul up and running. diff --git a/website/content/docs/intro/vs/eureka.mdx b/website/content/docs/intro/vs/eureka.mdx index 7fe29af682..f64b4c4e78 100644 --- a/website/content/docs/intro/vs/eureka.mdx +++ b/website/content/docs/intro/vs/eureka.mdx @@ -32,9 +32,9 @@ most applications to be Consul unaware, performing the service registration via files and discovery via DNS or load balancer sidecars. Consul provides a strong consistency guarantee, since servers replicate state using the -[Raft protocol](/docs/internals/consensus). Consul supports a rich set of health checks +[Raft protocol](/docs/architecture/consensus). Consul supports a rich set of health checks including TCP, HTTP, Nagios/Sensu compatible scripts, or TTL based like Eureka. Client nodes -participate in a [gossip based health check](/docs/internals/gossip), which distributes +participate in a [gossip based health check](/docs/architecture/gossip), which distributes the work of health checking, unlike centralized heartbeating which becomes a scalability challenge. Discovery requests are routed to the elected Consul leader which allows them to be strongly consistent by default. Clients that allow for stale reads enable any server to process their request allowing diff --git a/website/content/docs/intro/vs/nagios.mdx b/website/content/docs/intro/vs/nagios.mdx index c075466c78..c1f9aee8d1 100644 --- a/website/content/docs/intro/vs/nagios.mdx +++ b/website/content/docs/intro/vs/nagios.mdx @@ -36,8 +36,8 @@ allowing the system to be much more scalable. An astute reader may notice that if a Consul agent dies, then no edge triggered updates will occur. From the perspective of other nodes, all checks will appear to be in a steady state. However, Consul guards against this as well. The -[gossip protocol](/docs/internals/gossip) used between clients and servers +[gossip protocol](/docs/architecture/gossip) used between clients and servers integrates a distributed failure detector. This means that if a Consul agent fails, the failure will be detected, and thus all checks being run by that node can be assumed failed. This failure detector distributes the work among the entire cluster -while, most importantly, enabling the edge triggered architecture to work. \ No newline at end of file +while, most importantly, enabling the edge triggered architecture to work. diff --git a/website/content/docs/intro/vs/serf.mdx b/website/content/docs/intro/vs/serf.mdx index dc7af98edc..437b76e102 100644 --- a/website/content/docs/intro/vs/serf.mdx +++ b/website/content/docs/intro/vs/serf.mdx @@ -21,7 +21,7 @@ Serf does not provide any high-level features such as service discovery, health checking or key/value storage. Consul is a complete system providing all of those features. -The internal [gossip protocol](/docs/internals/gossip) used within Consul is in +The internal [gossip protocol](/docs/architecture/gossip) used within Consul is in fact powered by the Serf library: Consul leverages the membership and failure detection features and builds upon them to add service discovery. By contrast, the discovery feature of Serf is at a node level, while Consul provides a service and node level @@ -42,7 +42,7 @@ catalog while Serf is only eventually-consistent. In addition to the service level abstraction and improved health checking, Consul provides a key/value store and support for multiple datacenters. Serf can run across the WAN but with degraded performance. Consul makes use -of [multiple gossip pools](/docs/internals/architecture) so that +of [multiple gossip pools](/docs/architecture) so that the performance of Serf over a LAN can be retained while still using it over a WAN for linking together multiple datacenters. diff --git a/website/content/docs/intro/vs/smartstack.mdx b/website/content/docs/intro/vs/smartstack.mdx index dbac8f2e09..668841e614 100644 --- a/website/content/docs/intro/vs/smartstack.mdx +++ b/website/content/docs/intro/vs/smartstack.mdx @@ -25,7 +25,7 @@ and dynamically configures HAProxy. Finally, clients speak to HAProxy, which doe health checking and load balancing across service providers. Consul is a much simpler and more contained system as it does not rely on any external -components. Consul uses an integrated [gossip protocol](/docs/internals/gossip) +components. Consul uses an integrated [gossip protocol](/docs/architecture/gossip) to track all nodes and perform server discovery. This means that server addresses do not need to be hardcoded and updated fleet-wide on changes, unlike SmartStack. diff --git a/website/content/docs/k8s/connect/ingress-gateways.mdx b/website/content/docs/k8s/connect/ingress-gateways.mdx index 17bf2e67b7..8095c63847 100644 --- a/website/content/docs/k8s/connect/ingress-gateways.mdx +++ b/website/content/docs/k8s/connect/ingress-gateways.mdx @@ -8,10 +8,10 @@ description: Configuring Ingress Gateways on Kubernetes -> 1.9.0+: This feature is available in Consul versions 1.9.0 and higher -~> This topic requires familiarity with [Ingress Gateways](/docs/connect/ingress-gateway). +~> This topic requires familiarity with [Ingress Gateways](/docs/connect/gateways/ingress-gateway). This page describes how to enable external access to Connect Service Mesh services running inside Kubernetes using Consul ingress gateways. -See [Ingress Gateways](/docs/connect/ingress-gateway) for more information on use-cases and how it works. +See [Ingress Gateways](/docs/connect/gateways/ingress-gateway) for more information on use-cases and how it works. Adding an ingress gateway is a multi-step process that consists of the following steps: diff --git a/website/content/docs/k8s/connect/terminating-gateways.mdx b/website/content/docs/k8s/connect/terminating-gateways.mdx index 9326b695e8..c4a90a9230 100644 --- a/website/content/docs/k8s/connect/terminating-gateways.mdx +++ b/website/content/docs/k8s/connect/terminating-gateways.mdx @@ -8,7 +8,7 @@ description: Configuring Terminating Gateways on Kubernetes -> 1.9.0+: This feature is available in Consul versions 1.9.0 and higher -~> This topic requires familiarity with [Terminating Gateways](/docs/connect/terminating-gateway). +~> This topic requires familiarity with [Terminating Gateways](/docs/connect/gateways/terminating-gateway). Adding a terminating gateway is a multi-step process: diff --git a/website/content/docs/k8s/index.mdx b/website/content/docs/k8s/index.mdx index e3efa8d0d8..69817d21ba 100644 --- a/website/content/docs/k8s/index.mdx +++ b/website/content/docs/k8s/index.mdx @@ -48,7 +48,7 @@ Kubernetes can choose to leverage Consul. ## Architecture Consul runs on Kubernetes with the same -[architecture](/docs/internals/architecture) +[architecture](/docs/architecture) as other platforms. There are some benefits Kubernetes can provide that eases operating a Consul cluster and we document those below. The standard [production deployment guide](https://learn.hashicorp.com/consul/datacenter-deploy/deployment-guide) is still an diff --git a/website/content/docs/k8s/installation/deployment-configurations/clients-outside-kubernetes.mdx b/website/content/docs/k8s/installation/deployment-configurations/clients-outside-kubernetes.mdx index 6bb8ad43b2..d35b818a82 100644 --- a/website/content/docs/k8s/installation/deployment-configurations/clients-outside-kubernetes.mdx +++ b/website/content/docs/k8s/installation/deployment-configurations/clients-outside-kubernetes.mdx @@ -26,7 +26,7 @@ with the server pod or host IP addresses. ## Auto-join The recommended way to join a cluster running within Kubernetes is to -use the ["k8s" cloud auto-join provider](/docs/agent/cloud-auto-join#kubernetes-k8s). +use the ["k8s" cloud auto-join provider](/docs/install/cloud-auto-join#kubernetes-k8s). The auto-join provider dynamically discovers IP addresses to join using the Kubernetes API. It authenticates with Kubernetes using a standard diff --git a/website/content/docs/k8s/installation/deployment-configurations/servers-outside-kubernetes.mdx b/website/content/docs/k8s/installation/deployment-configurations/servers-outside-kubernetes.mdx index dd3031d0f3..2e5c758017 100644 --- a/website/content/docs/k8s/installation/deployment-configurations/servers-outside-kubernetes.mdx +++ b/website/content/docs/k8s/installation/deployment-configurations/servers-outside-kubernetes.mdx @@ -23,7 +23,7 @@ their pod IPs (`false`). Finally, `client.join` is set to an array of valid [`-retry-join` values](/docs/agent/options#retry-join). In the -example above, a fake [cloud auto-join](/docs/agent/cloud-auto-join) +example above, a fake [cloud auto-join](/docs/install/cloud-auto-join) value is specified. This should be set to resolve to the proper addresses of your existing Consul cluster. @@ -57,7 +57,7 @@ You may also consider adopting Consul Enterprise for -> **Note:** Consul on Kubernetes currently does not support external servers that require mutual authentication for the HTTPS clients of the Consul servers, that is when servers have either `verify_incoming` or `verify_incoming_https` set to `true`. -As noted in the [Security Model](/docs/internals/security#secure-configuration), +As noted in the [Security Model](/docs/security#secure-configuration), that setting isn't strictly necessary to support Consul's threat model as it is recommended that all requests contain a valid ACL token. @@ -94,7 +94,7 @@ to help initialize ACL tokens for Consul clients and consul-k8s components for y ### Manually Bootstrapping ACLs -If you would like to call the [ACL bootstrapping API](/api/acl/acl#bootstrap-acls) yourself or if your cluster has already been bootstrapped with ACLs, +If you would like to call the [ACL bootstrapping API](/api-docs/acl#bootstrap-acls) yourself or if your cluster has already been bootstrapped with ACLs, you can provide the bootstrap token to the Helm chart. The Helm chart will then use this token to configure ACLs for Consul clients and any consul-k8s components you are enabling. @@ -128,7 +128,7 @@ The bootstrap token requires the following minimal permissions: Next, configure external servers. The Helm chart will use this configuration to talk to the Consul server's API to create policies, tokens, and an auth method. If you are [enabling Consul Connect](/docs/k8s/connect), `k8sAuthMethodHost` should be set to the address of your Kubernetes API server -so that the Consul servers can validate a Kubernetes service account token when using the [Kubernetes auth method](/docs/acl/auth-methods/kubernetes) +so that the Consul servers can validate a Kubernetes service account token when using the [Kubernetes auth method](/docs/security/acl/auth-methods/kubernetes) with `consul login`. diff --git a/website/content/docs/k8s/installation/install.mdx b/website/content/docs/k8s/installation/install.mdx index 170a8212db..9d0543519f 100644 --- a/website/content/docs/k8s/installation/install.mdx +++ b/website/content/docs/k8s/installation/install.mdx @@ -98,7 +98,7 @@ cluster with default configurations. We strongly recommend [learning about the c of Consul. This provides a less complicated out-of-box experience for new users, but is not appropriate for a production setup. We strongly recommend using a properly-secured Kubernetes cluster or making sure that you understand and enable -the [recommended security features](/docs/internals/security). Currently, +the [recommended security features](/docs/security). Currently, some of these features are not supported in the Helm chart and require additional manual configuration. @@ -180,7 +180,7 @@ NAME: consul ``` If you've already installed Consul and want to make changes, you'll need to run -`helm upgrade`. See [Upgrading](/docs/k8s/operations/upgrading) for more details. +`helm upgrade`. See [Upgrading](/docs/k8s/upgrade) for more details. ## Viewing the Consul UI diff --git a/website/content/docs/k8s/installation/multi-cluster/index.mdx b/website/content/docs/k8s/installation/multi-cluster/index.mdx index 85bf6d801f..1daa074fec 100644 --- a/website/content/docs/k8s/installation/multi-cluster/index.mdx +++ b/website/content/docs/k8s/installation/multi-cluster/index.mdx @@ -13,7 +13,7 @@ with one another. This enables the following features: - Services on all clusters can make calls to each other through Consul Service Mesh. - [Intentions](/docs/connect/intentions) can be used to enforce rules about which services can communicate across all clusters. -- [L7 Routing Rules](/docs/connect/l7-traffic-management) can enable multi-cluster failover +- [L7 Routing Rules](/docs/connect/l7-traffic) can enable multi-cluster failover and traffic splitting. - The Consul UI has a drop-down menu that lets you navigate between datacenters. diff --git a/website/content/docs/k8s/installation/multi-cluster/kubernetes.mdx b/website/content/docs/k8s/installation/multi-cluster/kubernetes.mdx index bbb6520077..6c90549035 100644 --- a/website/content/docs/k8s/installation/multi-cluster/kubernetes.mdx +++ b/website/content/docs/k8s/installation/multi-cluster/kubernetes.mdx @@ -9,7 +9,7 @@ description: >- -> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher -~> This topic requires familiarity with [Mesh Gateways](/docs/connect/mesh-gateway) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways). +~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). -> Looking for a step-by-step guide? Please follow our Learn tutorial: [Secure and Route Service Mesh Communication Across Kubernetes](https://learn.hashicorp.com/tutorials/consul/kubernetes-mesh-gateways). @@ -163,7 +163,7 @@ If you've set `enableAutoEncrypt: true`, this is also supported. creates a Kubernetes Load Balancer service. If you wish to customize the mesh gateway, see the [Helm reference](/docs/k8s/helm#v-meshgateway) for that setting. -With the above settings added to your existing config, follow the [Upgrading](/docs/k8s/operations/upgrading) +With the above settings added to your existing config, follow the [Upgrading](/docs/k8s/upgrade) guide to upgrade your cluster and then come back to the [Federation Secret](#federation-secret) section. -> **NOTE:** You must be using consul-helm 0.21.0+. diff --git a/website/content/docs/k8s/installation/multi-cluster/vms-and-kubernetes.mdx b/website/content/docs/k8s/installation/multi-cluster/vms-and-kubernetes.mdx index f003ceefcf..dc238649c1 100644 --- a/website/content/docs/k8s/installation/multi-cluster/vms-and-kubernetes.mdx +++ b/website/content/docs/k8s/installation/multi-cluster/vms-and-kubernetes.mdx @@ -9,7 +9,7 @@ description: >- -> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher -~> This topic requires familiarity with [Mesh Gateways](/docs/connect/mesh-gateway) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways). +~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). Consul datacenters running on non-kubernetes platforms like VMs or bare metal can be federated with Kubernetes datacenters. Just like with Kubernetes, one datacenter @@ -202,7 +202,7 @@ construct the [Federation Secret](/docs/k8s/installation/multi-cluster/kubernete Kubernetes clusters as secondaries. -> Your VM cluster must be running mesh gateways, and have mesh gateway WAN -federation enabled. See [WAN Federation via Mesh Gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways). +federation enabled. See [WAN Federation via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). You'll need: diff --git a/website/content/docs/k8s/operations/tls-on-existing-cluster.mdx b/website/content/docs/k8s/operations/tls-on-existing-cluster.mdx index daa3522ef1..2b69be5380 100644 --- a/website/content/docs/k8s/operations/tls-on-existing-cluster.mdx +++ b/website/content/docs/k8s/operations/tls-on-existing-cluster.mdx @@ -34,7 +34,7 @@ This upgrade will trigger a rolling update of the clients, as well as any other `consul-k8s` components, such as sync catalog or client snapshot deployments. 1. Perform a rolling upgrade of the servers, as described in - [Upgrade Consul Servers](/docs/k8s/operations/upgrading#upgrading-consul-servers). + [Upgrade Consul Servers](/docs/k8s/upgrade#upgrading-consul-servers). 1. Repeat steps 1 and 2, turning on TLS verification by setting `global.tls.verify` to `true`. @@ -71,7 +71,7 @@ applications to it. ``` In this configuration, we're setting `server.updatePartition` to the number of - server replicas as described in [Upgrade Consul Servers](/docs/k8s/operations/upgrading#upgrading-consul-servers) + server replicas as described in [Upgrade Consul Servers](/docs/k8s/upgrade#upgrading-consul-servers) and `client.updateStrategy` to `OnDelete` to manually trigger an upgrade of the clients. 1. Run `helm upgrade` with the above config file. The upgrade will trigger an update of all @@ -94,7 +94,7 @@ applications to it. the sidecar proxy. Also, Kubernetes should schedule these applications on the new node pool. 1. Perform a rolling upgrade of the servers described in - [Upgrade Consul Servers](/docs/k8s/operations/upgrading#upgrading-consul-servers). + [Upgrade Consul Servers](/docs/k8s/upgrade#upgrading-consul-servers). 1. If everything is healthy, delete the old node pool. diff --git a/website/content/docs/k8s/service-sync.mdx b/website/content/docs/k8s/service-sync.mdx index 182de64c47..686b50e06a 100644 --- a/website/content/docs/k8s/service-sync.mdx +++ b/website/content/docs/k8s/service-sync.mdx @@ -92,9 +92,9 @@ then the sync program should work. For Consul, if ACLs are configured on the cluster, a Consul [ACL token](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production) -will need to be provided. Review the [ACL rules](/docs/agent/acl-rules) +will need to be provided. Review the [ACL rules](/docs/security/acl/acl-rules) when creating this token so that it only allows the necessary privileges. The catalog -sync process accepts this token by using the [`CONSUL_HTTP_TOKEN`](/docs/commands#consul_http_token) +sync process accepts this token by using the [`CONSUL_HTTP_TOKEN`](/commands#consul_http_token) environment variable. This token should be set as a [Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/#creating-your-own-secrets) and referenced in the Helm chart. diff --git a/website/content/docs/k8s/upgrade/index.mdx b/website/content/docs/k8s/upgrade/index.mdx index 6909b4da93..2a2eeb67e5 100644 --- a/website/content/docs/k8s/upgrade/index.mdx +++ b/website/content/docs/k8s/upgrade/index.mdx @@ -323,4 +323,4 @@ Consul clients. If you already have a Consul cluster deployed on Kubernetes and would like to turn on TLS for internal Consul communication, please see -[Configuring TLS on an Existing Cluster](/docs/k8s/tls-on-existing-cluster). +[Configuring TLS on an Existing Cluster](/docs/k8s/operations/tls-on-existing-cluster). diff --git a/website/content/docs/nia/api/tasks.mdx b/website/content/docs/nia/api/tasks.mdx index 342e72eadd..9dbcb70502 100644 --- a/website/content/docs/nia/api/tasks.mdx +++ b/website/content/docs/nia/api/tasks.mdx @@ -24,7 +24,7 @@ This endpoint allows patch updates to specifically supported fields for existing #### Response Fields -* `inspect` - Information on how resources would be changed given a proposed task update, similar to [inspect-mode](/docs/nia/cli/cli-overview#inspect-mode). This is only returned when passed the `run=inspect` request parameter +* `inspect` - Information on how resources would be changed given a proposed task update, similar to [inspect-mode](/docs/nia/cli#inspect-mode). This is only returned when passed the `run=inspect` request parameter * `changes_present` - (bool) Whether or not changes were detected for running the proposed task update * `plan` - (string) The Terraform plan generated for the proposed task update . Note: a non-empty string does not necessarily indicate changes were detected. diff --git a/website/content/docs/nia/cli/task.mdx b/website/content/docs/nia/cli/task.mdx index fdc46bc72e..4e6caa9582 100644 --- a/website/content/docs/nia/cli/task.mdx +++ b/website/content/docs/nia/cli/task.mdx @@ -8,7 +8,7 @@ description: >- ## task enable -`task enable` command enables an existing task so that it will run and update task resources. If the task is already enabled, it will return a success. The command generates and outputs a Terraform plan, similar to [inspect-mode](/docs/nia/cli/cli-overview#inspect-mode), of how resources will be modified if task becomes enabled. If resources changes are detected, the command will ask for user approval before enabling the task. If no resources are detected, the command will go ahead and enable the task. +`task enable` command enables an existing task so that it will run and update task resources. If the task is already enabled, it will return a success. The command generates and outputs a Terraform plan, similar to [inspect-mode](/docs/nia/cli#inspect-mode), of how resources will be modified if task becomes enabled. If resources changes are detected, the command will ask for user approval before enabling the task. If no resources are detected, the command will go ahead and enable the task. ### Usage `consul-terraform-sync task enable [options] ` @@ -16,7 +16,7 @@ description: >- **Arguments:** - `task_name` - (string: required) The name of the task to enable -**Options:** Currently only supporting [general options](/docs/nia/cli/cli-overview#general-options) +**Options:** Currently only supporting [general options](/docs/nia/cli#general-options) ### Example @@ -62,7 +62,7 @@ Enter a value: yes **Arguments:** - `task_name` - (string: required) The name of the task to disable -**Options:** Currently only supporting [general options](/docs/nia/cli/cli-overview#general-options) +**Options:** Currently only supporting [general options](/docs/nia/cli#general-options) ### Example diff --git a/website/content/docs/nia/installation/run.mdx b/website/content/docs/nia/installation/run.mdx index 7deed8e4f9..f6e3049f49 100644 --- a/website/content/docs/nia/installation/run.mdx +++ b/website/content/docs/nia/installation/run.mdx @@ -13,7 +13,7 @@ description: >- $ mv ~/Downloads/consul-terraform-sync /usr/local/bin/consul-terraform-sync ``` -2. Create the config.hcl file, all the options are available [here](/docs/nia/installation/configuration). +2. Create the config.hcl file, all the options are available [here](/docs/nia/configuration). 3. Run consul-terraform-sync. diff --git a/website/content/docs/security/acl/acl-legacy.mdx b/website/content/docs/security/acl/acl-legacy.mdx index b556ee2b00..629fa0b1e1 100644 --- a/website/content/docs/security/acl/acl-legacy.mdx +++ b/website/content/docs/security/acl/acl-legacy.mdx @@ -10,24 +10,24 @@ description: >- # ACL System in Legacy Mode --> **1.3.0 and earlier:** This document only applies in Consul versions 1.3.0 and before. If you are using version 1.4.0 or later please use the updated documentation [here](/docs/acl/acl-system). +-> **1.3.0 and earlier:** This document only applies in Consul versions 1.3.0 and before. If you are using version 1.4.0 or later please use the updated documentation [here](/docs/security/acl/acl-system). ~> **Alert: Deprecation Notice** The ACL system described here was Consul's original ACL implementation. The legacy ACL system was deprecated in Consul 1.4.0 and removed in Consul 1.11.0. -The documentation for the new ACL system can be found [here](/docs/acl/acl-system). For information on how to migrate to the new ACL System, please read the [Migrate Legacy ACL Tokens](https://learn.hashicorp.com/tutorials/consul/access-control-token-migration) tutorial. +The documentation for the new ACL system can be found [here](/docs/security/acl/acl-system). For information on how to migrate to the new ACL System, please read the [Migrate Legacy ACL Tokens](https://learn.hashicorp.com/tutorials/consul/access-control-token-migration) tutorial. The legacy documentation has two sections. - The [New ACL System Differences](#new-acl-system-differences) section - details the differences between ACLs in Consul 1.4.0 and older versions. You should read this section before upgrading to Consul 1.4.0 and [migrating](/docs/acl/acl-migrate-tokens) tokens. + details the differences between ACLs in Consul 1.4.0 and older versions. You should read this section before upgrading to Consul 1.4.0 and [migrating](/docs/security/acl/acl-migrate-tokens) tokens. - The [Legacy ACL System documentation](#legacy-acl-system) section details the ACL system in Consul 1.3.0 and older. # New ACL System Differences -The [ACL System documentation](/docs/acl/acl-system) and [legacy ACL -documentation](/docs/acl/acl-legacy) describes the new and old systems in +The [ACL System documentation](/docs/security/acl/acl-system) and [legacy ACL +documentation](/docs/security/acl/acl-legacy) describes the new and old systems in detail. Below is a summary of the changes that need to be considered when migrating legacy tokens to the new system. @@ -82,7 +82,7 @@ advantage of the new ACL system improvements. They are documented fully under - [`GET /acl/list` - List Legacy Tokens](/api/acl/legacy#list-acls) The new ACL system includes new API endpoints to manage -the [ACL System](/api/acl/acl), [Tokens](/api/acl/tokens) +the [ACL System](/api-docs/acl), [Tokens](/api/acl/tokens) and [Policies](/api/acl/policies). # Legacy ACL System @@ -105,7 +105,7 @@ all while providing administrative insight. #### ACL Tokens The ACL system is based on tokens, which are managed by Consul operators via Consul's -[ACL API](/api/acl/acl), or systems like +[ACL API](/api-docs/acl), or systems like [HashiCorp's Vault](https://www.vaultproject.io/docs/secrets/consul). Every token has an ID, name, type, and rule set. The ID is a randomly generated @@ -117,12 +117,12 @@ The token ID is passed along with each RPC request to the servers. Consul's [HTTP endpoints](/api) can accept tokens via the `token` query string parameter, or the `X-Consul-Token` request header, or Authorization Bearer token [RFC6750](https://tools.ietf.org/html/rfc6750). Consul's -[CLI commands](/docs/commands) can accept tokens via the +[CLI commands](/commands) can accept tokens via the `token` argument, or the `CONSUL_HTTP_TOKEN` environment variable. If no token is provided, the rules associated with a special, configurable anonymous token are automatically applied. The anonymous token is managed using the -[ACL API](/api/acl/acl) like any other ACL token, but using `anonymous` for the ID. +[ACL API](/api-docs/acl) like any other ACL token, but using `anonymous` for the ID. #### ACL Rules and Scope @@ -171,7 +171,7 @@ Constructing rules from these policies is covered in detail in the All nodes (clients and servers) must be configured with a [`acl_datacenter`](/docs/agent/options#acl_datacenter) which enables ACL enforcement but also specifies the authoritative datacenter. Consul relies on -[RPC forwarding](/docs/internals/architecture) to support multi-datacenter +[RPC forwarding](/docs/architecture) to support multi-datacenter configurations. However, because requests can be made across datacenter boundaries, ACL tokens must be valid globally. To avoid consistency issues, a single datacenter is considered authoritative and stores the canonical set of tokens. @@ -241,7 +241,7 @@ In Consul 0.9.1 and later, the agent ACL tokens can be introduced or updated via The [`acl_agent_token`](/docs/agent/options#acl_agent_token) is a special token that is used for an agent's internal operations. It isn't used directly for any user-initiated operations like the [`acl_token`](/docs/agent/options#acl_token), though if the `acl_agent_token` isn't configured the `acl_token` will be used. The ACL agent token is used for the following operations by the agent: 1. Updating the agent's node entry using the [Catalog API](/api/catalog), including updating its node metadata, tagged addresses, and network coordinates -2. Performing [anti-entropy](/docs/internals/anti-entropy) syncing, in particular reading the node metadata and services registered with the catalog +2. Performing [anti-entropy](/docs/architecture/anti-entropy) syncing, in particular reading the node metadata and services registered with the catalog 3. Reading and writing the special `_rexec` section of the KV store when executing [`consul exec`](/commands/exec) commands Here's an example policy sufficient to accomplish the above for a node called `mynode`: @@ -274,7 +274,7 @@ The first step for bootstrapping ACLs is to enable ACLs on the Consul servers in datacenter. In this example, we are configuring the following: 1. An ACL datacenter of "dc1", which is where these servers are -2. An ACL master token of "b1gs33cr3t"; see below for an alternative using the [/v1/acl/bootstrap API](/api/acl/acl#bootstrap-acls) +2. An ACL master token of "b1gs33cr3t"; see below for an alternative using the [/v1/acl/bootstrap API](/api-docs/acl#bootstrap-acls) 3. A default policy of "deny" which means we are in allowlist mode 4. A down policy of "extend-cache" which means that we will ignore token TTLs during an outage @@ -302,7 +302,7 @@ a server acquires cluster leadership. If you would like to install or change the [`acl_master_token`](/docs/agent/options#acl_master_token) in the configuration for all servers. Once this is done, restart the current leader to force a leader election. -In Consul 0.9.1 and later, you can use the [/v1/acl/bootstrap API](/api/acl/acl#bootstrap-acls) +In Consul 0.9.1 and later, you can use the [/v1/acl/bootstrap API](/api-docs/acl#bootstrap-acls) to make the initial master token, so a token never needs to be placed into a configuration file. To use this approach, omit `acl_master_token` from the above config and then call the API: @@ -319,7 +319,7 @@ It's only possible to bootstrap one time, and bootstrapping will be disabled if token was configured and created. Once the ACL system is bootstrapped, ACL tokens can be managed through the -[ACL API](/api/acl/acl). +[ACL API](/api-docs/acl). #### Create an Agent Token @@ -334,7 +334,7 @@ servers related to permission denied errors: These errors are because the agent doesn't yet have a properly configured [`acl_agent_token`](/docs/agent/options#acl_agent_token) that it can use for its own internal operations like updating its node information in the catalog and performing -[anti-entropy](/docs/internals/anti-entropy) syncing. We can create a token using the +[anti-entropy](/docs/architecture/anti-entropy) syncing. We can create a token using the ACL API, and the ACL master token we set in the previous step: ```shell-session @@ -418,7 +418,7 @@ environment it is recommended that each client get an ACL agent token with `node privileges for just its own node name prefix, and `service` read privileges for just the service prefixes expected to be registered on that client. -[Anti-entropy](/docs/internals/anti-entropy) syncing requires the ACL agent token +[Anti-entropy](/docs/architecture/anti-entropy) syncing requires the ACL agent token to have `service` read privileges for all services that may be registered with the agent, so generally an empty `service` prefix can be used, as shown in the example. @@ -591,7 +591,7 @@ The token can then be set on the "settings" page of the UI. #### Next Steps The examples above configure a basic ACL environment with the ability to see all nodes -by default, and limited access to just the "consul" service. The [ACL API](/api/acl/acl) +by default, and limited access to just the "consul" service. The [ACL API](/api-docs/acl) can be used to create tokens for applications specific to their intended use, and to create more specific ACL agent tokens for each agent's expected role. @@ -658,7 +658,7 @@ This is equivalent to the following JSON input: } ``` -The [ACL API](/api/acl/acl) allows either HCL or JSON to be used to define the content +The [ACL API](/api-docs/acl) allows either HCL or JSON to be used to define the content of the rules section. Here's a sample request using the HCL form: @@ -876,7 +876,7 @@ to a given service name, but only on an allowed subset of node names. Node rules come into play when using the [Agent API](/api/agent) to register node-level checks. The agent will check tokens locally as a check is registered, and Consul also performs -periodic [anti-entropy](/docs/internals/anti-entropy) syncs, which may require an +periodic [anti-entropy](/docs/architecture/anti-entropy) syncs, which may require an ACL token to complete. To accommodate this, Consul provides two methods of configuring ACL tokens to use for registration events: @@ -886,8 +886,8 @@ to use for registration events: 2. Providing an ACL token with service and check definitions at registration time. This allows for greater flexibility and enables the use of multiple tokens on the same agent. Examples of what this looks like are - available for both [services](/docs/agent/services) and - [checks](/docs/agent/checks). Tokens may also be passed to the + available for both [services](/docs/discovery/services) and + [checks](/docs/discovery/checks). Tokens may also be passed to the [HTTP API](/api) for operations that require them. In addition to ACLs, in Consul 0.9.0 and later, the agent must be configured with @@ -1033,7 +1033,7 @@ used to filter the results of the query. Service rules come into play when using the [Agent API](/api/agent) to register services or checks. The agent will check tokens locally as a service or check is registered, and Consul also -performs periodic [anti-entropy](/docs/internals/anti-entropy) syncs, which may require an +performs periodic [anti-entropy](/docs/architecture/anti-entropy) syncs, which may require an ACL token to complete. To accommodate this, Consul provides two methods of configuring ACL tokens to use for registration events: @@ -1043,8 +1043,8 @@ to use for registration events: 2. Providing an ACL token with service and check definitions at registration time. This allows for greater flexibility and enables the use of multiple tokens on the same agent. Examples of what this looks like are available for - both [services](/docs/agent/services) and - [checks](/docs/agent/checks). Tokens may also be passed to the [HTTP + both [services](/docs/discovery/services) and + [checks](/docs/discovery/checks). Tokens may also be passed to the [HTTP API](/api) for operations that require them. **Note:** all tokens passed to an agent are persisted on local disk to allow recovery from restarts. See [`-data-dir` flag @@ -1115,7 +1115,7 @@ a large set of ACLs. If there's a partition or other outage affecting the authoritative datacenter, and the [`acl_down_policy`](/docs/agent/options#acl_down_policy) is set to "extend-cache", tokens will be resolved during the outage using the -replicated set of ACLs. An [ACL replication status](/api/acl/acl#check-acl-replication) +replicated set of ACLs. An [ACL replication status](/api-docs/acl#check-acl-replication) endpoint is available to monitor the health of the replication process. Also note that in recent versions of Consul (greater than 1.2.0), using `acl_down_policy = "async-cache"` refreshes token asynchronously when an ACL is @@ -1133,7 +1133,7 @@ using a process like this: 1. Enable ACL replication in all datacenters to allow continuation of service during the migration, and to populate the target datacenter. Verify replication is healthy and caught up to the current ACL index in the target datacenter - using the [ACL replication status](/api/acl/acl#check-acl-replication) + using the [ACL replication status](/api-docs/acl#check-acl-replication) endpoint. 2. Turn down the old authoritative datacenter servers. 3. Rolling restart the agents in the target datacenter and change the diff --git a/website/content/docs/security/acl/acl-rules.mdx b/website/content/docs/security/acl/acl-rules.mdx index 1571f754b2..f104458e68 100644 --- a/website/content/docs/security/acl/acl-rules.mdx +++ b/website/content/docs/security/acl/acl-rules.mdx @@ -10,9 +10,9 @@ description: >- # ACL Rules -This topic describes how to configure rules for Consul's access control list (ACL) system. The ACL system enables you to control access to data and APIs. Refer to the [ACL system documentation](/docs/acl/acl-system) to learn more about ACLs. +This topic describes how to configure rules for Consul's access control list (ACL) system. The ACL system enables you to control access to data and APIs. Refer to the [ACL system documentation](/docs/security/acl/acl-system) to learn more about ACLs. --> **1.4.0 and later:** This topic applies to Consul versions 1.4.0 and later. Refer to the [legacy ACL system documentation](/docs/acl/acl-legacy) for older versions of Consul. +-> **1.4.0 and later:** This topic applies to Consul versions 1.4.0 and later. Refer to the [legacy ACL system documentation](/docs/security/acl/acl-legacy) for older versions of Consul. ## Rule Specification @@ -269,7 +269,7 @@ operator = "read" ## Defining Rules with the ACL API -You can configure ACLs remotely by calling the ACL HTTP API endpoint and including rules in the payload. The endpoint takes data formatted in HCL or JSON. Refer to the [ACL HTTP API endpoint documentation](/api/acl/acl) for details about the API. +You can configure ACLs remotely by calling the ACL HTTP API endpoint and including rules in the payload. The endpoint takes data formatted in HCL or JSON. Refer to the [ACL HTTP API endpoint documentation](/api-docs/acl) for details about the API. The following example adds a set of rules that apply to the `key` resource (Consul K/V) within the `my-app-policy` policy. The rules are formatted in HCL, but they are wrapped in JSON so that the data can be sent using cURL: @@ -318,7 +318,7 @@ The following table provides an overview of the resources you can use to create | Resource | Description | Labels | |-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|----------| -| `acl` | Controls access to ACL operations in the [ACL API](/api/acl/acl).
See [ACL Resource Rules](#acl-resource-rules) for details. | No | +| `acl` | Controls access to ACL operations in the [ACL API](/api-docs/acl).
See [ACL Resource Rules](#acl-resource-rules) for details. | No | | `partition`
`partition_prefix` | Controls access to one or more admin partitions.
See [Admin Partition Rules](#admin-partition-rules) for details. | Yes | | `agent`
`agent_prefix` | Controls access to the utility operations in the [Agent API](/api/agent), such as `join` and `leave`.
See [Agent Rules](#agent-rules) for details. | Yes | | `event`
`event_prefix` | Controls access to event operations in the [Event API](/api/event), such as firing and listing events.
See [Event Rules](#event-rules) for details. | Yes | @@ -336,7 +336,7 @@ The following topics provide additional details about the available resources. ### ACL Resource Rules -The `acl` resource controls access to ACL operations in the [ACL API](/api/acl/acl). Only one `acl` rule is allowed per policy. The value is set to one of the [policy dispositions](#policy-dispositions). +The `acl` resource controls access to ACL operations in the [ACL API](/api-docs/acl). Only one `acl` rule is allowed per policy. The value is set to one of the [policy dispositions](#policy-dispositions). The `acl = "write"` rule is also required to create snapshots. This is because all token secrets are contained within the snapshot. @@ -875,14 +875,14 @@ The [`acl.token.default`](/docs/agent/options#acl_tokens_default) used by the ag Node rules are used to filter query results when reading from the catalog or retrieving information from the health endpoints. This allows for configurations where a token has access to a given service name, but only on an allowed subset of node names. -Consul agents check tokens locally when health checks are registered and when Consul performs periodic [anti-entropy](/docs/internals/anti-entropy) syncs. +Consul agents check tokens locally when health checks are registered and when Consul performs periodic [anti-entropy](/docs/architecture/anti-entropy) syncs. These actions may required an ACL token to complete. Use the following methods to configure ACL tokens for registration events: * Configure a global token in the [acl.tokens.default](/docs/agent/options#acl_tokens_default) parameter. This allows a single token to be used during all check registration operations. * Provide an ACL token with service and check definitions at registration time. This allows for greater flexibility and enables the use of multiple tokens on the same agent. -Refer to the [services](/docs/agent/services) and [checks](/docs/agent/checks) documentation for examples. +Refer to the [services](/docs/discovery/services) and [checks](/docs/discovery/checks) documentation for examples. Tokens may also be passed to the [HTTP API](/api) for operations that require them. ### Operator Rules @@ -1068,7 +1068,7 @@ used to filter the results of the query. Service rules come into play when using the [Agent API](/api/agent) to register services or checks. The agent will check tokens locally as a service or check is registered, and Consul also -performs periodic [anti-entropy](/docs/internals/anti-entropy) syncs, which may require an +performs periodic [anti-entropy](/docs/architecture/anti-entropy) syncs, which may require an ACL token to complete. To accommodate this, Consul provides two methods of configuring ACL tokens to use for registration events: @@ -1078,8 +1078,8 @@ to use for registration events: 2. Providing an ACL token with service and check definitions at registration time. This allows for greater flexibility and enables the use of multiple tokens on the same agent. Examples of what this looks like are available for - both [services](/docs/agent/services) and - [checks](/docs/agent/checks). Tokens may also be passed to the [HTTP + both [services](/docs/discovery/services) and + [checks](/docs/discovery/checks). Tokens may also be passed to the [HTTP API](/api) for operations that require them. **Note:** all tokens passed to an agent are persisted on local disk to allow recovery from restarts. See [`-data-dir` flag diff --git a/website/content/docs/security/acl/acl-system.mdx b/website/content/docs/security/acl/acl-system.mdx index 8f951d0043..820629c9f7 100644 --- a/website/content/docs/security/acl/acl-system.mdx +++ b/website/content/docs/security/acl/acl-system.mdx @@ -10,7 +10,7 @@ description: >- # ACL System --> **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/acl/acl-legacy). +-> **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/security/acl/acl-legacy). Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL is [Capability-based](https://en.wikipedia.org/wiki/Capability-based_security), relying on tokens which @@ -57,10 +57,10 @@ may benefit from additional components in the ACL system: independently configured. (Added in Consul 1.8.1) - **ACL Auth Methods and Binding Rules** - To learn more about these topics, - see the [auth methods documentation page](/docs/acl/auth-methods). + see the [auth methods documentation page](/docs/security/acl/auth-methods). ACL tokens, policies, roles, auth methods, and binding rules are managed by -Consul operators via Consul's [ACL API](/api/acl/acl), +Consul operators via Consul's [ACL API](/api-docs/acl), [ACL CLI](/commands/acl), or systems like [HashiCorp's Vault](https://www.vaultproject.io/docs/secrets/consul). @@ -78,12 +78,12 @@ ACL policies can have the following attributes: | `ID` | The policy's auto-generated public identifier. | N/A | N/A | | `name` | Unique name for the policy. | Required | none | | `description` | Human readable description of the policy. | Optional | none | -| `rules` | Set of rules granting or denying permissions. See the [Rule Specification](/docs/acl/acl-rules#rule-specification) documentation for more details. | Optional | none | -| `datacenter` | Datacenter in which the policy is valid. More than one datacenter can be specified. | Optional | none | +| `rules` | Set of rules granting or denying permissions. See the [Rule Specification](/docs/security/acl/acl-rules#rule-specification) documentation for more details. | Optional | none | +| `datacenter` | Datacenter in which the policy is valid. More than one datacenter can be specified. | Optional | none | | `namespace` | Namespace in which the policy is valid. Added in Consul Enterprise 1.7.0. | Optional | `default` | | `partition` | Admin partition in which the policy is valid. Added in Consul Enterprise 1.11.0 | Optional | `default` | --> **Non-default Namespaces and Partitions** - Rules defined in a policy tied to an namespace or admin partition other than `default` can only grant a subset of privileges that affect the namespace or partition. See [Namespace Rules](/docs/acl/acl-rules#namespace-rules) and [Admin Partition Rules](/docs/acl/acl-rules#admin-partition-rules) for additional information. +-> **Non-default Namespaces and Partitions** - Rules defined in a policy tied to an namespace or admin partition other than `default` can only grant a subset of privileges that affect the namespace or partition. See [Namespace Rules](/docs/security/acl/acl-rules#namespace-rules) and [Admin Partition Rules](/docs/security/acl/acl-rules#admin-partition-rules) for additional information. You can view the current ACL policies on the command line or through the API. The following example demonstrates the command line usage: @@ -130,7 +130,7 @@ Note that the `Hash`, `CreateIndex`, and `ModifyIndex` attributes are also print -> Added in Consul 1.5.0 -An ACL service identity is an [ACL policy](/docs/acl/acl-system#acl-policies) template for expressing a link to a policy +An ACL service identity is an [ACL policy](/docs/security/acl/acl-system#acl-policies) template for expressing a link to a policy suitable for use in [Consul Connect](/docs/connect). They are usable on both tokens and roles and are composed of the following elements: @@ -144,7 +144,7 @@ template to aid in avoiding boilerplate policy creation. During the authorization process, the configured service identity is automatically applied as a policy with the following preconfigured [ACL -rules](/docs/acl/acl-system#acl-rules-and-scope): +rules](/docs/security/acl/acl-system#acl-rules-and-scope): ```hcl # Allow the service and its sidecar proxy to register into the catalog. @@ -173,7 +173,7 @@ examples of using a service identity. -> Added in Consul 1.8.1 -An ACL node identity is an [ACL policy](/docs/acl/acl-system#acl-policies) template for expressing a link to a policy +An ACL node identity is an [ACL policy](/docs/security/acl/acl-system#acl-policies) template for expressing a link to a policy suitable for use as an [Consul `agent` token](/docs/agent/options#acl_tokens_agent). They are usable on both tokens and roles and are composed of the following elements: @@ -182,7 +182,7 @@ on both tokens and roles and are composed of the following elements: During the authorization process, the configured node identity is automatically applied as a policy with the following preconfigured [ACL -rules](/docs/acl/acl-system#acl-rules-and-scope): +rules](/docs/security/acl/acl-system#acl-rules-and-scope): ```hcl # Allow the agent to register its own node in the Catalog and update its network coordinates @@ -296,7 +296,7 @@ The token Secret ID is passed along with each RPC request to the servers. Consul [HTTP endpoints](/api) can accept tokens via the `token` query string parameter, the `X-Consul-Token` request header, or an [RFC6750](https://tools.ietf.org/html/rfc6750) authorization bearer token. Consul's -[CLI commands](/docs/commands) can accept tokens via the +[CLI commands](/commands) can accept tokens via the `token` argument, or the `CONSUL_HTTP_TOKEN` environment variable. The CLI commands can also accept token values stored in files with the `token-file` argument, or the `CONSUL_HTTP_TOKEN_FILE` environment variable. @@ -319,16 +319,16 @@ rules: | Resource | Scope | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`acl`](/docs/acl/acl-rules#acl-resource-rules) | Operations for managing the ACL system [ACL API](/api/acl/acl) | -| [`agent`](/docs/acl/acl-rules#agent-rules) | Utility operations in the [Agent API](/api/agent), other than service and check registration | -| [`event`](/docs/acl/acl-rules#event-rules) | Listing and firing events in the [Event API](/api/event) | -| [`key`](/docs/acl/acl-rules#key-value-rules) | Key/value store operations in the [KV Store API](/api/kv) | -| [`keyring`](/docs/acl/acl-rules#keyring-rules) | Keyring operations in the [Keyring API](/api/operator/keyring) | -| [`node`](/docs/acl/acl-rules#node-rules) | Node-level catalog operations in the [Catalog API](/api/catalog), [Health API](/api/health), [Prepared Query API](/api/query), [Network Coordinate API](/api/coordinate), and [Agent API](/api/agent) | -| [`operator`](/docs/acl/acl-rules#operator-rules) | Cluster-level operations in the [Operator API](/api/operator), other than the [Keyring API](/api/operator/keyring) | -| [`query`](/docs/acl/acl-rules#prepared-query-rules) | Prepared query operations in the [Prepared Query API](/api/query) | -| [`service`](/docs/acl/acl-rules#service-rules) | Service-level catalog operations in the [Catalog API](/api/catalog), [Health API](/api/health), [Intentions API](/api/connect/intentions), [Prepared Query API](/api/query), and [Agent API](/api/agent) | -| [`session`](/docs/acl/acl-rules#session-rules) | Session operations in the [Session API](/api/session) | +| [`acl`](/docs/security/acl/acl-rules#acl-resource-rules) | Operations for managing the ACL system [ACL API](/api-docs/acl) | +| [`agent`](/docs/security/acl/acl-rules#agent-rules) | Utility operations in the [Agent API](/api/agent), other than service and check registration | +| [`event`](/docs/security/acl/acl-rules#event-rules) | Listing and firing events in the [Event API](/api/event) | +| [`key`](/docs/security/acl/acl-rules#key-value-rules) | Key/value store operations in the [KV Store API](/api/kv) | +| [`keyring`](/docs/security/acl/acl-rules#keyring-rules) | Keyring operations in the [Keyring API](/api/operator/keyring) | +| [`node`](/docs/security/acl/acl-rules#node-rules) | Node-level catalog operations in the [Catalog API](/api/catalog), [Health API](/api/health), [Prepared Query API](/api/query), [Network Coordinate API](/api/coordinate), and [Agent API](/api/agent) | +| [`operator`](/docs/security/acl/acl-rules#operator-rules) | Cluster-level operations in the [Operator API](/api/operator), other than the [Keyring API](/api/operator/keyring) | +| [`query`](/docs/security/acl/acl-rules#prepared-query-rules) | Prepared query operations in the [Prepared Query API](/api/query) | +| [`service`](/docs/security/acl/acl-rules#service-rules) | Service-level catalog operations in the [Catalog API](/api/catalog), [Health API](/api/health), [Intentions API](/api/connect/intentions), [Prepared Query API](/api/query), and [Agent API](/api/agent) | +| [`session`](/docs/security/acl/acl-rules#session-rules) | Session operations in the [Session API](/api/session) | Since Consul snapshots actually contain ACL tokens, the [Snapshot API](/api/snapshot) requires a token with "write" privileges for the ACL system. @@ -346,7 +346,7 @@ The following resources are not covered by ACL policies: 3. The [connect CA roots endpoint](/api/connect/ca#list-ca-root-certificates) exposes just the public TLS certificate which other systems can use to verify the TLS connection with Consul. Constructing rules from these policies is covered in detail on the -[ACL Rules](/docs/acl/acl-rules) page. +[ACL Rules](/docs/security/acl/acl-rules) page. -> **Consul Enterprise Namespacing** - In addition to directly linked policies, roles and service identities, Consul Enterprise will include the ACL policies and roles defined in the [Namespaces definition](/docs/enterprise/namespaces#namespace-definition). (Added in Consul Enterprise 1.7.0) @@ -404,7 +404,7 @@ node_prefix "" { The [`acl.tokens.agent`](/docs/agent/options#acl_tokens_agent) is a special token that is used for an agent's internal operations. It isn't used directly for any user-initiated operations like the [`acl.tokens.default`](/docs/agent/options#acl_tokens_default), though if the `acl.tokens.agent` isn't configured the `acl.tokens.default` will be used. The ACL agent token is used for the following operations by the agent: 1. Updating the agent's node entry using the [Catalog API](/api/catalog), including updating its node metadata, tagged addresses, and network coordinates -2. Performing [anti-entropy](/docs/internals/anti-entropy) syncing, in particular reading the node metadata and services registered with the catalog +2. Performing [anti-entropy](/docs/architecture/anti-entropy) syncing, in particular reading the node metadata and services registered with the catalog 3. Reading and writing the special `_rexec` section of the KV store when executing [`consul exec`](/commands/exec) commands Here's an example policy sufficient to accomplish the above for a node called `mynode`: @@ -426,4 +426,4 @@ The `service_prefix` policy needs read access for any services that can be regis ## Next Steps Setup ACLs with the [Bootstrapping the ACL System tutorial](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production?utm_source=consul.io&utm_medium=docs) or continue reading about -[ACL rules](/docs/acl/acl-rules). +[ACL rules](/docs/security/acl/acl-rules). diff --git a/website/content/docs/security/acl/auth-methods/index.mdx b/website/content/docs/security/acl/auth-methods/index.mdx index 102e156045..6f3385a03e 100644 --- a/website/content/docs/security/acl/auth-methods/index.mdx +++ b/website/content/docs/security/acl/auth-methods/index.mdx @@ -36,9 +36,9 @@ service mesh with minimal operator intervention. | Types | Consul Version | | ------------------------------------------------- | --------------------------------- | -| [`kubernetes`](/docs/acl/auth-methods/kubernetes) | 1.5.0+ | -| [`jwt`](/docs/acl/auth-methods/jwt) | 1.8.0+ | -| [`oidc`](/docs/acl/auth-methods/oidc) | 1.8.0+ | +| [`kubernetes`](/docs/security/acl/auth-methods/kubernetes) | 1.5.0+ | +| [`jwt`](/docs/security/acl/auth-methods/jwt) | 1.8.0+ | +| [`oidc`](/docs/security/acl/auth-methods/oidc) | 1.8.0+ | ## Operator Configuration @@ -68,8 +68,8 @@ token replication enabled. ## Binding Rules Binding rules allow an operator to express a systematic way of automatically -linking [roles](/docs/acl/acl-system#acl-roles) and [service -identities](/docs/acl/acl-system#acl-service-identities) to newly created +linking [roles](/docs/security/acl/acl-system#acl-roles) and [service +identities](/docs/security/acl/acl-system#acl-service-identities) to newly created tokens without operator intervention. Successful authentication with an auth method returns a set of trusted @@ -87,8 +87,8 @@ Each binding rule is composed of two portions: `"serviceaccount.namespace==default and serviceaccount.name!=vault"` - **Bind Type and Name** - A binding rule can bind a token to a - [role](/docs/acl/acl-system#acl-roles) or to a [service - identity](/docs/acl/acl-system#acl-service-identities) by name. The name + [role](/docs/security/acl/acl-system#acl-roles) or to a [service + identity](/docs/security/acl/acl-system#acl-service-identities) by name. The name can be specified with a plain string or the bind name can be lightly templated using [HIL syntax](https://github.com/hashicorp/hil) to interpolate the same values that are usable by the `Selector` syntax. For example: @@ -105,7 +105,7 @@ bearer token for a Consul ACL token by using the login process: ![diagram of auth method login](/img/auth-methods.svg) 1. Applications use the `consul login` subcommand or the [login API - endpoint](/api/acl/acl#login-to-auth-method) to authenticate to a + endpoint](/api-docs/acl#login-to-auth-method) to authenticate to a specific auth method using their local Consul client. Applications provide both the name of the auth method and a secret bearer token during login. @@ -131,7 +131,7 @@ bearer token for a Consul ACL token by using the login process: 8. The Consul client returns the token details back to the application. 9. (later) Applications SHOULD use the `consul logout` subcommand or the - [logout API endpoint](/api/acl/acl#logout-from-auth-method) to destroy + [logout API endpoint](/api-docs/acl#logout-from-auth-method) to destroy their token when it is no longer required. For more details about specific auth methods and how to configure them, click diff --git a/website/content/docs/security/acl/auth-methods/jwt.mdx b/website/content/docs/security/acl/auth-methods/jwt.mdx index 4c518677ec..d3d8130c66 100644 --- a/website/content/docs/security/acl/auth-methods/jwt.mdx +++ b/website/content/docs/security/acl/auth-methods/jwt.mdx @@ -18,10 +18,10 @@ cryptographically verified using locally-provided keys, or, if configured, an OIDC Discovery service can be used to fetch the appropriate keys. This page assumes general knowledge of JWTs and the concepts described in the -main [auth method documentation](/docs/acl/auth-methods). +main [auth method documentation](/docs/security/acl/auth-methods). -Both the [`jwt`](/docs/acl/auth-methods/jwt) and the -[`oidc`](/docs/acl/auth-methods/oidc) auth method types allow additional +Both the [`jwt`](/docs/security/acl/auth-methods/jwt) and the +[`oidc`](/docs/security/acl/auth-methods/oidc) auth method types allow additional processing of the claims data in the JWT. @include 'jwt_or_oidc.mdx' diff --git a/website/content/docs/security/acl/auth-methods/kubernetes.mdx b/website/content/docs/security/acl/auth-methods/kubernetes.mdx index 107f3a2f79..e1490ba8ee 100644 --- a/website/content/docs/security/acl/auth-methods/kubernetes.mdx +++ b/website/content/docs/security/acl/auth-methods/kubernetes.mdx @@ -17,7 +17,7 @@ easy to introduce a Consul token into a Kubernetes pod. This page assumes general knowledge of [Kubernetes](https://kubernetes.io/) and the concepts described in the main [auth method -documentation](/docs/acl/auth-methods). +documentation](/docs/security/acl/auth-methods). ## Config Parameters @@ -75,7 +75,7 @@ parameters are required to properly configure an auth method of type ## RBAC The Kubernetes service account corresponding to the configured -[`ServiceAccountJWT`](/docs/acl/auth-methods/kubernetes#serviceaccountjwt) +[`ServiceAccountJWT`](/docs/security/acl/auth-methods/kubernetes#serviceaccountjwt) needs to have access to two Kubernetes APIs: - [**TokenReview**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#create-tokenreview-v1-authentication-k8s-io) @@ -136,7 +136,7 @@ roleRef: ## Kubernetes Authentication Details Initially the -[`ServiceAccountJWT`](/docs/acl/auth-methods/kubernetes#serviceaccountjwt) +[`ServiceAccountJWT`](/docs/security/acl/auth-methods/kubernetes#serviceaccountjwt) given to the Consul leader uses the TokenReview API to validate the provided JWT. The trusted attributes of `serviceaccount.namespace`, `serviceaccount.name`, and `serviceaccount.uid` are populated directly from the diff --git a/website/content/docs/security/acl/auth-methods/oidc.mdx b/website/content/docs/security/acl/auth-methods/oidc.mdx index 67d0b37a42..5c96058317 100644 --- a/website/content/docs/security/acl/auth-methods/oidc.mdx +++ b/website/content/docs/security/acl/auth-methods/oidc.mdx @@ -24,10 +24,10 @@ This method may be initiated from the Consul UI or the command line. This page assumes general knowledge of [OIDC concepts](https://developer.okta.com/blog/2017/07/25/oidc-primer-part-1) and the concepts described in the main [auth method -documentation](/docs/acl/auth-methods). +documentation](/docs/security/acl/auth-methods). -Both the [`jwt`](/docs/acl/auth-methods/jwt) and the -[`oidc`](/docs/acl/auth-methods/oidc) auth method types allow additional +Both the [`jwt`](/docs/security/acl/auth-methods/jwt) and the +[`oidc`](/docs/security/acl/auth-methods/oidc) auth method types allow additional processing of the claims data in the JWT. @include 'jwt_or_oidc.mdx' diff --git a/website/content/docs/security/acl/index.mdx b/website/content/docs/security/acl/index.mdx index 08d6488bac..44b9776574 100644 --- a/website/content/docs/security/acl/index.mdx +++ b/website/content/docs/security/acl/index.mdx @@ -23,32 +23,32 @@ ACLs. 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. The -[ACL System documentation](/docs/acl/acl-system) details the functionality +[ACL System documentation](/docs/security/acl/acl-system) details the functionality of Consul ACLs. ### ACL Rules A core part of the ACL system is the rule language, which is used to describe the policy that must be enforced. Read the ACL rules -[documentation](/docs/acl/acl-rules) to learn about rule specifications. +[documentation](/docs/security/acl/acl-rules) to learn about rule specifications. ### ACL Auth Methods An auth method is a component in Consul that performs authentication against a trusted external party to authorize the creation of an ACL tokens usable within the local datacenter. Read the ACL auth method -[documentation](/docs/acl/auth-methods) to learn more about how they +[documentation](/docs/security/acl/auth-methods) to learn more about how they work and why you may want to use them. ### ACL Legacy System The ACL system in Consul 1.3.1 and older is now called legacy. For information on bootstrapping the legacy system, ACL rules, and a general ACL system -overview, read the legacy [documentation](/docs/acl/acl-legacy). +overview, read the legacy [documentation](/docs/security/acl/acl-legacy). ### ACL Migration -[The migration documentation](/docs/acl/acl-migrate-tokens) details how to +[The migration documentation](/docs/security/acl/acl-migrate-tokens) details how to upgrade existing legacy tokens after upgrading to 1.4.0. It will briefly describe what changed, and then walk through the high-level migration process options, finally giving some specific examples of migration strategies. The new diff --git a/website/content/docs/security/encryption.mdx b/website/content/docs/security/encryption.mdx index 2956d19ee2..0d71e8654d 100644 --- a/website/content/docs/security/encryption.mdx +++ b/website/content/docs/security/encryption.mdx @@ -10,7 +10,7 @@ description: >- # Encryption The Consul agent supports encrypting all of its network traffic. The exact -method of encryption is described on the [encryption internals page](/docs/internals/security). +method of encryption is described on the [encryption internals page](/docs/security). There are two separate encryption systems, one for gossip traffic and one for RPC. To configure the encryption systems on a new cluster, review this following tutorials to diff --git a/website/content/docs/security/security-models/core.mdx b/website/content/docs/security/security-models/core.mdx index 83ac5ade65..3f1198367f 100644 --- a/website/content/docs/security/security-models/core.mdx +++ b/website/content/docs/security/security-models/core.mdx @@ -154,7 +154,7 @@ environment and adapt these configurations accordingly. capabilities tied to an individual human, or machine operator identity. To ultimately secure the ACL system, administrators should configure the [`default_policy`](/docs/agent/options#acl_default_policy) to "deny". - The [system](/docs/acl/acl-system) is comprised of five major components: + The [system](/docs/security/acl/acl-system) is comprised of five major components: - **🗝 Token** - API key associated with policies, roles, or service identities. diff --git a/website/content/docs/troubleshoot/faq.mdx b/website/content/docs/troubleshoot/faq.mdx index 4bc63d5c8f..9734c38806 100644 --- a/website/content/docs/troubleshoot/faq.mdx +++ b/website/content/docs/troubleshoot/faq.mdx @@ -78,9 +78,9 @@ Consul has two important subsystems, the service catalog and the gossip protocol. The service catalog stores all the nodes, service instances, health check data, ACLs, and KV information. It is strongly consistent, and replicated -using the [consensus protocol](/docs/internals/consensus). +using the [consensus protocol](/docs/architecture/consensus). -The [gossip protocol](/docs/internals/gossip) is used to track which +The [gossip protocol](/docs/architecture/gossip) is used to track which nodes are part of the cluster and to detect a node or agent failure. This information is eventually consistent by nature. When the servers detects a change in membership, or receive a health update, they update the service @@ -174,7 +174,7 @@ We recommend taking any precautions or remediation steps that you would normally do for individual processes, based on your operating system. Please see our -[Security Model](/docs/internals/security) for more information. +[Security Model](/docs/security) for more information. ### Q: Are the Consul Docker Images OCI Compliant? diff --git a/website/content/docs/upgrading/compatibility.mdx b/website/content/docs/upgrading/compatibility.mdx index e43d112478..a60b8ab832 100644 --- a/website/content/docs/upgrading/compatibility.mdx +++ b/website/content/docs/upgrading/compatibility.mdx @@ -40,4 +40,4 @@ For more details on the specifics of upgrading, see the [upgrading page](/docs/u | 0.6 | 1, 2, 3 | | >= 0.7 | 2, 3. Will automatically use protocol > 2 when speaking to compatible agents | --> **Note:** Raft Protocol is versioned separately, but maintains compatibility with at least one prior version. See [here](/docs/upgrade-specific#raft-protocol-version-compatibility) for details. +-> **Note:** Raft Protocol is versioned separately, but maintains compatibility with at least one prior version. See [here](/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for details. diff --git a/website/content/docs/upgrading/index.mdx b/website/content/docs/upgrading/index.mdx index aee42b4875..3087c7d1a1 100644 --- a/website/content/docs/upgrading/index.mdx +++ b/website/content/docs/upgrading/index.mdx @@ -30,7 +30,7 @@ Visit the [General Upgrade Process](https://www.consul.io/docs/upgrading/instruc For most upgrades, the process is simple. Assuming the current version of Consul is A, and version B is released. -1. Check the [version's upgrade notes](/docs/upgrade-specific) to ensure +1. Check the [version's upgrade notes](/docs/upgrading/upgrade-specific) to ensure there are no compatibility issues that will affect your workload. If there are plan accordingly before continuing. @@ -81,7 +81,7 @@ version B comes out. You can verify this is the case by running `consul members` to make sure all members are speaking the same, latest protocol version. -The key to making this work is the [protocol compatibility](/docs/compatibility) +The key to making this work is the [protocol compatibility](/docs/upgrading/compatibility) of Consul. The protocol version system is discussed below. ## Protocol Versions @@ -124,7 +124,7 @@ your cluster so that you can run the latest protocol version. ## Upgrading on Kubernetes -See the dedicated [Upgrading Consul on Kubernetes](/docs/platform/k8s/upgrading) page. +See the dedicated [Upgrading Consul on Kubernetes](/docs/k8s/upgrade) page. ## Upgrading federated datacenters diff --git a/website/content/docs/upgrading/instructions/general-process.mdx b/website/content/docs/upgrading/instructions/general-process.mdx index c18e361f1e..2a515ec83b 100644 --- a/website/content/docs/upgrading/instructions/general-process.mdx +++ b/website/content/docs/upgrading/instructions/general-process.mdx @@ -39,7 +39,7 @@ Docker containers are available at these locations: If you are using Kubernetes, then please review our documentation for -[Upgrading Consul on Kubernetes](/docs/k8s/operations/upgrading). +[Upgrading Consul on Kubernetes](/docs/k8s/upgrade). @@ -74,7 +74,7 @@ this snapshot somewhere safe. More documentation on snapshot usage is available - https://www.consul.io/commands/snapshot - https://learn.hashicorp.com/tutorials/consul/backup-and-restore -**2.** Temporarily modify your Consul configuration so that its [log_level](/docs/agent/options.html#_log_level) +**2.** Temporarily modify your Consul configuration so that its [log_level](/docs/agent/options#_log_level) is set to `debug`. After doing this, issue the following command on your servers to reload the configuration: @@ -183,7 +183,7 @@ then the following options for further assistance are available: When contacting Hashicorp Support, please include the following information in your ticket: - Consul version you were upgrading FROM and TO. -- [Debug level logs](/docs/agent/options.html#_log_level) from all servers in the cluster +- [Debug level logs](/docs/agent/options#_log_level) from all servers in the cluster that you are having trouble with. These should include logs from prior to the upgrade attempt up through the current time. If your logs were not set at debug level prior to the upgrade, please include those logs as well. Also, update your config to use debug logs, diff --git a/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx b/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx index 78a602b035..b4fd85c459 100644 --- a/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx +++ b/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx @@ -115,7 +115,7 @@ are operating Consul within Kubernetes. **5.** Upgrade all client agents to the latest 1.8.x or 1.9.x release. -**6.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to the latest 1.8.x or 1.9.x release. +**6.** Upgrade all [snapshot agents](/commands/snapshot/agent) to the latest 1.8.x or 1.9.x release. **7.** Take a snapshot of the upgraded cluster by running the following command: @@ -124,7 +124,7 @@ consul snapshot save intermediate.snap ``` Note that you can run the command from anywhere Consul is already running or from a location that has network access to the cluster. -If run elsewhere, [additional command line options](/docs/commands/snapshot/save#api-options) may be needed to direct the request to the right Consul API. +If run elsewhere, [additional command line options](/commands/snapshot/save#api-options) may be needed to direct the request to the right Consul API. Note that you will need to ensure there is enough disk space in the current directory to store the snapshot. In the worst case, the snapshot size could be close to the amount @@ -145,7 +145,7 @@ You can also refer to the [Apply Enterprise License](https://learn.hashicorp.com **10.** Upgrade all client agents to v1.10.0. -**11.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to v1.10.0. +**11.** Upgrade all [snapshot agents](/commands/snapshot/agent) to v1.10.0. @@ -173,7 +173,7 @@ to promptly proceed with the upgrade and not leave agents in the intermediate st **7.** Pre-configure the snapshot agents with a license. This is the same process that was executed for the servers in step 5. -**8.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to the latest 1.8.x or 1.9.x release. +**8.** Upgrade all [snapshot agents](/commands/snapshot/agent) to the latest 1.8.x or 1.9.x release. **9.** Take a snapshot of the upgraded cluster by running the following command: @@ -198,7 +198,7 @@ was executed for the servers in step 5. **12.** Upgrade all client agents to v1.10.0. -**13.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to v1.10.0. +**13.** Upgrade all [snapshot agents](/commands/snapshot/agent) to v1.10.0. diff --git a/website/content/docs/upgrading/instructions/upgrade-to-1-6-x.mdx b/website/content/docs/upgrading/instructions/upgrade-to-1-6-x.mdx index 5fae87dd88..460fe4b18f 100644 --- a/website/content/docs/upgrading/instructions/upgrade-to-1-6-x.mdx +++ b/website/content/docs/upgrading/instructions/upgrade-to-1-6-x.mdx @@ -51,7 +51,7 @@ Looking through these changes prior to upgrading is highly recommended. Two very notable items are: - 1.6.2 introduced more strict JSON decoding. Invalid JSON that was previously ignored might result in errors now (e.g., `Connect: null` in service definitions). See [[GH#6680](https://github.com/hashicorp/consul/pull/6680)]. -- 1.6.3 introduced the [http_max_conns_per_client](https://www.consul.io/docs/agent/options.html#http_max_conns_per_client) limit. This defaults to 200. Prior to this, connections per client were unbounded. [[GH#7159](https://github.com/hashicorp/consul/issues/7159)] +- 1.6.3 introduced the [http_max_conns_per_client](https://www.consul.io/docs/agent/options#http_max_conns_per_client) limit. This defaults to 200. Prior to this, connections per client were unbounded. [[GH#7159](https://github.com/hashicorp/consul/issues/7159)] ## Procedure diff --git a/website/content/docs/upgrading/upgrade-specific.mdx b/website/content/docs/upgrading/upgrade-specific.mdx index 91a0a7c2c8..096ecba581 100644 --- a/website/content/docs/upgrading/upgrade-specific.mdx +++ b/website/content/docs/upgrading/upgrade-specific.mdx @@ -420,7 +420,7 @@ as soon as possible after upgrade, as well as updating any integrations to work with the the new ACL [Token](/api/acl/tokens) and [Policy](/api/acl/policies) APIs. -More complete details on how to upgrade "legacy" tokens is available [here](/docs/acl/acl-migrate-tokens). +More complete details on how to upgrade "legacy" tokens is available [here](/docs/security/acl/acl-migrate-tokens). ### Connect Multi-datacenter @@ -480,7 +480,7 @@ The following previously deprecated fields and config options have been removed: - `CheckID` has been removed from config file check definitions (use `id` instead). - `script` has been removed from config file check definitions (use `args` instead). - `enableTagOverride` is no longer valid in service definitions (use `enable_tag_override` instead). -- The [deprecated set of metric names](/docs/upgrade-specific#metric-names-updated) (beginning with `consul.consul.`) has been removed +- The [deprecated set of metric names](/docs/upgrading/upgrade-specific#metric-names-updated) (beginning with `consul.consul.`) has been removed along with the `enable_deprecated_names` option from the metrics configuration. #### New defaults for Raft Snapshot Creation @@ -550,7 +550,7 @@ Raft protocol version 3 requires Consul running 0.8.0 or newer on all servers in order to work, so if you are upgrading with older servers in a cluster then you will need to set this back to 2 in order to upgrade. See [Raft Protocol Version -Compatibility](/docs/upgrade-specific#raft-protocol-version-compatibility) +Compatibility](/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for more details. Also the format of `peers.json` used for outage recovery is different when running with the latest Raft protocol. Review [Manual Recovery Using @@ -558,7 +558,7 @@ peers.json](https://learn.hashicorp.com/tutorials/consul/recovery-outage#manual- for a description of the required format. Please note that the Raft protocol is different from Consul's internal protocol -as described on the [Protocol Compatibility Promise](/docs/compatibility) +as described on the [Protocol Compatibility Promise](/docs/upgrading/compatibility) page, and as is shown in commands like `consul members` and `consul version`. To see the version of the Raft protocol in use on each server, use the `consul operator raft list-peers` command. @@ -592,7 +592,7 @@ file directly. All config file formats now require snake_case fields, so all CamelCased parameter names should be changed before upgrading. -See [Service Definition Parameter Case](/docs/agent/services#service-definition-parameter-case) documentation for details. +See [Service Definition Parameter Case](/docs/discovery/services#service-definition-parameter-case) documentation for details. #### Deprecated Options Have Been Removed @@ -626,10 +626,10 @@ upgrading. Here's the complete list of removed options and their equivalents: | `statsite_addr` | [`telemetry.statsite_address`](https://github.com/hashicorp/consul/blob/main/website/pages/docs/agent/options.mdx#telemetry-statsite_address) | | `statsite_prefix` | [`telemetry.metrics_prefix`](/docs/agent/options#telemetry-metrics_prefix) | | `telemetry.statsite_prefix` | [`telemetry.metrics_prefix`](/docs/agent/options#telemetry-metrics_prefix) | -| (service definitions) `serviceid` | [`service_id`](/docs/agent/services) | -| (service definitions) `dockercontainerid` | [`docker_container_id`](/docs/agent/services) | -| (service definitions) `tlsskipverify` | [`tls_skip_verify`](/docs/agent/services) | -| (service definitions) `deregistercriticalserviceafter` | [`deregister_critical_service_after`](/docs/agent/services) | +| (service definitions) `serviceid` | [`service_id`](/docs/discovery/services) | +| (service definitions) `dockercontainerid` | [`docker_container_id`](/docs/discovery/services) | +| (service definitions) `tlsskipverify` | [`tls_skip_verify`](/docs/discovery/services) | +| (service definitions) `deregistercriticalserviceafter` | [`deregister_critical_service_after`](/docs/discovery/services) | #### `statsite_prefix` Renamed to `metrics_prefix` @@ -996,7 +996,7 @@ require any ACL to manage them, and prepared queries with a `Name` defined are now governed by a new `query` ACL policy that will need to be configured after the upgrade. -See the [ACL rules documentation](/docs/acl/acl-rules#prepared-query-rules) for more details +See the [ACL rules documentation](/docs/security/acl/acl-rules#prepared-query-rules) for more details about the new behavior and how it compares to previous versions of Consul. ## Consul 0.6