When integrating with external systems that issue NATS User JWTs (e.g., authorization services in a decentralized JWT schema), those systems need two inputs: an Account Signing Key seed and the public key of the Account they issue Users for.
With AccountSigningKey (#138, #306), the seed part is now fully declarative: the secret name is chosen upfront via spec.secretName and can be referenced in workloads before anything is reconciled.
The account public key still isn't. It is derived by NAuth when the Account is first reconciled and is currently exposed only as the account.nauth.io/id label on the Account resource and on the managed secrets. That leaves a workload with no declarative way to consume it, since Kubernetes can only inject env vars or volumes from ConfigMaps and Secrets.
In practice this forces the same workaround as for #138: deploy the Account, wait for reconciliation, look the value up (kubectl get account -o jsonpath=... or via the secret labels), and paste it into the consumer's values — or maintain custom lookup hooks/jobs per deployment.
The same could be said about other label-only public metadata, but the rest has much less use for workloads: user.nauth.io/id is redundant since any workload holding the creds file already has the user JWT (which embeds the user's public key), and I don't see a workload use case for *.nauth.io/signed-by. So I'd focus on the account ID only.
Given the convention of small secrets describing a single thing under a default key, how about a ConfigMap per derived public datum: <account>-ac-id with default holding the resolved identity of the Account resource? Unlike the seed secrets, the name needs no hash suffix (#9): the data is derived and public, so on account recreation overwriting it with the new identity is exactly the desired behavior.
Happy to pick up the implementation once we agree on a direction.
When integrating with external systems that issue NATS User JWTs (e.g., authorization services in a decentralized JWT schema), those systems need two inputs: an Account Signing Key seed and the public key of the Account they issue Users for.
With
AccountSigningKey(#138, #306), the seed part is now fully declarative: the secret name is chosen upfront viaspec.secretNameand can be referenced in workloads before anything is reconciled.The account public key still isn't. It is derived by NAuth when the Account is first reconciled and is currently exposed only as the
account.nauth.io/idlabel on the Account resource and on the managed secrets. That leaves a workload with no declarative way to consume it, since Kubernetes can only inject env vars or volumes from ConfigMaps and Secrets.In practice this forces the same workaround as for #138: deploy the Account, wait for reconciliation, look the value up (
kubectl get account -o jsonpath=...or via the secret labels), and paste it into the consumer's values — or maintain custom lookup hooks/jobs per deployment.The same could be said about other label-only public metadata, but the rest has much less use for workloads:
user.nauth.io/idis redundant since any workload holding the creds file already has the user JWT (which embeds the user's public key), and I don't see a workload use case for*.nauth.io/signed-by. So I'd focus on the account ID only.Given the convention of small secrets describing a single thing under a
defaultkey, how about a ConfigMap per derived public datum:<account>-ac-idwithdefaultholding the resolved identity of the Account resource? Unlike the seed secrets, the name needs no hash suffix (#9): the data is derived and public, so on account recreation overwriting it with the new identity is exactly the desired behavior.Happy to pick up the implementation once we agree on a direction.