Support predictable secret names for external consumers

[wingsofovnia]

When integrating with external systems that issue NATS User JWTs (e.g., authorization services in a decentralized JWT schema), those systems need access to the Account Signing Key secret.

Following #44, NAUTH names secrets with a hash suffix derived from the account's public key:

<account>-ac-sign-<hash>

This solved #9 where orphaned account IDs could cause new accounts to overwrite existing secrets, leading to credential loss.

However, it makes the secret name unpredictable until the Account resource is created and reconciled. This makes it hard to reference the secret in a Helm chart or GitOps.

The deprecated naming templates (<account>-ac-root, <account>-ac-sign) would work for this use case, but, apart from being scheduled for removal #102, there is no (declarative) way to opt into the old naming for new accounts.

I suggest allowing user to specify custom/predictable secret names, e.g.

spec:
  secrets:
    rootName: "my-account-root"
    signName: "my-account-sign"

Users could set one, both, or neither (defaulting to hash-based naming for unspecified ones).

To mitigate #9, which motivated moving away from predictable secret names, if a secret with that name already exists, fail reconciliation with a clear error until a user manually deletes the existing secret.

Let me know if this approach works. I can try to pick this up if time allows.

[choufraise]

I believe this would be a good feature. In #11 we are planning to separate the imports/exports into their own CRDs, meaning the Account CRD will not be the sole truth of the account reconciliation. Instead of re-using the existing signing key, would it make sense to introduce a separate CRD AccountSigningKey that would be reconciled together with the Account? Then if that signing key is compromised it's more explicit to rotate just that one, or even remove it. This would also enable creating multiple signing keys used by other systems/operators, bound explicitly to one system.

[choufraise]

@wingsofovnia I'm thinking that we should avoid the single account signing key and go towards scoped signing keys instead. I however still see reasons to support explicit account signing keys; both generated and explicitly stated, both would greatly benefit your case. The problem with a single signing key is obviously that it's hard to rotate if you transfer the User JWTs outside of the kube context, e.g. to an external client. Another problem is that if a User JWT is exposed accidentally, you need to rotate it and re-sign all User JWTs, hence delegate/reload the new JWTs in all clients.

If we were to introduce an AccountSigningKey CRD, where you could state e.g. the secret where you want it stored, if it should be generated by nAuth or if it should simply connect an existing secret to the AccountSigningKey resource. Then the Account reconciler would add those "external" signing keys as trusted during reconciliation.

We have other use-cases for this, for instance if you would have a cross-account Auth Callback service that relies on a single signing key, then you would have to "trust" it by adding it to each account that allows that type of auth login.

Would this solve your problem? What do you think about it.