Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
Share
5 min read
Share
This blog is part of the APIClarity Overview Series.
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 introductory blog for a high-level description of APIClarity functionality, and the architecture blog for more in-depth coverage.
Install your microservice application, making sure to 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
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.
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
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.
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.
That’s it – you're up and running! Play around with APIClarity and see what it can do to strengthen your applications' API security.
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 in Cisco’s Emerging Technology & Incubation organization.
Get emerging insights on emerging technology straight to your inbox.
Discover why security teams rely on Panoptica's graph-based technology to navigate and prioritize risks across multi-cloud landscapes, enhancing accuracy and resilience in safeguarding diverse ecosystems.
The Shift is Outshift’s exclusive newsletter.
Get the latest news and updates on cloud native modern applications, application security, generative AI, quantum computing, and other groundbreaking innovations shaping the future of technology.