mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
fixes from PR
This commit is contained in:
parent
48fa4a4800
commit
9b801cf14a
@ -1,15 +1,15 @@
|
|||||||
# Working with Managed Operators
|
# Working with Managed Operators
|
||||||
|
|
||||||
`nsc` can be used to administrate multiple operators. Operators can be thought of as the owners of nats-servers, and fall into two categories: local and managed. The key difference, pardon the pun, is that managed operators are ones which you don't have the nkey for. An example of a managed operator is the Synadia service called NGS. Synadia has the keys.
|
`nsc` can be used to administer multiple operators. Operators can be thought of as the owners of nats-servers, and fall into two categories: local and managed. The key difference, pardon the pun, is that managed operators are ones which you don't have the nkey for. An example of a managed operator is the Synadia service called NGS. Synadia has the keys.
|
||||||
|
|
||||||
Accounts, as represented by their JWTs, are signed by the operator. Some operators may use local copies of JWTs, others may use the [nats-account-server](../nas/README.md) to manage their JWTS. Synadia uses a custom server for their JWTs that works similarly to the open-sourced account server.
|
Accounts, as represented by their JWTs, are signed by the operator. Some operators may use local copies of JWTs, others may use the [nats-account-server](../nas/README.md) to manage their JWTs. Synadia uses a custom server for their JWTs that works similarly to the open-sourced account server.
|
||||||
|
|
||||||
There are a few special commands when dealing with server based operators:
|
There are a few special commands when dealing with server based operators:
|
||||||
|
|
||||||
* Account JWTs can be pushed to the server using `nsc push`
|
* Account JWTs can be pushed to the server using `nsc push`
|
||||||
* Account JWTs can be pulled from a server using `nsc pull`
|
* Account JWTs can be pulled from a server using `nsc pull`
|
||||||
|
|
||||||
For managed operators this push/pull behavior is built into `nsc`. Each time you edit your account JWT `nsc` will push the change to a managed operator's server and pull the signed response. If this fails the JWT on disk may not match the value on the server. You can always push or pull the account again without editing it.
|
For managed operators this push/pull behavior is built into `nsc`. Each time you edit your account JWT `nsc` will push the change to a managed operator's server and pull the signed response. If this fails the JWT on disk may not match the value on the server. You can always push or pull the account again without editing it. Note - push only works if the operator JWT was configured with an account server URL.
|
||||||
|
|
||||||
The managed operator will not only sign your account JWT with its key, but may also edit the JWT to include limits to constrain your access to their NATS servers. Some operators may also add demonstration or standard imports. Generally you can remove these, although the operator gets the final call on all Account edits. As with any deployment, the managed operator doesn't track user JWTs.
|
The managed operator will not only sign your account JWT with its key, but may also edit the JWT to include limits to constrain your access to their NATS servers. Some operators may also add demonstration or standard imports. Generally you can remove these, although the operator gets the final call on all Account edits. As with any deployment, the managed operator doesn't track user JWTs.
|
||||||
|
|
||||||
|
@ -1,6 +1,6 @@
|
|||||||
# NSC
|
# NSC
|
||||||
|
|
||||||
NATS uses JWTs to armor the various identity and authorization artifacts. These JWTs are created with the `nsc` tool. NSC simplifies the tasks of creating and managing identities and other JWT artifacts.
|
NATS uses JWTs to armor the various identity and authorization artifacts. These JWTs are created with the `nsc` tool. NSC simplifies the tasks of creating and managing identities and other JWT artifacts.
|
||||||
|
|
||||||
There’s a logical hierarchy to the entities:
|
There’s a logical hierarchy to the entities:
|
||||||
|
|
||||||
@ -46,7 +46,7 @@ To see the current NSC environment use the command `nsc env`:
|
|||||||
|
|
||||||
As you can see there is a setting for the nkeys folder and the nsc home. By default you’ll see that generated secrets are stored in `~/.nkeys`, and configurations in `~/.nsc/nats`. All operations are assumed to be in a context of the current operator and current account. When working with multiple operators and accounts you may need to set the current one. You can easily do so by issuing the `nsc env` and provide flags to set the current operator or account. See `nsc env —help` for more details.
|
As you can see there is a setting for the nkeys folder and the nsc home. By default you’ll see that generated secrets are stored in `~/.nkeys`, and configurations in `~/.nsc/nats`. All operations are assumed to be in a context of the current operator and current account. When working with multiple operators and accounts you may need to set the current one. You can easily do so by issuing the `nsc env` and provide flags to set the current operator or account. See `nsc env —help` for more details.
|
||||||
|
|
||||||
You can easily change the home and keys locations by setting `NSC_HOME` and `NKEYS_PATH` respectively in your environment to your desired locations. The environment itself is stored in the `NSC_HOME` while the operators are in the stores directory which can be elsewhere.
|
You can easily change the home and keys locations by setting `NSC_HOME` and `NKEYS_PATH` respectively in your environment to your desired locations. The environment itself is stored in the `NSC_HOME`. Operator folders are in the stores directory which can be inside `NSC_HOME` or external to it.
|
||||||
|
|
||||||
> The $NKEYS_PATH stores secrets. Since nkeys relies on cryptographic signatures to prove identity, anyone with access to your private keys will be able to assume your identity. With that said, treat them as secrets and guard them carefully.
|
> The $NKEYS_PATH stores secrets. Since nkeys relies on cryptographic signatures to prove identity, anyone with access to your private keys will be able to assume your identity. With that said, treat them as secrets and guard them carefully.
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user