mirror of https://github.com/status-im/consul.git
docs: Remove unnecessary use of CodeBlockConfig (#12974)
Remove empty CodeBlockConfig elements. These elements are not providing any benefit for the enclosed code blocks. This PR removes the elements so so that the source is easier to read.
This commit is contained in:
Blake Covarrubias
GitHub
parent
88449b1f1b
commit
9378880c42
|
|
@ -501,7 +501,6 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
|
|||
|
||||
- `response_headers` This object allows adding headers to the HTTP API and UI responses. For example, the following config can be used to enable [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) on the HTTP API endpoints:
|
||||
|
||||
|
||||
<CodeTabs heading="Enable CORS on the HTTP API endpoints">
|
||||
|
||||
```hcl
|
||||
|
|
|
|||
|
|
@ -19,14 +19,10 @@ Ensure that the environment you are deploying Consul API Gateway in meets the re
|
|||
|
||||
1. Issue the following command to install the CRDs:
|
||||
|
||||
<CodeBlockConfig>
|
||||
|
||||
```shell-session
|
||||
$ kubectl apply --kustomize="github.com/hashicorp/consul-api-gateway/config/crd?ref=vVERSION"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
1. Create a `values.yaml` file for your Consul API Gateway deployment. Copy the content below into the `values.yaml` file. The `values.yaml` will be used by the Consul Helm chart. Available versions of the [Consul](https://hub.docker.com/r/hashicorp/consul/tags) and [Consul API Gateway](https://hub.docker.com/r/hashicorp/consul-api-gateway/tags) Docker images can be found on DockerHub, with additional context on version compatibility published in [GitHub releases](https://github.com/hashicorp/consul-api-gateway/releases). See [Helm Chart Configuration - apiGateway](https://www.consul.io/docs/k8s/helm#apigateway) for more available options on how to configure your Consul API Gateway deployment via the Helm chart.
|
||||
|
||||
<CodeBlockConfig hideClipboard filename="values.yaml">
|
||||
|
|
@ -47,14 +43,10 @@ Ensure that the environment you are deploying Consul API Gateway in meets the re
|
|||
|
||||
1. Install Consul API Gateway using the standard Consul Helm chart and specify the custom values file. Available versions of the [Consul Helm chart](https://github.com/hashicorp/consul-k8s/releases) can be found in GitHub releases.
|
||||
|
||||
<CodeBlockConfig>
|
||||
|
||||
```shell-session
|
||||
$ helm install consul hashicorp/consul --version 0.43.0 --values values.yaml --create-namespace --namespace consul
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
1. Verify that the [requirements](#requirements) have been met.
|
||||
|
|
@ -73,14 +65,10 @@ Ensure that the environment you are deploying Consul API Gateway in meets the re
|
|||
|
||||
1. Issue the `kubectl apply` command to implement the configurations, e.g.:
|
||||
|
||||
<CodeBlockConfig>
|
||||
|
||||
```shell-session
|
||||
$ kubectl apply -f gateway.yaml routes.yaml
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
<!--- Commented out per https://github.com/hashicorp/consul/pull/11951/files#r791204596
|
||||
|
||||
### Using the Consul API Gateway Binary
|
||||
|
|
|
|||
|
|
@ -38,7 +38,6 @@ You can configure the settings defined in the `exported-services` configuration
|
|||
Configure the following parameters to define a `exported-services` configuration entry:
|
||||
|
||||
<CodeTabs heading="Exported services configuration syntax" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
Kind = "exported-services"
|
||||
|
|
@ -57,9 +56,6 @@ Services = [
|
|||
]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ExportedServices
|
||||
|
|
@ -73,9 +69,6 @@ spec:
|
|||
- partition: <name of the partition that will dial the exported service>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"Kind": "exported-services",
|
||||
"Partition": "<partition containing services to export>",
|
||||
|
|
@ -93,7 +86,6 @@ spec:
|
|||
]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
### Configuration Parameters
|
||||
|
|
@ -120,8 +112,7 @@ The `Services` parameter contains one or more lists of parameters that specify w
|
|||
|
||||
The following example configures the agent to export the `billing` service from the `default` namespace of the `finance` admin partition to the `frontend` and `backend` partitions. Additionally, all services in all namespaces within the `finance` partition will be exported to the `monitoring` partition.
|
||||
|
||||
<CodeTabs heading="" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
<CodeTabs heading="Example exported services configuration" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
```hcl
|
||||
Kind = "exported-services"
|
||||
|
|
@ -153,9 +144,6 @@ Services = [
|
|||
]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
Kind: ExportedServices
|
||||
|
|
@ -174,9 +162,6 @@ spec:
|
|||
- partition: backend
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"Kind": "exported-services",
|
||||
"Partition": "finance",
|
||||
|
|
@ -206,7 +191,6 @@ spec:
|
|||
]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
## Reading Services
|
||||
|
|
|
|||
|
|
@ -47,7 +47,6 @@ Configure the following parameters to define a `proxy-defaults` configuration en
|
|||
<Tab heading="Consul OSS">
|
||||
|
||||
<CodeTabs heading="Proxy defaults configuration syntax" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
Kind = "proxy-defaults"
|
||||
|
|
@ -80,9 +79,6 @@ Expose {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ProxyDefaults
|
||||
|
|
@ -108,9 +104,6 @@ spec:
|
|||
protocol:= <protocol of the listener>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"Kind": "proxy-defaults",
|
||||
|
|
@ -143,7 +136,6 @@ spec:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
</Tab>
|
||||
|
|
@ -153,7 +145,6 @@ spec:
|
|||
namespace and it will configure proxies in **all** namespaces.
|
||||
|
||||
<CodeTabs heading="Proxy defaults configuration syntax" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
Kind = "proxy-defaults"
|
||||
|
|
@ -187,9 +178,6 @@ Expose {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ProxyDefaults
|
||||
|
|
@ -216,9 +204,6 @@ spec:
|
|||
protocol:= <protocol of the listener>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"Kind": "proxy-defaults",
|
||||
|
|
@ -252,7 +237,6 @@ spec:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
</Tab>
|
||||
|
|
@ -441,7 +425,6 @@ The following example configures the default protocol for all sidecar proxies.
|
|||
<Tab heading="Consul OSS">
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
Kind = "proxy-defaults"
|
||||
|
|
@ -451,9 +434,6 @@ Config {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ProxyDefaults
|
||||
|
|
@ -464,9 +444,6 @@ spec:
|
|||
protocol: http
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"Kind": "proxy-defaults",
|
||||
|
|
@ -477,7 +454,6 @@ spec:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
</Tab>
|
||||
|
|
@ -487,7 +463,6 @@ spec:
|
|||
namespace and it will configure proxies in **all** namespaces.
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
Kind = "proxy-defaults"
|
||||
|
|
@ -498,9 +473,6 @@ Config {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ProxyDefaults
|
||||
|
|
@ -512,9 +484,6 @@ spec:
|
|||
protocol: http
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"Kind": "proxy-defaults",
|
||||
|
|
@ -526,7 +495,6 @@ spec:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
</Tab>
|
||||
|
|
@ -537,7 +505,6 @@ spec:
|
|||
The following example configures all sidecar proxies to expose Prometheus metrics.
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
Kind = "proxy-defaults"
|
||||
|
|
@ -547,9 +514,6 @@ Config {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ProxyDefaults
|
||||
|
|
@ -560,9 +524,6 @@ spec:
|
|||
envoy_prometheus_bind_addr: '0.0.0.0:9102'
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"Kind": "proxy-defaults",
|
||||
|
|
@ -573,7 +534,6 @@ spec:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
### Proxy-specific defaults
|
||||
|
|
@ -581,7 +541,6 @@ spec:
|
|||
The following example configures some custom default values for all sidecar proxies.
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
Kind = "proxy-defaults"
|
||||
|
|
@ -592,9 +551,6 @@ Config {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ProxyDefaults
|
||||
|
|
@ -606,9 +562,6 @@ spec:
|
|||
handshake_timeout_ms: 10000
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"Kind": "proxy-defaults",
|
||||
|
|
@ -620,7 +573,6 @@ spec:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
## ACLs
|
||||
|
|
|
|||
|
|
@ -16,7 +16,6 @@ This topic describes how to declare a proxy as a `connect-proxy` in service defi
|
|||
Configure a service mesh proxy using the following syntax:
|
||||
|
||||
<CodeTabs heading="Basic syntax for configuring a service mesh proxy">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
name = <name of the service>
|
||||
|
|
@ -26,10 +25,7 @@ proxy = {
|
|||
<additional proxy parameters> = "<additional parameter values>"
|
||||
}
|
||||
port = <port where services can discover and connect to proxied services>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -43,7 +39,6 @@ port = <port where services can discover and connect to proxied services>
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
The following table describes the parameters that must be added to the service definition to declare the service as a proxy.
|
||||
|
|
@ -62,7 +57,6 @@ You can specify several additional parameters to configure the proxy to meet you
|
|||
In the following example, a proxy named `redis-proxy` is registered as a service mesh proxy. It proxies to the `redis` service and is available at port `8181`. As a result, any service mesh clients searching for a Connect-capable endpoint for `redis` will find this proxy.
|
||||
|
||||
<CodeTabs heading="Minimal example of a service mesh proxy">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
kind = "connect-proxy"
|
||||
|
|
@ -72,8 +66,6 @@ proxy = {
|
|||
destination_service_name = "redis"
|
||||
}
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -85,9 +77,8 @@ proxy = {
|
|||
"port": 8181
|
||||
}
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
### Sidecar Proxy Configuration
|
||||
|
||||
|
|
@ -107,7 +98,6 @@ See (Sidecar Service Registration)[/docs/connect/registration/sidecar-service] f
|
|||
The following example includes values for all available options when registering a proxy instance.
|
||||
|
||||
<CodeTabs heading="Example that includes all configuration options when registering a proxy instance">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
kind = "connect-proxy"
|
||||
|
|
@ -127,9 +117,6 @@ proxy = {
|
|||
upstreams = []
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "redis-proxy",
|
||||
|
|
@ -150,7 +137,7 @@ proxy = {
|
|||
"port": 8181
|
||||
}
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
### Proxy Parameters
|
||||
|
|
@ -196,7 +183,6 @@ Upstreams support multiple destination types. The following examples include inf
|
|||
-> **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.
|
||||
|
||||
<CodeTabs heading="Example service destination upstream">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
destination_type = "service"
|
||||
|
|
@ -210,8 +196,6 @@ mesh_gateway = {
|
|||
mode = "local"
|
||||
}
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -228,11 +212,9 @@ mesh_gateway = {
|
|||
},
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
<CodeTabs heading="Example prepared query upstream">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
destination_type = "prepared_query"
|
||||
|
|
@ -242,9 +224,6 @@ local_bind_port = 1234
|
|||
config = {}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"destination_type": "prepared_query",
|
||||
|
|
@ -254,12 +233,10 @@ config = {}
|
|||
"config": {}
|
||||
},
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
|
||||
<CodeTabs heading="Example of dialing remote upstreams across admin partitions">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
destination_partition = "finance"
|
||||
|
|
@ -268,8 +245,6 @@ destination_type = "service"
|
|||
destination_name = "billing"
|
||||
local_bind_port = 9090
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -281,7 +256,6 @@ local_bind_port = 9090
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
## Proxy Modes
|
||||
|
|
|
|||
|
|
@ -28,7 +28,6 @@ This section describes about how to assemble rules into policies. Refer to the [
|
|||
A rule is composed of a resource declaration and an access level defined with the `policy` keyword and a [policy disposition](#policy-dispositions). The following syntax describes the basic structure of a rule:
|
||||
|
||||
<CodeTabs heading="Basic syntax for configuring an ACL rule">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
<resource> {
|
||||
|
|
@ -36,16 +35,12 @@ A rule is composed of a resource declaration and an access level defined with th
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
"<resource>": [{
|
||||
"policy": "<policy disposition>"
|
||||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Access to the specified resource is granted or denied based on the policy disposition.
|
||||
|
|
@ -57,7 +52,6 @@ Many resources take an additional value that limits the scope of the rule to res
|
|||
The following syntax describes how to include a resource label in the rule:
|
||||
|
||||
<CodeTabs heading="Syntax for applying an ACL rule to named resources">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
<resource> "<label>" {
|
||||
|
|
@ -65,9 +59,6 @@ The following syntax describes how to include a resource label in the rule:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
"<resource>": [{
|
||||
"<label>": [{
|
||||
|
|
@ -76,7 +67,6 @@ The following syntax describes how to include a resource label in the rule:
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Labels provide operators with more granular control over access to the resource, but the following resource types do not take a label:
|
||||
|
|
@ -89,20 +79,15 @@ Labels provide operators with more granular control over access to the resource,
|
|||
Use the following syntax to create rules for these resources:
|
||||
|
||||
<CodeTabs heading="Syntax for resources that take ACL rule configurations directly">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
<resource> = "<policy disposition>"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
"<resource>": "<policy disposition>"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
### Policy Dispositions
|
||||
|
|
@ -122,7 +107,6 @@ You can define rules for labeled resources based on exact matches or by using re
|
|||
The following example rule is an exact match that denies access to services labeled `web-prod`:
|
||||
|
||||
<CodeTabs heading="Example rule that denies access to services named 'web-prod'">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
service "web-prod" {
|
||||
|
|
@ -130,9 +114,6 @@ service "web-prod" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
"service": [{
|
||||
"web-prod" : [{
|
||||
|
|
@ -141,13 +122,11 @@ service "web-prod" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
You can append the resource with `_prefix` to match all resource labels beginning with the same value. The following example rule allows `write` access to all services with labels that begin with "web":
|
||||
|
||||
<CodeTabs heading="Example rule that grants read and write access to services with names beginning with 'web'">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
service_prefix "web" {
|
||||
|
|
@ -155,9 +134,6 @@ service_prefix "web" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
"service_prefix": [{
|
||||
"web" : [{
|
||||
|
|
@ -166,13 +142,11 @@ service_prefix "web" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Prefix-based resource labels can also contain an empty string, which configures the rule to apply to all resources of the declared type. The following example rule allows `read` access to all `service` resources:
|
||||
|
||||
<CodeTabs heading="Example rule that grants read access to all services">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
service_prefix "" {
|
||||
|
|
@ -180,9 +154,6 @@ service_prefix "" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
"service_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -191,7 +162,6 @@ service_prefix "" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
When using prefix-based rules, the most specific prefix match determines the action. In a real-world scenario, a combination of rules would be combined to create a flexible policy. Each team or business unit would use tokens based on policies that enforce several rules, for example:
|
||||
|
|
@ -216,7 +186,6 @@ HCL is human readable and interoperable with JSON, making it easy to automate po
|
|||
The following examples show the same policy formatted in HCL and JSON:
|
||||
|
||||
<CodeTabs heading="Example rules">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
# These control access to the key/value store.
|
||||
|
|
@ -238,9 +207,6 @@ key "foo/bar/secret" {
|
|||
operator = "read"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
{
|
||||
"key": [
|
||||
|
|
@ -279,7 +245,6 @@ operator = "read"
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
## Rule Scope
|
||||
|
|
@ -488,16 +453,16 @@ service "consul-snapshot" {
|
|||
|
||||
</CodeTabs>
|
||||
|
||||
### Enable Vault to Access the Consul Storage Backend
|
||||
### Enable Vault to Access the Consul Storage Backend
|
||||
|
||||
If you are using [Vault](https://www.vaultproject.io/docs) to manage secrets in your infrastructure, you can configure Vault to use Consul's key/value (KV) store as backend storage to persist Vault's data. Refer to the [Consul KV documentation](/docs/dynamic-app-config/kv) and the [Vault storage documentation](https://www.vaultproject.io/docs/configuration/storage) for additional information.
|
||||
If you are using [Vault](https://www.vaultproject.io/docs) to manage secrets in your infrastructure, you can configure Vault to use Consul's key/value (KV) store as backend storage to persist Vault's data. Refer to the [Consul KV documentation](/docs/dynamic-app-config/kv) and the [Vault storage documentation](https://www.vaultproject.io/docs/configuration/storage) for additional information.
|
||||
|
||||
In the following example, Vault is registered as a service and provided access to Consul's KV store.
|
||||
|
||||
<CodeTabs>
|
||||
|
||||
```hcl
|
||||
# Provide KV visibility to all agents.
|
||||
# Provide KV visibility to all agents.
|
||||
agent_prefix "" {
|
||||
"policy" = "read"
|
||||
}
|
||||
|
|
@ -538,6 +503,6 @@ session_prefix "" {
|
|||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
</CodeTabs>
|
||||
|
|
|
|||
|
|
@ -50,20 +50,15 @@ Rules for ACL resources do not use labels.
|
|||
In the following example, `write` access to the ACL API. The rule enables the operator to read or write ACLs, as well as discover the secret ID of any token.
|
||||
|
||||
<CodeTabs heading="Example acl rule">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
acl = "write"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"acl" : "write"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
## Admin Partition Rules <EnterpriseAlert inline />
|
||||
|
|
@ -75,7 +70,6 @@ In the following example, the agent has write access to the `ex-namespace` names
|
|||
The `mesh` resource is also scoped to the admin partition rule, which grants `write` access to mesh-level resources in the partition:
|
||||
|
||||
<CodeTabs heading="Example admin partition rules">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
partition "example" {
|
||||
|
|
@ -96,9 +90,6 @@ partition_prefix "ex-" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"partition": [
|
||||
|
|
@ -174,7 +165,6 @@ partition_prefix "ex-" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
## Agent Rules
|
||||
|
|
@ -184,7 +174,6 @@ such as join and leave. All of the catalog-related operations are covered by the
|
|||
and [`service` or `service_prefix`](#service-rules) policies instead.
|
||||
|
||||
<CodeTabs heading="Example agent rules">
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```hcl
|
||||
agent_prefix "" {
|
||||
|
|
@ -198,9 +187,6 @@ agent_prefix "bar" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig lineNumbers>
|
||||
|
||||
```json
|
||||
"agent_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -217,7 +203,6 @@ agent_prefix "bar" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Agent rules are keyed by the node name they apply to. In the example above the rules
|
||||
|
|
@ -236,7 +221,6 @@ The `event` and `event_prefix` resources control access to event operations in t
|
|||
firing events and listing events.
|
||||
|
||||
<CodeTabs heading="Example event rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
event_prefix "" {
|
||||
|
|
@ -247,9 +231,6 @@ event "deploy" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"event_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -263,7 +244,6 @@ event "deploy" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Event rules are labeled with the event name they apply to. In the example above, the rules allow
|
||||
|
|
@ -279,7 +259,6 @@ give agents a token with access to this event prefix, in addition to configuring
|
|||
The `key` and `key_prefix` resources control access to key/value store operations in the [KV API](/api-docs/kv).
|
||||
|
||||
<CodeTabs heading="Example key rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
key_prefix "" {
|
||||
|
|
@ -293,9 +272,6 @@ key "bar" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"key_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -312,7 +288,6 @@ key "bar" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Key rules are labeled with the key name they apply to. In the example above, the rules allow read-only access
|
||||
|
|
@ -323,7 +298,6 @@ to any key name with the empty prefix rule, allow read-write access to the "foo"
|
|||
Enable the `list` policy disposition (Consul 1.0+) by setting the `acl.enable_key_list_policy` parameter to `true`. The disposition provides recursive access to `key` entries. Refer to the [KV API](/api-docs/kv#recurse) documentation for additional information. In the following example, `key` resources that start with `bar` are listed.
|
||||
|
||||
<CodeTabs heading="Example 'key' rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
key_prefix "" {
|
||||
|
|
@ -339,9 +313,6 @@ key_prefix "baz" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"key_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -356,7 +327,6 @@ key_prefix "baz" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
In the example above, the rules allow reading the key "baz", and only allow recursive reads on the prefix "bar".
|
||||
|
|
@ -388,20 +358,15 @@ For more detailed information, see the [Consul Sentinel documentation](/docs/age
|
|||
The `keyring` resource controls access to keyring operations in the [Keyring API](/api-docs/operator/keyring). Only one keyring policy is allowed per rule set. The value is set to one of the policy dispositions, but may be read and updated.
|
||||
|
||||
<CodeTabs heading="Example keyring rule">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
keyring = "write"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"keyring" : "write"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
### Mesh Rules
|
||||
|
|
@ -409,20 +374,15 @@ keyring = "write"
|
|||
The `mesh` resource controls access to ingress gateways, terminating gateways, and mesh configuration entries. The following rule grants read and write access:
|
||||
|
||||
<CodeTabs heading="Example mesh rule">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
mesh = "write"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"mesh" : "write"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
See [Admin Partition Rules](#admin-partition-rules) for another example rule that uses the `mesh` resource.
|
||||
|
|
@ -436,7 +396,6 @@ The `namespace` and `namespace_prefix` resource controls access to Consul namesp
|
|||
The following examples describe how namespace rules can be defined in a policy:
|
||||
|
||||
<CodeTabs heading="Example namespace rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
namespace_prefix "" {
|
||||
|
|
@ -483,9 +442,6 @@ namespace "foo" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"namespace": [
|
||||
|
|
@ -564,7 +520,6 @@ namespace "foo" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
### Restrictions
|
||||
|
|
@ -602,7 +557,6 @@ The following example rule uses an empty prefix label, which provides read-only
|
|||
The rule also provides read-write access to the `app` node and denies all access to the `admin` node:
|
||||
|
||||
<CodeTabs heading="Example node rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
node_prefix "" {
|
||||
|
|
@ -616,9 +570,6 @@ node "admin" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"node_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -633,7 +584,6 @@ node "admin" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
### Registering and Querying Node Information
|
||||
|
|
@ -665,20 +615,15 @@ Only one operator rule allowed per rule set. In the following example, the token
|
|||
diagnostic purposes but it will not make changes.
|
||||
|
||||
<CodeTabs heading="Example operator rule">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
operator = "read"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"operator" : "read"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
## Prepared Query Rules
|
||||
|
|
@ -689,7 +634,6 @@ The resource label in the following example is empty. As a result, the rules all
|
|||
The rules also grant read-write access to the query named `foo`, which allows control of the query namespace to be delegated based on ACLs:
|
||||
|
||||
<CodeTabs heading="Example query rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
query_prefix "" {
|
||||
|
|
@ -700,9 +644,6 @@ query "foo" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"query_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -716,7 +657,6 @@ query "foo" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Executing queries is subject to `node`/`node_prefix` and `service`/`service_prefix`
|
||||
|
|
@ -798,7 +738,6 @@ The resource label in the following example is empty. As a result, the rules all
|
|||
The rules also allow read-write access to the `app` service and deny all access to the `admin` service:
|
||||
|
||||
<CodeTabs heading="Example service rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
service_prefix "" {
|
||||
|
|
@ -812,9 +751,6 @@ service "admin" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"service_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -831,7 +767,6 @@ service "admin" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Consul's DNS interface is affected by restrictions on service rules. If the
|
||||
|
|
@ -871,7 +806,6 @@ following policy provides read-write access to the "app" service, and explicitly
|
|||
grants `intentions:read` access to view intentions associated with the "app" service.
|
||||
|
||||
<CodeTabs heading="Example service rule with intentions">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
service "app" {
|
||||
|
|
@ -880,9 +814,6 @@ service "app" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"service" : [{
|
||||
"app" : [{
|
||||
|
|
@ -892,7 +823,6 @@ service "app" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
Refer to [Intention Management Permissions](/docs/connect/intentions#intention-management-permissions)
|
||||
|
|
@ -907,7 +837,6 @@ The resource label in the following example is empty. As a result, the rules all
|
|||
The rules also allow creating sessions on the node named `app` and deny all access to any sessions on the `admin` node:
|
||||
|
||||
<CodeTabs heading="Example session rules">
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
session_prefix "" {
|
||||
|
|
@ -921,9 +850,6 @@ session "admin" {
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
"session_prefix" : [{
|
||||
"" : [{
|
||||
|
|
@ -940,5 +866,4 @@ session "admin" {
|
|||
}]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
|
|
|||
|
|
@ -85,17 +85,12 @@ In the following example, the agent is configured to use a default token:
|
|||
|
||||
<CodeTabs>
|
||||
|
||||
<CodeBlockConfig>
|
||||
|
||||
```hcl
|
||||
"tokens" = {
|
||||
"default" = "233b604b-b92e-48c8-a253-5f11514e4b50"
|
||||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"tokens": {
|
||||
|
|
@ -104,8 +99,6 @@ In the following example, the agent is configured to use a default token:
|
|||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
Refer to the [agent configurations documentation](/docs/agent/options) for additional information.
|
||||
|
|
|
|||
Loading…
Reference in New Issue