Status: Draft

Sponsor User: Anylog/Edge Lake

Date of Submission: Apr 14, 2025

Submitted by: @Joe Pearson

Affiliation(s): IBM

<Please fill out the above fields, and the Overview, Design and User Experience sections below for an initial review of the proposed feature.>

Scope and Signoff: Agent, Agbot, and Exchange (small)

Overview

The Secrets Management functionality in Open Horizon is designed to generate a file containing secrets serialized into JSON objects. Some services expect bare secret values in the file with no adornment. Provide a configuration property that will trigger this behavior.

Design

Today, in a Service Definition file, secrets can be defined in the “deployment” property:

    "deployment": {
        "services": {
            "$SERVICE_NAME": {
                "image": "postgres:17.4",
                "privileged": false,
                "ports": [{"HostPort":"5432:5432"}],
                "binds":["/db-data/:/var/lib/postgresql/data/:rw"],
                "secrets": {"secret_user":{},"secret_password":{},"secret_db":{}}
            }
        }
    }

With the above example configuration, the deployed workload would have the three secrets serialized into JSON files available at the following paths in the container:

/open-horizon-secrets/secret_user
/open-horizon-secrets/secret_password
/open-horizon-secrets/secret_db

And the contents of those files would be something like this:

{"key":"user","value":"jpearson"}

{"key":"password","value":"notapw"}

{"key":"db","value":"MYdatabase"}

We are proposing to add an optional key/value pair in each secret Array in the Service Definition that would allow overriding this behavior:

    "deployment": {
        "services": {
            "$SERVICE_NAME": {
                "image": "postgres:17.4",
                "privileged": false,
                "ports": [{"HostPort":"5432:5432"}],
                "binds":["/db-data/:/var/lib/postgresql/data/:rw"],
                "secrets": {
                    "secret_user":{"format":"value_only"},
                    "secret_password":{"format":"value_only"},
                    "secret_db":{"format":"value_only"}
                }
            }
        }
    }

Resulting in the contents of the serialized secrets files being:

jpearson

notapw

MYdatabase

User Experience

Command Line Interface

Booz: In the CLI, the secret related commands all "force" the user to CRUD secrets as name value pairs: Key and Value. This is why the mounted secret file contents are structured JSON. It would be interesting to understand if Vault supports any other kinds of secrets (besides the Key/Value secrets) that might also align with this design proposal. What I'm wondering is if we could support an additional Vault secret type that inherently works like a bare credential, without the need to extend the OH metadata with the "format" config option.

External Components

<Describe any new or changed interactions with components that are not the agent or the management hub.>

Affected Components

Security

APIs

<Describe and new/changed/deprecated APIs, including before and after snippets for clarity. Include which components or users will use the APIs.>

Build, Install, Packaging

Documentation Notes

Test

<Summarize new automated tests that need to be added in support of this feature, and describe any special test requirements that you can foresee.>

Bare Secrets Files Feature Design Candidate