NATS Weekly #8
Week of January 3 - 9, 2022
🗞 Announcements, writings, and projects
A short list of announcements, blog posts, projects updates and other news.
⚡Releases
-
nats.java - v2.13.2 - with experimental KV support
-
nats.net - v0.14.4 - with experimental KV support
🎬 Media
- NATS Connect Live! Pub Sub on the Power Grid (YouTube, ~31m) - by Duke Energy, April 2020, slide deck
📖 Articles
-
Integrating NATS into the Cyscale Platform - Cyscale blog
-
Grokking NATS Consumers: Intro and push-based - Byron Ruth (me!)
💁♀️ FYI
-
GitHub Discussions have been enabled in nats.deno repo
-
Derek Collison (NATS creator) asked what message encoding do you use?
💡 Recently asked questions
Questions sourced from Slack, Twitter, or individuals. Responses and examples are in my own words, unless otherwise noted.
How can I create a user JWT without requiring the seed?
Normally, when a new user is created under an account, a credentials file is created consisting of a JWT token and a seed having this structure:
-----BEGIN NATS USER JWT-----
eyJ0eXAiOiJqd3QiLCJhbGciOiJlZDI1NTE5In0.eyJqdGkiOiJUVlNNTEtTWkJBN01VWDNYQUxNUVQzTjRISUw1UkZGQU9YNUtaUFhEU0oyWlAzNkVMNVJBIiwiaWF0IjoxNTU4MDQ1NTYyLCJpc3MiOiJBQlZTQk0zVTQ1REdZRVVFQ0tYUVM3QkVOSFdHN0tGUVVEUlRFSEFKQVNPUlBWV0JaNEhPSUtDSCIsIm5hbWUiOiJvbWVnYSIsInN1YiI6IlVEWEIyVk1MWFBBU0FKN1pEVEtZTlE3UU9DRldTR0I0Rk9NWVFRMjVIUVdTQUY3WlFKRUJTUVNXIiwidHlwZSI6InVzZXIiLCJuYXRzIjp7InB1YiI6e30sInN1YiI6e319fQ.6TQ2ilCDb6m2ZDiJuj_D_OePGXFyN3Ap2DEm3ipcU5AhrWrNvneJryWrpgi_yuVWKo1UoD5s8bxlmwypWVGFAA
------END NATS USER JWT------
************************* IMPORTANT *************************
NKEY Seed printed below can be used to sign and prove identity.
NKEYs are sensitive and should be treated as secrets.
-----BEGIN USER NKEY SEED-----
SUAOY5JZ2WJKVR4UO2KJ2P3SW6FZFNWEOIMAXF4WZEUNVQXXUOKGM55CYE
------END USER NKEY SEED------
*************************************************************
The seed is used to sign a nonce which is provided by the server when establishing a connection.
There was an option added with MQTT support was added which was to introduce the --bearer option when creating users. This specifically indicates that this user only needs to supply the JWT and not be required to sign the nonce provided by the server.
The justification was that existing MQTT clients only support supplying username and password without the addition nonce singing step. This means that users flagged as bearer tokens can authenticate using only the JWT as the password (and with a non-empty arbitrary username).
Bearer-only tokens should not be used with native NATS clients. However, if there is a desire to use NATS users for authenticating with other non-NATS servers, using bearer tokens could be an option.
Are user permissions inherited from account permissions?
I ran into this question after configuring an account with a set of permissions that I had expected all users created under that account would inherit and individual users could augment those permissions.
It turns out that this is not the behavior, but there is support for scoped account signing keys which can be used to stamp out users having identical permissions.
It did not quite fit my need, but it is a great option for use when deploying replicas a given client where individual user credentials are desired.
Is is possible to show the streams for an account, using the system account?
The short answer is no. The primary reason is because the system account (typically referred to as SYS) is a separate account from any other accounts which means it has isolated permissions.
As noted in the docs, the system account is used for monitor the NATS server/cluster specifically, under the $SYS.> subject space. It states:
It is NOT recommended to use this account to facilitate communication between your own applications. Its sole purpose is to facilitate communication with and between nats-server.
Within your own application account, a simple solution is to create a dedicated user with the desired permissions for inspecting metadata on streams and consumers. This can be achieved by giving permission to a subset of the $JS.> subject space.
