Nats Features
Core nats features give teams fast message passing, persistent streams, and account isolation. You set them up by defining subjects, roles, and storage rules on your server. Engineering teams use this message system to link small apps together. Most teams start with one shared account for all services and developers. This setup makes early testing fast and simple. Yet broad permissions create big risks when you move to production. When one user or app has full subject rights, mistakes happen fa
Linkerd Security Features + NATS Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Core nats features give teams fast message passing, persistent streams, and account isolation. You set them up by defining subjects, roles, and storage rules on your server.
Engineering teams use this message system to link small apps together. Most teams start with one shared account for all services and developers. This setup makes early testing fast and simple. Yet broad permissions create big risks when you move to production. When one user or app has full subject rights, mistakes happen fast. A bad command can delete a stream or leak private data.
How core nats features work in practice
The system routes messages using text strings called subjects. Apps publish data to a subject, and other apps listen to it. You can use wildcards in subjects to match many topics at once. Core messaging sends data right away without saving it to a disk. If no app listens at that moment, the message disappears.
When teams need to save messages, they turn on the built-in storage engine. This engine writes messages to memory or disk inside streams. Consumers can replay old messages or process work in a queue. It also gives apps a simple key-value store and an audit storage. Teams use the key-value store to hold app settings and session state.
For security, the server uses accounts to split traffic between teams. One account cannot read or write messages in another account by default. Admins can set up explicit exports and imports to share chosen subjects. Users log in with passwords, tokens, keys, or decentralized JSON files. Each user gets a role that lists which subjects they can read or write.
How teams manage subject roles and stream limits
In production, admins map each service to its own restricted user role. A payment app might only write to billing subjects. A reporting app might only read from those same billing subjects. Admins also set resource limits on each account. These limits cap how many streams or connections an account can hold.
Human engineers also need ways to check streams and fix broken queues. Admins often give developers an admin credential to run server checks. This shared key lets them inspect stream state and purge stuck messages. Teams store these keys in secret managers or local files on laptops. Over time, too many people end up holding high-level messaging keys.
Linkerd Security Features + NATS Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native nats features solve and what keeps the session active
Native server rules do a great job of blocking unknown callers. Account walls keep different apps from mixing up their message traffic. Subject rules stop a service from writing to the wrong topic. TLS encryption keeps data safe while it moves across the network. These tools build a strong outer wall for your message bus.
Still, native setup rules only check who logs in and which subject they touch. The server does not inspect the payload inside a message in flight. If an engineer has read rights on a subject, they get everything. Payloads often hold raw emails, phone numbers, card numbers, or national IDs. A developer checking a live queue will pull those raw values onto their screen.
Also, static subject roles stay active all day and night. An engineer who needs five minutes to fix a stream keeps access forever. If a laptop gets stolen, the attacker gets that standing key too. Native logs show who logged in, not every single command or payload read. Teams need a better way to control human actions at runtime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between core messaging and the storage engine?
Core messaging sends data right to active listeners and does not save it. The storage engine saves messages to disk or memory for later replay.
How does the server keep different teams separate?
It uses isolated accounts to wall off message traffic by default. Teams only share data when an admin sets up an explicit subject export.
Why are static admin keys risky for message streams?
Static keys give broad power to delete streams or read raw payloads anytime. They do not expire after a fix or mask sensitive fields like card numbers.