-
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
-