-
Story
-
Resolution: Done
-
Medium
-
None
-
Frankfurt Sp1: 11/4 - 11/22
This is a draft that propose a first implementation of Vault Client with source-rest source mapping.
he attached archive (CBA) show a simple Vault action to CDS. The action request 3 secret to Vault server and fill a payload (template) for future usage during a config provisioning.
- DSL definition in CBA config file:
"dsl_definitions" : { "dynamic-secret-source" : { "type": "token-auth", "url": "http://192.168.56.101:8200", "token" : "TOKEN_HERE", "additionalHeaders" : { "X-Vault-Token": "TOKEN_HERE" } } }
- Action:
{ "commonHeader":{ "originatorId":"System", "requestId":"1234", "subRequestId":"1234-12234" }, "actionIdentifiers":{ "blueprintName":"vault-operations", "blueprintVersion":"1.0.0", "actionName":"resolve-vault", "mode":"sync" }, "payload":{ "resolve-vault-request":{ "secret-path": "/v1/secret/my-app/login" } } }
- Payload with secrets
<?xml version="1.0" encoding="UTF-8"?> {% set mySecret = secret[0]["data"] %} <config> <accesses> <access> <access-list-name>{{ mySecret.username }}</access-list-name> <access-password>{{ mySecret.password }}</access-list-entry> </access> </accesses> </config>
- Mapping variables in template
[ { "name": "secret", "input-param": true, "property": { "type": "map", "entry_schema": { "type": "string" }, "metadata": [ "log-protect": "yes" ] }, "dictionary-name": "vault-secrets", "dictionary-source": "vault-data", "dependencies": [ "secret-path" ] }, { "name": "secret-path", "input-param": true, "property": { "type": "string" }, "dictionary-name": "input-source", "dictionary-source": "input", "dependencies": [] } ]
The capture below show a resource resolution output for Vault data.
- is blocked by
-
CCSDK-1597 First draft: Vault Client Rest API implementation for CDS sensitive data
- Closed