max_allowed_secret_in_bytes is too low and can't be tuned

Bug #1946018 reported by Vladimir Grevtsev
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Barbican Charm
Fix Released
High
Felipe Reyes
OpenStack Charm Guide
Fix Released
Undecided
Felipe Reyes

Bug Description

env: focal/ussuri, cs:barbican-41

I have tried to create a TLS-terminated loadbalancer, following the https://docs.openstack.org/octavia/latest/user/guides/basic-cookbook.html guide:

> openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"

But the above command failed with the following error:

https://barbican.fqdn:9311 "POST /v1/secrets/ HTTP/1.1" 413 110
RESP: [413] Connection: close Content-Length: 110 Content-Type: application/json Date: Mon, 04 Oct 2021 16:47:04 GMT Server: Apache/2.4.41 (Ubuntu) x-openstack-request-id: req-76aa4ce2-7403-46b4-bf75-e8e65e402203
RESP BODY: {"code": 413, "title": "Request Entity Too Large", "description": "Provided information too large to process"}
POST call to key-manager for https://barbican.fqdn:9311/v1/secrets/ used request id req-76aa4ce2-7403-46b4-bf75-e8e65e402203
Response status 413
4xx Client error: Request Entity Too Large: Provided information too large to process
Request Entity Too Large: Provided information too large to process
Traceback (most recent call last):
  File "/snap/openstackclients/116/lib/python3.6/site-packages/cliff/app.py", line 400, in run_subcommand
    result = cmd.run(parsed_args)
  File "/snap/openstackclients/116/lib/python3.6/site-packages/cliff/display.py", line 117, in run
    column_names, data = self.take_action(parsed_args)
  File "/snap/openstackclients/116/lib/python3.6/site-packages/barbicanclient/barbican_cli/v1/secrets.py", line 192, in take_action
    entity.store()
  File "/snap/openstackclients/116/lib/python3.6/site-packages/barbicanclient/v1/secrets.py", line 44, in wrapper
    return func(self, *args)
  File "/snap/openstackclients/116/lib/python3.6/site-packages/barbicanclient/v1/secrets.py", line 338, in store
    response = self._api.post(self._entity, json=secret_dict)
  File "/snap/openstackclients/116/lib/python3.6/site-packages/barbicanclient/client.py", line 75, in post
    return super(_HTTPClient, self).post(path, *args, **kwargs).json()
  File "/snap/openstackclients/116/lib/python3.6/site-packages/keystoneauth1/adapter.py", line 392, in post
    return self.request(url, 'POST', **kwargs)
  File "/snap/openstackclients/116/lib/python3.6/site-packages/barbicanclient/client.py", line 63, in request
    self._check_status_code(resp)
  File "/snap/openstackclients/116/lib/python3.6/site-packages/barbicanclient/client.py", line 107, in _check_status_code
    status
barbicanclient.exceptions.HTTPClientError: Request Entity Too Large: Provided information too large to process
clean_up StoreSecret: Request Entity Too Large: Provided information too large to process
END return value: 1

After looking at the Barbican logs, I was able to identify the place where it's being raised:

[Mon Oct 04 16:30:52.798339 2021] [wsgi:error] [pid 1187998:tid 140681750877952] [remote 127.0.0.1:55908] 2021-10-04 16:30:52.797 1187998 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/common/validators.py", line 209, in validate
[Mon Oct 04 16:30:52.798345 2021] [wsgi:error] [pid 1187998:tid 140681750877952] [remote 127.0.0.1:55908] 2021-10-04 16:30:52.797 1187998 ERROR barbican.api.controllers payload = self._extract_payload(json_data)
[Mon Oct 04 16:30:52.798348 2021] [wsgi:error] [pid 1187998:tid 140681750877952] [remote 127.0.0.1:55908] 2021-10-04 16:30:52.797 1187998 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/common/validators.py", line 319, in _extract_payload
[Mon Oct 04 16:30:52.798350 2021] [wsgi:error] [pid 1187998:tid 140681750877952] [remote 127.0.0.1:55908] 2021-10-04 16:30:52.797 1187998 ERROR barbican.api.controllers raise exception.LimitExceeded()
[Mon Oct 04 16:30:52.798353 2021] [wsgi:error] [pid 1187998:tid 140681750877952] [remote 127.0.0.1:55908] 2021-10-04 16:30:52.797 1187998 ERROR barbican.api.controllers webob.exc.HTTPRequestEntityTooLarge: Provided information too large to process

