Introduction

rApp is a combination of microservice & platform service components. The PF components could be Policy, Service Orchestrator, etc.

When the rApp is installed, it requires certain level of composition work to wire all the components & microservices in rApp.

A simple rApp can be imagined as the combination of below,

1. one or more microservice
2. Policy configuration
3. Camunda Workflow

Tools Used

A study is done to understand how rApp behaves in the Nonrtric & SMO environment. For this analysis we need below components as prerequisite,

1. Kong Gateway
2. Istio
3. Keycloak
4. Network Policy - Calico
5. Nonrtric functions - ECS & Policy Service

Kong Gateway

Kong is an open-source API gateway. More information on Kong installation & configuration can be found at https://docs.konghq.com/gateway-oss/2.6.x/kong-for-kubernetes/install/

Istio

Istio is an open source service mesh which provides extensive control over traffic flow between the services. More information can be found at https://istio.io/latest/docs/setup/install/istioctl/

Keycloak

Keycloak is an open source identity & access management solution. Further information can be found at https://www.keycloak.org/docs/latest/getting_started/

Network policy

Kubernetes supports different network policies like Calico, Cilium. For this study we have used Calico https://docs.projectcalico.org/getting-started/kubernetes/helm

Nonrtric

Install the nonrtric functions and Make sure the sidecar injection is enabled for nonrtric namespace,

kubectl label namespace nonrtric istio-injection=enabled --overwrite

Once the sidecar injection is enabled in nonrtric namespace, the envoy sidecar is injected into all the pods in nonrtric.

kubectl -n nonrtric get pod

NAME                               READY   STATUS    RESTARTS   AGE
a1-sim-osc-0                       2/2     Running   0          2d16h
controlpanel-5f866754f4-8lqqz      1/1     Running   0          24d
enrichmentservice-0                2/2     Running   0          24d
nonrtricgateway-675f4c8b66-g5vm4   2/2     Running   0          2d16h
policymanagementservice-0          2/2     Running   33         2d16h

Open the Istio console to view the traffic flow between services in nonrtric namespace. 

As you can see from the above image, there is a network traffic between Policy Management Service, A1 Simulator (previously called Near-RT RIC A1 Interface) & DMaaP. The unknown here represents the postman request to the Enrichment Service.

Configure Istio & Keycloak

We use Keycloak as the identity & access management system and Istio connects to Keycloak over OIDC (OpenID Connect). 

For the analysis purpose, the Enrichment Service is configured with JWT token so that the envoy proxy will detect the incoming request and validates the JWT token with Keycloak. If the token is invalid or not present in the request, the access is denied.

Both the Policy Management Service & Enrichment Service endpoint is configured in the Kong gateway. Here Kong gateway acts as the R1 Interface, which means all these services can only be accessed through Kong gateway.

Keycloak Realm

Follow the Keycloak guideline to create Realm, user, role and assign the user to the role that you have created. Once this is done add the realm configuration as policy to the Istio config

Istio Policy

Create the RequestAuthentication & Auhorisation Policy in Istio as shown below.

RequestAuthentication:

AuthorizationPolicy:

As you can see from the policy config, the rule is applied on Enrichment Service. Any call to Enrichment Service, the envoy proxy will apply this rule and invoke the Keycloak over OIDC to authenticate the JWT.

Network Policy

There are various open source network policy libraries available and in this analysis Calico is used. When the rApp is installed in the environment, the nonrtric framework will apply the DENY_ALL rule to all the microservices of the rApp.

Note: It is still unclear how the network policy or network traffic restriction can be applied over Platform functions like Policy or SO components.

More fine grained traffic restriction can be applied on the later stage of the life cycle of the rApp microservice.

Introduction

rApp is a combination of microservice & platform service components. The PF components could be Policy, Service Orchestrator, etc.

When the rApp is installed, it requires certain level of composition work to wire all the components & microservices in rApp.

A simple rApp can be imagined as the combination of below,

1. one or more microservice
2. Policy configuration
3. Camunda Workflow

Tools Used

A study is done to understand how rApp behaves in the Nonrtric & SMO environment. For this analysis we need below components as prerequisite,

1. Kong Gateway
2. Istio
3. Keycloak
4. Network Policy - Calico
5. Nonrtric functions - ECS & Policy Service

Kong Gateway

Kong is an open-source API gateway. More information on Kong installation & configuration can be found at https://docs.konghq.com/gateway-oss/2.6.x/kong-for-kubernetes/install/

Istio

Istio is an open source service mesh which provides extensive control over traffic flow between the services. More information can be found at https://istio.io/latest/docs/setup/install/istioctl/

Keycloak

Keycloak is an open source identity & access management solution. Further information can be found at https://www.keycloak.org/docs/latest/getting_started/

Network policy

Kubernetes supports different network policies like Calico, Cilium. For this study we have used Calico https://docs.projectcalico.org/getting-started/kubernetes/helm

Nonrtric

Install the nonrtric functions and Make sure the sidecar injection is enabled for nonrtric namespace,

kubectl label namespace nonrtric istio-injection=enabled --overwrite

Once the sidecar injection is enabled in nonrtric namespace, the envoy sidecar is injected into all the pods in nonrtric.

kubectl -n nonrtric get pod

NAME                               READY   STATUS    RESTARTS   AGE
a1-sim-osc-0                       2/2     Running   0          2d16h
controlpanel-5f866754f4-8lqqz      1/1     Running   0          24d
enrichmentservice-0                2/2     Running   0          24d
nonrtricgateway-675f4c8b66-g5vm4   2/2     Running   0          2d16h
policymanagementservice-0          2/2     Running   33         2d16h

Open the Istio console to view the traffic flow between services in nonrtric namespace. 

As you can see from the above image, there is a network traffic between Policy Management Service, A1 Simulator & DMaaP. The unknown here represents the postman request to the Enrichment Service.

Configure Istio & Keycloak

We use Keycloak as the identity & access management system and Istio connects to Keycloak over OIDC (OpenID Connect). 

For the analysis purpose, the Enrichment Service is configured with JWT token so that the envoy proxy will detect the incoming request and validates the JWT token with Keycloak. If the token is invalid or not present in the request, the access is denied.

Both the Policy Management Service & Enrichment Service endpoint is configured in the Kong gateway. Here Kong gateway acts as the R1 Interface, which means all these services can only be accessed through Kong gateway.

Keycloak Realm

Follow the Keycloak guideline to create Realm, user, role and assign the user to the role that you have created. Once this is done add the realm configuration as policy to the Istio config

Istio Policy

Create the RequestAuthentication & Auhorisation Policy in Istio as shown below.

RequestAuthentication:

AuthorizationPolicy:

As you can see from the policy config, the rule is applied on Enrichment Service. Any call to Enrichment Service, the envoy proxy will apply this rule and invoke the Keycloak over OIDC to authenticate the JWT.

Network Policy

There are various open source network policy libraries available and in this analysis Calico is used. When the rApp is installed in the environment, the nonrtric framework will apply the DENY_ALL rule to all the microservices of the rApp.

Note: It is still unclear how the network policy or network traffic restriction can be applied over Platform functions like Policy or SO components.

More fine grained traffic restriction can be applied on the later stage of the life cycle of the rApp microservice.