Support Mounts and Secrets in Compose Provider Extensions

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.

Start by tracing Compose provider extension handling and the existing CDI extension capabilities described in the issue. Define how provider-supplied secrets and mounts should be represented and propagated to the resulting service, then add coverage for the database-provider example and verify that file-based credentials are available.