taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

Merge pull request #77 from nats-io/tls-auth

Browse Source 
Incorporate details about mutual auth
This commit is contained in:
Ginger Collison 2020-03-26 15:54:14 -05:00 committed by GitHub
commit ded758e784
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 8 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
nats-server/configuration/clustering/cluster_config.md
View File

@ -7,7 +7,7 @@ The `cluster` configuration map has the following configuration options:
| `host` | Interface where the gateway will listen for incoming route connections. | | `host` | Interface where the gateway will listen for incoming route connections. |
| `port` | Port where the gateway will listen for incoming route connections. | | `port` | Port where the gateway will listen for incoming route connections. |
| `listen` | Combines `host` and `port` as `<host>:<port>`. | | `listen` | Combines `host` and `port` as `<host>:<port>`. |
| `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing the clustering connection. | | `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing the clustering connection. `verify` is always enabled and `cert_file` is used for client and server. [See](../securing_nats/tls.md#Wrong-Key-Usage) for certificate pitfalls. |
| `advertise` | Hostport `<host>:<port>` to advertise how this server can be contacted by other cluster members. This is useful in setups with NAT. | | `advertise` | Hostport `<host>:<port>` to advertise how this server can be contacted by other cluster members. This is useful in setups with NAT. |
| `no_advertise` | When set to `true`, do not advertise this server to clients. | | `no_advertise` | When set to `true`, do not advertise this server to clients. |
| `routes` | A list of other servers \(URLs\) to cluster with. Self-routes are ignored. Should authentication via `token` or `username`/`password` be required, specify them as part of the URL. | | `routes` | A list of other servers \(URLs\) to cluster with. Self-routes are ignored. Should authentication via `token` or `username`/`password` be required, specify them as part of the URL. |

5
nats-server/configuration/clustering/cluster_tls.md
View File

@ -1,9 +1,8 @@
# TLS Authentication # TLS Authentication
When setting up clusters all servers in the cluster, if using TLS, will both verify the connecting endpoints and the server responses. So certificates are checked in both directions. Certificates can be configured only for the server's cluster identity, keeping client and server certificates separate from cluster formation. When setting up clusters, all servers in the cluster, if using TLS, will both verify the connecting endpoints and the server responses. So certificates are checked in [both directions](../securing_nats/tls.md#Wrong-Key-Usage). Certificates can be configured only for the server's cluster identity, keeping client and server certificates separate from cluster formation.
TLS Mutual Authentication _is the recommended way_ of securing routes.
TLS Mutual Authentication _is the only way_ of securing routes.
```text ```text
cluster { cluster {
listen: 127.0.0.1:4244 listen: 127.0.0.1:4244

2
nats-server/configuration/gateways/gateway.md
View File

@ -68,7 +68,7 @@ Published [foo] : 'bar'
| `host` | Interface where the gateway will listen for incoming gateway connections. | | `host` | Interface where the gateway will listen for incoming gateway connections. |
| `port` | Port where the gateway will listen for incoming gateway connections. | | `port` | Port where the gateway will listen for incoming gateway connections. |
| `listen` | Combines `host` and `port` as `<host>:<port>` | | `listen` | Combines `host` and `port` as `<host>:<port>` |
| `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing gateway connections. | | `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing gateway connections. `verify` is always enabled. Unless otherwise specified in a [`gateway`](#Gateway-Entry), `cert_file` will be the default client certificate. [See](../securing_nats/tls.md#Wrong-Key-Usage) for certificate pitfalls. |
| `advertise` | Hostport `<host>:<port>` to advertise how this server can be contacted by other gateway members. This is useful in setups with NAT. | | `advertise` | Hostport `<host>:<port>` to advertise how this server can be contacted by other gateway members. This is useful in setups with NAT. |
| `connect_retries` | After how many failed connect attempts to give up establishing a connection to a discovered gateway. Default is `0`, do not retry. When enabled, attempts will be made once a second. This, does not apply to explicitly configured gateways. | | `connect_retries` | After how many failed connect attempts to give up establishing a connection to a discovered gateway. Default is `0`, do not retry. When enabled, attempts will be made once a second. This, does not apply to explicitly configured gateways. |
| `authorization` | [Authorization](../securing_nats/auth_intro/README.md#Authorization-Map) map for gateways. When `token` or a single `username`/`password` are used, they define the authentication mechanism this server expects. What authentication values other server have to provide when connecting. They also specify how this server will authenticate itself when establishing a connection to a discovered gateway. This will not be used for gateways explicitly listed in [`gateways`](#Gateway-Entry) and therefore have to be provided as part of the URL. If you use token or password based authentication, either use the same credentials throughout the system or list every gateway explicitly on every server. If the `tls` configuration map specifies `verify_and_map` only provide the expected `username`. Here different certificates can be used, but they do have to map to the same `username`. The authorization map also allows for `timeout` which is honored but `users` and `permissions` are ignored. | | `authorization` | [Authorization](../securing_nats/auth_intro/README.md#Authorization-Map) map for gateways. When `token` or a single `username`/`password` are used, they define the authentication mechanism this server expects. What authentication values other server have to provide when connecting. They also specify how this server will authenticate itself when establishing a connection to a discovered gateway. This will not be used for gateways explicitly listed in [`gateways`](#Gateway-Entry) and therefore have to be provided as part of the URL. If you use token or password based authentication, either use the same credentials throughout the system or list every gateway explicitly on every server. If the `tls` configuration map specifies `verify_and_map` only provide the expected `username`. Here different certificates can be used, but they do have to map to the same `username`. The authorization map also allows for `timeout` which is honored but `users` and `permissions` are ignored. |

5
nats-server/configuration/securing_nats/tls.md
View File

@ -107,7 +107,10 @@ The necessary values for key usage depend on the ciphers used. `Digital Signatur
With respect to NATS the relevant values for extended key usage are: With respect to NATS the relevant values for extended key usage are:
* `TLS WWW server authentication` - To authenticate as server for incoming connections. A NATS server will need a certificate containing this. * `TLS WWW server authentication` - To authenticate as server for incoming connections. A NATS server will need a certificate containing this.
* `TLS WWW client authentication` - To authenticate as client for outgoing connections. Only needed when connecting to a server where `verify` or `verify_and_map` are specified. In these cases, a NATS client will need a certificate with this value. Server to server connections can be configured with `verify` as well. Then NATS server will have to present a certificate with this value too. Certificates containing both values are an option. * `TLS WWW client authentication` - To authenticate as client for outgoing connections. Only needed when connecting to a server where `verify` or `verify_and_map` are specified. In these cases, a NATS client will need a certificate with this value.
* [Leaf node](../leafnodes/README.md) connections can be configured with `verify` as well. Then connecting NATS server will have to present a certificate with this value too. Certificates containing both values are an option.
* [Cluster](../clustering/README.md) connections always have `verify` enabled. Which server acts as client and server comes down to timing and therefore can't be individually configured. Certificates containing both values are a must.
* [Gateway](../gateways/README.md) connections always have `verify` enabled. Unlike cluster outgoing connections can specify a separate cert. Certificates containing both values are an option that reduce configuration.
Note that it's common practice for non-web protocols to use the `TLS WWW` authentication fields, as a matter of history those have become embedded as generic options. Note that it's common practice for non-web protocols to use the `TLS WWW` authentication fields, as a matter of history those have become embedded as generic options.