Allow Cloudinary credentials to be stored using Key module or private storage instead of configuration

Problem/Motivation

Currently, the Cloudinary module stores sensitive credentials (e.g., API key, API secret, cloud name) directly in Drupal configuration.

This approach has several drawbacks:

• Security risk: Configuration is often committed to version control, which may expose sensitive credentials.
• Environment inflexibility: Different environments (local, dev, staging, production) require different credentials, making config synchronization problematic.
• Not aligned with Drupal best practices: Sensitive data should not be stored in configuration but instead in secure storage such as the Key module or environment-specific settings.

Many contributed and core-adjacent modules already support integrating with the Key module or similar secure storage mechanisms.

Proposed resolution

Provide support for storing Cloudinary credentials securely using one of the following approach:

Integration with Key module

• Allow administrators to select keys created via the Key module for:
  • API Key
  • API Secret
  • Cloud Name (optional)
• Replace direct config values with references to Key entities.
• Load credential values at runtime via the Key module service.

• Refactor current configuration schema to support:
  • Either configuration or key references
• Update service(s) that instantiate the Cloudinary client to:
  • Resolve credentials dynamically from Key or fallback configuration
• Ensure backward compatibility:
  • Existing config values continue to work unless explicitly migrated

Remaining tasks

• Review current credential handling in the Cloudinary service classes
• Add optional dependency support for Key module
• Implement configuration form updates to allow selecting keys
• Add validation to ensure either direct values or keys are provided
• Refactor credential loading logic to support multiple sources
• Provide update hook to migrate existing configurations (optional)
• Add automated tests for:
  • Config-based credentials
  • Key-based credentials
• Update documentation

User interface changes

• Update the Cloudinary configuration form:
  • Add option to choose between:
    • "Store credentials in configuration"
    • "Use Key module"
  • If Key module is enabled:
    • Show dropdowns to select Key entities
  • Hide or disable plaintext fields when keys are used
• Add descriptions explaining:
  • Security implications
  • Recommended approach for production environments

API changes

• Internal service changes:
  • Credential retrieval becomes dynamic instead of config-only
• No breaking changes to public APIs expected, but:
  • Services depending on config values may need to use a new credential resolver service

Suggested new service:

• cloudinary.credentials_resolver
  • Responsible for:
    • Fetching credentials from config, Key module, or private storage
    • Providing a unified interface for the rest of the module