concept Order Processing microservice in category microservice

appears as: Order Processing microservice, The Order Processing microservice, Order Processing microservice, Order Processing microservices
Microservices Security in Action

This is an excerpt from Manning's book Microservices Security in Action.

A log can be any event you record that corresponds to a given service. A log, for example, can be an audit trail that says that the Order Processing microservice accessed the Inventory microservice to update the inventory on April 15th, 2020, at 10:15.12 p.m. on behalf of the user Peter.

In this section, we’re going to deploy the Order Processing microservice in Kubernetes. As in figure 11.1, the Order Processing microservice trusts the tokens issued by the STS, which we now have running in Kubernetes. Once the client application passes the JWT to the Order Processing microservice, the Order Processing microservice talks to the STS to retrieve its public key to validate the signature of the JWT. This is the only communication that happens between the Order Processing microservice and the STS. In fact, to be precise, the Order Processing microservice doesn’t wait until it gets a request to talk to the STS; it talks to the STS at startup to get its public key and stores it in memory.

In chapter 10, we explained how to run the Order Processing microservice as a Docker container. This is the Docker command we used in section 10.4, which externalized the application.properties file, the keystore (keystore.jks), the trust store (trust-store.jks), the keystore credentials, and the trust store credentials. You don’t need to run this command now; if you want to try it out, follow the instructions in chapter 10:

\> export JKS_SOURCE="$(pwd)/keystores/keystore.jks"

\> export JKS_TARGET="/opt/keystore.jks"
\> export JWT_SOURCE="$(pwd)/keystores/jwt.jks"
\> export JWT_TARGET="/opt/jwt.jks"
\> export APP_SOURCE="$(pwd)/config/application.properties"
\> export APP_TARGET="/opt/application.properties"

\> docker run -p 8443:8443 \
--name sts --net manning-network  \
--mount type=bind,source="$JKS_SOURCE",target="$JKS_TARGET" \
--mount type=bind,source="$JWT_SOURCE",target="$JWT_TARGET" \
--mount type=bind,source="$APP_SOURCE",target="$APP_TARGET" \
-e KEYSTORE_SECRET=springboot \
-e JWT_KEYSTORE_SECRET=springboot \
prabath/order-processing:v1

To deploy the Order Processing microservice in Kubernetes, we need to create a Kubernetes Deployment and a Service. This is similar to what we did before when deploying the STS in Kubernetes.

In this section, we introduce another microservice, the Inventory microservice, to our Kubernetes environment and see how service-to-service communication works (figure 11.3). Here, when you invoke the Order Processing microservice with a JWT obtained from the STS, the Order Processing microservice internally talks to the Inventory microservice.

Figure 11.3 STS issues a JWT access token to the client application, and the client application uses it to access the Order Processing microservice on behalf of the user, Peter. The Order Processing microservice uses the same JWT it got from the client application to access the Inventory microservice.

Because the process of deploying the Inventory microservice on Kubernetes is similar to the process we followed while deploying the Order Processing microservice, we won’t go into details. The only key difference is that the Kubernetes Service corresponding to the Inventory microservice is of ClusterIP type (or the default Service type) because we don’t want external client applications to directly access it.

sitemap

Unable to load book!

The book could not be loaded.

(try again in a couple of minutes)

manning.com homepage
test yourself with a liveTest