@sil2100 hello lukasz I've added a **IMPACTED VERSIONS NOTE **** note in the description. Any user running Bionic may hit this issue if running the library in standalone and hitting the same endpoints. However, this is unlikely to be manifested by any user, unless it is deployed with octavia (which is in the cloud-archive). This component (octavia-api) makes extensive use of the barbicanclient API and therefore any clouds >= rocky deployed on top of Bionic will manifest the issue.
I hope this clarifies the situation further and if not, please let me know to provide you any further details. ** Description changed: [Impact] Users of Ubuntu bionic running openstack clouds >= rocky can't create octavia load balancers listeners anymore since the backport of the following patch: https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df This change was introduced as part of the following backports and their posterior syncs into the current Bionic version. - This fix being SRUed here is contained in 4.8.1-0ubuntu1 (disco onwards) - but not on the Bionic version 4.6.0-0ubuntu1. + **** IMPACTED VERSIONS NOTE **** - The issue gets exposed with the following octavia - packages from UCA + python-barbicanclient 4.6.0ubuntu1. + This issue can be triggered in standalone without any cloud-archive + dependency and affects python-barbicanclient 4.6.0ubuntu1, which is the + Bionic version. The issue was fixed in 4.8.1-0ubuntu1 (disco onwards). - Please note that likely this python-barbicanclient dependency should - be part of UCA and not of main/universe. + However, this exception gets easily manifested in OpenStack deployments + that uses octavia packages from UCA + python-barbicanclient 4.6.0ubuntu1, as it provides direct interaction with the barbican client. + + This means that any Ubuntu openstack cloud deployed from UCA on release + >= rocky will manifest this issue when deployed on top of Bionic + octavia-api | 3.0.0-0ubuntu3~cloud0 | rocky | all octavia-api | 4.0.0-0ubuntu1.1~cloud0 | stein | all octavia-api | 4.0.0-0ubuntu1~cloud0 | train | all This change added a new exception handler in the code that manages the decoding of the given PCKS12 certicate bundle when the listener is created, this handler now captures the PCKS12 decoding error and then raises it preventing the listener creation to happen (when its invoked with i.e.: --default-tls-container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c-86eb3cc7fe1a"; ) , this was originally being hidden under the legacy code handler as can be seen here: https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df This exception is raised because the barbicanclient doesn't know how to distinguish between a given secret and a container, therefore, when the user specifies a container UUID the client tries to fetch a secret with that uuid (including the /containers/UUID path) and a error 400 (not the expected 404 http error) is returned. The change proposed on the SRU makes the client aware of container and secret UUID(s) and is able to split the path to distinguish a non-secret (such as a container), in that way if a container is passed, it fails to pass the parsing validation and the right return code (404) is returned by the client. If a error 404 gets returned, then the except Exception block gets executed and the legacy driver code for decoding the pcks12 certicate in octavia is invoked, this legacy driver is able to decode the container payloads and the decoding of the pcks12 certificate succeeds. This differentiation was implemented here: https://github.com/openstack/python- barbicanclient/commit/6651c8ffce48ce7ff08f5563a8e6212677ea0468 As an example (this worked before the latest bionic version was pushed) openstack loadbalancer listener create --protocol-port 443 --protocol "TERMINATED_HTTPS" --name "test-listener" --default-tls- container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c- 86eb3cc7fe1a" -- lb1 With the newest package upgrade this creation will fail with the following exception: The PKCS12 bundle is unreadable. Please check the PKCS12 bundle validity. In addition, make sure it does not require a pass phrase. Error: [('asn1 encoding routines', 'asn1_d2i_read_bio', 'not enough data')] (HTTP 400) (Request-ID: req-8e48d0b5-3f5b- 4d26-9920-72b03343596a) Further rationale on this can be found on https://storyboard.openstack.org/#!/story/2007371 [Test Case] 1) Deploy this bundle or similar (http://paste.ubuntu.com/p/cgbwKNZHbW/) 2) Create self-signed certificate, key and ca (http://paste.ubuntu.com/p/xyyxHZGDFR/) 3) Create the 3 certs at barbican $ openstack secret store --name "test-pk-1" --secret-type "private" --payload-content-type "text/plain" --payload="$(cat ./keys/controller_key.pem)" $ openstack secret store --name "test-ca-1" --secret-type "certificate" --payload-content-type "text/plain" --payload="$(cat ./keys/controller_ca.pem)" $ openstack secret store --name "test-pub-1" --secret-type "certificate" --payload-content-type "text/plain" --payload="$(cat ./keys/controller_cert.pem)" 4) Create a loadbalancer $ openstack loadbalancer create --name lb1 --vip-subnet-id private_subnet 5) Create a secrets container $ openstack secret container create --type='certificate' --name "test- tls-1" --secret="certificate=https://10.5.0.4:9312/v1/secrets/3c9109d9-05e0-45fe-9661-087c50061c00"; --secret="private_key=https://10.5.0.4:9312/v1/secrets/378e8f8c-81f5 -4b5a-bffd-c0c43a41b4a8" --secret="intermediates=https://10.5.0.4:9312/v1/secrets/07a7564d- b5c6-4433-a0a9-a195e2d54c57" 6) Try to create the listener openstack loadbalancer listener create --protocol-port 443 --protocol "TERMINATED_HTTPS" --name "test-listener" --default-tls- container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c- 86eb3cc7fe1a" -- lb1 With the newest package upgrade this creation will fail with the following exception: The PKCS12 bundle is unreadable. Please check the PKCS12 bundle validity. In addition, make sure it does not require a pass phrase. Error: [('asn1 encoding routines', 'asn1_d2i_read_bio', 'not enough data')] (HTTP 400) (Request-ID: req-8e48d0b5-3f5b- 4d26-9920-72b03343596a) [Regression Potential] - - * Creation and List/Get secrets by UUID and with different prefixes (as container secrets) and how this can affect is something to validate with the new SRU. + * Creation and List/Get secrets by UUID and with different prefixes (as + container secrets) and how this can affect is something to validate with + the new SRU. * Please remember that this breakage is only exposed with octavia-api from UCA >= rocky, and affects a very minor subset of users that make use of the default-tls-container option when creating the listener. The change considers both cases for compatibility so no breakage is expected on this front. * Also the unit and functional tests have been included in the SRU changeset in order to ensure that no functionality is broken. [Discussion] The following changesets needs to be backported into the bionic version 4.6.0-0ubuntu1 All of those are part of 4.8.0 onward. ** https://github.com/openstack/python-barbicanclient/commit/6651c8ffce48ce7ff08f5563a8e6212677ea0468 ** https://github.com/openstack/python-barbicanclient/commit/4eec7121b39de3849b469c56d85b95520aab7bad Corresponding reviews https://review.opendev.org/#/c/602810/ https://review.opendev.org/#/c/628046/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1867676 Title: Fetching by secret container doesn't raises 404 exception To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1867676/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
