gogrlx/nats-server
1
0
Fork 0
mirror of https://github.com/gogrlx/nats-server.git synced 2026-04-02 03:38:42 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #731 from nats-io/doc-route-perms

Browse Source 
Document route permissions
This commit is contained in:
Colin Sullivan
2018-09-05 10:39:12 -06:00
committed by GitHub
parent 2030d65ae2 0bc2663977
commit c6a71aece7
1 changed files with 54 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
README.md
View File

@@ -661,6 +661,60 @@ authorization {
The above configuration means that user `myUser` is allowed to publish to subjects with 2 tokens (`allow = "*.*"`) but not to the subjects matching `SYS.*`, `bar.baz` or `foo.*`. The user can subscribe to subjects matching `foo.*` and subject `bar` but not `foo.baz`.
Without the `deny` clause, you would have to explicitly list all the subjects the user can publish (and subscribe) without the ones in the deny list, which could prove difficult if the set size is huge.
#### Authorization and Clustering
The NATS server also supports route permissions. Route permissions define subjects that are imported and exported between individual servers in a cluster. Permissions may be defined in the cluster configuration using the `import` and `export` clauses. This enables a variety of use cases, allowing for configurations that will enforce a directional flow of messages or only allow a subset of data.
The following two server configurations will restrict messages that can flow between servers and allow
a directional flow of messages:
**Edge Server**
```text
cluster {
listen: 4244
authorization {
user: ruser
# bcrypted hash of "top_secret"
password: $2a$11$UaoHwUEqHaMwqo6L4kM2buOBnGFnSCWxNXY87hl.kCERqKK8WAXM.
timeout: 3
permissions {
import:["_INBOX.>", "global.>"]
export:["_INBOX.>", "global.>", "sensors.>"]
}
}
routes = [
nats-route://ruser:top_secret@cloudserver:4344
]
}
```
**Cloud Server**
```text
cluster {
listen: 4244
authorization {
user: ruser
# bcrypted hash of "top_secret"
password: $2a$11$UaoHwUEqHaMwqo6L4kM2buOBnGFnSCWxNXY87hl.kCERqKK8WAXM.
timeout: 3
permissions {
import:["_INBOX.>", "global.>", "sensors.>"]
export:["_INBOX.>", "global.>"]
}
}
routes = [
nats-route://ruser:top_secret@edgeserver:4244
]
}
```
The example above allows request/reply and messages published to any subject matching `global.>` to be freely propagated throughout the cluster. The cloud server imports and locally delivers messages published to subjects matching `sensors.>`, but won't export messages published to subjects matching `sensors.>`. This enforces a directional flow of sensor data from edge servers to the cloud servers. Also, as new edge servers are added they will not receive sensor data from other edge servers. Importing and exporting subjects in server clustering can provide additional security and optimize use of network resources.
### TLS