What is the problem you're trying to solve
Docker secret use a simple model to map the content of a secret as plain text to a file under /run/secrets.
Both Kubernetes and AWS Secret Manager use a more complex model where secrets are stored as key-indexed documents (map[string]string).

The intent of this proposal is to extend Compose spec secret definition to cover both use cases in a consistent way.

Describe the solution you'd like
I propose we introduce support for keys in secret definition:

secrets:
  my_secret:
    external: true
    keys: ["foo", "bar"]

Doing so will result into retrieving external secret my_secret from infrastructure as a hierarchical document, and create files foo and bar in secret volume mounted inside container:

➜  ls -l /run/secrets/my_secret
total 0
-r--r--r--    1 root  root     bar
-r--r--r--    1 root  root     foo

Not being able to parse secret content as a hierarchical document will result into an error.

keys will support special value * to inject all entries in the secret as files.

if keys is not defined, and Compose implementation support this, the raw secret content is written into a file and attached to the container as secret volume:

secrets:
  my_secret:
    external: true

➜  cat /run/secrets/my_secret
{
  "foo": "***",
  "bar": "***"
}

So,

• Kubernetes Secrets can be covered with optionally limiting bound keys. As raw secret is not supported on this platform, keys could default to *.
• Swarm do not supported hierarchical secrets, and would reject (or ignore) a Compose file using `keys``
• AWS ECS can both support hierarchical secrets being injected, as well as plain text secrets.

Additional context
see https://github.com/docker/ecs-plugin/issues/207