mirror of https://github.com/status-im/consul.git
docs: JWT Authorization for intentions (#17643)
* Initial page/nav creation * configuration entry reference page * Usage + fixes * service intentions page * usage * description * config entry updates * formatting fixes * Update website/content/docs/connect/config-entries/service-intentions.mdx Co-authored-by: Paul Glass <pglass@hashicorp.com> * service intentions review fixes * Overview page review fixes * Apply suggestions from code review Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com> --------- Co-authored-by: Paul Glass <pglass@hashicorp.com> Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
This commit is contained in:
Jeff Boruszak
GitHub
parent
b678742c68
commit
66704e5cb9
File diff suppressed because it is too large
Load Diff
|
|
@ -21,7 +21,13 @@ The following outline shows how to format the service intentions configuration e
|
|||
- [`Name`](#name): string | required
|
||||
- [`Namespace`](#namespace): string | `default` | <EnterpriseAlert inline/>
|
||||
- [`Partition`](#partition): string | `default` | <EnterpriseAlert inline />
|
||||
- [`Meta`](#meta): map | no default
|
||||
- [`Meta`](#meta): map
|
||||
- [`JWT`](#jwt): map
|
||||
- [`Providers`](#jwt-providers): list of maps
|
||||
- [`Name`](#jwt-providers-name): string
|
||||
- [`VerifyClaims`](#jwt-provider-verifyclaims): list of maps
|
||||
- [`Path`](#jwt-provider-verifyclaims-path): list of strings
|
||||
- [`Value`](#jwt-provider-verifyclaims-value): string
|
||||
- [`Sources`](#sources): list | no default
|
||||
- [`Name`](#sources-name): string | no default
|
||||
- [`Peer`](#sources-peer): string | no default
|
||||
|
|
@ -32,25 +38,25 @@ The following outline shows how to format the service intentions configuration e
|
|||
- [`Permissions`](#sources-permissions): list | no default
|
||||
- [`Action`](#sources-permissions-action): string | no default | required
|
||||
- [`HTTP`](#sources-permissions-http): map | required
|
||||
- [`PathExact`](#sources-permissions-http): string | no default
|
||||
- [`PathPrefix`](#sources-permissions-http): string | no default
|
||||
- [`PathRegex`](#sources-permissions-http): string | no default
|
||||
- [`Methods`](#sources-permissions-http): list | no default
|
||||
- [`Header`](#sources-permissions-http-header): list of maps |no default
|
||||
- [`PathExact`](#sources-permissions-http): string
|
||||
- [`PathPrefix`](#sources-permissions-http): string
|
||||
- [`PathRegex`](#sources-permissions-http): string
|
||||
- [`Methods`](#sources-permissions-http): list
|
||||
- [`Header`](#sources-permissions-http-header): list of maps
|
||||
- [`Name`](#sources-permissions-http-header): string | required
|
||||
- [`Present`](#sources-permissions-http-header): boolean | `false`
|
||||
- [`Exact`](#sources-permissions-http-header): string | no default
|
||||
- [`Prefix`](#sources-permissions-http-header): string | no default
|
||||
- [`Suffix`](#sources-permissions-http-header): string | no default
|
||||
- [`Regex`](#sources-permissions-http-header): string | no default
|
||||
- [`Exact`](#sources-permissions-http-header): string
|
||||
- [`Prefix`](#sources-permissions-http-header): string
|
||||
- [`Suffix`](#sources-permissions-http-header): string
|
||||
- [`Regex`](#sources-permissions-http-header): string
|
||||
- [`Invert`](#sources-permissions-http-header): boolean | `false`
|
||||
- [`Precedence`](#sources-precedence): number | no default | _read-only_
|
||||
- [`Precedence`](#sources-precedence): number
|
||||
- [`Type`](#sources-type): string | `consul`
|
||||
- [`Description`](#sources-description): string
|
||||
- [`LegacyID`](#sources-legacyid): string | no default | _read-only_
|
||||
- [`LegacyMeta`](#sources-legacymeta): map | no default | _read-only_
|
||||
- [`LegacyCreateTime`](#sources-legacycreatetime): string | no default | _read-only_
|
||||
- [`LegacyUpdateTime`](#sources-legacyupdatetime): string | no default | _read-only_
|
||||
- [`LegacyID`](#sources-legacyid): string
|
||||
- [`LegacyMeta`](#sources-legacymeta): map
|
||||
- [`LegacyCreateTime`](#sources-legacycreatetime): string
|
||||
- [`LegacyUpdateTime`](#sources-legacyupdatetime): string
|
||||
|
||||
</Tab>
|
||||
<Tab heading= "YAML" group="yaml">
|
||||
|
|
@ -64,6 +70,12 @@ The following outline shows how to format the service intentions configuration e
|
|||
- [`destination`](#spec-destination): map | no default
|
||||
- [`name`](#spec-destination-name): string | required
|
||||
- [`namespace`](#metadata-namespace): string | `default` | <EnterpriseAlert inline/>
|
||||
- [`jwt`](#spec-jwt): map
|
||||
- [`providers`](#spec-jwt-providers): list of maps
|
||||
- [`name`](#spec-jwt-providers-name): string
|
||||
- [`verifyClaims`](#spec-jwt-provider-verifyclaims): list of maps
|
||||
- [`path`](#spec-jwt-provider-verifyclaims-path): list of strings
|
||||
- [`value`](#spec-jwt-provider-verifyclaims-value): string
|
||||
- [`sources`](#spec-sources): list | no default
|
||||
- [`name`](#spec-sources-name): string | no default
|
||||
- [`peer`](#spec-sources-peer): string | no default
|
||||
|
|
@ -109,6 +121,19 @@ Meta = {
|
|||
"<key-1>" = "<value-1>"
|
||||
"<key-2>" = "<value-2>"
|
||||
}
|
||||
JWT = {
|
||||
Providers = [
|
||||
{
|
||||
Name = "<JWT-provider-name>"
|
||||
VerifyClaims = [
|
||||
{
|
||||
Path = ["<claim>"]
|
||||
Value = "<api.apps.organization.com>"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
Sources = [
|
||||
{
|
||||
Name = "<name of service sending traffic>" # string
|
||||
|
|
@ -179,6 +204,12 @@ spec:
|
|||
destination:
|
||||
name: <name of destination service>
|
||||
namespace: <destination namespace>
|
||||
jwt:
|
||||
providers:
|
||||
name: <JWT-provider-name>
|
||||
verifyClaims:
|
||||
path: [<aud>]
|
||||
value: <api.apps.organization.com>
|
||||
sources:
|
||||
name: <name of service sending traffic>
|
||||
peer: <name of cluster containing source service>
|
||||
|
|
@ -224,6 +255,19 @@ spec:
|
|||
"key-1":"<value-1>",
|
||||
"key-2":"<value-2>"
|
||||
},
|
||||
"JWT": {
|
||||
"Providers": [
|
||||
{
|
||||
"Name": "<JWT-provider-name>",
|
||||
"VerifyClaims": [
|
||||
{
|
||||
"Path": ["<aud>"],
|
||||
"Value": "<api.apps.organization.com>"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"Sources":[
|
||||
{
|
||||
"Name":"<name of service sending traffic>",
|
||||
|
|
@ -346,6 +390,63 @@ Specifies key-value pairs to add to the KV store when the configuration entry is
|
|||
- keys: String
|
||||
- values: String, integer, or float
|
||||
|
||||
### `JWT`
|
||||
|
||||
Specifies a JSON Web Token provider configured in a [JWT provider configuration entry](/consul/docs/connect/config-entries/jwt-provider), as well as additional configurations for verifying a service's JWT before authorizing communication between services
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: Map that contains [`JWT{}.Providers`](#jwt-providers)
|
||||
|
||||
### `JWT{}.Providers`
|
||||
|
||||
Specifies the names of one or more previously configured [JWT provider configuration entries](/consul/docs/connect/config-entries/jwt-provider), which include the information necessary to validate a JSON web token.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: List of maps
|
||||
|
||||
### `JWT{}.Providers[].Name`
|
||||
|
||||
Specifies the name of a JWT provider defined in the `Name` field of the [`jwt-provider` configuration entry](/consul/docs/connect/config-entries/jwt-provider). You must write the JWT Provider to Consul before referencing it in a service intention.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: String
|
||||
|
||||
### `JWT{}.Providers[].VerifyClaims`
|
||||
|
||||
Specifies additional token information to verify beyond what is configured in the JWT provider configuration entry. This map takes the form of a JSON web token claim and a value to match for verification.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: List of maps that can contain the following parameters:
|
||||
|
||||
- [`Path`](#jwt-providers-verifyclaims-path)
|
||||
- [`Value`](#jwt-providers-verifyclaims-value)
|
||||
|
||||
### `JWT{}.Providers[].VerifyClaims[].Path`
|
||||
|
||||
Specifies the path to the claim in the JSON web token. For more information about JWT claims, refer to the [IETF standards documentation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1).
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: List of strings
|
||||
|
||||
### `JWT{}.Providers[].VerifyClaims.Value`
|
||||
|
||||
Specifies the value to match on when verifying the the claim designated in [`JWT{}.Providers[].VerifyClaims[].Path`](#jwt-providers-verifyclaims-path).
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: String
|
||||
|
||||
### `Sources[]`
|
||||
|
||||
List of configurations that define intention sources and the authorization granted to the sources. You can specify source configurations in any order, but Consul stores and evaluates them in order of reverse precedence at runtime. Refer to [`Precedence`](#sources-precedence) for additional information.
|
||||
|
|
@ -514,7 +615,6 @@ Each member of the `Header` list is a map that contains a `Name` field and at le
|
|||
| `Regex` | Specifies a regular expression pattern as the value for the header key set in the `Name` field. If the request header value matches the regex, Consul applies the permission. Do not specify `Regex` if `Present`, `Exact`, `Prefix`, or `Suffix` are configured in the same `Header` configuration. The regex syntax is proxy-specific. If using Envoy, refer to the [re2 documentation](https://github.com/google/re2/wiki/Syntax) for details. | string | optional |
|
||||
| `Invert` | Inverts the matching logic configured in the `Header`. Default is `false`. | boolean | optional |
|
||||
|
||||
|
||||
### `Sources[].Precedence`
|
||||
|
||||
The `Precedence` field contains a read-only integer. Consul generates the value based on name configurations for the source and destination services. Refer to [Precedence and matching order](/consul/docs/connect/intentions/create-manage-intentions#precedence-and-matching-order) for additional information.
|
||||
|
|
@ -608,6 +708,7 @@ Specifies the [namespace](/consul/docs/enterprise/namespaces) that the configura
|
|||
- Data type: String
|
||||
|
||||
### `spec`
|
||||
|
||||
Map that contains the details about the `ServiceIntentions` configuration entry. The `apiVersion`, `kind`, and `metadata` fields are siblings of the spec field. All other configurations are children.
|
||||
|
||||
#### Values
|
||||
|
|
@ -637,15 +738,61 @@ You can also specify a wildcard character (`*`) to match all services that are m
|
|||
- This field is required.
|
||||
- Data type: String
|
||||
|
||||
### `spec.metadata.namespace` <EnterpriseAlert inline />
|
||||
### `spec.jwt`
|
||||
|
||||
Specifies the [namespace](/consul/docs/enterprise/namespaces) that the configuration entry applies to. You can also specify a wildcard character (`*`) to match all namespaces. Intentions that are applied with a wildcard, however, are not supported when defining L7 [`permissions`](#spec-sources-permissions).
|
||||
|
||||
Refer to [Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for information about how Consul namespaces map to Kubernetes Namespaces. Open source Consul distributions (Consul OSS) ignore the `metadata.namespace` configuration.
|
||||
Specifies a JSON Web Token provider configured in a [JWT provider configuration entry](/consul/docs/connect/config-entries/jwt-provider), as well as additional configurations for verifying a service's JWT before authorizing communication between services
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: If not set, destination service namespace is inherited from the `connectInject.consulNamespaces` configuration. Refer to [ServiceIntentions Special Case (Enterprise)](/consul/docs/k8s/crds#serviceintentions-special-case-enterprise) for details.
|
||||
- Default: None
|
||||
- Data type: Map that contains [`spec.jwt.providers`](#spec-jwt-providers)
|
||||
|
||||
### `spec.jwt.providers`
|
||||
|
||||
Specifies the names of one or more previously configured [JWT provider configuration entries](/consul/docs/connect/config-entries/jwt-provider), which include the information necessary to validate a JSON web token.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: List of maps
|
||||
|
||||
### `spec.jwt.providers[].name`
|
||||
|
||||
Specifies the name of a JWT provider defined in the `metadata.name` field of the [JWT provider configuration entry](/consul/docs/connect/config-entries/jwt-provider). You must write the JWT Provider to Consul before referencing it in a service intention.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: String
|
||||
|
||||
### `spec.jwt.providers[].verifyClaims`
|
||||
|
||||
Specifies additional token information to verify beyond what is configured in the JWT provider configuration entry. This map takes the form of a JSON web token claim and a value to match for verification.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: List of maps that can contain the following parameters:
|
||||
|
||||
- [`path`](#spec-jwt-providers-verifyclaims-path)
|
||||
- [`value`](#spec-jwt-providers-verifyclaims-value)
|
||||
|
||||
### `spec.jwt.providers[].verifyClaims[].path`
|
||||
|
||||
Specifies the path to the claim in the JSON web token. For more information about JWT claims, refer to the [IETF standards documentation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1).
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: List of strings
|
||||
|
||||
### `spec.jwt.providers[].verifyClaims[].value`
|
||||
|
||||
Specifies the value to match on when verifying the the claim designated in [`JWT{}.Providers[].VerifyClaims[].Path`](#jwt-providers-verifyclaims-path).
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: String
|
||||
|
||||
### `spec.sources[]`
|
||||
|
|
@ -1313,3 +1460,111 @@ When using cluster peering connections, intentions secure your deployments with
|
|||
```
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
### JWT validation with intentions
|
||||
|
||||
The following example configures a service intention that evaluates requests when a service named `backend` receives a request from the `frontend` service. When the request is sent to the `/admin` HTTP path, a JSON Web Token provided by Okta is evaluated. In addition to the validation requirements in a separate JWT provider configuration entry, an additional check occurs to confirm that the token has either a `perms` or `role` claim with the `admin` value. If it does, the request is authorized.
|
||||
|
||||
Because the intention allows requests that come from the `/` HTTP path, only requests on the `/admin` path are subject to token validation.
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
```hcl
|
||||
Kind = "service-intentions"
|
||||
Name = "backend"
|
||||
Sources = [
|
||||
{
|
||||
Name = "frontend"
|
||||
Permissions = [
|
||||
{
|
||||
HTTP = {
|
||||
PathExact = "/admin"
|
||||
}
|
||||
JWT = {
|
||||
Providers = [
|
||||
{
|
||||
Name = "okta"
|
||||
VerifyClaims = [
|
||||
{
|
||||
Path = ["perms", "role"]
|
||||
Value = "admin"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
Action = "allow"
|
||||
HTTP = {
|
||||
PathPrefix = "/"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ServiceIntentions
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
sources:
|
||||
name: frontend
|
||||
permissions:
|
||||
http:
|
||||
pathExact: /admin
|
||||
jwt:
|
||||
providers:
|
||||
name: okta
|
||||
verifyClaims:
|
||||
path:
|
||||
- perms
|
||||
- role
|
||||
value: admin
|
||||
action: allow
|
||||
http:
|
||||
pathPrefix: /
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"Kind": "service-intentions",
|
||||
"Name": "backend",
|
||||
"Sources": [
|
||||
{
|
||||
"Name": "frontend",
|
||||
"Permissions": [
|
||||
{
|
||||
"HTTP": {
|
||||
"PathExact": "/admin"
|
||||
},
|
||||
"JWT": {
|
||||
"Providers": [
|
||||
{
|
||||
"Name": "okta",
|
||||
"VerifyClaims": [
|
||||
{
|
||||
"Path": ["perms", "role"],
|
||||
"Value": "admin"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"Action": "allow",
|
||||
"HTTP": {
|
||||
"PathPrefix": "/"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
</CodeTabs>
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
---
|
||||
page_title: JWT authorization overview
|
||||
description: |-
|
||||
Consul can use service mesh proxies to check and validate JSON Web Tokens (JWT) to enable additional identify-based access security for both human and machine users. Learn how to configure a JWT provider configuration entry and a service intentions configuration entry to authorize requests.
|
||||
---
|
||||
|
||||
# Use JWT authorization with service intentions
|
||||
|
||||
JSON Web Tokens (JWT) are a method for identity-based access to services for both humans and machines. The [JWT provider configuration entry](/consul/docs/connect/config-entries/jwt-provider) enables you to define JWTs as part of a JSON Web Key Set (JWKS), which contains the information necessary for Consul to validate access and configure behavior for requests that include JWTs.
|
||||
|
||||
By specifying a JSON Web Key Set (JWKS) in the configuration entry and referencing the key set in a service intention, Consul can enforce service intentions based on the presence of a JWT. This security configuration is not related to the [JSON Web Token Auth Method](/consul/docs/security/acl/auth-methods/jwt), which associates JWTs with the Consul ACLs instead of service intentions.
|
||||
|
||||
## Workflow
|
||||
|
||||
The process to configure your network to enforce service intentions based on JSON web tokens consists of the following steps:
|
||||
|
||||
1. **Create a JWT provider configuration entry**. This configuration entry defines rules and behaviors for verifying tokens. These configurations apply to admin partitions in Consul Enterprise, which is functionally equivalent to a datacenter in Consul OSS. Then, write the `jwt-provider` configuration entry to Consul. The ACL policy requirement to read and modify this configuration entry is `mesh:write`.
|
||||
|
||||
1. **Create or update a service intentions configuration entry to reference the JWT provider**. This configuration invokes the name of the `jwt-provider` configuration entry you created, which causes the Envoy proxy to verify the token and the permissions it authorizes before the incoming request is accepted. Then, write the `service-intentions` configuration entry that references the JWT to Consul. The ACL policy requirement to read and modify this configuration entry is `mesh:write`.
|
||||
|
||||
### Wildcards and intention defaults
|
||||
|
||||
Because intentions without tokens are authorized when they arrive at the destination proxy, a [common pattern for the service-intentions configuration entry](/consul/docs/connect/config-entries/service-intentions#l4-intentions-for-all-destinations) sets the entry’s `Name` field as a wildcard, `*`. This pattern enables you to apply incoming requests from specific services to every service in the datacenter.
|
||||
|
||||
When configuring your deployment to enforce service intentions with JSON Web Tokens, it is possible for multiple tokens with different permissions to apply to a single service’s incoming request based on attributes such as HTTP path or the request method. Because the `service-intentions` configuration entry applies the intention that most closely matches the request, using the `Name` wildcard with specific JWT authorization configurations can lead to unintended results.
|
||||
|
||||
When you set the `JWT{}.Providers` field in a service intentions configuration entry to the wildcard `*`, you can configure default behavior for all services that present a token that matches an existing JWT provider configuration entry. In this configuration, services that have a valid token but do not have a more specific matching intention default to the behavior defined in the wildcard intention.
|
||||
|
||||
## Usage
|
||||
|
||||
To configure Envoy proxies in the service mesh to validate JWTs before forwarding requests to servers, complete the following steps:
|
||||
|
||||
### Create a JWT provider configuration entry
|
||||
|
||||
The `jwt-provider` configuration requires the following fields:
|
||||
|
||||
- `Kind`: This field must be set to `"jwt-provider"`
|
||||
- `Name`: We recommend naming the configuration file after the JWT provider used in the configuration.
|
||||
- `Issuer`: This field must match the token's `iss` claim
|
||||
|
||||
You must also specify a JSON Web Key Set in the `JSONWebKeySet` field. You can specify the JWKS as one of the following:
|
||||
|
||||
- A local string
|
||||
- A path to a local file
|
||||
- A remote location specified with a URI
|
||||
|
||||
A JWKS can be made available locally or remotely, but not both. In addition, a local JWKS must be specified as either a string or a path to the file containing the token.
|
||||
|
||||
You can also specify where the JWT is located, a retry policy, and text to append to the header when forwarding the request after token validation.
|
||||
|
||||
The following example configures Consul to fetch a JSON Web Token issued by Okta. Consul fetches the token from the URI and keeps it in its cache for 30 minutes before the token expires. After validation, the token is forwarded to the backend with `user-token` appended to the HTTP header.
|
||||
|
||||
```hcl
|
||||
Kind = "jwt-provider"
|
||||
Name = "okta"
|
||||
|
||||
Issuer = "okta"
|
||||
|
||||
JSONWebKeySet = {
|
||||
Remote = {
|
||||
URI = "https://<org>.okta.com/oauth2/default/v1/keys"
|
||||
CacheDuration = "30m"
|
||||
}
|
||||
}
|
||||
|
||||
Forwarding = {
|
||||
HeaderName = "user-token"
|
||||
}
|
||||
```
|
||||
|
||||
Refer to [JWT provider configuration entry](/consul/docs/connect/config-entries/jwt-provider) for more information about the fields you can configure.
|
||||
|
||||
To write the configuration entry to Consul, use the [`consul config write` command](/consul/commands/config/write):
|
||||
|
||||
```shell-session
|
||||
$ consul config write okta-provider.hcl
|
||||
```
|
||||
|
||||
### Update service intentions
|
||||
|
||||
After you create the JWT provider entry, you can update your service intentions so that proxies validate the token before authorizing a request. The following example includes the minimum required configuration to enable JWT authorization with service intentions:
|
||||
|
||||
```hcl
|
||||
Kind = "service-intentions"
|
||||
Name = "web"
|
||||
JWT = {
|
||||
Providers = [
|
||||
{
|
||||
Name = "okta"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
You can include additional configuration information to require the token to match specific claims. You can also configure the `JWT` field to apply only to requests that come from certain HTTP paths. Refer to [JWT validations with intentions](/consul/docs/conntect/config-entries/service-intentions#jwt-validations-with-intentions) for an example configuration.
|
||||
|
||||
After you update the service intention, write the configuration to Consul so that it takes effect:
|
||||
|
||||
```shell-session
|
||||
$ consul config write web-intention.hcl
|
||||
```
|
||||
|
|
@ -420,6 +420,10 @@
|
|||
"title": "Ingress gateway",
|
||||
"path": "connect/config-entries/ingress-gateway"
|
||||
},
|
||||
{
|
||||
"title": "JWT Provider",
|
||||
"path": "connect/config-entries/jwt-provider"
|
||||
},
|
||||
{
|
||||
"title": "Mesh",
|
||||
"path": "connect/config-entries/mesh"
|
||||
|
|
@ -566,6 +570,10 @@
|
|||
"title": "Create and manage service intentions",
|
||||
"path": "connect/intentions/create-manage-intentions"
|
||||
},
|
||||
{
|
||||
"title": "JWT authorization for intentions",
|
||||
"path": "connect/intentions/jwt-authorization"
|
||||
},
|
||||
{
|
||||
"title": "Service intentions legacy mode",
|
||||
"path": "connect/intentions/legacy"
|
||||
|
|
|
|||
Loading…
Reference in New Issue