Building a secure service network with Red Hat Service Interconnect - Instructions

In this lab, you will use two OpenShift namespaces. In one namespace the Globex application is deployed. The other namespace is isolated from the rest of the cluster through a network policy (only egress allowed, no ingress) and that is where the Globex retail database is deployed. In the lab, you will create a service network between these two clusters, so that the Globex application can connect and use the database in the isolated namespace. Note that the database is not exposed to the outside world. It cannot be reached from other namespaces in the OpenShift cluster

1. Prepare your Development environment

1.1. Ensure lab readiness

Before your proceed it is critical that your lab environment is completely ready before executing the lab instructions.

Access the Workshop Deployer browser tab and check if the Launch new channels using Contract-First approach has turned green. This indicates that the module has been fully deployed and is ready to use.

Figure 1. Module Readiness on Workshop Deployer

2. Deployment overview: Globex application namespace

In a browser tab navigate to {openshift_cluster_console}[OpenShift console, window="console"]. If needed, login with your username and password ({user_name}/{user_password}).
If this is the first time you open the console, you will be directed to the Developer Perspective of the console, which shows you the different namespaces you have access to.

Click on the globex-skupper-{user_name} link to select the namespace you are going to use in this lab, and select Topology from the left menu.
Expect to see two deployments: The Globex retail application frontend (called globex-web, and running on Node.js) and the Globex retail application itself, called globex-store-app. Note that the Globex retail application is scaled down to zero pods. As the database is missing, the application would not start up correctly if scaled up. You will scale it up once the connection with the database running in the isolated namespace is established.
You can check the state of the application by clicking on the icon next to the Node.js deployment.

This opens a new browser tab pointing to the home page of the Globex retail application.
Click on the Cool Stuff Store link in the top menu. This opens a view of the Globex store catalog. If the application would run as expected, you should see a paginated listing of products. However in this case, you will see an empty list:

3. Deployment overview: Globex database namespace

In the Topology view, select the globex-skupper-db-{user_name} namespace from the drop down box at the top.
Expect to see the deployment for the Globex retail app database.
The globex-skupper-db-{user_name} namespace is isolated from other namespaces and the outside world by applying a Network Policy. To view the Network Policy:
- In the Developer Perspective of the OpenShift console, select Project from the menu on the left, and on the project overview page, select the Details tab. Click on the NetworkPolicies link to view the Network Policies installed in this namespace.
- The Network Policy overview page shows one Network Policy, named allow-same-namespace. Click on the name of the Network Policy to open the details page. Scroll down to see the rules defined for ingress traffic:
- The rule defines a whitelist for all pods within the globex-skupper-db-{user_name} namespace, blocking all other ingress traffic into the namespace. Thus pods in the globex-skupper-db-{user_name} can connect to each other, but connections from outside the namespace will be blocked.

4. Connect the Services with Red Hat Service Interconnect

Building a Service network between the two namespaces of the OpenShift cluster takes several steps:

Install Service Interconnect in both namespaces.
Create a connection token on one of the namespaces. In our scenario it is important that the token is created in the namespace where the globex application is running.
Use the token on the other namespace to create a link between the namespaces. In our scenario the link needs to be initiated in the isolated namespace. Egress from that namespace is allowed, so pods in the namespace can create a connection to other services running in (or outside) the cluster.
Expose services of one namespace on the other namespace. In this case, you will expose the Globex database on the isolated namespace, so that the Globex retail app can connect to it as if it were a local service.

4.1. Install Red Hat Service Interconnect: Globex application namespace

The easiest way to install Red Hat Service Interconnect in a namespace on OpenShift is through the skupper CLI (Skupper is the name of the open-source upstream project of Red Hat Service Interconnect). In this lab, the skupper cli is available through the OpenShift Command Line terminal, so that you don’t have to install it locally on your workstation.

Open the browser window pointing to the OpenShift Console at {openshift_cluster_console}[OpenShift console, window="console"]. Click on the icon on the top menu to open a terminal window.
Make sure to select the correct namespace from the drop-down box (globex-skupper-{user_name})

Click Start to start and open the terminal.
After a couple of seconds, the terminal is up and running. Also note the terminal deployment in the topology view (make sure to select the globex-skupper-{user_name} namespace in the project dropdown box).

If you prefer, you can maximize the terminal in a new browser tab by clicking on the icon.
In the terminal, check that you are logged in into the OpenShift cluster.
```
oc whoami
```
Output
```
{user_name}
```

Check that the skupper CLI is available in the terminal:

skupper version

Output

client version                 1.5.3-rh-5
transport version              not-found
controller version             not-found
config-sync version            not-found
flow-collector version         not-found'

Install the Red Hat Service Interconnect resources in the globex-skupper-{user_name} namespace:

skupper init -n globex-skupper-{user_name} --enable-console --enable-flow-collector --console-auth unsecured

Output

Waiting for status...
Skupper is now installed in namespace "globex-skupper-{user_name}".  Use 'skupper status' to get more information.

