[RESOLVED] ER: Suppress trigger result JSON packet

Docker Hub
1

When you fire off a trigger :gun: it responds with data packet with everything about the container service. Given that triggers require no authentication (secured by obfuscation only) this is bad news :scream:

The calculated_envvars is the main culprit, revealing all environment variables for the service. If you need to provide any secrets in your stack configuration it makes triggers especially vulnerable.

  "calculated_envvars": [
    {
      "key": "COOKIE",
      "origin": "user",
      "value": "SRV insert indirect nocache"
    },
    {
      "key": "EXCLUDE_PORTS",
      "origin": "user",
      "value": "8080"
    },
    {
      "key": "FARCRY_DBTYPE",
      "origin": "user",
      "value": "mysql"
    },
    {
      "key": "FARCRY_DSN",
      "origin": "user",
      "value": "foobar"
    },
    {
      "key": "FARCRY_DSN_CLASS",
      "origin": "user",
      "value": "org.gjt.mm.mysql.Driver"
    },
    {
      "key": "FARCRY_DSN_CONNECTIONSTRING",
      "origin": "user",
      "value": "jdbc:mysql://mytopsecret.database.location.com:3306/foo_stage?useUnicode=true&characterEncoding=UTF-8&allowMultiQueries=true&useLegacyDatetimeCode=true"
    },
    {
      "key": "FARCRY_DSN_PASSWORD",
      "origin": "user",
      "value": "encrypted:topsecretsquirrelpasswordxxxx"
    },

...snip8<...snip8<...snip8<...snip8<

It would be ideal if triggers suppressed everything by default beyond a success message confirming the service identity. Perhaps for those more trusting souls, triggers could have an option on the trigger ui to optionally expose data.

What do you think?

2

Just re-raising this issue. Having this level of detail returned as part of an anonymous trigger makes this useless for nearly all our use cases.

If someone needs to orchestrate a more complex series of events that might justify the level of detail currently blurted back, then they can always use the API directly.

At the very least can someone on the Cloud team explain why triggers have been designed like this? Surely a redeploy trigger only needs to confirm that the redeploy request has been accepted and all is well?

3

Last ditch effort to get a response on this issue. Can someone acknowledge the issue and confirm whether or not Docker intend to address it?

I need to know if we should be looking at writing our own interface for triggers via the API or if this issue will eventually be rectified.

:dog: “Bark! Bark-bark! Bark!”
:man: “What is it, Lassie?”
:dog: “Bark! Bark-bark-bark! Bark-bark!”
:man: “What, Timmy’s fallen in the well?”

Given that there is no recommended best practice for managing secrets in Docker (let alone in Docker Cloud) it seems inevitable that many customers will be exposing at least some secrets in their stack files. This reality makes triggers a security hole folks are bound to fall into.

:head_bandage: “Help… I’ve fallen down the well and I can’t get out…”

4

@modius: Just wanted to let you know that we’ve added a FR to suppress environment variables within the JSON response. Appreciate the feedback and apologies for the delay! :dog:

1 Like
5

@modius A fix for this issue has been deployed to production. Thanks again for the feedback!