4ccb4368ce
Under some circumstances, the payloads retrieved from Barbican do not match what was stored. This primarily affects surrounding whitespace[0], but the implications for passphrases are significant, and even for PEM encoded data, a difference in whitespace in a configmap is enough to trigger a chart upgrade. In general, the effort to align Deckhand document types with Barbican secret types adds complexity without tangible benefit. Barbican does no enforcement of the contents of the data, and if it did, that could lead to further incompatibilities. This change uses the 'opaque' secret type for all secret document types. Before storage (or caching), the payload is serialized using `repr`, and base64 encoded. Upon retrieval, the payload is base64 decoded and parsed back into an object with `ast.literal_eval`. [0]: https://storyboard.openstack.org/#!/story/2007017 Change-Id: I9c2f3427f52a87aad718f95160cf688db35e1b83 |
||
|---|---|---|
| .. | ||
| gabbits | ||
| README.rst | ||
| __init__.py | ||
README.rst
Integration Tests
What
These tests validate integration scenarios between Deckhand, Keystone and Barbican. These scenarios include validating Deckhand's secret lifecycle management as well as substitution of encrypted secrets, which are stored in Barbican and retrieved by Deckhand during document rendering.
How
Deckhand uses gabbi to
drive its integration tests. The entry point for these tests is
integration-tests.sh under tools
directory.
The integration environment is deployed using OpenStack-Helm which uses Helm to orchestrate deployment of Keystone, Barbican and other pre-requisite services.
Usage
These tests can be executed via
./tools/integration-tests.sh <test-regex> from the
command line, where <test-regex> is optional and if
omitted all available tests are run. sudo permissions are
required. It is recommended that these tests be executed inside a VM as
a lot of data is pulled in (which requires thorough clean up) during the
deployment phase.