Currently, there isn’t a great way to get secrets into Docker containers when using multi-docker builds.
As you have discovered, the environment variables are not expanded in the environment section like they are in the auth section
- image: example/example:1.2.3
auth:
username: $USERNAME
password: $PASSWORD
The secondary container does not have the environment variables passed in like they are in the primary container. So, as you also discovered, you cannot set these in your Project Settings in the UI.
Many configurations are using Postgres as a test database which is seeded with test data. Because of that, and the fact that these databases are short-lived ephemeral containers, the username and password are not security concerns. They are often just things like root or the name of the project.
With that said, everyone’s use-case is unique so I’ll assume you have a good reason for needing production or other sensitive secrets in your test database for CI. If that is the case, you probably want to look at making use of the machine executors. Machine executors are full VMs and have things like Docker and Docker Compose preconfigured for you. That way you could just run your Postgres container directly and pass whatever values you want into it. Either via docker run or docker-compose. Think of it more like what you would be able to do locally on your development machine.
If you really did need to pass those secrets while use the Docker builds, you can create a custom image based on the Postgres image and pass those values in over the network. There is an article that talks about some techniques, while complex, that can accomplish that.