Preface
To be able to use it, you must first understand it. I am too lazy to draw pictures, so I can draw pictures from the online big guys. The structure of springcloud is as shown in the figure:
Application scenarios of microservice architecture:
1. System split, multiple subsystems
2. Each subsystem can deploy multiple applications, and load balancing between applications is implemented
3. A service registration center is required, and all services are registered in the registration center. Load balancing is also achieved by using certain strategies for services registered in the registration center.
4. All clients access the backend services through the same gateway address. Through routing configuration, the gateway determines which service handles a URL request. Load balancing is also used when forwarding requests to the service.
5. Sometimes services also need to access each other. For example, there is a user module, and other services need to obtain user data of user services when processing some services.
6. A circuit breaker is needed to handle timeouts and errors during service calls in a timely manner to prevent the overall system from being paralyzed due to problems with one of the services.
7. A monitoring function is also needed to monitor the time spent on each service call, etc.
introduction
In microservice architecture, we usually adopt the DevOps organization method to reduce the huge costs caused by communication between teams to accelerate the delivery capabilities of microservice applications. This makes the online information originally controlled by the operation and maintenance team handed over to members of the microservice organization to maintain for themselves, which will include a large amount of sensitive information, such as the database account and password. Obviously, it is very dangerous if we directly store sensitive information in plaintext in the configuration file of the microservice application. In response to this problem, Spring Cloud Config provides the ability to encrypt and decrypt properties to protect the information in the configuration file. For example, the following example:
spring.datasource.username=didispring.datasource.password={cipher}dba6505baa81d78bd08799d8d4429de499bd4c2053c05f029e7cfbf143695f5bIn Spring Cloud Config, the content is marked as an encrypted value by using the {cipher} prefix in front of the attribute value. When the microservice client loads the configuration, the configuration center will automatically decrypt the value with the {cipher} prefix. Through the implementation of this mechanism, the operation and maintenance team can safely give the encrypted resources of the online information to the microservice team without worrying about the leakage of these sensitive information. Let’s introduce how to use this function in the configuration center.
Prerequisites for use
When using Spring Cloud Config's encryption and decryption function, there is a necessary prerequisite that we need to pay attention to. To enable this feature, we need to install an unlimited JCE version (Unlimited Strength Java Cryptography Extension) in the runtime of the configuration center. Although the JCE function is available in JRE, the default version with length limitation is used. We can download it from Oracle's official website. It is a compressed package. After decompression, you can see the following three files:
README.txtlocal_policy.jarUS_export_policy.jar
We need to copy the local_policy.jar and US_export_policy.jar files to the $JAVA_HOME/jre/lib/security directory to overwrite the original default content. At this point, the preparations for encryption and decryption are completed.
Related Endpoints
After completing the JCE installation, you can try to start the Configuration Center. In the console, some configuration center-specific endpoints will be output, mainly including:
You can try to access the /encrypt/status endpoint via GET request, and we will get the following:
{ "description": "No key was installed for encryption service", "status": "NO_KEY"}This return indicates that the encryption function of the current configuration center cannot be used yet because the corresponding key is not configured for the encryption service.
Configuration key
We can directly specify the key information (symmetry key) in the configuration file through the encrypt.key property, for example:
encrypt.key=didispace
After adding the above configuration information, restart the configuration center and access the /encrypt/status endpoint. We will get the following content:
{ "status": "OK"}At this time, the encryption and decryption function in our configuration center is ready to be used. You might as well try to access the /encrypt and /decrypt endpoints for encryption and decryption functions. Note that both endpoints are POST requests, and the encryption and decryption information need to be sent through the request body. For example, taking the curl command as an example, we can call the encryption and decryption endpoints in the following ways:
$ curl localhost:7001/encrypt -d didispace3c70a809bfa24ab88bcb5e1df51cb9e4dd4b8fec88301eb7a18177f1769c849ae9c9f29400c920480be2c99406ae28c7$ curl localhost:7001/decrypt -d 3c70a809bfa24ab88bcb5e1df51cb9e4dd4b8fec88301eb7a18177f1769c849ae9c9f29400c920480be2c99406ae28c7didispace
Here, we use symmetric encryption to specify the implementation method of the key by configuring the encrypt.key parameter. This method is relatively simple to implement, and only one parameter is required. In addition, we can also use the environment variable ENCRYPT_KEY to configure it to allow the key information to be stored externally.
Asymmetric encryption
Spring Cloud Config's configuration center can not only use symmetry encryption, but also asymmetric encryption (such as RSA key pairs). Although the key generation and configuration of asymmetric encryption are relatively complex, it has higher security. Below, let’s introduce in detail how to use asymmetric encryption.
First, we need to generate the key pair through the keytool tool. keytool is a key and certificate management tool in the JDK. It enables users to manage their own public/private key pairs and related certificates for (via digital signature) self-authentication (user authenticates itself to other users/services) or data integrity and authentication services. This tool is included in versions after JDK 1.4, and its location is: %JAVA_HOME%/bin/keytool.exe.
The specific commands for generating the key are as follows:
$ keytool -genkeypair -alias config-server -keyalg RSA -keystore config-server.keystore
Enter the keystore password:
Enter the new password again:
What is your first and last name?
[Unknown]: zhaiyongchao
What is your organizational unit name?
[Unknown]: company
What is your organization name?
[Unknown]: organization
What is the name of your city or region?
[Unknown]: city
What is the name of your province/city/autonomous region?
[Unknown]: province
What is the two-letter country code for this unit?
[Unknown]: china
Is CN=zhaiyongchao, OU=company, O=organization, L=city, ST=province, C=china correct?
[No]: yEnter the key password for <config-server>
(If the password is the same as the keystore, press Enter):
Enter the new password again:
In addition, if we do not want to enter those prompt information step by step, we can use -dname to specify it directly, while the keystore password and key password can be specified directly using -storepass and -keypass. Therefore, we can directly create the same keystore as the above command through the following command:
$ keytool -genkeypair -alias config-server -keyalg RSA / -dname "CN=zhaiyongchao, OU=company, O=organization, L=city, ST=province, C=china" / -keypass 222222 / -keystore config-server.keystore / -storepass 111111 /
By default, the key created by the above command is only valid for 90 days. If we want to adjust its validity period, we can do it by adding the -validity parameter. For example, we can extend the validity period of the key to one year through the following command:
$ keytool -genkeypair -alias config-server -keyalg RSA / -dname "CN=zhaiyongchao, OU=company, O=organization, L=city, ST=province, C=china" / -keypass 222222 / -keystore config-server.keystore / -storepass 111111 / -validity 365 /
The above three command generation methods will eventually generate a config-server.keystore file in the current execution directory of the command. Next, we need to save it in a location in the file system of the configuration center, for example, place it in the current user directory, and then add relevant configuration information to the configuration center:
encrypt.key-store.location=file://${user.home}/config-server.keystoreencrypt.key-store.alias=config-serverencrypt.key-store.password=111111encrypt.key-store.secret=222222If we place the config-server.keystore in the src/main/resource directory in the configuration center, we can also configure it directly like this: encrypt.key-store.location=config-server.keystore. In addition, the configuration information of asymmetric encryption can also be configured through environment variables, and their corresponding specific variable names are as follows:
ENCRYPT_KEY_STORE_LOCATIONENCRYPT_KEY_STORE_ALIASENCRYPT_KEY_STORE_PASSWORDENCRYPT_KEY_STORE_SECRET
Configuring keystore-related information through environment variables can achieve better security, so it is a good choice for us to store sensitive password information in the environment variables in the configuration center.
Summarize
The above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support to Wulin.com.