Xynnn007
commented
4 days ago I prefer to add this logic to a script that generates the key pair and runs separately from the deployment of trustee. For example of docker compose case, we have an auth key pair generation commands before docker compose up -d. We could extend that and include all contents in one script. Same works with k8s deployments I think.
For advanced users, we could provide a guide to use their own key pairs.
Currently it's optional whether the KBS is configured with the public key of the AS. If the public key is not provided, the token is not verified. There is an option for someone to use a secure configuration, but I would be surprised if any users were aware of that.
With the EAR tokens, the EAR crate doesn't provide an option to use a token that hasn't been verified. It requires that the public key is provided. We could propose adding a non-secure feature to the crate, but I think it's better to start requiring that the public key is always set.
That said, we don't want to increase the burden on the end user. How can we have a configuration that is secure by default without making setup more complicated? One way would be to add some kind of init container to create these keys. Another option is to add an interface to the AS that allows it to report it public key. Then if the public key is not explicitly set in the KBS config, the KBS could ask the AS for it. In the built-in case this is secure. In the external case this would only be secure if the network where the KBS and AS communicate is trusted (which it often is).
Any other ideas?