Made sure configTokenProvider default bean will be overridden by more specific versions (e.g. vault configTokenProvider, etc.)
Fixes gh-1485
Fixes gh-1537
The default ssh-keygen command creates unreadable SSH keys for spring-cloud-config. This change provides the exception that people are searching with as well as a resolution to the issue.
without this change when adding the vault token `spring.cloud.config.server.vault.token` we have 2 config token providers on the classpath, the `VaultConfiguration#configTokenProvider` and the `EnvironmentRepositoryConfiguration$DefaultConfigTokenProvider` both with the same bean name. Starting from Boot 2.2 (AFAIR) that's unacceptable by default.
with this change we're changing the bean name so that we don't override the other bean name.
CipherEnvironmentEncryptor.decrypt() gets a TextEncryptor for each
environment property by KeyStoreTextEncryptorLocator.locate() which
calls KeyStoreKeyFactory.getKeyPair() to create an instance of
RsaSecretEncrptor.
Unfortunately KeyStoreKeyFactory.getKeyPair() seems extremely slow for
jks files whose format is PKCS12. So we need not to repeat calling the
method if possible.
Reuse an intance of RsaSecretEncrptor to avoid the performance problem.
Always including application as default so that it can be shared accross all applications to be consistent with other repository implementations.
Sharing secrets to the application from default profile.
Updated the docs to reflect the changes
* Use a more robust filter when dealing with multiple keys. Fixes#1533
* Simplifying tests
* Creating a variable for the Pattern to avoid creating it everytime
The description shows what you need to do starting from Vault 0.10.0, now the fresh installation of Vault gives you version 1.3.1. Adding the full property name for those that have nothing to do with vault can come in handy.
Also I think we should change the default to be `kvVersion=2`.
* Documenting changes that resulted from issue 1475
Scott Frederick asked me to document the changes he made while implementing the changes needed for issue 1475 (https://github.com/spring-cloud/spring-cloud-config/issues/1475). This PR adds the details that Scott explained to me. Thanks, Scott. :)
* Accounting for Scott Frederick's feedback
Scott had a clarification in one spot and some more detail in another spot. I made the corresponding changes. Thanks, Scott. :)
Migrates the Spring Cloud Config Server support for Vault from using a RestTemplate directly to using Spring Vault and VaultTemplate. These changes should provide exactly the same features with backward-compatible properties-based auto-configuration and Java configuration, while allowing for more features in the future via Spring Vault's extensive support for Vault integration.
The old RestTemplate implementation remains as deprecated. The implementation is chosen based on the existence of VaultTemplate.
Fixes gh-1474
