From 6315c9d944b0e89f21c0cadde221ebf69075278b Mon Sep 17 00:00:00 2001 From: Jay Bryant Date: Wed, 18 Dec 2019 15:41:40 -0600 Subject: [PATCH] Documenting changes that resulted from issue 1475 (#1524) * 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. :) --- docs/src/main/asciidoc/spring-cloud-config.adoc | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/docs/src/main/asciidoc/spring-cloud-config.adoc b/docs/src/main/asciidoc/spring-cloud-config.adoc index 2a816fd3..13e12985 100644 --- a/docs/src/main/asciidoc/spring-cloud-config.adoc +++ b/docs/src/main/asciidoc/spring-cloud-config.adoc @@ -663,6 +663,16 @@ You should see a response similar to the following: } ---- +The default way for a client to provide the necessary authentication to let Config Server talk to Vault is to set the X-Config-Token header. +However, you can instead omit the header and configure the authentication in the server, by setting the same configuration properties as Spring Cloud Vault. +The property to set is `spring.cloud.config.server.vault.authentication`. +It should be set to one of the supported authentication methods. +You may also need to set other properties specific to the authentication method you use, by using the same property names as documented for `spring.cloud.vault` but instead using the `spring.cloud.config.server.vault` prefix. +See the https://cloud.spring.io/spring-cloud-vault/reference/html/#vault.config.authentication[Spring Cloud Vault Reference Guide] for more detail. + +IMPORTANT: If you omit the X-Config-Token header and use a server property to set the authentication, the Config Server application needs an additional dependency on Spring Vault to enable the additional authentication options. +See the https://docs.spring.io/spring-vault/docs/current/reference/html/#dependencies[Spring Vault Reference Guide] for how to add that dependency. + ===== Multiple Properties Sources When using Vault, you can provide your applications with multiple properties sources. @@ -1337,9 +1347,9 @@ So, the preceding example for the `default` profile could be `/foo/default/nginx === Decrypting Plain Text -By default, encrypted values in plain text files are not decrypted. In order to enable decryption for plain text files, set `spring.cloud.config.server.encrypt.enabled=true` and `spring.cloud.config.server.encrypt.plainTextEncrypt=true` in `bootstrap.[yml|properties]` +By default, encrypted values in plain text files are not decrypted. In order to enable decryption for plain text files, set `spring.cloud.config.server.encrypt.enabled=true` and `spring.cloud.config.server.encrypt.plainTextEncrypt=true` in `bootstrap.[yml|properties]` -NOTE: Decrypting plain text files is only supported for YAML, JSON, and properties file extensions. +NOTE: Decrypting plain text files is only supported for YAML, JSON, and properties file extensions. If this feature is enabled, and an unsupported file extention is requested, any encrypted values in the file will not be decrypted. @@ -1484,7 +1494,7 @@ For instance, you might want to align the config label with your branch but make === Specifying Multiple Urls for the Config Server -To ensure high availability when you have multiple instances of Config Server deployed and expect one or more instances to be unavailable from time to time, you can either specify multiple URLs (as a comma-separated list under the `spring.cloud.config.uri` property) or have all your instances register in a Service Registry like Eureka ( if using Discovery-First Bootstrap mode ). Note that doing so ensures high availability only when the Config Server is not running (that is, when the application has exited) or when a connection timeout has occurred. For example, if the Config Server returns a 500 (Internal Server Error) response or the Config Client receives a 401 from the Config Server (due to bad credentials or other causes), the Config Client does not try to fetch properties from other URLs. An error of that kind indicates a user issue rather than an availability problem. +To ensure high availability when you have multiple instances of Config Server deployed and expect one or more instances to be unavailable from time to time, you can either specify multiple URLs (as a comma-separated list under the `spring.cloud.config.uri` property) or have all your instances register in a Service Registry like Eureka ( if using Discovery-First Bootstrap mode ). Note that doing so ensures high availability only when the Config Server is not running (that is, when the application has exited) or when a connection timeout has occurred. For example, if the Config Server returns a 500 (Internal Server Error) response or the Config Client receives a 401 from the Config Server (due to bad credentials or other causes), the Config Client does not try to fetch properties from other URLs. An error of that kind indicates a user issue rather than an availability problem. If you use HTTP basic security on your Config Server, it is currently possible to support per-Config Server auth credentials only if you embed the credentials in each URL you specify under the `spring.cloud.config.uri` property. If you use any other kind of security mechanism, you cannot (currently) support per-Config Server authentication and authorization.