I've been away from OpenStack for a couple of years now, so this may have changed. But back around the Icehouse release, at least, upgrading between OpenStack releases was a major undertaking, so backing an older OpenStack with newer Ceph seems like it might be more common than one might think. Which is not to argue for or against dropping PKI in Ceph, but if it's going to be done, please call that out early in the release notes to avoid rude awakenings. > [Adding ceph-users for better usability] > > On Fri, 19 Apr 2019, Radoslaw Zarzynski wrote: >> Hello, >> >> RadosGW can use OpenStack Keystone as one of its authentication >> backends. Keystone in turn had been offering many token variants >> over the time with PKI/PKIz being one of them. Unfortunately, >> this specific type had many flaws (like explosion in size of HTTP >> header) and has been dropped from Keystone in August 2016 [1]. >> By "dropping" I don't mean just "deprecating". PKI tokens have >> been physically eradicated from Keystone's code base not leaving >> documentation behind. This happened in OpenStack Ocata. >> >> Intuitively I don't expect that brand new Ceph is deployed with >> an ancient OpenStack release. Similarly, upgrading Ceph while >> keeping very old OpenStack seems quite improbable. > > This sounds reasonable to me. If someone is running an old OpenStack, > they should be able to defer their Ceph upgrade until OpenStack is > upgraded... or at least transition off the old keystone variant? > > sage > >> If so, we may consider dropping PKI token support in further >> releases. What makes me perceive this idea as attractive is: >> 1) significant clean-up in RGW. We could remove a lot of >> complexity including the entire revocation machinery with >> its dedicated thread. >> 2) Killing the NSS dependency. After moving the AWS-like >> crypto services of RGW to OpenSSL, the CMS utilized by PKI >> token support is the library sole's user. >> I'm not saying it's a blocker for NSS removal. Likely we could >> reimplement the stuff on top of OpenSSL as well. >> All I'm worrying about is this can be futile effort bringing >> more problems/confusion than benefits. For instance, instead >> of just dropping the "nss_db_path" config option, we would >> need to replace it with counterpart for OpenSSL or take care >> of differences in certificate formats between the libraries. >> >> I can see benefits of the removal. However, the actual cost >> is mysterious to me. Is the feature useful? >> >> Regards, >> Radek >> >> [1]: https://github.com/openstack/keystone/commit/8a66ef635400083fa426c0daf477038967785caf >> >>
