github
/
consul
mirror of https://github.com/hashicorp/consul
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

Merge pull request #11930 from hashicorp/docs/admin-partition-updates-1.11.0-misc 

added line about wildcard intentions not supported for admin partitions
pull/11990/head
trujillo-adam 3 years ago committed by GitHub
parent
69ccad8b44 d4f9a30927
commit
0ac96c7d23
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 107 additions and 26 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 133
      website/content/docs/connect/intentions.mdx

133
website/content/docs/connect/intentions.mdx
Unescape View File

@ -49,26 +49,17 @@ target destination. After verifying the TLS client certificate, the cached
intentions should be consulted for each incoming connection/request to intentions should be consulted for each incoming connection/request to
determine if it should be accepted or rejected. determine if it should be accepted or rejected.
The default intention behavior is defined by the default [ACL The default intention behavior is defined by the [`default_policy`](/docs/agent/options#acl_default_policy) configuration.
policy](/docs/agent/options#acl_default_policy). If the default ACL policy is If the configuration is set `allow`, then all service mesh Connect connections will be allowed by default.
"allow all", then all Connect connections are allowed by default. If the If is set to `deny`, then all connections or requests will be denied by default.
default ACL policy is "deny all", then all Connect connections or requests are
denied by default.
## Intention Basics ## Intention Basics
Intentions are managed primarily via You can define a [`service-intentions`](/docs/connect/config-entries/service-intentions) configuration entry to create and manage intentions, as well as manage intentions through the Consul UI. You can also perform some intention-related tasks using the API and CLI commands. Refer to the [API](/api-docs/connect/intentions) and [CLI](/commands/intention) documentation for details.
[`service-intentions`](/docs/connect/config-entries/service-intentions) config
entries or the UI. Some simpler tasks can also be achieved with the older
[API](/api-docs/connect/intentions) or [CLI](/commands/intention). Please see
the respective documentation for each for full details on options, flags, etc.
Below is an example of a basic The following example shows a `service-intentions` configuration entry that specifes two intentions. Refer to the [`service-intentions`](/docs/connect/config-entries/service-intentions) documentation for the full data model and additional examples.
[`service-intentions`](/docs/connect/config-entries/service-intentions) config
entry representing two simple intentions. The full data model complete with <CodeTabs>
more examples can be found in the
[`service-intentions`](/docs/connect/config-entries/service-intentions) config
entry documentation.
```hcl ```hcl
Kind = "service-intentions" Kind = "service-intentions"
@ -85,20 +76,41 @@ Sources = [
] ]
``` ```
This config entry defines two intentions with a common destination of "db". The ```json
first intention above is a deny intention with a source of "web". This says {
"Kind": "service-intentions",
"Name": "db",
"Sources": [
{
"Action": "deny",
"Name": "web"
},
{
"Action": "allow",
"Name": "api"
}
]
}
```
</CodeTabs>
This configuration entry defines two intentions with a common destination of `db`. The
first intention above is a deny intention with a source of `web`. This says
that connections from web to db are not allowed and the connection will be that connections from web to db are not allowed and the connection will be
rejected. The second intention is an allow intention with a source of "api". rejected. The second intention is an allow intention with a source of `api`.
This says that connections from api to db are allowed and connections will be This says that connections from api to db are allowed and connections will be
accepted. accepted.
### Wildcard Intentions ### Wildcard Intentions
You can use the `*` wildcard when defining an intention source or destination. The wildcard matches _any_ value and can serve as a "catch-all" entry for intentions that should have a wide scope. You can use the `*` wildcard to match service names when defining an intention source or destination. The wildcard matches _any_ value, which enables you to set a wide initial scope when configuring intentions.
The wildcard is supported in Consul Enterprise `namespace` fields (see [Namespaces](/docs/enterprise/namespaces) for additional information), but it _is not supported_ in `partition` fields (see [Admin Partitions](/docs/enterprise/admin-partitions) for additional information).
You can use a wildcard to match service names. If you are using Consul Enterprise, you can also use a wildcard to match a namespace. In the following example, the `web` service cannot connect to _any_ service:
This example says that the "web" service cannot connect to _any_ service: <CodeTabs>
```hcl ```hcl
Kind = "service-intentions" Kind = "service-intentions"
@ -111,7 +123,24 @@ Sources = [
] ]
``` ```
And this example says that _no_ service can connect to the "db" service: ```json
{
"Kind": "service-intentions",
"Name": "*",
"Sources": [
{
"Action": "deny",
"Name": "web"
}
]
}
```
</CodeTabs>
The `db` service is configured to deny all connection in the following example:
<CodeTabs>
```hcl ```hcl
Kind = "service-intentions" Kind = "service-intentions"
@ -124,8 +153,25 @@ Sources = [
] ]
``` ```
<EnterpriseAlert inline /> This example grants Prometheus ```json
access to any service in any namespace. {
"Kind": "service-intentions",
"Name": "db",
"Sources": [
{
"Action": "deny",
"Name": "*"
}
]
}
```
</CodeTabs>
<EnterpriseAlert inline /> This example grants Prometheus access to any service in
any namespace.
<CodeTabs>
```hcl ```hcl
Kind = "service-intentions" Kind = "service-intentions"
@ -140,6 +186,23 @@ Sources = [
] ]
``` ```
```json
{
"Kind": "service-intentions",
"Name": "*",
"Namespace": "*",
"Sources": [
{
"Action": "allow",
"Name": "prometheus",
"Namespace": "monitoring"
}
]
}
```
</CodeTabs>
### Enforcement ### Enforcement
For services that define their [protocol] as TCP, intentions mediate the For services that define their [protocol] as TCP, intentions mediate the
@ -177,7 +240,7 @@ top to bottom, with larger numbers being evaluated first.
The precedence value can be read from a The precedence value can be read from a
[field](/docs/connect/config-entries/service-intentions#precedence) on the [field](/docs/connect/config-entries/service-intentions#precedence) on the
`service-intentions` config entry after it is modified. Precedence cannot be `service-intentions` configuration entry after it is modified. Precedence cannot be
manually overridden today. manually overridden today.
The numbers in the table above are not stable. Their ordering will remain The numbers in the table above are not stable. Their ordering will remain
@ -201,12 +264,30 @@ for its own service name in order to know whether or not to authorize
connections. The following ACL policy will implicitly grant `intentions:read` connections. The following ACL policy will implicitly grant `intentions:read`
(note _read_) for service `web`. (note _read_) for service `web`.
<CodeTabs>
```hcl ```hcl
service "web" { service "web" {
policy = "write" policy = "write"
} }
``` ```
```json
{
"service": [
{
"web": [
{
"policy": "write"
}
]
}
]
}
```
</CodeTabs>
It is possible to explicitly specify intention permissions. For example, It is possible to explicitly specify intention permissions. For example,
the following policy will allow a service to be discovered without granting the following policy will allow a service to be discovered without granting
access to read intentions for it. access to read intentions for it.

Write Preview
Loading…
Cancel
Save