showoci - additional enhancement for Keys

[hslange]

In issue #882 the reference to vaults was added to the Keys and Secrets have been added.
Unfortunately, the information provided for Keys is limited.
In the current implementation, key information is gathered using a search query. Although this is fine, it gives limited information regarding a single key.
Using the get_key API call will provide a lot more information including:

• autoKeyRotationDetails
• isAutoRotationEnabled
• isPrimary
• protectionMode
• replicaDetails
• restoredFromKeyId
• timeOfDeletion

Based on the Key OCID, also the key versions can be obtained (using API call list_key_versions or get_key_version)

The same is actually true for secrets as well. The current solution provides information regarding secrets using a search query. This provides minimal information, but no detailed information using the get_secret API calls.

Why is this interesting to know? If I know the creation date of the current key or secret version, I can calculate when to rotate the key or secret based on customer specific requirements and notify the Admin in advance. This is currently not possible, as only the key creation date is available.

Hope this makes sense and can be considered as a usefull addition for a future release.
Kind regards,
Herman

[adizohar]

Hi Herman,

Thank you for the detailed feedback and for explaining the use case. It definitely makes sense that having access to additional key and secret metadata (such as rotation details, protection mode, version information, etc.) would enable more advanced use cases like proactive rotation notifications.

That said, the current implementation is intentionally based on the Search service rather than calling the individual Vault APIs for every key and secret. While the get_key, get_secret, and version APIs provide much richer information, invoking them for every discovered resource would introduce significant overhead. Some customers have environments with thousands (or even tens of thousands) of keys and secrets, and issuing multiple API calls per resource would substantially increase execution time, API traffic, and service load.

Since this project is an open-source example application, we've intentionally optimized for scalability and broad applicability rather than retrieving every available attribute from each service.

Your use case is certainly valid, and one of the advantages of the project being open source is that it can be customized for specific requirements. If your environment requires the additional metadata, you can extend the code to call the get_key, list_key_versions, get_secret, or related APIs for the resources you're interested in, or implement filtering so those calls are only made when needed.

We appreciate the suggestion and the detailed explanation behind it.

Kind regards,

[hslange]

Hi Adi,
Thanks again for the quick reply and explanation.
I fully understand your explanation and see the impact.
Since it's open-source example, I will have a look to see where I can include such requirements with minimal impact (so I can keep up-to-date with future releases).
I will explore how to best add these features include the export to json or csv.

Can you make a note in the READE.md about this, so everybody understands?
In the "Modules included" the oci.key_management.KmsVaultClient is mentioned, which would asume you use this to get Keys and Secrets, but in reality the Search is used to get Keys and Secrets, which provides a subset of the actual information available.
This is OK for me for now, but it would even be better if some more detail was available :)
Think I was mislead by this.

Thanks again and if you agree, the issue can be closed.
Herman

[adizohar]

Hi Herman,

Thank you for the detailed feedback and for taking the time to explain where the confusion came from.

You're right that the README could better explain how the application currently retrieves Keys and Secrets, and I can certainly add a note to clarify that it uses Search rather than the Key Management API directly. That should help set the right expectations for other users.

Regarding retrieving additional key details, unfortunately it's not as straightforward as it may seem. Retrieving the full key metadata requires using oci.key_management.KmsManagementClient and the GetKey API. The challenge is that KmsManagementClient must be instantiated with the vault management endpoint, and keys may reside in different vaults, potentially across different compartments. As a result, the application would need to determine the correct vault for every key and instantiate a KmsManagementClient for each vault before it could retrieve the key details.

Besides making the implementation significantly more complex, this would also introduce considerable overhead in both execution time and the number of service calls. If it were a simple change, I would have already added an optional flag to retrieve the additional key information, but with the current OCI API design, it's not a straightforward enhancement.

That said, I may revisit this in the near future and see if I can implement it as an optional flag, so users who need the additional key details can enable it while accepting the extra overhead.

I appreciate your suggestions, and I'll update the README to make the current behavior clearer. If you're satisfied with that, I'm happy to close the issue.

Thanks again for your feedback and for helping improve the project.

[adizohar]

Herman, I decided to add this functionality with additional flag (-keydata), already completed it, I will test and push together with the rest.

[hslange]

Wow, thanks so much for providing this update. Really appreciate it.
Wonder what did make you decide to implement it…
Anyway, I’m happy to test it as soon as it’s available. I have multiple vaults, keys and secrets.
Herman