Compose provider extensions are useful for provisioning or configuring resources that are not managed directly by Compose. They can also inject information about those resources into the application, commonly through environment variables—for example, providing managed database credentials.
However, credentials and other sensitive values are often better distributed as mounted files rather than environment variables. Environment variables can unintentionally leak through process inspection, debugging output, logs, crash reports, or other tooling.
At present, Compose providers appear to only have the ability to add or override environment variables. There does not seem to be a way for a provider to inject a mount, secret, or other file-based credential into the resulting Compose service.
Proposed Feature
Allow Compose provider extensions to contribute file-based (secrets) resources such as, and overall align them better with existing capabilities like cdi extensions which in principle can mutate containers at runtime with additional volume and/or bind mounts.
For example, a database provider could expose credentials through a secret:
services:
app:
providers:
database:
type: managed-db
secrets:
- db_password
secrets:
db_password:
# Provided by the provider
The application could then consume the credential from the mounted secret file rather than receiving it through an environment variable.
Motivation
This would allow providers to follow more secure secret-distribution practices while retaining the convenience of provider extensions. In particular, it would: better align the feature with security recommendations/best practices, and align the feature for images that exclusively be used with such password files.
Compose provider extensions are useful for provisioning or configuring resources that are not managed directly by Compose. They can also inject information about those resources into the application, commonly through environment variables—for example, providing managed database credentials.
However, credentials and other sensitive values are often better distributed as mounted files rather than environment variables. Environment variables can unintentionally leak through process inspection, debugging output, logs, crash reports, or other tooling.
At present, Compose providers appear to only have the ability to add or override environment variables. There does not seem to be a way for a provider to inject a mount, secret, or other file-based credential into the resulting Compose service.
Proposed Feature
Allow Compose provider extensions to contribute file-based (secrets) resources such as, and overall align them better with existing capabilities like cdi extensions which in principle can mutate containers at runtime with additional volume and/or bind mounts.
For example, a database provider could expose credentials through a secret:
The application could then consume the credential from the mounted secret file rather than receiving it through an environment variable.
Motivation
This would allow providers to follow more secure secret-distribution practices while retaining the convenience of provider extensions. In particular, it would: better align the feature with security recommendations/best practices, and align the feature for images that exclusively be used with such password files.