keys created with vault plugin aren't "normalized" and make payload retrieval fails in barbican

Bug #1916793 reported by Arnaud Alcabas
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
castellan
Invalid
Undecided
Unassigned

Bug Description

Castellan version: castellan-3.7.0

Openstack distro: devstack
devstack local.conf:
[[local|localrc]]
disable_all_services

enable_plugin barbican https://opendev.org/openstack/barbican stable/victoria

enable_service rabbit mysql key

# Modify passwords as needed
DATABASE_PASSWORD=secretdatabase
RABBIT_PASSWORD=secretrabbit
ADMIN_PASSWORD=secretadmin
SERVICE_PASSWORD=secretservice
SERVICE_TOKEN=111222333444

Behaviour with default keymanager:
[stack@infraa-007 devstack]$ openstack secret order create --name swift_root_secret \
> --payload-content-type="application/octet-stream" --algorithm aes \
> --bit-length 256 --mode ctr key
+----------------+--------------------------------------------------------------------------------+
| Field | Value |
+----------------+--------------------------------------------------------------------------------+
| Order href | http://10.112.11.91/key-manager/v1/orders/7f605f1a-3e7a-4ef3-b0c3-34ec4c5ec308 |
| Type | Key |
| Container href | N/A |
| Secret href | None |
| Created | None |
| Status | None |
| Error code | None |
| Error message | None |
+----------------+--------------------------------------------------------------------------------+
[stack@infraa-007 devstack]$ openstack secret order get http://10.112.11.91/key-manager/v1/orders/7f605f1a-3e7a-4ef3-b0c3-34ec4c5ec308
+----------------+---------------------------------------------------------------------------------+
| Field | Value |
+----------------+---------------------------------------------------------------------------------+
| Order href | http://10.112.11.91/key-manager/v1/orders/7f605f1a-3e7a-4ef3-b0c3-34ec4c5ec308 |
| Type | Key |
| Container href | N/A |
| Secret href | http://10.112.11.91/key-manager/v1/secrets/560f8100-4a0c-445c-bfec-33dd32c7a9db |
| Created | 2021-02-24T15:11:07+00:00 |
| Status | ACTIVE |
| Error code | None |
| Error message | None |
+----------------+---------------------------------------------------------------------------------+
[stack@infraa-007 devstack]$ openstack secret get http://10.112.11.91/key-manager/v1/orders/560f8100-4a0c-445c-bfec-33dd32c7a9db --payload --payload_content_type="application/octet-stream"
+---------+--------------------------------------------------------------------------------------+
| Field | Value |
+---------+--------------------------------------------------------------------------------------+
| Payload | b'&G\xb6T\xac\x8dhy\x91\xb4\x14\xb6R\xe8\x15\xc0|nzT\x91\x0b\t\xb1e\xe6t\xceF\x1bzu' |
+---------+--------------------------------------------------------------------------------------+

Behaviour with vault configured (repeat secret order create and secret order get):
[stack@infraa-007 ~]# openstack secret get http://10.112.11.91:9311/v1/secrets/30e2eefb-aa60-4094-b65f-c0b0a279b31f --payload --payload_content_type="application/octet-stream"
5xx Server error: Internal Server Error: Secret payload retrieval failure seen - please contact site administrator.
Internal Server Error: Secret payload retrieval failure seen - please contact site administrator.

The problem is that vault plugin manager store the created key as bytes without going through the normalize process from barbican translator. When retrieving the key, barbican try to decode the bytes, expecting base64 and fails with:
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00mTraceback (most recent call last):
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m File "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 101, in handler
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m return fn(inst, *args, **kwargs)
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m File "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 87, in enforcer
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m return fn(inst, *args, **kwargs)
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m File "/opt/stack/barbican/barbican/api/controllers/secrets.py", line 209, in payload
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m **kwargs)
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m File "/opt/stack/barbican/barbican/api/controllers/secrets.py", line 187, in _on_get_secret_payload
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m transport_key)
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m File "/opt/stack/barbican/barbican/plugin/resources.py", line 147, in get_secret
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m requesting_content_type)
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m File "/opt/stack/barbican/barbican/plugin/util/translations.py", line 108, in denormalize_after_decryption
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m unencrypted = base64.decode_as_bytes(unencrypted)
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m File "/usr/local/lib/python3.6/site-packages/oslo_serialization/base64.py", line 68, in decode_as_bytes
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m encoded = encoded.decode('ascii')
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00mUnicodeDecodeError: 'ascii' codec can't decode byte 0xad in position 2: ordinal not in range(128)
2021-02-24 15:17:01.360 TRACE barbican.api.controllers ESC[01;35mESC[00m

I can work around this for swift root key using a plain/text secret, but cinder/nova aren't playing nicely since the use the order method.

Wrapping the key_value using base64 from oslo_serialization in vault_key_manager.py made it work as intented:
key_value = base64.encode_as_bytes(os.urandom((length or 256) // 8))

Tags: vault
description: updated
tags: added: vault
Changed in castellan:
status: New → Confirmed
Changed in castellan:
status: Confirmed → In Progress
assignee: nobody → Yoshi Kadokawa (yoshikadokawa)
Revision history for this message
Yoshi Kadokawa (yoshikadokawa) wrote :

This also affects when creating an encrypted volume(following the steps described in the below URL) with Vault as a backend for Barbican.
https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-encryption.html

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to castellan (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/castellan/+/808018

Revision history for this message
Douglas Mendizábal (dougmendizabal) wrote :

This is not a Castellan bug. The root issue is that Barbican makes bad assumptions about the encoding of data stored via Castellan wich results in some secrets being stored as plain text and others being stored as base64-encoded strings.

See this Barbican bug story for details: https://storyboard.openstack.org/#!/story/2008335

Revision history for this message
Yoshi Kadokawa (yoshikadokawa) wrote :

Thank you for the update Douglas.
Noted, that this is not a bug in Castellan but Barbican.
Also thanks for the link to the storyboard. I'll wait for the fix in Barbican then.

Changed in castellan:
assignee: Yoshi Kadokawa (yoshikadokawa) → nobody
status: In Progress → New
Revision history for this message
Nobuto Murata (nobuto) wrote :

Looks like the Barbican patch has been merged into master so marking Castellan one as Invalid.
https://review.opendev.org/c/openstack/barbican/+/796065

Changed in castellan:
status: New → Invalid
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on castellan (master)

Change abandoned by "Stephen Finucane <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/castellan/+/808018

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.