Deleting a User should revoke it

[BZValoche]

When deleting a User, it's credentials remain valid for the lifetime of the NATS account.

The credentials should be revoked, please see: https://docs.nats.io/using-nats/nats-tools/nsc/revocation

[BZValoche]

Preferably, the users should not be signed directly by the account signing key.
Instead, a signing key should be created for every user, and the permissions set on the signing key.

Like this, modifying the permissions would not emit a new secret, and revocation would be de facto.

[BZValoche]

I will create a PR.
My idea is to not break the compatibility, and add an opt-in field in the CR, something like useSigningKey (boolean).

[BZValoche]

Scoped users is the way to go here, and it should be the default IMO, because eternal creds are not something we want to have in a production environment. If there is a credentials leak, it is easier to remove a scoping sigking key than an account (with all of its data).

While I am diving in the code, I found some patterns which might not suit a Kubernetes controller very well.

For example, creating a user when the account is not ready yet should not be treated as an error, but log an information message and retry later. I will try my best not to modify too much code for my PR though.

[kejne]

I see that we we're missing an issue that was actually part of the backlog: #132
The intention is that the signing key is rotated automatically periodically.

This in combination with adding users to revocation lists would solve the issue of the deleting users.
I would prefer not to add additional signing keys, but keep it to signing keys that are rotated and handled by nauth and that specific users are handled by revocation list instead. (The revocation list can then be cleared when the key is rotated).

My suggestion would be to first add the functionality of adding User to revocation list if deleted. Then at a later stage we would be able to add functionality to reduce the revocation list during rotation.

Regarding the patterns where the User controller returns an error: This is intentional and is how the controller pattern works. If it it cannot reconcile, it returns an error in order to try again later. Not returning an error = reconciliation completed, which is not the case.

[choufraise]

Rotating signing keys is one thing, but for regular users it comes with a price. If you rotate the signing key(s) used to generate users, you need to rotate the credentials at the client(s). If the client simply gets the credentials from the k8s secret it might be pretty straight forward, except that you'll need to ensure that clients have a TTL/automatic refresh of the credentials. For long running applications based on mounted credentials this could be a hazzle.

I really like the approach with Scoped Signing Keys (as mentioned), then the actual credentials doesn't change and does not need to be updated at the client side when you change any permissions on the CRD. The shared credentials would be AuthN only while AuthZ is defined in the Account JWT.

The reason to revoke users and/or rotating signing keys becomes less critical. If a user's credentials are leaked, you could simply revoke that signing-key, re-create a new (scoped) signing key and re-create the user credentials previously bound to that one. So, if you would then have one SSK per user, then other users won't be affected when that SSK permission changes or is revoked/rotated.

Each SSKs is bound to a User Scope containing a role name. Hence, we could introduce a Role CRD bound to an account which would then be referenced from a User CRD. Doing this, the developers could be very granular and have one role per user; we would leave this design entirely up to the developers owning the account.

Please note that an SSK generated User can still only be revoked on Account level, and since it's no longer bound to the Account Signing Key we wouldn't really know when to not revoke it no longer without having access to the User JWT or the relationship between the user and the SSK.

[choufraise]

That last note also means that if we introduce SSKs, then we can't implicitly assume that rotating the Account Signing Key should automatically mean that it's safe to clear the revocation list. This is important to remember when implementing this issue I'd say.

[kejne]

Created #135 which I would think is a feasible path forward. I believe that "delete" should be something which is decoupled from the signing key so that there is no hard signing key-user dependency, but rather that it is possible to reference a specific key for a user.

• Delete = revoke user in account. No extra opt-in fields (CRDs tend to be huge if adding too many opt-in fields)
• Signing Key has it's own life cycle and possible to create very narrow keys if wanted.

[BZValoche]

That last note also means that if we introduce SSKs, then we can't implicitly assume that rotating the Account Signing Key should automatically mean that it's safe to clear the revocation list. This is important to remember when implementing this issue I'd say.

Revocations are stored in the account's JWT. Rotating an account is not a thing in decentralized auth. You simply generate a new signing key for the account, invalidating de facto all the users JWT signed with the former account key. Hence it is safe to clear the revocation list for the account.

[choufraise]

That last note also means that if we introduce SSKs, then we can't implicitly assume that rotating the Account Signing Key should automatically mean that it's safe to clear the revocation list. This is important to remember when implementing this issue I'd say.

Revocations are stored in the account's JWT. Rotating an account is not a thing in decentralized auth. You simply generate a new signing key for the account, invalidating de facto all the users JWT signed with the former account key. Hence it is safe to clear the revocation list for the account.

Yes, we are not discussing rotation of the account seed. If you would have an account signing key, as we have it today, to sign all users, and then you also introduce SSKs (which are other account signing keys), then if you rotate the "standard" signing key there might exist (revoked) users signed by SSKs that will not implicitly be invalidated. Those would only be invalidated if you rotate the SSK; first then you can safely remove those users from the revocation list. Right?

For instance. If you have one SSK (bound to one role) and several users signed by that SSK, and you want to invalidate only one of those users, you might not want to rotate the SSK until you've safely replaced the role with a new signing key and handed out new users to the other clients. Revoking users are probably mainly done if the user credentials has been exposed, so you'd like to revoke the user asap and then take your time to deliver replacement users to other clients. I guess.