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.
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.
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.
<CodeTabs>
```hcl
Kind = "service-intentions"
@ -85,20 +76,41 @@ Sources = [
]
```
This config 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
```json
{
"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
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
accepted.
### 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
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
Kind = "service-intentions"
@ -124,8 +153,25 @@ Sources = [
]
```
<EnterpriseAlert inline /> This example grants Prometheus
access to any service in any namespace.
```json
{
"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
Kind = "service-intentions"
@ -140,6 +186,23 @@ Sources = [
]
```
```json
{
"Kind": "service-intentions",
"Name": "*",
"Namespace": "*",
"Sources": [
{
"Action": "allow",
"Name": "prometheus",
"Namespace": "monitoring"
}
]
}
```
</CodeTabs>
### Enforcement
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
[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.
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`
(note _read_) for service `web`.
<CodeTabs>
```hcl
service "web" {
policy = "write"
}
```
```json
{
"service": [
{
"web": [
{
"policy": "write"
}
]
}
]
}
```
</CodeTabs>
It is possible to explicitly specify intention permissions. For example,
the following policy will allow a service to be discovered without granting
trujillo-adam
3 years ago
committed by