Compose: Docker secrets compatibility issue

[hiagop]

I'm trying to deploy an IMAP server using docker-compose and secrets for the sensitive data management. I followed the documentation for the long syntax form of creating secrets. But anytime I do docker-compose up -d I get this warning:

WARNING: Service "imap" uses secret "key" with uid, gid, or mode. These fields are not supported by this implementation of the Compose file
WARNING: Service "imap" uses secret "cert" with uid, gid, or mode. These fields are not supported by this implementation of the Compose file

This actually doesn't prevent the containers from being deployed though. But none of the properties set in the docker-compose.yml file are applied to the generated files inside the container.

I have already checked for the compatibility table, but according to it, I should not be getting this warning, since I'm running my containers with the following docker engine and docker-compose versions:

$ docker version:

Client:
Version: 17.06.0-ce
API version: 1.30
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:20:04 2017
OS/Arch: linux/amd64

Server:
Version: 17.06.0-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:18:59 2017
OS/Arch: linux/amd64
Experimental: false

$ docker-compose version:

docker-compose version 1.14.0, build c7bdf9e
docker-py version: 2.3.0
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1t 3 May 2016

---

This is my docker-compose.yml file:

version: '3.1'
services:
    imap:
        image: cyrus
        hostname: cyrus
        volumes:
            - volume1
            - volume2
            - volume3
            - volume4
        secrets:
            - source: key
              target: my.key
              uid: '0'
              gid: '109'
              mode: 0640
            - source: cert
              target: my.crt
              uid: '0'
              gid: '109'
              mode: 0640
        ports:
            - 110:110
            - 143:143
            - 993:993
            - 995:995
            - 4190:4190
        restart: always
        networks:
            - mail
    logger:
        image: gliderlabs/logspout
        hostname: logspout
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
        networks:
            - mail
        command: syslog://log-server-ip:514
networks:
    mail:
        driver: bridge
secrets:
    key:
        file: ./my.key
    cert:
        file: ./my.crt

[johnharris85]

Ye this is weird, the code just has a blanket warning message for any of those fields, regardless of version. Which seems at odds with the documentation.

[shin-]

The secrets implementation in docker-compose is a mock implementation using host binds. The actual secrets feature is only available to Swarm services, which can be deployed using docker stack deploy.

Those warnings are valid for any version of docker-compose.

[johnharris85]

Makes sense, PR welcome to clarify warning / docs explicitly to reference docker stack deploy?

[shin-]

@johnharris85 Absolutely! Please submit it to the docs repo :)

[hiagop]

Okay. Any prevision on when the working feature will be released? Or it's going to be a swarm specific function?
Anyway, thank you guys for the comments. Gave some light for addressing my issue.

[shin-]

As far as I know this feature will stay specific to Swarm services.

[hiagop]

That's sad. But it's OK. I'll find a workaround. You can close the issue.

[jamiejackson]

@shin-

The secrets implementation in docker-compose is a mock implementation using host binds. The actual secrets feature is only available to Swarm services, which can be deployed using docker stack deploy.

Those warnings are valid for any version of docker-compose.

My attempt at a clarification: You're saying is that the secrets feature works in docker-compose (non-swarm mode), but only sort of: If you specify a file secret, it gets a host bind mount, and the same limitations of docker bind mounts apply; i.e., no ability to set uid/gid or mode, just like the limitation of bind mounted volumes.

Instead of:

WARNING: Service "myapp" uses secret "my_secret" with uid, gid, or mode. These fields are not supported by this implementation of the Compose file

... a better message would be:

WARNING: Service "myapp" uses secret "my_secret" with uid, gid, or mode. These fields are only supported in swarm mode

[shin-]

@jamiejackson Thanks! Indeed - I'll consider updating that warning message.

[StephenOTT]

Update to the docs for docker secrets would be hugely helpful as well. The basic docker secrets docs have little to no reference that uid gid and mode require swarm... (as in there is reference to swarm, BUT all of the examples for the dockerfile and composer files work without swarm..)

This is especially an issue for working SSH keys, where ssh will throw an error when trying to read a ssh key from a Docker Secret using the default settings / non-swarm-mode.
But the default Docker secret docs reference that its can be used for SSH keys.

[blaggacao]

@shin- Not having feature parity does basically break my attempt to align production and dev environment... as .pgpass file is another candidate which would not accept the docker-compose file mode...

EDIT: Especially so, as to my knowledge, swarm mode does not support combining several compose files... So that I could do a development override easily...

EDIT2: Seems that Swarm mode is too slow, too, for that purpose.

[StephenOTT]

@blaggacao ya the lack of "mode" support is a really big pain point. Can live with it being a mock when used without swarm. But without Mode its a problem...

[prokhorovn]

I'm trying to add secrets in docker-compose file and get the same message

WARNING: Service "s" uses secret "s" with uid, gid, or mode. These fields are not supported by this implementation of the Compose file

Would it be possible to use uid, gid, mode with secrets and docker-compose?

[lonix1]

The docs are still misleading.

I also couldn't get secrets to work with docker-compose, as docker doesn't mount the secret as 444 and so the container errors with "permission denied" when trying to access /run/secrets/foo.

I'm not using swarm. Is there a workaround? How can I use secrets and docker-compose? I don't want to paste passwords into my docker-compose.yml.

Any advice really appreciated!