smoonen's Posts

Thanks, Radostin! Some further replies: For VM disks, I am thinking for example of cloning the VM and decrypting the clone in vCenter console. Alternately we could use a backup provider with crypto ... See more...
Thanks, Radostin! Some further replies: For VM disks, I am thinking for example of cloning the VM and decrypting the clone in vCenter console. Alternately we could use a backup provider with crypto admin access to backup decrypted disks and restore them elsewhere. Your understanding of our setup is correct. Keep in mind that I was using vSphere encryption as my mental model, so that each VM would have its own key issued by the KMS, which ideally would be visible to the tenant in the Director portal as an attribute of the VM, and which would also allow for the rekeying of VMs on an individual basis. It seems to me your setup is more similar to vTA in that a single key issued by the KMS will be used to protect the keys in use for all VMs. So I agree with you that with this approach there is not as much apparent value to the tenant as there would have been in the key-per-VM scenario that I envisioned. It seems like there is some dissonance between what your model wants to achieve and what we want to achieve for our customers. I'm happy to get on a call. I work regularly with Jon Schulz as well. I have availability this week but am traveling the following two weeks, then will be back in the office the week of the 18th. Thanks!
Thank you, Radostin. Here is an additional question and a few brief replies: Does the existing VMware KMIP certification process cover this solution? I.e., the solution does not leverage any more KM... See more...
Thank you, Radostin. Here is an additional question and a few brief replies: Does the existing VMware KMIP certification process cover this solution? I.e., the solution does not leverage any more KMIP capabilities than are used today by vSphere, vSAN, and vTA encryption? I understand the sovereign cloud motivation. However, it seems to me that there are many more gaps to close. A vCenter/Director administrator with sufficient privileges can access tenant VM consoles and VM disks today even if they do not have access to the key provider credentials. Do you have a roadmap for closing such gaps? Without such a roadmap it seems premature to name this sovereign cloud. In our particular case, we operate Director for our tenants and we also operate a multi-tenant key provider for them. It is our vision that we will connect the customer org directly to the customer's key provider instance, including the establishment of credentials, all transparently to the customer. Our desire is that the customer need not manage network connectivity, key provider credentials, or enrollment of particular VDCs in their org. The customer may still revoke either their root key or individual keys within the key provider instance as a means of retaining the right of cryptographic erasure. Thanks!
I've reviewed the documentation - thanks - but haven't had a chance to test this yet. It's interesting to me that this solution exists in a space in between provider and tenant. Unlike the org SSO c... See more...
I've reviewed the documentation - thanks - but haven't had a chance to test this yet. 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. 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. 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. 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. Thanks for the opportunity to review this early!