VMware vCenter 6.7 and PyKMIP / VMWare's PyKMIP failure

[brandonpoc]

I have tried adding as a KMS server in vCenter 6.7 both the latest PyKMIP and the modified PyKMIP that VMware made for demoing KMS in their 6.5 release but have had no luck. I get the following error:

'Cannot retrieve the requested certificate'

Again this is with both the current PyKMIP from github and the modified PyKMIP from VMWare that was present in their demo .ova and on William Lan's docker repository (lamw/vmwkmip). Is anyone aware of what is causing this error and if it's something I could fix or if it is just not supported in vCenter 6.7 and, if so, what it is that isn't supported? I get 'transport endpoint not connected' on the latest PyKMIP which I believe is from the vCenter client closing the connection out of protocol/sequence and the pykmip server calling close() on it. Other than that there's really no information.

Thanks

[KBassford]

You might want to check out issue #566 (#566). You have to use the certificate generation script under "bin" and point to the appropriate ones in both the server.conf and client.conf. Also make certain the permissions on where you store them allow for read access.

I think everyone is out for the time being due to the coronavirus. Hope this helps.

[PeterHamilton]

Hi @brandonpoc, thank you filing this issue. My apologies for the extreme delay on this; @KBassford was correct, I've been out and unable to work on PyKMIP due to the ongoing pandemic. I should be able to spend more time on this going forward.

Are you still having issues using PyKMIP with vCenter? If so, I will need more information to help you debug the problem. Let me know and we can discuss it further.

[brandonpoc]

Thanks for the response. If I recall correctly the version of PyKMIP that came as part of a VMware-provided image to demo OpenKMIP/PyKMIP worked fine but, as stated, could not save the key and associated meta-data to disk. I looked at the source code and it was not going to be as simple as I had hoped to change that, with serialization via 'pickle' not supporting some of the data structures and the denseness of the KMIP protocol was going to result in a decently long journey to get things working (at least, for me). That being said, if you were to integrate support for vCenter/VMware vSphere, it might be beneficial to take a look at the modified PyKMIP that VMware provided and to take a look at their 'memory database' where they store the key objects and the key meta info/descriptors/etc. You may be able to then bridge the gap between the two. If you'd prefer, I *think* I extracted the VMware-modified codebase and have it somewhere in my data hoard. I can provide a link if you ask. Regards, Brandon

…

On Tue, Jun 30, 2020 at 8:23 AM Peter Hamilton ***@***.***> wrote: Hi @brandonpoc <https://github.com/brandonpoc>, thank you filing this issue. My apologies for the extreme delay on this; @KBassford <https://github.com/KBassford> was correct, I've been out and unable to work on PyKMIP due to the ongoing pandemic. I should be able to spend more time on this going forward. Are you still having issues using PyKMIP with vCenter? If so, I will need more information to help you debug the problem. Let me know and we can discuss it further. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#626 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEOTIOSM67JDDIEBC6MXL3RZHRNLANCNFSM4MRLZDHA> .

[PeterHamilton]

If I recall correctly the version of PyKMIP that came as part of a VMware-provided image to demo OpenKMIP/PyKMIP worked fine but, as stated, could not save the key and associated meta-data to disk.

Actually, this isn't true. PyKMIP does store it's data (a single SQLite database file) on the filesystem, it just defaults to storage in /tmp which gets purged on reboot (or by routinely running cron jobs depending on your system). This is intentional, since the PyKMIP server is meant for testing and demonstration purposes. If you use a different storage location (using the database_path argument when running the server) you can have PyKMIP store your data wherever you want.

It's been a while since I looked at William's Docker image for PyKMIP. I was not involved in its creation. However, it shouldn't take much to map a host directory onto /tmp in the PyKMIP container when you start it up, allowing you to persist your data.

It's important to note that the PyKMIP data is not secured in any way. Any user with access to that SQLite database file will have access to all of your keys, certificates, etc. This is another reason we don't recommend the PyKMIP server for production use.

[brandonpoc]

The PyKMIP alternate that was implemented by VMware kept it in memory; it's the PyKMIP branch from VMware that worked with VMware for me, while the (latest) PyKMIP did not work for me with VMware. So I was thinking the two could be merged. Regards

…

On Wed, Jul 1, 2020 at 10:15 AM Peter Hamilton ***@***.***> wrote: If I recall correctly the version of PyKMIP that came as part of a VMware-provided image to demo OpenKMIP/PyKMIP worked fine but, as stated, could not save the key and associated meta-data to disk. Actually, this isn't true. PyKMIP does store it's data (a single SQLite database file) on the filesystem, it just defaults to storage in /tmp which gets purged on reboot (or by routinely running cron jobs depending on your system). This is intentional, since the PyKMIP server is meant for testing and demonstration purposes. If you use a different storage location (using the database_path argument when running the server) you can have PyKMIP store your data wherever you want. It's been a while since I looked at William's Docker image for PyKMIP. I was not involved in its creation. However, it shouldn't take much to map a host directory onto /tmp in the PyKMIP container when you start it up, allowing you to persist your data. It's important to note that the PyKMIP data is not secured in any way. Any user with access to that SQLite database file will have access to all of your keys, certificates, etc. This is another reason we don't recommend the PyKMIP server for production use. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#626 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEOTINZRCKHCZTARSMPMG3RZNHKRANCNFSM4MRLZDHA> .

[thevelement]

I had a similar issue when I was setting up PyKMIP on a Photon-based appliance. The UI would tell me it couldn't get the certificate, and running openssl s_client -connect from vCenter would not pull the cert. The issue for me was when defining the server configuration (/etc/pykmip/server.conf) I was using the FQDN for the 'hostname' directive, but with Photon, it resolves the hostname to 127.0.0.1 in /etc/hosts, so the PyKMIP server was only ever working when connections were initiated from that appliance. Once I changed the value of the 'hostname' directive to the IP of the system, it worked.

I've been using PyKMIP with vCenter 6.7 U3h and it works pretty well.

[eyooooo]

#717 i bet this fixes your issue