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.
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
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. :)
* Add AWS S3 Environment Repository
This adds s3 as an Environment Repository.
This is based on code linked here:
https://github.com/spring-cloud/spring-cloud-config/issues/654
though it has been significantly reworked and tested.
It has been tested against vanilla buckets, versioned buckets, encrypted buckets with both AES-256 and AWS-KMS.
There are several things that I am not sure I have done 100% correctly. I'm happy to take feedback and fix. Here is a list of specific things that are known unknowns for me.
* Is there anything else that I need to do to make this implementation available in addition to what I added in EnvironmentRespositoryConfiguration?
* I added the AWS s3 java dependency for obvious reasons. There was already an AWS core dependency so I just used the same version. It is a very old version thought (2016). It seems to get the job done, but there is some stuff for STS credentials that I might use in the newer AWS SDK. I'm unsure what the process for testing the other code that requires AWS would be and updating.
* The AWS S3 client is constructed using the Default AWS provider chain. This should handle most cases implicitly (including assume role), though a newer AWS SDK might be preferable.
* This currently works against typical <app>-<profile>.properties and <app>-<profile>.yml files that are in a single AWS account and in a specified bucket. Label is optionally used as another suffix on the file name (<app>-<profile>-<label>.yml). This seems like a straight forward mapping of config server concepts to S3, but I am happy to hear other ideas. I noticed that the Git impl allows multiple repos and a kind of routing layer. This is a possibility later if needed, but this seems like a good place to start.
* I think the yaml and properties are parsed into a map correctly, but have a look at the unit tests to ensure.
* I'm trying to handle exceptional cases like other implementations when there are problems getting the config.
* In the factory I pass in ConfigServerProperties and make use of several of its attributes.
* I added the new test to AdhocTestSuite.
* I've tried serveral things, but I don't have the dependencies resolving correctly in IntelliJ Idea. I can compile and run tests with mvn on the command line, but it would be great to be able to do those things in IJ. I think that it gets confused with the parent pom in spring-cloud-build.
* Simpler YAML handling
Use YamlPropertiesFactoryBean for YAML.
Add configurable s3 endpoint.
* handle JSON config content in S3
* Label should denote a directory in S3
* Checkstyle changes, and make S3 JSON look more deliberate
Noted that JSON is using a YAML parser on purpose.
* added documentation for AWS S3 backend
* Allow overriding of AwsS3EnvironmentRepository
* put awss3 config properties at a consistent path
* Minor addition to get the new AwsS3 beans picked up during app init.