This installs 3 new components in the namespace: skupper-service-controller, skupper-router and skupper-prometheus, as you can see in the Topology view:
Service Interconnect also comes with its own console, which you can access by opening a new browser tab and navigating to {skupper_console_aws}[Service Interconnect, window="skupper"]. At the moment there is not a lot to see as we have only installed one side of the service network.

4.2. Install Red Hat Service Interconnect: Globex database namespace

The steps to install Service Interconnect on the isolated namespace are very similar to the ones you just performed.

From the OpenShift terminal window that you still have open from the previous step, install the Red Hat Service Interconnect resources (without the console this time) in the globex-skupper-db-{user_name} namespace.
```
skupper -n globex-skupper-db-{user_name} init
```
Output
```
Waiting for status...
Skupper is now installed in namespace "globex-skupper-db-{user_name}".  Use 'skupper status' to get more information.
```

To see the status of the skupper network:

skupper -n globex-skupper-db-{user_name} status

Output

Skupper is enabled for namespace "globex-skupper-db-{user_name}". It is not connected to any other sites. It has no exposed services.

4.3. Create a link between the two namespaces

To create a link between the two namespace, you create a token on one of the namespaces, and then use the token to create the link on the other namespace.

Navigate to the browser tab pointing to the OpenShift Web terminal.
Issue the following command:

skupper -n globex-skupper-{user_name} token create /tmp/skupper.token

Output

Token written to /tmp/skupper.token

If you want to have a look at the token that was created:

cat /tmp/skupper.token

Output

apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURMVENDQWhXZ0F3SUJBZ0lSQUxuRSsrMmNiYmlUMFZESWdyb2dXdm93RFFZSktvWklodmNOQVFFTEJRQXcKR2pFWU1CWUdBMVVFQXhNUGMydDFjSEJsY2kxemFYUmxMV05oTUI0WERUSXpNRFF5TlRFME1ETTFObG9YRFRJNApNRFF5TXpFME1ETTFObG93R2pFWU1CWUdBMVVFQXhNUGMydDFjSEJsY2kxemFYUmxMV05oTUlJQklqQU5CZ2txCmhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBclRjOVNBOEtPRlh2RWpWN2JYWWVRUytKRXFZRU52ZmgKblA5NHV0SGxVZWwvWEpyeW1lK3V2YzhjK21yRjBhVEdLZ2licGVab1JFcXdVWW9CR3ZMTXhOMEJXenlVNWlseQovcFRYMmthSGtJbDlVUzdYbDRaQ09hNHB4bDE2WnhVNDYxbU9uMDJQUDEwVVdUVFg2Vk9NQ2VEZEdOYlRTZ3BuCkdTMlEzS0JMMXRBa201cDdRRGYrMTRIdEl1ZGUvdzBySnFJc1RPbkJnSHlGVy9ZTlZKdlUyZ2I5WjRzRWEyUWsKY2E3MEF6Mkw2bnJkV1BiMVFnem1QQXBrSWc5K0hQSDVqYkZSNzNVYUpNbDR3ZVhzdTdNQmFUNDRJeG1FVCtBTApxS3BkTjlMaFFSb21wQ3ZETWFsQTdQamU4cWcvNWlkSFd4cEtFdi84VS9yTC9mbEpyNlZycndJREFRQUJvMjR3CmJEQU9CZ05WSFE4QkFmOEVCQU1DQXFRd0hRWURWUjBsQkJZd0ZBWUlLd1lCQlFVSEF3RUdDQ3NHQVFVRkJ3TUMKTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SFFZRFZSME9CQllFRkhITTdoS0JwSVFKK3FtZ2lmNUVld2NLZVE3dgpNQXNHQTFVZEVRUUVNQUtDQURBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQVdhaEtnVER0N3h3WnJjYTJaQXFYCk1ZZFV4RFk2NzI1anNLZTh0Ym1RbmVnZ21vcURDKzBXM2pGc0tYUnVEMXJJMmZTNFhRZHYxYUhzZnhuenkyOFMKVXdZQVFaRi9oTFFZRTNqYXhybkV0TmlJaE1KWGkyQ3BDN3ZvL2V6MDBWYzVxNmlKbms4eHBOelEyNlZzVk9ELwpBY2x4MG1sMDgyajRUc0tWZzVxemt0Z2xEK1FQRTNRcDViNzl5ZVg3UG80dW13Vm9jK3RlaHduNDY1Qy8remZqCks3ckZqZW1XZE9McFhIZHpPc3E4LzZWR1IzTUJCcnZBTjZ6MC95STdxZ3VJNGdCSDFxUzZ4Sm1rbW9PQXAxWU4Ka21HZXQvbk9ZVldzQW1nQTd4UGlVWTNxRUkrQWdCUGloeS9NR3FOaGpvYkRCS1J0OGVSdU9ESmJDdVNvRjhpcAo0UT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  password: Sko2akMzaDdIZDFyUDlCY0dzSlNSbkUx
kind: Secret
metadata:
  annotations:
    skupper.io/generated-by: eecb731d-3457-4a05-b5dc-7982bbf91a6b
    skupper.io/site-version: 1.5.2
    skupper.io/url: https://claims-globex-skupper-{user_name}.{openshift_subdomain}:443/9698eead-1a96-11ee-9dad-0a580a83003b
  creationTimestamp: null
  labels:
    skupper.io/type: token-claim
  name: 9698eead-1a96-11ee-9dad-0a580a83003b

