CDH | Support signature for sealed secrets

[Xynnn007]

When sealed secret was first designed, it was declared to support integrity protection via signature. Currently, sealed secret does not support this ability, and a fakesignature is used to replace the original valid JWT signature. This issue mainly hopes to solve several issues about signatures:

• Add support for CDH to verify the signature of a signed sealed secret. The public key can either be accessed from KBS, or be set via CDH's config file.
• Add support for sealed secret client tool to generate a signed sealed secret.

This issue is purely from technical point view, but we can start from this point to talk more about the signed sealed secret use case.

[fitzthum]

Where should we get the key to verify the secret? Can we expect the kid field to have a resource URI? Does that make sense even for secrets that point to some other HSM?

[Xynnn007]

Resource URI should be fine. And to avoid circular dependency, HSM can play a role as a storage repository. This means the sealed secret's key cannot be wrapped in another sealed secret.

Other choices are a path inside guest image, a key from initdata. The integrity of both can be protected by RA.

[fitzthum]

Ok I think getting from the KBS is fine although initdata support would also be good.

This is going to impact the user experience a bit. Now people will have to provision more stuff. I wonder if it makes sense to support unsigned secrets as well and if there is any way to do that safely.