Many of those features are covered by Spring Boot, which we build on in Spring Cloud. Some more are delivered by Spring Cloud as two libraries: Spring Cloud Context and Spring Cloud Commons. Spring Cloud Context provides utilities and special services for the ApplicationContext of a Spring Cloud application (bootstrap context, encryption, refresh scope and environment endpoints). Spring Cloud Commons is a set of abstractions and common classes used in different Spring Cloud implementations (eg. Spring Cloud Netflix vs. Spring Cloud Consul).
If you are getting an exception due to "Illegal key size" and you are using Sun’s JDK, you need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. See the following links for more information:
+Java 6 JCE Link http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
+Java 7 JCE Link http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
+Java 8 JCE Link http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
+Extract files into JDK/jre/lib/security folder (whichever version of JRE/JDK x64/x86 you are using).
+Environment. To use the encryption
features in a client you need to include Spring Security RSA in your
classpath (Maven co-ordinates
"org.springframework.security:spring-security-rsa") and you also need
-the full strength JCE extensions in your JVM (google it and download
-from Oracle).
+the full strength JCE extensions in your JVM.
+
+include::jce.adoc
org.springframework.cloud:spring-cloud-starter. There is also a
+org.springframework.cloud:spring-cloud-starter-config. There is also a
parent pom and BOM (spring-cloud-starter-parent) for Maven users and a
Spring IO version management properties file for Gradle and Spring CLI
users. Example Maven configuration:
@@ -1150,7 +1173,7 @@ users. Example Maven configuration:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
- <version>1.1.7.RELEASE</version>
+ <version>1.2.3.RELEASE</version>
<relativePath /> <!-- lookup parent from repository -->
</parent>
@@ -1159,7 +1182,7 @@ users. Example Maven configuration:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-parent</artifactId>
- <version>1.0.0.BUILD-SNAPSHOT</version>
+ <version>1.0.1.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
@@ -1169,7 +1192,7 @@ users. Example Maven configuration:
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
- <artifactId>spring-cloud-starter</artifactId>
+ <artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
@@ -1394,6 +1417,38 @@ and in the "foo/" sub-directory and also any sub-directory whose name
begins with "bar".
By default the server clones remote repositories when configuration +is first requested. The server can be configured to clone the repositories +at startup. For example at the top level:
+spring: + cloud: + config: + server: + git: + uri: https://git/common/config-repo.git + repos: + team-a: + pattern: team-a-* + cloneOnStart: true + uri: http://git/team-a/config-repo.git + team-b: + pattern: team-b-* + cloneOnStart: false + uri: http://git/team-b/config-repo.git + team-c: + pattern: team-c-* + uri: http://git/team-a/config-repo.git+
In this example the server clones team-a’s config-repo on startup before it +accepts any requests. All other repositories will not be cloned until +configuration from the repository is requested.
+To use HTTP basic authentication on the remote repository add the "username" and "password" properties separately (not in the URL), e.g.
@@ -1477,7 +1532,7 @@ for an application namedapp, the default profile and
label provided by the EnvironmentRepository implementation.
You can configure the Health Indicator to check more appliations +
You can configure the Health Indicator to check more applications along with custom profiles and custom labels, e.g.
The server exposes /encrypt and /decrypt endpoints (on the
-assumption that these will be secured and only accessed by authorized
-agents). If the remote property sources contain encryted content
+
If the remote property sources contain encryted content
(values starting with {cipher}) they will be decrypted before
sending to clients over HTTP. The main advantage of this set up is
that the property values don’t have to be in plain text when they are
"at rest" (e.g. in a git repository). If a value cannot be decrypted
it is replaced with an empty string, largely to prevent cipher text
-being used as a password in Spring Boot autconfigured HTTP basic.
If you are setting up a remote config repository for config client @@ -1565,7 +1618,9 @@ instance:
secret password is protected.If you are editing a remote config file you can use the Config Server +
The server also exposes /encrypt and /decrypt endpoints (on the
+assumption that these will be secured and only accessed by authorized
+agents). If you are editing a remote config file you can use the Config Server
to encrypt values by POSTing to the /encrypt endpoint, e.g.
Take the encypted value and add the {cipher} prefix before you put
it in the YAML or properties file, and before you commit and push it
-to a remote, potentially insecure store.
/encypt and /decrypt
+endpoints also both accept paths of the form /*/{name}/{profiles}
+which can be used to control cryptography per application (name)
+and profile when clients call into the main Environment resource.
+|
+ Note
+ |
+
+to control the cryptography in this granular way you must also
+provide a @Bean of type TextEncryptorLocator that creates a
+different encryptor per name and profiles. The one that is provided
+by default does not do this.
+ |
+
The spring command line client (with Spring Cloud CLI extensions
@@ -1626,9 +1699,7 @@ it is just a single property value to configure.
To configure a symmetric key you just need to set encrypt.key to a
secret String (or use an enviroment variable ENCRYPT_KEY to keep it
-out of plain text configuration files). You can also POST a key value
-to the /key endpoint (but that won’t change any existing encrypted
-values in remote repositories).
To configure an asymmetric key you can either set the key as a
@@ -1690,6 +1761,57 @@ your application.yml for the Config Server:
In addition to the {cipher} prefix in encrypted property values, the
+Config Server looks for {name:value} prefixes (zero or many) before
+the start of the (Base64 encoded) cipher text. The keys are passed to
+a TextEncryptorLocator which can do whatever logic it needs to
+locate a TextEncryptor for the cipher. If you have configured a
+keystore (encrypt.keystore.location) the default locator will look
+for keys in the store with aliases as supplied by the "key" prefix,
+i.e. with a cipher text like this:
foo:
+ bar: `{cipher}{key:testkey}...`
+the locator will look for a key named "testkey". A secret can also be
+supplied via a {secret:…} value in the prefix, but if it is not
+the default is to use the keystore password (which is what you get
+when you build a keytore and don’t specify a secret). If you do
+supply a secret it is recommended that you also encrypt the secrets
+using a custom SecretLocator.
Key rotation is hardly ever necessary on cryptographic grounds if the
+keys are only being used to encrypt a few bytes of configuration data
+(i.e. they are not being used elsewhere), but occasionally you might
+need to change the keys if there is a security breach for instance. In
+that case all the clients would need to change their source config
+files (e.g. in git) and use a new {key:…} prefix in all the
+ciphers, checking beforehand of course that the key alias is available
+in the Config Server keystore.
|
+ Tip
+ |
+
+the {name:value} prefixes can also be added to plaintext posted
+to the /encrypt endpoint, if you want to let the Config Server
+handle all encryption as well as decryption.
+ |
+
The Config Server runs best as a standalone application, but if you @@ -1769,8 +1891,7 @@ an Exception.
The Config Service serves property sources from /{name}/{env}/{label}, where the default bindings in the
-client app are
The Config Service serves property sources from /{name}/{env}/{label}, where the default bindings in the client app are
* is "name", "env" or "label"). The "label" is useful for
rolling back to previous versions of configuration; with the default
Config Server implementation it can be a git label, branch name or
-commit id.
+commit id. Label can also be provided as a comma-separated list, in
+which case the items in the list are tried on-by-one until one succeeds.
+This can be useful when working on a feature branch, for instance,
+when you might want to align the config label with your branch, but
+make it optional (e.g. spring.cloud.config.label=myfeature,develop).
When a client registers with Eureka, it provide meta-data about itself +
When a client registers with Eureka, it provides meta-data about itself
such as host and port, health indicator URL, home page etc. Eureka
receives heartbeat messages from each instance belonging to a service.
If the heartbeat fails over a configurable timetable, the instance is
@@ -3644,6 +3769,16 @@ of AuthorizationCodeResourceDetails so all its properties can be sp
Google (and certain other 3rd party identity providers) is more strict
+about the token type name that is sent in the headers to the user info
+endpoint. The default is "Bearer" which suits most providers and
+matches the spec, but if you need to change it you can set
+spring.oauth2.resource.tokenType.
The SSO (and Resource Server) features use an OAuth2RestTemplate
@@ -3954,7 +4089,7 @@ ProxyAuthenticationProperties] for full details.