CLI parameter to overwrite MTA parameters

[LukasHeimann]

Description

Hi everyone,

In my project, I have a resource which needs to be passed a secret token during deployment. This is why I wouldn't want to put the token into the repository as part of mta or extension (even if putting credentials into the extension seems to be recommended), but inject it to the cf deploy command from the CD pipeline.

As a workaround, we've currently modeled the resource as existing-service and manually create the service instance. For dev-spaces, however, we'd like to use a development plan of the service, which doesn't need the secret token. However, we still have to manually create the service, as we can't change the resource type to managed-service from the mta extension.

In an ideal world, I would be able to, in my mta.yaml (or any extension), specify a parameter like this:

ID: test
_schema-version: 3.3.0
version: 0.0.0

parameters:
  secret: fillme

resources:
  ...

In the CLI, I would only now need to be able to overwrite the parameters via an additional CLI parameter, e.g.:

cf deploy my.mtar --parameter secret=thesecret

Would it be possible to add such a feature? I've checked cf help deploy but didn't find any hint into this direction...

I don't know if server-side support is necessary here, but in the worst case the CLI could generate an transient mta extension with the parameters and just send it along.

Thank you very much for your support! Kind regards Lukas

[ddonchev]

Hi Lukas & thanks for sharing your feedback!

Until the service starts supporting such capabilities, the closest experience I can propose is templating the secret in the *.mtaext right before deployment. This is also a bit more flexible, as one can pick from a variety of templating tools. The downside is obvious - extra templating has to be done over the mta model, which already kind of supports templating with its properties/parameters references.

From the top of my head I see security shortcomings with both mentioned approaches so far

• if sensitive data is passed as cli options, it may leak - by getting cached in shell history or get printed by "ps" etc.
• if sensitive data is persisted to disk even right before deployment, it may be red & leaked to other processes having access to the file

The security mindful options I can think of are

• to read a json with params from an env variable,
• to stream the sensitive data to stdin of the cf deploy command ,
  • be it only parameters in some structure we invent
  • or entire extension descriptor(s) in yaml.

None of those options are trivial enhancements to the service. Only the last one is at least contained only in the client code(this repo). I'll run them through the team before we decide on any implementation. Best regards!

[LukasHeimann]

Hi Dido,

thank you very much for the reply!

I didn't consider the leaking, I think in the past I observed Jenkins marking secrets regardless of where they are used, but I might be wrong.

I like the idea about passing it via environment variables directly, as this is already supported by our pipeline framework's model of reading secrets from the credential store -- they are put into arbitrarily nameable environment variables. No extra steps to provide them as CLI parameters as well. (This is also what other projects seem to do in similar situations. I sometimes use the static site generator Hugo (written in Go as well), that has this baked in for configuration: https://gohugo.io/getting-started/configuration/#configure-with-environment-variables -- you can give configuration via a YAML or TOML file and overwrite it via CLI parameters or environment variables.)

So thank you for looking into this! Kind regards Lukas

[SathishKumarRamasamy]

@ddonchev : We do have a similar requirement. Any updates on the feature?