VaultTransitSecretEngine.readKey fails with asymmetric keys

[kdubb]

Describe the bug

Invoking VaultTransitSecretEngine.readKey on a key with an asymmetric type (e.g. ecdsa-* or rsa-*) fails with a Jackson MismatchedInputException: Cannot deserialize value of type 'java.lang.Integer' from Object value (token 'JsonToken.START_OBJECT').

This is also a small feature request to provide the extended information that Vault returns for asymmetric keys.

Expected behavior

VaultTransitSecretEngine.readKey should properly handle asymmetric keys and provide the public key and its parameters (which Vault already includes in the output)

Actual behavior

VaultTransitSecretEngine.readKey assumes that the JSON response's keys property is a map of strings to integer timestamps. With asymmetric keys the keys property is a map of strings to maps of key info. Each key info map includes the public key (public_key), creation time (creation_time ), and rsa key size or ecdsa curve (name).

To Reproduce

Steps to reproduce the behavior:

1. Create a transit key with an asymmetric type (e.g. ecdsa-p256), using VaultTransitSecretEngine.createKey is a valid method in addition to using the Vault cli or API.
2. Attempt to read the key using VaultTransitSecretEngine.readKey

Screenshots

Here is a sample response from Vault's transit/keys/:key-id endpoint for an asymmetric key.

{
  "request_id": "c1d0fb48...",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "allow_plaintext_backup": false,
    "deletion_allowed": false,
    "derived": false,
    "exportable": false,
    "keys": {
      "1": {
        "creation_time": "2021-05-05T01:55:20.177039982Z",
        "name": "P-256",
        "public_key": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----\n"
      }
    },
    "latest_version": 1,
    "min_available_version": 0,
    "min_decryption_version": 1,
    "min_encryption_version": 0,
    "name": "test-796e638e",
    "supports_decryption": false,
    "supports_derivation": false,
    "supports_encryption": false,
    "supports_signing": true,
    "type": "ecdsa-p256"
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Environment (please complete the following information):

Output of uname -a or ver

Darwin terminal.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64

Output of java -version

java version "11.0.6" 2020-01-14 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.6+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.6+8-LTS, mixed mode)

Quarkus version or git rev

1.13.3.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Additional context

(Add any other context about the problem here.)

[quarkus-bot]

/cc @vsevel

[sberyozkin]

@vsevel Hi Vincent, would adding Map<String, VaultAsymmetricKey> to VaultTransitKeyDetail make sense ?

[vsevel]

@sberyozkin I will be looking at it tonight

[kdubb]

@sberyozkin @vsevel

To be clear in the JSON for symmetric keys, the keys map still contains integer values. So the Java map should probably be an interface (e.g. VaultKeyVersion) that has concrete subclasses for VaultSymmetricKeyVersion and VaultAsymmetricKeyVersion.

Because of the dynamic nature of the 'type' field (i.e. Vault can add new key types at will), I would imagine a custom deserializer is more appropriate than a scheme based on polymorphic decoding (e.g. @JsonSubTypes).

[sberyozkin]

@kdubb That would require users casting and doing instanceof checks, Vincent will decide, but I guess as a user I'd prefer to work with typed asymmetric key beans; representing the symmetric ones as typed beans would be nice too, but it would be a breaking change - may be the method returning Map<String, Integer> can be deprecated...

[kdubb]

@sberyozkin PR #17024 fixes this issue, it adds a new versions and maintains the previous keys for backwards compatibility.

@vsevel It needs a reviewer but I'm not sure how to add one.