Use Docker Secrets for MariaDB password

[BadCoder12]

What's Your Idea?

Use Docker Secrets in the Docker Compose to enter the MariaDB password

Why Would This Be Helpful?

You won't have the database password in plain text in the yml or the .env file

Anything Else? (Optional)

This can be done by adding the following as a shell command.

if [ -n "$DATABASE_PASSWORD_FILE" ]; then
export DATABASE_PASSWORD=$(cat $DATABASE_PASSWORD_FILE)
fi

Want to Help Out?

I'm happy to help test and give feedback

Have You Considered Any Alternatives? (Optional)

No response

Before Submitting

• I've searched existing issues and confirmed this feature hasn't been requested yet

[itsalljustdata]

PR 2019 Created for this #2019

[imnotjames]

This can be done by adding the following as a shell command.

if [ -n "$DATABASE_PASSWORD_FILE" ]; then
    export DATABASE_PASSWORD=$(cat $DATABASE_PASSWORD_FILE)
fi

This is still vulnerable to the same issues as other approaches: It's available under /proc/$PID/environ in plain text. The correct way to implement this is to have our application read the values into its protected memory locations directly from the file.

This is still a feature that should be implemented, and is still on our backlog. For those that REQUIRE storing secrets in a properly restricted file for their Grimmory deployment in a secure production environment:

We support configuration via the environment variable SPRING_CONFIG_ADDITIONAL_LOCATION, which you can use until this feature is implemented properly.

Copy the backend/src/main/resources/application.yaml and change values to what they are needed to be. Persist that file in some way (docker secrets, kubernetes secrets, a volume).

Then, you can update your docker env vars with SPRING_CONFIG_ADDITIONAL_LOCATION=my-application.yaml

This is described in our documentation

[webysther]

This can be done by adding the following as a shell command.

if [ -n "$DATABASE_PASSWORD_FILE" ]; then
    export DATABASE_PASSWORD=$(cat $DATABASE_PASSWORD_FILE)
fi

This is still vulnerable to the same issues as other approaches: It's available under /proc/$PID/environ in plain text. The correct way to implement this is to have our application read the values into its protected memory locations directly from the file.

This is still a feature that should be implemented, and is still on our backlog. For those that REQUIRE storing secrets in a properly restricted file for their Grimmory deployment in a secure production environment:

We support configuration via --spring.config.location, which you can use until this feature is implemented properly.

Copy the backend/src/main/resources/application.yaml and change values to what they are needed to be. Persist that file in some way (docker secrets, kubernetes secrets, a volume).

Then, you can update your docker env vars with SPRING_CONFIG_ADDITIONAL_LOCATION=my-application.yaml

This is described in our documentation

Why create so much friction for a implementation that takes so litle? For mostly projects is just a script batch.
This is about reduce the attack surface and TBH, I don't want to wast time explain the security implications that you is not able to see, maybe you ask the GPT for education will help.

This sounds you want this problem to exists.

[webysther]

References:

https://docs.docker.com/engine/swarm/secrets/#build-support-for-docker-secrets-into-your-images
https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets

[webysther]

I will add just one thing here to people that read this in future:

W/O this you have to keep secrets in the .env in the git repo or use extra devops steps to inject the .env to deploy the docker.

[webysther]

https://www.helpnetsecurity.com/2026/03/27/gitguardian-exposed-credentials-risk-report/

[imnotjames]

W/O this you have to keep secrets in the .env in the git repo or use extra devops steps to inject the .env to deploy the docker.

It is against OWASP guidelines to include secrets in your application's version control, and I highly suggest against doing so. Twelve factor app best practices also suggest against including configuration in your application's version control.

Depending on your tool of choice for managing your deployments there are often proper techniques for including sensitive environment variables.

---

If there are security considerations where you must include the secrets as files (such as via Docker secrets) rather than as environment variables, please refer to our documentation - I've added a helpful bit of information on how to do that.