Basics
Basic configuration revolves around 4 settings:
The store to read JWTs from
The HTTP/S configuration
NATS (for cases where updates are enabled)
Logging
For complete information, please refer to the project's Github.
Directory Configuration
You can start a server using a plain directory. In this case you'll be responsible for adding any JWT that you want resolved.
The server looks for account JWTs by using the public key of the account as the file name followed by the extension
.jwt
. The server will not introspect the JWTs, so if you don't name the files correctly, it will fail to find them or serve a JWT that doesn't match the requested account.
Configuration for the NATS server is the same as in the previous example:
A step by step tutorial using directory configuration can be found here.
Configuration File
While the -dir
store flag is sufficient for some very simple developer setups, any production or non-read-only server will require a configuration file.
Let's take a look at the configuration options:
Configuration Options
store
Configuration
store
Configurationlogging
Options
logging
Optionshttp
Options
http
Optionsnats
Options
nats
Optionstls
Options
tls
OptionsExample Setup
Provided a setup with 4 accounts, one of them a system account, this example shows how to set up the account server by:
adding the account server to the operator
configuring the account server
push the accounts to the account server
configure a
nats-server
to make use of the account servertest the setup
Set environment variables
Run setup script that creates a few sample accounts and a system account
List all accounts
Add the endpoint for the account server to which accounts can be published
Generate account server config that references the operator jwt
Start the account server
Upload the local accounts in the nsc directory structure
Generate the NATS Server config that points to the account server
Start the NATS Server in trusted operator mode
Try to subscribe on account without permissions, this should fail
Subscribe then publish to subject should work on 'test' since enough permissions
Published message on 'test' subject would be received by started subscriber above
Subscribe using the system account user credentials can receive all system events