Add Google Cloud Secret Manager and HashiCorp Vault integration

[Copilot]

This PR adds support for Google Cloud Secret Manager and HashiCorp Vault to the credentials library, allowing users to securely store and retrieve sensitive configuration values from external secret management systems.

Features Added

Secret Manager Integration

• Google Cloud Secret Manager: Full integration with Google Cloud Secret Manager API
• HashiCorp Vault: Complete Vault API integration with support for both KV v1 and v2 engines
• Pluggable Architecture: Extensible SecretManager interface for future secret management systems

Configuration Priority System

The library now follows this priority order when loading configuration values:

1. Secret Managers: If a secret manager environment variable is set (e.g., GOOGLE_DB_PASSWORD), retrieve from secret manager
2. Environment Variables: If no secret manager variable found, check regular environment variables (e.g., DB_PASSWORD)
3. Credentials File: If no environment variable found, use the encrypted credentials file

Usage Examples

Google Cloud Secret Manager

export GOOGLE_PROJECT_ID="my-project"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"
export GOOGLE_DB_PASSWORD="database-password-secret"
export GOOGLE_API_KEY="api-key-secret"

HashiCorp Vault

export VAULT_ADDR="https://vault.example.com"
export VAULT_TOKEN="hvs.ABC123..."
export VAULT_DB_PASSWORD="secret/data/database/password"
export VAULT_API_KEY="secret/data/api/key"

Application Code

type Config struct {
    DatabasePassword string `mapstructure:"DB_PASSWORD"`
    APIKey          string `mapstructure:"API_KEY"`
}

reader := credentials.NewConfigReader()
var config Config
err := reader.Read("production", &config)
// DB_PASSWORD will be loaded from Google Secret Manager if GOOGLE_DB_PASSWORD is set
// API_KEY will be loaded from Vault if VAULT_API_KEY is set

Implementation Details

Key Files Added

• pkg/credentials/secret_manager.go - Core interfaces and registry
• pkg/credentials/google_secret_manager.go - Google Cloud Secret Manager implementation
• pkg/credentials/vault_secret_manager.go - HashiCorp Vault implementation
• pkg/credentials/secret_manager_test.go - Comprehensive test suite
• cmd/example/main.go - Example application demonstrating integration

Backward Compatibility

• 100% backward compatible - existing configurations continue to work unchanged
• No breaking changes to existing API
• Secret manager integration is opt-in via environment variables

Dependencies Added

• cloud.google.com/go/secretmanager - Google Cloud Secret Manager client
• github.com/hashicorp/vault/api - HashiCorp Vault client

Testing

• Comprehensive test suite covering all new functionality
• Mock implementations for testing without external dependencies
• Integration tests demonstrating the complete workflow
• All existing tests continue to pass

Documentation

• Updated README with detailed secret manager usage examples
• Environment variable configuration guide
• Priority system explanation
• Example application with usage demonstrations

This implementation provides a secure, scalable way to manage sensitive configuration values while maintaining the simplicity and flexibility of the existing credentials library.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[roonglit]

@copilot I explained to you wrong. We are not reading every key when there is GOOGLE prefix. But if we have a set that we need for accessing Google Secret Manager, we will be using Google Secret Manager for all keys. For example, if google secret manager requires password to access, when there is environment variable GOOGLE_SECRET set, we will be query all value from there. For the value which is not in Google Secret Manager, even we have it set in credentials or environment variable, we will return blank value. Simply speaking, entire set in Google Secret Manager will be override all. But if there is no GOOGLE_SECRET is set, we will read variable base on the current behavior, by reading from credentials file and then allow overriding with environment variable.

[Copilot]

@copilot I explained to you wrong. We are not reading every key when there is GOOGLE prefix. But if we have a set that we need for accessing Google Secret Manager, we will be using Google Secret Manag...

I've fixed the secret manager integration to work correctly based on your feedback. The changes include:

1. Changed activation method: Now uses GOOGLE_SECRET and VAULT_SECRET environment variables to activate the respective secret managers for ALL configuration values
2. All-or-nothing approach: When a secret manager is activated, ALL configuration values are loaded from that secret manager using the mapstructure tag names (e.g., DATABASE_URL, API_KEY)
3. No fallback when active: If a secret manager is activated but a value is not found, it returns empty (no fallback to environment variables or credentials file)
4. Preserved default behavior: When no secret manager is activated, the original behavior is preserved (credentials file + environment variable overrides)

The implementation is now in commit aecaf92 and includes updated tests, documentation, and examples that demonstrate the corrected behavior.