Add support for softkms and cloudkms uris on requests #240
Conversation
maraino
changed the title
|
In terms of options: I think it's nice if I would say that returning the scheme in the URI in the responses makes sense. That way it's self-contained. If the scheme were to be excluded from the response, it could happen that the value from a response would be used with a different KMS, I guess? With the full URI returned, it could be passed on to the next operation more easily. For the TPM KMS I've implemented returning the full URI too. I might add support for not having to specify the With the above changes, I think we can still support the current |
I want to support both. I think I will return URIs in |
|
Sounds good! |
This PR allows referring a key using a uri like "sofkms:path/to/key"
This commit allows to pass urls like cloudkms:projects/foo/... on cloudkms requests.
This commit allow urls with the resource attribute in cloudkms and the path attribute in softkms. In cloudkms the create key method will return the key names as cloudkms:projects/foo/locations/...
This commit adds supports for any crypto.Signer in softkms.GetPublicKey as long as the key is not encrypted. It also adds support for x25519 keys.
|
@hslatman This should be ready now. |
kms/cloudkms/cloudkms.go
Outdated
| @@ -190,9 +190,12 @@ func (k *CloudKMS) CreateKey(req *apiv1.CreateKeyRequest) (*apiv1.CreateKeyRespo | |||
|
|
|||
| var crytoKeyName string | |||
|
|
|||
| // resource is the plain Gloud KMS resource name | |||
There was a problem hiding this comment.
| // resource is the plain Gloud KMS resource name | |
| // resource is the plain Google Cloud KMS resource name |
| // - projects/id/locations/global/keyRings/ring/cryptoKeys/root-key/cryptoKeyVersions/1 | ||
| // - cloudkms:resource=projects/id/locations/global/keyRings/ring/cryptoKeys/root-key/cryptoKeyVersions/1 | ||
| // - cloudkms:projects/id/locations/global/keyRings/ring/cryptoKeys/root-key/cryptoKeyVersions/1 | ||
| func resourceName(name string) string { |
There was a problem hiding this comment.
Just a thought I had: when other people use our kms package, they may want to have this same logic available to them when handling certain requests/responses. We could expose these helpers in the future.
There was a problem hiding this comment.
The main reason for this method is to support backward compatibility. The CreateKey method now returns the URI that you should use, in this case, cloudkms:projects/id/...
Description
This PR allows referring a key using a URIs like "sofkms:/path/to/key.pem" or "cloudkms:projects/p/locations/l/keyRings/k/cryptoKeys/c/cryptoKeyVersions/1".
TBD:
@hslatman What do you think?