SynadiaSynadia

Back to Newsletter

NATS Weekly #23

Byron Ruth

Published on Apr 25th, 2022

Week of April 18 - 24, 2022

🗞 Announcements, writings, and projects

A short list of  announcements, blog posts, projects updates and other news.

️ 💁 News

Random announcements that don't fit into the other categories.

⚡Releases

Official releases from NATS repos and others in the ecosystem.

📖 Articles

Blog posts, tutorials, or any other text-based content about NATS.

💬 Discussions

Github Discussions from various NATS repositories.

💡 Recently asked questions

Questions sourced from Slack, Twitter, or individuals. Responses and examples are in my own words, unless otherwise noted.

How can I use subject mapping to prepend a token?

This is a tip from Jean-Noel Moyne to introduce an default token when the publish subject is an optional prefix.

Given the subjects events.foo and special.events.foo, a subscription of *.events.foo would only match the latter. If a client ommitted the prefix token or if you are migrating from an existing subject mapping to require a specific subject hierarchy, then this can be done using subject mapping.

For this specific question, a subject maping from events.foo to, say, no_prefix.events.foo could be defined. This logically prepends a token so that a subscription of *.events.foo now receives messages published to events.foo.

One thing to keep in mind is choosing a new token that would not conflict with another existing subject. My choice for filling in tokens is to use a single underscore, e.g. _.events.foo.

Generalizing this pattern, optional tokens could be placed anywhere in the subject, e.g. _.events.foo._, for example if a suffix token is desired in the future.

How can you disconnect all connections for a specific user?

Two use cases that motivate this need would be operational and/or security related. A fairly straightforward one is handling the case when credentials are compromised and a user needs to either be removed completely or their password/token/key needs to be changed.

Another example would be an organization that has a policy in place that requires a person (or some level of automation) to control which users have access at what time and/or force password/token/key rotation.

NATS has multiple authentication methods, most of which support differentiating users, including:

For the first three methods above, since the users are defined in the server config, forcing a specific user connections to disconnect would require to remove the user from the respective block and then hot reloading the server.

For the JWT method, revocations are built-in with the ability to remove a revocation later if desired. Note, when a recovation is added or removed, the changes need to be pushed to the server to take effect (e.g. nsc push).

How many different ways can you run a NATS server?

This question is generalized from a user asking how they can run NATS in a testing/development environment.

The tl;dr is that NATS pretty much runs everywhere and with arbitrary topologies, and that is by design.

Here is a brief list of the ways that a NATS server process can run.

  • Embedded in your application process if you are using Go. See the server's test package for some examples.
  • Download the binary for your host architecture and run nats-server for a single node deployment. This can be on a physical machine/device or in a virtualized host such as a VM or container. Add the -js option is you want JetStream enabled. Alternately use -c and provide a config file.
  • Multiple nodes can be clustered together. For test/dev setups, this could be multiple nodes on the same host (machine or VM) using different ports. This could be used to mimic a production deployment with the same topology, but simplified to remove the need to provision additional servers. For a production setup, each node should be on a separate machine, across zones in the same region.
  • Gateways are used to cross region/geographic boundaries. These are clusters that are linked together.
  • Leaf nodes are a way to extend an existing cluster with a local authorization policy and/or for scenarios where low latency round trip time (RTT) is desired in the local application. Leaf nodes will transparently communicate with the cluster for subjects that are remote.

Note that all of these extended features like gateways and leaf nodes can be modeled with a set of nats-server processes on the same physical host. If each node is configured with its own port, they can be networked together using the various configuration blocks to create the topology you desire.

Back to Newsletter