开源应用中使用Spring Cloud Config存储密钥的最佳实践

Great question—this is such a common headache for open-source projects that need to keep secrets safe while keeping their core code public. Let’s walk through the most reliable, widely-adopted practices to handle this with Spring Cloud Config:

• Inject Git repo credentials via environment variables
  The simplest starting point is to keep your private config repo's credentials out of code entirely by passing them as environment variables when starting your Spring Cloud Config server. For example, instead of hardcoding spring.cloud.config.server.git.username and spring.cloud.config.server.git.password in a config file, set them at runtime:

  SPRING_CLOUD_CONFIG_SERVER_GIT_USERNAME=my-git-user SPRING_CLOUD_CONFIG_SERVER_GIT_PASSWORD=my-git-token java -jar config-server.jar
  

  In containerized environments (Docker, Kubernetes), you can define these variables in your deployment manifests (just make sure those manifests aren't committed to your public repo either—use your cluster's secret management instead).

• Leverage cloud-native secret management services
  For production-grade setups, use your cloud provider's built-in secret manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) to store both your private Git repo credentials and your application's API keys. Spring has official starters to integrate these services directly with Spring Cloud Config:

  • For Azure Key Vault: Add the spring-cloud-starter-azure-keyvault-config dependency, then configure your vault endpoint in your public config. The actual secrets (like Git credentials or API keys) stay in Key Vault, and the Config server pulls them at startup.
  • For AWS Secrets Manager: Use spring-cloud-starter-aws-secrets-manager-config to map secrets directly to your Spring properties.
    This way, no sensitive values ever touch your codebase or public repos.

• Encrypt sensitive properties with Spring Cloud Config's encryption
  Spring Cloud Config has built-in encryption for config properties. You can encrypt your API keys (or Git credentials) using the Config server's /encrypt endpoint, then store the encrypted cipher text in your public config repo. The decryption key is never committed to version control—instead, you pass it via an environment variable (ENCRYPT_KEY) or pull it from a KMS at runtime.
  Example workflow:

  1. Start your Config server with an encryption key (locally, use ENCRYPT_KEY=my-strong-key java -jar config-server.jar)
  2. Encrypt a secret: curl http://localhost:8888/encrypt -d "my-secret-api-key"
  3. Store the encrypted value in your config file: api.key={cipher}abc123xyz...
     The Config server will automatically decrypt this value when serving it to your applications.

• Split config repos: Public vs. Private
  Separate your non-sensitive, public config (like feature flags, timeout values) into your main public repo, and keep all sensitive config in a private Git repo. Configure your Spring Cloud Config server to pull from both repos, using environment variables/KMS to inject credentials for the private repo. Here's a sample config snippet:

  spring:
    cloud:
      config:
        server:
          git:
            uri: https://github.com/your-org/public-config-repo
            repos:
              private-secrets:
                pattern: '*/secrets'
                uri: git@github.com:your-org/private-config-repo.git
                private-key: ${GIT_SSH_PRIVATE_KEY} # Injected via environment variable
  

  This way, your public repo only contains safe, shareable config, and sensitive data stays locked away.

• Local development: Use ignored config files
  For local development, have each developer create a application-local.yml (or bootstrap-local.yml) file on their machine, add it to .gitignore, and populate it with their own local secrets or test credentials. Spring Boot will prioritize this local config over the remote Config server values, so developers can work without exposing real secrets.

The core rule across all these practices is: Never commit sensitive values to your public codebase. All secrets should only exist at runtime, injected via secure channels like environment variables, cloud KMS, or encrypted configs.

内容的提问来源于stack exchange，提问作者Mitch Talmadge