APIClarity installation: Improve your API security posture

Let’s get you started using APIClarity to strengthen the API security posture of your cloud-native applications! 

In this blog, we’ll walk through the steps to install APIClarity in a Kubernetes cluster and configure it to monitor API calls. See the APIClarity series introduction blog for a high-level description of APIClarity functionality, and the APIClarity architecture blog for more in-depth coverage.

The prerequisites of better API security through APIClarity

• A running Kubernetes cluster 
  • This blog assumes you’ve already got a Kubernetes cluster up and running. Here, I’m using an EKS cluster. 
• Service mesh installed  
  • A service mesh is needed for APIClarity to monitor internal API traffic (i.e. API calls between your application microservices). Both Istio and Kuma are supported. I’m using Istio for our purposes here. 
• A microservice application 
  • APIClarity monitors API traffic for a microservice application. We’ll use Sock Shop as the sample application. 

Install the microservice application

Install your microservice application and enable service-mesh sidecar injection for the application namespace. 

Let’s install Sock Shop. Run the following commands for your cluster: 

# create sock shop namespace 
kubectl create namespace sock-shop 

# label it for Istio auto-injection 
kubectl label namespaces sock-shop istio-injection=enabled 

# apply the manifest to install sock shop 
kubectl apply -f https://raw.githubusercontent.com/microservices-demo/microservices-demo/master/deploy/kubernetes/complete-demo.yaml 

# check the status of pods in sock-shop namespace 
kubectl get pods -n sock-shop 

Note that there are two pods for each microservice, one for the microservice itself and one for the service mesh sidecar. For example, this is my output: 

$ kubectl get pods -n sock-shop  
NAME                            READY   STATUS    RESTARTS   AGE 
carts-5dc994cf5b-4rhfj          2/2     Running   0          44h 
carts-db-556cbbd5fb-64qls       2/2     Running   0          44h 
catalogue-b7b968c97-b9k8p       2/2     Running   0          44h 
catalogue-db-f7547dd6-smzk2     2/2     Running   0          44h 
front-end-848c97475d-b7sl8      2/2     Running   0          44h 
orders-7d47794476-9fjsx         2/2     Running   0          44h 
orders-db-bbfb8f8-7ndr6         2/2     Running   0          44h 
payment-77bd4bbdf6-hkzh7        2/2     Running   0          44h 
queue-master-6d4cf8c4ff-pzk68   2/2     Running   0          44h 
rabbitmq-9dd69888f-6lzfh        3/3     Running   0          44h 
session-db-7d9d77c495-zngsn     2/2     Running   0          44h 
shipping-67fff9d476-t87jw       2/2     Running   0          44h 
user-7b667cd8d-q8bg8            2/2     Running   0          44h 
user-db-5599d45948-vxpq6        2/2     Running   0          44h 

Note: Because I’m installing Sock Shop on EKS, I needed to change the service type from NodePort to LoadBalancer in order to access the Sock Shop UI later on. 

# replace “NodePort” with “LoadBalancer” 
kubectl edit svc -n sock-shop front-end 

Install APIClarity 

Next, we’ll install APIClarity and configure it to monitor the application namespace (e.g. “sock-shop” in this example). 

# add APIClarity helm repo 
helm repo add apiclarity https://openclarity.github.io/apiclarity 

# install APIClarity  
helm install --set 'trafficSource.envoyWasm.enabled=true' --set 'trafficSource.envoyWasm.namespaces={sock-shop}' --create-namespace apiclarity apiclarity/apiclarity -n apiclarity 

# check the status of pods in APIClarity namespace 
kubectl get pods -n apiclarity 

Notice that the above install command is enabling WebAssembly envoy filters for the traffic sources (in this case, for the Sock Shop microservices). 

Here is my example output: 

$ kubectl get pods -n apiclarity 
NAME                                     READY   STATUS    RESTARTS   AGE 
apiclarity-apiclarity-84874df754-hlh98   1/1     Running   0          44h 
apiclarity-apiclarity-postgresql-0       1/1     Running   0          44h 

Verify that the APIClarity server pod and the PostgreSQL database pod are running.  

Create service URL (if needed) 

Next, we’ll create a service URL for the APIClarity service so we can access the UI.  For EKS, this means we’ll create a LoadBalancer service for APIClarity. YMMV on other platforms. 

# create yaml file for load balancer 
cat > lb-apiclarity.yaml << EOF 
apiVersion: v1 
kind: Service 
metadata:  
  name: lb-apiclarity 
  labels: 
    app: apiclarity-apiclarity 
spec: 
  selector: 
    app: apiclarity-apiclarity 
  type: LoadBalancer 
  ports:  
  - name: http 
    port: 8080 
    targetPort: 8080 
    protocol: TCP 
EOF 

# install load balancer service for APIClarity 
kubectl apply -f lb-apiclarity.yaml -n apiclarity 

Access the UIs

Now you should be able to access the UIs for both APIClarity and Sock Shop. For EKS, get the service URLs for both the Sock Shop front-end service and for APIClarity. 

To access the Sock Shop UI: 

export FRONTENDIP=$(kubectl get service -n sock-shop front-end -o jsonpath='{.status.loadBalancer.ingress[0].hostname}') 

echo $FRONTENDIP 

Point your browser at http://<FRONTENDIP> to access the Sock Shop UI. Any clicking around that you do on the application UI will create API traffic that APIClarity will capture and assess. 

To access the APIClarity UI: 

export APICLARITYIP=$(kubectl get service -n apiclarity lb-apiclarity -o jsonpath='{.status.loadBalancer.ingress[0].hostname}') 

echo $APICLARITYIP 

Point your browser at http://<APICLARITYIP>:8080 to access the APIClarity UI. 

Generate traffic 

If manually clicking around in the Sock Shop UI isn’t generating enough API traffic, try using a Locust load test to generate some (this is specific to Sock Shop, but you could do something similar for your own application). Run this command from anywhere that has reachability to the Sock Shop front-end service URL: 

docker run --net=host weaveworksdemos/load-test -h <FRONTENDIP>:80 -r 100 -c 2

Note that c specifies the number of clients, and r specifies the number of API requests to generate. 

Better API security clarity with the right tools

That’s it – you're up and running! Play around with APIClarity and see what it can do to strengthen your applications' API security. And if you want to know more, read more in our APIClarity Overview Series below:

APIClarity overview series:

• Introduction
• Installation
• Architecture

APIClarity how-to series:

• Uploading an OpenAPI Spec
• Reconstructing an OpenAPI Spec
• Detecting Shadow APIs
• Detecting Zombie APIs
• Detecting BFLAs
• Using the Trace Analyzer

In your travels, if you think of new features that would be great in APIClarity, feel free to contribute to the code and make it even better. It’s open source, after all! 

This concludes the APIClarity Overview Blog Series. Next up is the How-To Series where we’ll work through how to use many of the features of APIClarity.  

Anne McCormick is a cloud architect and open-source advocate at Outshift, formerly Cisco’s Emerging Technology & Incubation organization.