Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
PRODUCT
6 min read
Published on 03/15/2023
Last updated on 06/18/2024
APIClarity overview series: Installation
Share
This blog is part of the APIClarity Overview Series.
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 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 2Note 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:
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.
Subscribe to
the Shift!
Get emerging insights on innovative technology straight to your inbox.
