This is an architecturally important feature. It should have first class status. Edit: just watching this video series for the first time. Hope to see more updates as time catches up to today.
@@SynadiaCommunications to confirm, we can self host with the platform, and this feature is available? But not on the free version? Thinking as an unfunded startup, what would be a good way to test our architecture with this feature? Would the cloud platform operate the same way?
I wish `nsc list keys -A` showed the role and listed users under the signing key that minted them in order to make it easier to understand what's going on
16:30 I'm not sure that the next episode has come out. It seems that a few other topics were covered. What are these solutions talked about in this video?
Keys are never pushed to the server, only the signed account JWTs which contain the metadata on limits/permissions/etc of the users that are created within that account. If using a scoped signing key, this acts as a template that all users created by that key will adhere to and the server can enforce those changes automatically.
@@SynadiaCommunications Thanks, I should have said tokens, not keys of course. What I'm sad to see is how the administration is "hidden" i.e. there is no clearly documented API for user administration. Just the NSC CLI, which makes automation that much more difficult.
Wonderful Jérémy
This kind of features was difficult to find out in the documentation.
Changing permission dynamically is a great progress
Thank you
Thanks! This is definitely a lesser known feature but a powerful one
Excellent information. I think that this feature needs more exposure.
We agree!
This is an architecturally important feature. It should have first class status.
Edit: just watching this video series for the first time. Hope to see more updates as time catches up to today.
Agreed! Although it requires some prior knowledge. We (Synadia) support this feature in our Synadia Cloud and Synadia Platform products
@@SynadiaCommunications to confirm, we can self host with the platform, and this feature is available? But not on the free version?
Thinking as an unfunded startup, what would be a good way to test our architecture with this feature? Would the cloud platform operate the same way?
nice video,
Please make video for NATS authentication using TLS self signed certificate for mTLS.
It's very imp and useful for us.
Thanks
I wish `nsc list keys -A` showed the role and listed users under the signing key that minted them in order to make it easier to understand what's going on
16:30 I'm not sure that the next episode has come out. It seems that a few other topics were covered. What are these solutions talked about in this video?
This is great but I'm running in Kubernetes, how can I do this with the nats clients?
If I'm using nsc remotely from the cluster, the signing keys would be loaded with a push to the server, right?
Keys are never pushed to the server, only the signed account JWTs which contain the metadata on limits/permissions/etc of the users that are created within that account. If using a scoped signing key, this acts as a template that all users created by that key will adhere to and the server can enforce those changes automatically.
@@SynadiaCommunications Thanks, I should have said tokens, not keys of course. What I'm sad to see is how the administration is "hidden" i.e. there is no clearly documented API for user administration. Just the NSC CLI, which makes automation that much more difficult.