https://github.com/openstack/barbican/blob/master/barbican/common/validators.py#L48-L52

Given the above, I might be able to workaround this issue by increasing the CONF.max_allowed_secret_in_bytes from DEFAULT section of the config, but currently charm does not support this.

summary: - Charm does not support custom parameters injection in DEFAULT section of
- barbican.conf
+ max_allowed_secret_in_bytes is too low and can't be tuned
Revision history for this message
Vladimir Grevtsev (vlgrevtsev) wrote :

Adding field-high as discussed with Corey:

> maybe that should get subscribed to field. I'd say it falls into a gray area between feature and bug.
> but the default is just too small so more of a bug

Revision history for this message
Felipe Reyes (freyes) wrote :

The size of the payload that Vladimir was trying to use was 10500 bytes .

Changed in charm-barbican:
status: New → Triaged
assignee: nobody → Felipe Reyes (freyes)
importance: Undecided → High
Revision history for this message
Felipe Reyes (freyes) wrote :

https://github.com/openstack/barbican/commit/c59f2a6bbb83308de1598cebdc82197f2a148c6b

this commit bumped up the max request size and secret size to 25000 and 20000 bytes respectively, those are the values we should use as default in the charm.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-barbican (master)
Changed in charm-barbican:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-guide (master)
Changed in charm-guide:
status: New → In Progress
Felipe Reyes (freyes)
Changed in charm-guide:
assignee: nobody → Felipe Reyes (freyes)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-barbican (master)

Reviewed: https://review.opendev.org/c/openstack/charm-barbican/+/812399
Committed: https://opendev.org/openstack/charm-barbican/commit/0740a468ef6fcd34ecc3b09ae3d1a5a124f86eab
Submitter: "Zuul (22348)"
Branch: master

commit 0740a468ef6fcd34ecc3b09ae3d1a5a124f86eab
Author: Felipe Reyes <email address hidden>
Date: Mon Oct 4 15:41:25 2021 -0300

    Expose max request and secret size config options.

    Upstream Barbican has bumped up its default for the configuration keys
    max_allowed_request_size_in_bytes and max_allowed_secret_in_bytes to
    25kB and 20kB respectively (c59f2a6b). This change adopts those values
    to be used in all the supported releases and exposes them via juju
    config.

    Closes-Bug: #1946018
    Change-Id: I3dcb30f5de6367de2aa5c26bb59a79893fb8e578

Changed in charm-barbican:
status: In Progress → Fix Committed
Felipe Reyes (freyes)
Changed in charm-barbican:
milestone: none → 21.10
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-guide (master)

Reviewed: https://review.opendev.org/c/openstack/charm-guide/+/812402
Committed: https://opendev.org/openstack/charm-guide/commit/d76e48449c853055bb2107b166872e25b88ab340
Submitter: "Zuul (22348)"
Branch: master

commit d76e48449c853055bb2107b166872e25b88ab340
Author: Felipe Reyes <email address hidden>
Date: Mon Oct 4 16:56:18 2021 -0300

    barbican charm: new options for request and secret sizes

    The barbican charm has some new configuration options:

    * max-allowed-request-size
    * max-allowed-secret-size

    Closes-Bug: #1946018
    Depends-On: https://review.opendev.org/c/openstack/charm-barbican/+/812399
    Change-Id: I981e9cd6a3c3bc7dab776fa08c114078bdfa62d1

Changed in charm-guide:
status: In Progress → Fix Released
Felipe Reyes (freyes)
Changed in charm-guide:
milestone: none → 21.10
Changed in charm-barbican:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.