Comment on page
Account lookup using Resolver
If the operator JWT specified in
operatorcontains an account resolver URL,
resolveronly needs to be specified in order to overwrite that default.
The NATS based resolver is the preferred and easiest way to enable account lookup for the nats servers. It is built-in into
nats-serverand stores the account JWTs in a local (not shared) directory that the server has access to (i.e. you can't have more than one
nats-servers using the same directory. All the servers in the cluster or super-cluster must be configured to use it, and they implement an 'eventually consistent' mechanism via NATS and the system account to synchronize (or lookup) the account data between themselves.
In order to avoid having to store all account JWT on every
nats-server(i.e. if you have a lot of accounts), this resolver has two sub types
In this mode of operation administrators typically use the
nscCLI tool to create/manage the JWTs locally, and use
nsc pushto push new JWTs to the nats-servers' built-in resolvers,
nsc pullto refresh their local copy of account JWTs, and
nsc revocationsto revoke them.
The Full resolver means that the
nats-serverstores all JWTs and exchanges them in an eventually consistent way with other resolvers of the same type.
# Directory in which account jwt will be stored
# In order to support jwt deletion, set to true
# If the resolver type is full delete will rename the jwt.
# This is to allow manual restoration in case of inadvertent deletion.
# To restore a jwt, remove the added suffix .delete and restart or send a reload signal.
# To free up storage you must manually delete files with the suffix .delete.
# Interval at which a nats-server with a nats based account resolver will compare
# it's state with one random nats based account resolver in the cluster and if needed,
# exchange jwt and converge on the same set of jwt.
# limit on the number of jwt stored, will reject new jwt once limit is hit.
This resolver type also supports
resolver_preload. When present, JWTs are listed and stored in the resolver. There, they may be subject to updates. Restarts of the
nats-serverwill hold on to these more recent versions.
Not every server in a cluster needs to be set to
full. You need enough to still serve your workload adequately, while some servers are offline.
The Cache resolver means that the
nats-serveronly stores a subset of the JWTs and evicts others based on an LRU scheme. Missing JWTs are downloaded from the
fullnats based resolver(s).
# Directory in which account jwt will be store
# limit on the number of jwt stored, will evict old jwt once limit is hit.
# How long to hold on to a jwt before discarding it.
The NATS based resolver utilizes the system account for lookup and upload of account JWTs. If your application requires tighter integration you can make use of these subjects for tighter integration.
To upload or update any generated account JWT without
nsc, send it as a request to
$SYS.REQ.CLAIMS.UPDATE. Each participating
fullNATS based account resolver will respond with a message detailing success or failure.
To serve a requested account JWT yourself and essentially implement an account server, subscribe to
$SYS.REQ.ACCOUNT.*.CLAIMS.LOOKUPand respond with the account JWT corresponding to the requested account id (wildcard).
To migrate account data when you change from using the standalone (REST) account server to the built-in NATS account resolver (or between NATS environments, or account servers) you can use
nsc pullto make sure you have a copy of all the account data in the server in your local machine
- 2.Reconfigure your servers to use the nats resolver instead of the URL resolver
- 3.Modify the 'account server URL' setting in your operator to the nats URL from the old REST URL: i.e. just copy the nats URLs from the operator's 'service URLs' setting into the account server URLs.
nsc edit operator --account-jwt-server-url <nats://...>
nsc push -Ato push your account data to the nats-servers using the built-in nats account resolver
You can also pass the account server URLs directly as a flag to the
MEMORYresolver is statically configured in the server's configuration file. You would use this mode if you would rather manage the account resolving 'by hand' through the
nat-servers' configuration files. The memory resolver makes use of the
resolver_preloaddirective, which specifies a map of public keys to account JWTs:
MEMORYresolver is recommended when the server has a small number of accounts that don't change very often.
URLresolver specifies a URL where the server can append an account public key to retrieve that account's JWT. Convention for standalone NATS Account JWT Servers is to serve JWTs at:
http://localhost:9090/jwt/v1/accounts/. For such a configuration you would specify the resolver as follows:
Note that if you are not using a nats-account-server, the URL can be anything as long as by appending the public key for an account, the requested JWT is returned.
If the server used requires client authentication, or you want to specify which CA is trusted for the lookup of account information, specify
tlsconfiguration map lets you further restrict TLS to the resolver.