84ab5c5096
This PS adds an integration test scenario for validating that encrypting a generic document type and using it as a substitution source during document rendering works. Deckhand will now submit all generic documents to be encrypted to Barbican with a 'secret_type' of 'passphrase'. No encoding is provided Deckhand-side (i.e. base64) because encoding is deprecated in Barbican since it lead to strange behavior; Barbican will figure out what to encode the payload as automatically. For more information, see [0] and [1]. In addition, this PS handles 2 edge cases around secret payloads that are rejected by Barbican if not handled correctly by Deckhand: empty payloads and non-string type payloads [2]. For the first case Deckhand forcibly changes the document to cleartext because there is no point in encrypting a document with an empty payload. For the second case Deckhand sets overrides any previously set secret_type to 'opaque' and encodes the payload to base64 -- when it goes to render the secret it decodes the payload also using base64. Integration tests have been added to handle both edge cases described above. [0] https://bugs.launchpad.net/python-barbicanclient/+bug/1419166 [1] |
||
|---|---|---|
| alembic | ||
| charts/deckhand | ||
| deckhand | ||
| doc | ||
| etc/deckhand | ||
| images/deckhand | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| HACKING.rst | ||
| LICENSE | ||
| Makefile | ||
| README.rst | ||
| alembic.ini | ||
| entrypoint.sh | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Deckhand
Deckhand is a storage service for YAML-based configuration documents, which are managed through version control and automatically validated. Deckhand provides users with a variety of different document types that describe complex configurations using the features listed below.
Find more documentation for Deckhand on Read the Docs.
Core Responsibilities
- layering - helps reduce duplication in configuration by applying the notion of inheritance to documents
- substitution - provides separation between secret data and other configuration data for security purposes and reduces data duplication by allowing common data to be defined once and substituted elsewhere dynamically
- revision history - maintains well-defined collections of documents within immutable revisions that are meant to operate together, while providing the ability to rollback to previous revisions
- validation - allows services to implement and register different kinds of validations and report errors
- secret management - leverages existing OpenStack APIs -- namely Barbican -- to reliably and securely store sensitive data
Getting Started
For more detailed installation and setup information, please refer to the Getting Started guide.
Testing
Automated Testing
To run unit tests using sqlite, execute:
$ tox -epy27
$ tox -epy35against a py27- or py35-backed environment, respectively. To run individual unit tests, run:
$ tox -e py27 -- deckhand.tests.unit.db.test_revisionsfor example.
To run functional tests:
$ tox -e functionalYou can also run a subset of tests via a regex:
$ tox -e functional -- gabbi.suitemaker.test_gabbi_document-crud-success-multi-bucketIntegration Points
Deckhand has the following integration points:
- Barbican (OpenStack Key Manager) provides secure storage for sensitive data.
- Keystone (OpenStack Identity service) provides authentication and support for role based authorization.
- PostgreSQL is used to persist information to correlate workflows with users and history of workflow commands.
Note
Currently, other database back-ends are not supported.
Though, being a low-level service, has many other UCP services that integrate with it, including: