API Discovery
API discovery helps in learning, searching, and identifying loopholes when app communicates via APIs especially in a large micro-services ecosystem. After discovery, the system analyzes the APIs, then will know how to secure the APIs from malicious requests.
Customer Challenges
With large ecosystems, integrations, and distributed microservices, there is a huge increase in the number of API attacks. Most of these API attacks authenticated users and are very hard to detect. Also, security controls for web apps are totally different than security controls for APIs. Customers increased adoption of microservice architecture has increased the complexity of managing, debugging, and securing applications. With microservices, all the traffic between apps is using REST/gRPC APIs that are multiplexed on the same network port (eg. HTTP 443) and as a result, the network level security and connectivity is not very useful anymore. With customers adopting a multi-cloud strategy, services might be residing on different cloud/vpc, so customers need a uniform way to apply app-level policies which will enforce zero trust API security across service-to-service communication.
Also, the SecOps team has an administrative overhead to manually track the changes to API’s in a multi-cloud environment. Dev/DevOps team needs an easier tool to debug the apps.
Solution Description
Volterra’s AI/ML learning engine uniquely discovers API endpoints used during a service-to-service communication. This feature provides users debugging capabilities for distributed apps that are deployed on a single cloud or across multiple clouds. API endpoints discovered could be used to create API-level security policy to enforce tighter service-to-service communication.
Also, the swagger schema helps in analyzing and debugging the request logs. Secops can download and use it for audit purposes. This also serves as an input to the third-party tools.
Step by step process to enable API discovery and auto-generation of swagger schema
There are mainly three steps in enabling the API discovery and downloading the swagger schema:
Step 1 . Enabling the API discovery which is to create an app-type config.
Step 2 . Deploying an application on Kubernetes and creating the HTTP load balancer.
Step 3 . Observing an app through service mesh graph and HTTP load balancer dashboard which includes downloading of swagger schema.
Let us see how to configure on VoltConsole:
Step 1
Create an application namespace under general namespace tab:
General > My Namespaces > Add name space.
Step 2
Next, we need to create an app type which is under the shared tab:
Shared > AI&ML > Add app type
Here, while creating a new app type, we need to enable the API discovery feature and markup setting to learn from direct traffic. Save and exit.
Step 3
Next, let's go to the app tab to deploy the app:
App > Applications >Virtual K8s > Add virtual K8s
While creating new virtual K8s, you give it a name and select ves-io-all-res as a virtual site.Save and exit.We have to wait till the cluster status is ready.
Next, we will have to download the kubeconfig file for the virtual K8S cluster.
Now, we will use the Kubectl to deploy the application using the below command:
kubeconfig $YOURKUBECONFIGFILE apply -f kubenetes-manifest.yml –namespace $YOURNAMESPACE
Step 4
Now, we can go to the VoltConsole to go and check the status of this app. We will wait for the pods to become ready and once all the pods are ready, we can now create the load balancer (LB) for frontend service.
Next, we give the LB a name and label the HTTP LB as ves-io/app_type and value as default (which is the name of the app type). Provide the domain name under basic config.
This guide provides instructions on how to delegate your DNS domain to Volterra using the VoltConsole. Delegating the domain to Volterra enables Volterra to manage the domain and be the authoritative domain name server for the domain. Volterra checks the DNS domain configured in the virtual host and verifies that the tenant owns that domain.
Step 5
Now select the origin pool, and create a new pool with the origin server type and name as below.Also, select the network on the site as vK8s network on site.Select the correct port number for the service and save & exit the configuration.
Step 6
Now, let's navigate to
HTTP LB dashboard > security monitoring > API endpoints.
Here you will see all the API endpoints that are discovered on the HTTP LB and you can download the swagger right from the HTTP LB dashboard page.
Step 7
Now , lets navigate to the service mesh graph where we can view the entire application micro-services and how they are connected, and how the east-west and north-south traffic is flowing.
App Namespace -> Mesh -> Service Mesh -> API endpoints tab
Step 8
Now, let's click on the API endpoints tab, and we will see all the API endpoints discovered for the default app type.
Now you can click on the Schema and then go to the PII& learned API data, and click on the download button to download the swagger schema for each specific API endpoint.
If we want to download the swagger schema for the entire application, then we go back to the API endpoints tab and download swagger as seen below:
Conclusion
With the increased attack surfaces with distributed microservices and other large ecosystems, having a feature such as API discovery and be able to auto-generate the swagger file really helps in mitigating the malicious API attacks. This feature provides users debugging capabilities for distributed apps that are deployed on a single cloud or across multiple clouds. In addition, API endpoints discovered could be used to create API level security policy to enforce tighter service-to-service communication.
The request logs are continuously analyzed to learn the schema for every learned API endpoint. The generated swagger schema could be downloaded through UI or Volterra API. SecOps can download and use it for audit purposes and Dev/DevOps team can use to see the delta variables/path between different version. It can be used as input to other third-party tools and is less administrative overhead of managing the documents.