This is actually an OpenShift secret which contains a certificate. This certificate will be used to setup a mTLS (mutual TLS) secured link between the two namespaces.

The next step is creating the link on the other namespace with the token. In a real life situation that probably requires to physically transfer the token to the other site. In this lab, you will create the link from the same terminal, but specifying the isolated namespace.

On the same terminal, create a link using the token:

skupper -n globex-skupper-db-{user_name} link create /tmp/skupper.token

Output

Site configured to link to https://claims-globex-skupper-{user_name}.{openshift_subdomain}:443/9698eead-1a96-11ee-9dad-0a580a83003b (name=link1)
Check the status of the link using 'skupper link status'.

To check the status of the link:

skupper -n globex-skupper-db-{user_name} link status

Output

Links created from this site:

         Link link1 is connected

Current links from other sites that are connected:

         There are no connected links

Finally, you need to expose the database service over the link. This will allow the Globex application to connect to the database as if it was a local service, while in reality the service is a proxy for the real service running in the isolated namespace.
```
skupper -n globex-skupper-db-{user_name} expose deployment/globex-db --port 5432
```
Output
```
deployment globex-db exposed as globex-db
```

You have established a secure link between the two namespaces, and exposed the globex-db service in the isolated namespace as a proxy service in the globex-skupper-{user_name} namespace.

There a couple of ways to verify this:

In the OpenShift terminal, use oc to get the services deployed in the globex-skupper-{user_name} namespace:

oc get service -n globex-skupper-{user_name}

Output

NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
globex-db                           ClusterIP   172.30.187.88            5432/TCP                     114s
globex-store-app                    ClusterIP   172.30.94.78             8080/TCP                     6h37m
globex-web                          ClusterIP   172.30.172.136           8080/TCP                     6h37m
skupper                             ClusterIP   172.30.250.157           8010/TCP,8080/TCP,8081/TCP   81m
skupper-router                      ClusterIP   172.30.252.101           55671/TCP,45671/TCP          81m
skupper-router-local                ClusterIP   172.30.49.91             5671/TCP                     81m
workspace207858d3e7d2450b-service   ClusterIP   172.30.2.112             4444/TCP                     93m

The globex-db service is the proxy service created by exposing the globex-db deployment in the isolated namespace over the service network.

You can also check out the globex-db service through the OpenShift console. Navigate to the browser tab pointing to the Developer perspective of the OpenShift console. Make sure to select the globex-skupper-{user_name} namespace from the drop-down box at the top.
On the left menu, select Project, and in the Inventory list click on Services.
This opens the list of Service resources in the namespace. Notice the globex-db service.

The Pod Selector indicates that this service is pointing to the Skupper router pod, which forwards the communication over the secure link to the real database service on the isolated namespace.
Finally, you can check the Service Interconnect console at {skupper_console_aws}. In the Topology section you’ll see a graphical representation of the Service InterConnect network.
The Sites tab shows the connected namespaces, globex-skupper-db-{user_name} and globex-skupper-{user_name}.

5. Verify the Service Interconnect network

At this point you can verify that the service network is actually working as expected. When scaling up the globex-store-app application to 1 pod, it should be able to connect to the database running on the isolated namespace through the service network.

In the browser tab pointing to the OpenShift console, select the Topology View on the globex-skupper-{user_name} namespace. Click in the center of the deployment of the globex-store-app application. This opens a side window with details about the deployment. Click on the Details tab.
To scale the deployment to 1 pod, click on the icon next to the empty circle representing the deployment.
After a while, the circle becomes dark blue, indicating a successful deployment. The globex-store-app application has 1 pod which successfully connected to the database over the service network.
Click on the icon next to the Node.js deployment.

This opens a new browser tab pointing to the home page of the Globex retail application.
Click on the Cool Stuff Store link in the top menu. This opens a view of the Globex store catalog. Expect to see a paginated listing of products from the Globex catalog.
The information on that page is retrieved from the database, demonstrating that the service network is working as expected. Feel free to navigate around the app to cause traffic between the application and the database.
You can also check the link between the two clusters in the Service Interconnect console at {skupper_console_aws}. In the Topology section, select the Components tab, which shows the connection between the globex-store-app deployment in the isolated namespace and the globex-db service which is proxied over the service network.

If you click on one of the two components in the component graph, you are redirected to the Components view which shows details about the connection:

6. Congratulations

Congratulations! You successfully used Red Hat Service Interconnect to build a secure service network between two services and allow application to connect and communicate over the secure network.

Please close all but the Workshop Deployer browser tab to avoid proliferation of browser tabs which can make working on other modules difficult.

Proceed to the Workshop Deployer to choose your next module.