Multi-file config files to allow JSON object as top level?

[karsten-wagner]

The current single-file config consists of a JSON object with named objects for the config sections, e.g. for KVMS {"envConfig":{"test":{"kvms":[]}}}.
For a multi-file config the KVMS.json file does not contain the JSON object kvms, but starts with the array right away. So in a multi file config the equivalent of above is: [].

In general this is fine if you have the files on your local computer. Once you upload the code and configuration to git, you are eventually sharing sensitive information with developers outside of your team.
To address this we have started to use transcrypt (https://github.com/elasticdog/transcrypt), which encrypts our KVMs and thus hides them from other people with read access to the code repositories (which are often broadly shared in my company for knowledge exchange).
The challenge we are now facing is that our CI/CD is not able to use the encrypted KVM file, since it would need to know all the repository passwords.
To address this we are planning to introduce the use of sops (https://github.com/mozilla/sops), which is more friendly to use to grant the CI/CD service account access to the keys it needs.
Unfortunately sops does not support top level arrays, so KVMS.json can only be handled as binary file, which removes a lot of benefits from using sops (e.g. identifying a single value that changed, vs "something" changed in the KVM).

I am aware this is not a problem of this plugin. Anyways I wanted to recommend to allow the following two alternatives to define multi-file configuration with KVMs as an example...

{ "kvms":
    [ {
        "name": "kvm-name",
        "encrypted": true,
        "entry": [ { "name": "entry-key", "value": "entry-value" } ]
    } ]
}

as an equivalent to:

    [ {
        "name": "kvm-name",
        "encrypted": true,
        "entry": [ { "name": "entry-key", "value": "entry-value" } ]
    } ]

[karsten-wagner]

Just asking the other way round... how do you secure sensitive configuration (e.g. API Key for the target system) when uploading to a code repository?
(Did we miss a similar thing like transcrypt/sops which works well with CI/CD on a large enterprise scale?)

[ssvaidyanathan]

Yes - this has come up previously. Either recommend not storing it in the repo and make changes in the UI (not my favorite). Or else have these sensitive config in a tightly secured Git repo (only DevOps team will have access) to change them. The pipeline will checkout that repo that has all the config and the plugin points to that repo within the CI/CD orchestrator's workspace.

Making a change to the existing structure might impact others as it is a breaking change. We might have to check other options we can use with the existing payload structure in the file