`nsc edit account` should not attempt to validate the operator signing keys in the local keystore
kimjarvis opened this issue · 2 comments
nsc edit account attempts to validate the operator nkeys in the local keystore, but in the self service deployment model the local keystore does not contain the private key of the operator.
root@instance: nsc edit account -n CA --sk ACTHXYSB3RLLUXQWGSEBKYP7P3WHCPGEMB6EFZLGLME6M5H7UIXLGMFC --config-dir $HOME/CSA/config --data-dir $HOME/CSA/data --keystore-dir $HOME/CSA/keys
Error: unable to resolve any of the following signing keys in the keystore: ODED54OCBKXGZOBP43NER37S4JFT77E7FQJIDYXOPUUOP3HF56KB5HLV, ODHS3EM2GHHL6VKP2VNCPNFQJH5WU7HAVYA6NI7YRQL3AB42TVMA4HLP, ODED54OCBKXGZOBP43NER37S4JFT77E7FQJIDYXOPUUOP3HF56KB5HLVIn the self service model, the administrator creates an account for the client to import. The client first imports the operator JWT, then the account JWT. In the self service model, the operator nkeys are not available in the clients's local keystore. The operator nkeys are private to to the administrator. The nsc edit account command should not attempt to validate the operator nkeys in the local keystore because they may not be present.
root@instance:/# nsc describe operator --config-dir $HOME/CSA/config --data-dir $HOME/CSA/data --keystore-dir $HOME/CSA/keys
+----------------------------------------------------------------------------------+
| Operator Details |
+-----------------------+----------------------------------------------------------+
| Name | O |
| Operator ID | OAG4N22BDKCXLFAQV7FC4CPOT7RB7WHUETVNBNLLNA4IBCAQ7OWWICIA |
| Issuer ID | ODHS3EM2GHHL6VKP2VNCPNFQJH5WU7HAVYA6NI7YRQL3AB42TVMA4HLP |
| Issued | 2023-04-09 16:39:05 UTC |
| Expires | |
| Account JWT Server | nats://localhost:4222 |
| Operator Service URLs | nats://localhost:4222 |
| System Account | ABECG34TPVEIXO5APWHMJ76STUXENUFTATQL4RSRP4FI3ZEUEWCNZHEH |
| Require Signing Keys | true |
+-----------------------+----------------------------------------------------------+
| Signing Keys | ODHS3EM2GHHL6VKP2VNCPNFQJH5WU7HAVYA6NI7YRQL3AB42TVMA4HLP |
| | ODED54OCBKXGZOBP43NER37S4JFT77E7FQJIDYXOPUUOP3HF56KB5HLV |
+-----------------------+----------------------------------------------------------+
nsc describe account -n CA --config-dir $HOME/CSA/config --data-dir $HOME/CSA/data --keystore-dir $HOME/CSA/keys
+--------------------------------------------------------------------------------------+
| Account Details |
+---------------------------+----------------------------------------------------------+
| Name | CA |
| Account ID | ABEVG2LJRTRWOJBPRV2IAA7KJX5OTSFJKW4YMFVZT6ZQ2V344U6K5MT2 |
| Issuer ID | ODED54OCBKXGZOBP43NER37S4JFT77E7FQJIDYXOPUUOP3HF56KB5HLV |
| Issued | 2023-04-09 16:39:10 UTC |
| Expires | |
+---------------------------+----------------------------------------------------------+
| Max Connections | Unlimited |
| Max Leaf Node Connections | Unlimited |
| Max Data | Unlimited |
| Max Exports | Unlimited |
| Max Imports | Unlimited |
| Max Msg Payload | Unlimited |
| Max Subscriptions | Unlimited |
| Exports Allows Wildcards | True |
| Disallow Bearer Token | False |
| Response Permissions | Not Set |
+---------------------------+----------------------------------------------------------+
| Jetstream | Disabled |
+---------------------------+----------------------------------------------------------+
| Imports | None |
| Exports | None |
+---------------------------+----------------------------------------------------------+
The client only has the nkey it just generated in it's keystore. The operator nkeys are not present.
root@instance:/# tree $HOME/CSA/keys
/root/CSA/keys
|-- creds
`-- keys
`-- A
`-- CT
`-- ACTHXYSB3RLLUXQWGSEBKYP7P3WHCPGEMB6EFZLGLME6M5H7UIXLGMFC.nkThis ticket is very similar to #577 and #579. In each case, nsc is looking for the private key of the issuer in the clients local keystore. But, if the issuing operator, or in the case of #577 the issuing account, is imported then the private key will not be available in the clients local keystore. Moreover, nsc does not need the private key of the issuer for the operation so the validation is unnecessary.
It may be that the scope for implementing self service models is more restricted than the documentation implies. For example, in an accounts "built to order" model accounts can only modified by the administrator with access to the private part of the issuing nkey. If the "built to order model" is the only self service model then all three tickets are expected behavior.
The issue here is that account JWTs must be signed by an operator. This means that in your use-case, there must be a process that handles the on-boarding of a self-signed JWT, which then re-signs the account using one of the operator keys.
In that use-case the flow is for an operator to be downloaded from an account server, (see https://github.com/nats-io/nats-account-server for some insight into the http api) - then nsc will self-sign accounts using the account key, send it to the account server which on seeing a self-signed JWT will re-issue the account but this time signed by the operator. At that point the JWT is published to the nats-resolver, and thus on-boarding the account.
The basic requirement for a valid account JWT is for it to be issued by an operator, so the process of onboarding requires a custom service that performs that operation.
To see how you can do this flow using an account server, checkout: