mirror of https://github.com/hashicorp/consul
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.pull/13047/head
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>
|
||||
|
|
@ -28,9 +27,6 @@ proxy = {
|
|||
port = <port where services can discover and connect to proxied services>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
<CodeBlockConfig>
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "<name of the service>",
|
||||
|
|
@ -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
|
||||
|
|
@ -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