diff --git a/multi/multi__embedding_the_config_server.html b/multi/multi__embedding_the_config_server.html
index 11c11da4..df3e2f32 100644
--- a/multi/multi__embedding_the_config_server.html
+++ b/multi/multi__embedding_the_config_server.html
@@ -6,7 +6,20 @@ To do so, use the @EnableConfigServer annotation.
An optional property named spring.cloud.config.server.bootstrap can be useful in this case.
It is a flag to indicate whether the server should configure itself from its own remote repository.
By default, the flag is off, because it can delay startup.
-However, when embedded in another application, it makes sense to initialize the same way as any other application.
Note
If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.
To change the location of the server endpoints, you can (optionally) set spring.cloud.config.server.prefix (for example, /config), to serve the resources under a prefix.
+However, when embedded in another application, it makes sense to initialize the same way as any other application.
+When setting spring.cloud.config.server.bootstrap to true you must also use a composite environment repository configuration.
+For example
If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.
To change the location of the server endpoints, you can (optionally) set spring.cloud.config.server.prefix (for example, /config), to serve the resources under a prefix.
The prefix should start but not end with a /.
It is applied to the @RequestMappings in the Config Server (that is, underneath the Spring Boot server.servletPath and server.contextPath prefixes).
If you want to read the configuration for an application directly from the backend repository (instead of from the config server), you
basically want an embedded config server with no endpoints.
diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html
index ce7a9bd8..28329983 100644
--- a/multi/multi__spring_cloud_config_server.html
+++ b/multi/multi__spring_cloud_config_server.html
@@ -241,7 +241,11 @@ Example:
The default value for deleteUntrackedBranches property is false.
2.1.2 Version Control Backend Filesystem Use
Warning
With VCS-based backends (git, svn), files are checked out or cloned to the local filesystem.
+ deleteUntrackedBranches: true
Note
The default value for deleteUntrackedBranches property is false.
Git Refresh Rate
You can control how often the config server will fetch updated configuration data
+from your Git backend by using spring.cloud.config.server.git.refreshRate. The
+value of this property is specified in seconds. By default the value is 0, meaning
+the config server will fetch updated configuration from the Git repo every time it
+is requested.
2.1.2 Version Control Backend Filesystem Use
Warning
With VCS-based backends (git, svn), files are checked out or cloned to the local filesystem.
By default, they are put in the system temporary directory with a prefix of config-repo-.
On linux, for example, it could be /tmp/config-repo-<randomid>.
Some operating systems routinely clean out temporary directories.
@@ -256,14 +260,14 @@ In this way, you can segregate the directories in the path and choose a strategy
Thus, the default behaviour with no placeholders is the same as adding a search location ending with /{label}/.
For example, file:/tmp/config is the same as file:/tmp/config,file:/tmp/config/{label}.
This behavior can be disabled by setting spring.cloud.config.server.native.addLabelLocations=false.
2.1.4 Vault Backend
Spring Cloud Config Server also supports Vault as a backend.
Vault is a tool for securely accessing secrets.
-A secret is anything that to which you want to tightly control access, such as API keys, passwords, certificates, and other sensitive information. Vault provides a unified interface to any secret while providing tight access control and recording a detailed audit log.
To enable the config server to use a Vault backend, you can run your config server with the vault profile.
+A secret is anything that to which you want to tightly control access, such as API keys, passwords, certificates, and other sensitive information. Vault provides a unified interface to any secret while providing tight access control and recording a detailed audit log.
To enable the config server to use a Vault backend, you can run your config server with the vault profile.
For example, in your config server’s application.properties, you can add spring.profiles.active=vault.
By default, the config server assumes that your Vault server runs at http://127.0.0.1:8200.
It also assumes that the name of backend is secret and the key is application.
All of these defaults can be configured in your config server’s application.properties.
The following table describes configurable Vault properties:
Name
Default Value
host
127.0.0.1
port
8200
scheme
http
backend
secret
defaultKey
application
profileSeparator
,
kvVersion
1
skipSslValidation
false
timeout
5
Important
All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault.
All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentRepository.
Vault 0.10.0 introduced a versioned key-value backend (k/v backend version 2) that exposes a different API than earlier versions, it now requires a data/ between the mount path and the actual context path and wraps secrets in a data object. Setting kvVersion=2 will take this into account.
With your config server running, you can make HTTP requests to the server to retrieve
values from the Vault backend.
-To do so, you need a token for your Vault server.
First, place some data in you Vault, as shown in the following example:
Properties written to secret/application are available to all applications using the Config Server.
An application with the name, myApp, would have any properties written to secret/myApp and secret/application available to it.
-When myApp has the dev profile enabled, properties written to all of the above paths would be available to it, with properties in the first path in the list taking priority over the others.
2.1.5 Accessing Backends Through a Proxy
The configuration server can access a Git or Vault backend through an HTTP or HTTPS proxy. This behavior is controlled for either Git or Vault by settings under proxy.http and proxy.https. These settings are per repository, so if you are using a composite environment repository you must configure proxy settings for each backend in the composite individually. If using a network which requires separate proxy servers for HTTP and HTTPS URLs, you can configure both the HTTP and the HTTPS proxy settings for a single backend.
The following table describes the proxy configuration properties for both HTTP and HTTPS proxies. All of these properties must be prefixed by proxy.http or proxy.https.
Table 2.2. Proxy Configuration Properties
Property Name
Remarks
host
The host of the proxy.
port
The port with which to access the proxy.
nonProxyHosts
Any hosts which the configuration server should access outside the proxy. If values are provided for both proxy.http.nonProxyHosts and proxy.https.nonProxyHosts, the proxy.http value will be used.
username
The username with which to authenticate to the proxy. If values are provided for both proxy.http.username and proxy.https.username, the proxy.http value will be used.
password
The password with which to authenticate to the proxy. If values are provided for both proxy.http.password and proxy.https.password, the proxy.http value will be used.
The following configuration uses an HTTPS proxy to access a Git repository.
spring:
+When myApp has the dev profile enabled, properties written to all of the above paths would be available to it, with properties in the first path in the list taking priority over the others.
2.1.5 Accessing Backends Through a Proxy
The configuration server can access a Git or Vault backend through an HTTP or HTTPS proxy. This behavior is controlled for either Git or Vault by settings under proxy.http and proxy.https. These settings are per repository, so if you are using a composite environment repository you must configure proxy settings for each backend in the composite individually. If using a network which requires separate proxy servers for HTTP and HTTPS URLs, you can configure both the HTTP and the HTTPS proxy settings for a single backend.
The following table describes the proxy configuration properties for both HTTP and HTTPS proxies. All of these properties must be prefixed by proxy.http or proxy.https.
Table 2.2. Proxy Configuration Properties
Property Name
Remarks
host
The host of the proxy.
port
The port with which to access the proxy.
nonProxyHosts
Any hosts which the configuration server should access outside the proxy. If values are provided for both proxy.http.nonProxyHosts and proxy.https.nonProxyHosts, the proxy.http value will be used.
username
The username with which to authenticate to the proxy. If values are provided for both proxy.http.username and proxy.https.username, the proxy.http value will be used.
password
The password with which to authenticate to the proxy. If values are provided for both proxy.http.password and proxy.https.password, the proxy.http value will be used.
The following configuration uses an HTTPS proxy to access a Git repository.
To use a key in a file (such as an RSA public key for encryption), prepend
the key value with "@" and provide the file path, as shown in the following example:
$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub
AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...
Note
The --key argument is mandatory (despite having a -- prefix).
2.5 Key Management
The Config Server can use a symmetric (shared) key or an asymmetric one (RSA key pair).
-The asymmetric choice is superior in terms of security, but it is often more convenient to use a symmetric key since it is a single property value to configure in the bootstrap.properties.
To configure a symmetric key, you need to set encrypt.key to a secret String (or use the ENCRYPT_KEY environment variable to keep it out of plain-text configuration files).
To configure an asymmetric key, you can either set the key as a PEM-encoded text value (in encrypt.key) or use a keystore (such as the keystore created by the keytool utility that comes with the JDK).
-The following table describes the keystore properties:
Property
Description
encrypt.keyStore.location
Contains a Resource location
encrypt.keyStore.password
Holds the password that unlocks the keystore
encrypt.keyStore.alias
Identifies which key in the store to use
The encryption is done with the public key, and a private key is
+The asymmetric choice is superior in terms of security, but it is often more convenient to use a symmetric key since it is a single property value to configure in the bootstrap.properties.
To configure a symmetric key, you need to set encrypt.key to a secret String (or use the ENCRYPT_KEY environment variable to keep it out of plain-text configuration files).
Note
You cannot configure an asymmetric key using encrypt.key.
To configure an asymmetric key use a keystore (e.g. as
+created by the keytool utility that comes with the JDK). The
+keystore properties are encrypt.keyStore.* with * equal to
Property
Description
encrypt.keyStore.location
Contains a Resource location
encrypt.keyStore.password
Holds the password that unlocks the keystore
encrypt.keyStore.alias
Identifies which key in the store to use
The encryption is done with the public key, and a private key is
needed for decryption.
Thus, in principle, you can configure only the public key in the server if you want to only encrypt (and are prepared to decrypt the values yourself locally with the private key).
In practice, you might not want to do decrypt locally, because it spreads the key management process around all the clients, instead of
diff --git a/multi/multi_spring-cloud-config.html b/multi/multi_spring-cloud-config.html
index ec1257db..7cf033d5 100644
--- a/multi/multi_spring-cloud-config.html
+++ b/multi/multi_spring-cloud-config.html
@@ -1,3 +1,3 @@
![[Note]](images/note.png)
![[Warning]](images/warning.png)
![[Important]](images/important.png)