Hi @smoonen ,

Thanks for your feedback and for making the next step in testing the solution add-on!

 > It's interesting to me that this solution exists in a space in between provider and tenant. Unlike the org SSO configuration, there is some responsibility on the provider's part to establish connectivity to the KMS. However, there is still a tenant responsibility to authenticate with the KMS.
[Radostin] Yes, you are right. One of the primary use cases of the solution is Sovereign Cloud where tenants want to own and control their encryption keys. The provider registers the KMS because they have to ensure the connectivity between VC and KMS and carefully review the KMS certificate and decide if they want to trust it. This trust is being stored in the underlying vCenter. When they publish the KMS to their tenants, the tenant admin needs to authenticate with their own credentials because it's their own KMS or their own space in a multi-tenant KMS.

 > In the enterprise context, I can understand why this might be a good arrangement. However, in a cloud context, it is likely that the cloud provider is managing both Director and the KMS. In this case the cloud provider might have means of managing both the network connectivity to KMS as well as the authentication to KMS. As a result:

1. It seems desirable to me for this solution to optionally allow the provider to manage authentication instead of the tenant. In this case, the provider should be able not only to publish the KMS to a tenant org, but there should be a way to ensure that existing and new tenant VDCs are enrolled in the KMS rather than in the default key provider.
[Radostin] It seems the idea is the provider to be able to manage multiple KMS systems and then publish those to their tenants so that they do not use the default key provider. It goes off the initial purpose of the solution which is to allow tenants to control their own encryption keys but it is a good use case and if there is wider need for such we can plan of adding in one of the next releases. Help me understand the use case - why do you want to manage multiple KMS and share KMS1 to tenant1 and KMS2 to tenant2? If you as a provider manage the encryption keys for your tenants and this is transparent to them, do they care in which KMS you store the keys?

 > 2. It seems highly desirable to me for APIs or CLIs to be exposed allowing the provider to automate all of this configuration. The documentation as currently written only shows UI operations.
[Radostin] The solution add-on comes with a full set of APIs which support all of the operations which you see in the UI. Actually the UI is entirely using this API to perform its operations so once you install the add-on which can be done through a CLI, you can use those APIs to build your own experience.

 > In fact I had pictured that this feature would be offered by establishing a vCenter KMS connection and selecting a Key Provider per org much like vCenter today allows you to select a Key Provider per cluster. It's interesting to me that you've chosen to implement this as a solution addon instead.
[Radostin] In VCD, solution add-ons are the way to deliver faster and more solutions / extensions which our providers can monetize on so expect to see more of these in the future