# What is Akto? [**API Security**](#api-security) • [**DAST**](/dast/akto-dast) • [**Akto Atlas**](https://ai-security-docs.akto.io/akto-atlas-agentic-ai-security-for-employee-endpoints/overview) • [**Akto Argus**](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/overview) • [**Join Discord Community**](https://discord.com/invite/Wpc6xVME4s) Akto is a **unified Agentic AI, MCP, and API security platform** built to secure autonomous AI workflows and modern APIs in production. Akto has **two major security pillars**: * [Agentic AI Security](#agentic-ai-security) * [API Security](#api-security) ## 🤖 Agentic AI Security Akto also secures **Agentic AI systems**, where AI agents interact with tools, APIs, users, and internal systems. Agentic AI Security in Akto has **two distinct products**: ### Akto Atlas **Agentic AI Security for Employee Endpoints** * Secures AI agents used by employees * Protects internal tools, SaaS actions, and AI-driven workflows * Prevents data leakage, prompt abuse, and unsafe agent actions {% hint style="success" %} 📘 Start here: [Akto Altas](https://ai-security-docs.akto.io/akto-atlas-agentic-ai-security-for-employee-endpoints/overview) {% endhint %} ### Akto Argus **Agentic AI Security for Homegrown AI** * Secures internally built AI agents and LLM workflows * Monitors agent decisions, tool usage, and execution paths * Detects: * Prompt injection * Privilege misuse * Unsafe autonomous actions {% hint style="success" %} 📘 Start here: [Akto Argus](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/overview) {% endhint %} ## 🔐 API Security Akto’s API Security platform helps teams **discover, test, and monitor APIs continuously** using real traffic and dynamic analysis. It consists of **two tightly integrated components**: ### API Security **Discovery & Runtime** * Automatically discover APIs from live traffic * Maintain a continuously updated API inventory * Detect: * Shadow and undocumented APIs * Sensitive data exposure * Authorization and authentication issues at runtime * Observe how APIs are *actually used* in production {% hint style="success" %} 📘 Start here: [Getting Started with API Security](/readme-1) {% endhint %} ### DAST **Dynamic API Security Testing** * Context-aware testing using observed API behavior * Covers OWASP API Top 10 + business logic vulnerabilities * Supports: * Manual test runs * Scheduled scans * CI/CD execution * Extremely low false positives {% hint style="success" %} 📘 Start here: [Getting Started with DAST](/dast/akto-dast) {% endhint %} {% hint style="warning" %} #### Scope of This Documentation This documentation site **only covers:** API Security & DAST For Agentic AI Security, refer to the [**AI Security documentation portal**](https://ai-security-docs.akto.io/) {% endhint %} # Getting Started with API Security [Getting-Started](#getting-started) • [API Discovery](/api-inventory/concepts/api-endpoints) • [API testing](/api-security-testing/concepts/test) • [Add Test](/test-editor/concepts/test-library) • [Join Discord community](https://discord.com/invite/Wpc6xVME4s) Akto has an instant API security platform that takes only 60 secs to get started. Akto is used by security teams to maintain a continuous inventory of APIs, test APIs for vulnerabilities and find runtime issues. Akto offers tests for all OWASP top 10 and HackerOne Top 10 categories including BOLA, authentication, SSRF, XSS, security configurations, etc. Akto's powerful testing engine runs variety of business logic tests by reading traffic data to understand API traffic pattern leading to reduced false positives. Akto can integrate with multiple traffic sources - Burpsuite, AWS, postman, GCP, gateways, etc. Akto enables security and engineering teams to secure their APIs by doing three things: 1. [API discovery](/api-inventory/concepts/api-collection) 2. [Run business logic tests in CI/CD](/integrations/ci-cd-integrations/how-to/run-tests-in-cicd) 3. [Find vulnerabilities in run-time](/api-security-testing/concepts/test) {% embed url="" %} ## Getting Started Get started with Akto Cloud in 5 simple steps: ### 1. Sign Up * Visit [app.akto.io](https://app.akto.io) * Create account with your work email
### 2. Create API Inventory * Go to API Collections → Create new collection * Name your collection * Connect your [Traffic Data Sources](/traffic-connector/traffic-data-sources) (Burp Suite/AWS/Postman) from Quick Start.
### 3. Set Authentication * Go to Settings → Authentication * Create auth type (Bearer/API Key/Basic)
### 4. Configure Attacker Token * Go to User Configuration * Set ATTACKER\_TOKEN\_ALL
### 5. Run Tests * Select your collection * Click Run Test * Choose tests you want to run * Select Test role * Click "Run once now"
# AktoGPT Harness the power of ChatGPT for API Security on your fingertips now! Akto integrates with ChatGPT to bring you insights from the most powerful bot. ### Data concerns Here is how and what of your data - 1. No data is sent out unless you click on the Send button [![Screenshot 2023-04-09 at 10 54 33 PM](https://user-images.githubusercontent.com/91221068/230789406-c1e898ab-52e1-45b2-b3b8-d4810e6d78ae.png)](https://user-images.githubusercontent.com/91221068/230789406-c1e898ab-52e1-45b2-b3b8-d4810e6d78ae.png) 2. Your Login email is sent to with every request to Akto. This email is retained by Akto and NOT sent to ChatGPT. This email ID is retained only till we receive a response from ChatGPT. 3. For Auto-group APIs and Filter APIs, a list of the API endpoint URLs is sent to Akto backend 4. For detecting Sensitive and PII data, request and response payload under the *Values* tab is sent to Akto backend 5. Akto retains only your email id. All the data is sent to ChatGPT in form of a prompt 6. Akto discards the data after the response is returned irrespective of success or failure ### How to use it? You will find **Ask AktoGPT** button on the dashboard at the top right. Currently, only a few pages have support for it. We will be extending the support to remaining pages as well soon. #### Auto-group APIs You can use AktoGPT to automatically group APIs based on their functionality. Follow these steps 1. Open any API collection and click on the **AktoGPT** button on the screen
2. From the list of prompts, select **Create API groups**
3. Click on the Send button to the right of the prompt
4. It should now classify all the APIs on the screen in multiple groups
#### Filter APIs You can use AktoGPT to automatically filter APIs based on a search phrase. Follow these steps 1. Open any API collection and click on the **AktoGPT** button on the screen
2. From the list of prompts, select **Tell me APIs related to**
3. Type a search phrase and click on the Send button to the right of the prompt
4. It should now show only APIs related to the search phrase
#### Sensitive and PII data You can use AktoGPT to look for any sensitive or PII parameters in the API payload. Follow these steps - 1. Open any API and click on the **AktoGPT** button on the screen
2. Select the **Fetch sensitive params** prompt
3. Click on the Send button to the right of the prompt
4. It should now show sensitive or PII params from the API payloads
\\ # Agentic AI Documentation Agentic AI Documentation Has Moved The Agentic AI security documentation has been migrated to a dedicated site for better organization and improved access. ## New Location All Agentic AI content is now available at: [**https://ai-security-docs.akto.io**](https://ai-security-docs.akto.io) ## What Changed? The following documentation sections have moved: ### MCP (Model Context Protocol) Security * [Akto MCP Server](https://ai-security-docs.akto.io/readme/akto-mcp-server) * [MCP Security](https://ai-security-docs.akto.io/readme/mcp-security) * [MCP Import](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/connectors/mcp-import) * [MCP Recon](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/connectors/others/mcp-recon) * [MCP Endpoint Shield](https://ai-security-docs.akto.io/akto-atlas-agentic-ai-security-for-employee-endpoints/endpoints-discovery-agents/mcp-endpoint-shield) * [MCP Endpoint Shield - Jamf MDM Deployment](https://ai-security-docs.akto.io/akto-atlas-agentic-ai-security-for-employee-endpoints/endpoints-discovery-agents/mcp-endpoint-shield/jamf-mdm-deployment) * [MCP Endpoint Shield via Cursor Hooks](https://ai-security-docs.akto.io/akto-atlas-agentic-ai-security-for-employee-endpoints/endpoints-discovery-agents/cursor-hooks) ### AI Agent Security * [AI Security](https://ai-security-docs.akto.io/readme/ai-security) * [AI Agent Security](https://ai-security-docs.akto.io/what-is-ai-agent-security) * [AI Agent Import](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/connectors/ai-agent-security) * [AI Model Import](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/connectors/ai-model-security) * [Agentic Shield](https://ai-security-docs.akto.io/akto-atlas-agentic-ai-security-for-employee-endpoints/endpoints-discovery-agents/agentic-shield) ### Agentic Guardrails * [Agent Guard](https://ai-security-docs.akto.io/agentic-guardrails/concepts/agent-guard) * [AI Agent Proxy](https://ai-security-docs.akto.io/agentic-guardrails/overview/akto-agent-proxy) * [MCP Proxy](https://ai-security-docs.akto.io/agentic-guardrails/overview/akto-mcp-proxy) * [Kong Agentic Guardrail Integration](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/connectors/others/api-gateways/connect-akto-with-kong) ### Cloud Provider Integrations * [AWS Bedrock Agents](https://ai-security-docs.akto.io/akto-argus-agentic-ai-security-for-homegrown-ai/connectors/ai-agent-security/connect-akto-with-aws-bedrock) ## Need Help? If you're looking for specific content that was previously here, please visit the [new documentation site](https://ai-security-docs.akto.io) or contact Akto Support. {% hint style="warning" %} ### **Note** This page serves as a redirect. Please update your bookmarks to the new locations. {% endhint %} # Deployment Types Akto integrates seamlessly into your pipeline, offering flexible deployment options to match your organization's API security needs. Choose from Cloud, Self-Hosted, or Local deployment. ### 1. Cloud Deployment The fastest and easiest way to get started with Akto. Ideal for organizations looking to quickly implement robust API security without infrastructure overhead. Steps: 1. [Set up Traffic Processor](/getting-started/quick-start-with-akto-self-hosted/helm-deploy) 2. [Configure Traffic Connector](/traffic-connector/traffic-data-sources) ### 2. Self-Hosted Deployment For organizations requiring complete control over their security infrastructure or with specific compliance needs. Steps: 1. [Choose Self-Hosted Configuration](/getting-started/quick-start-with-akto-self-hosted) 2. [Set up Traffic Processor](/getting-started/quick-start-with-akto-self-hosted/helm-deploy#install-akto-via-helm) 3. [Configure Traffic Connector](/traffic-connector/traffic-data-sources) ### 3. Local Deployment Perfect for development teams, security researchers, or evaluation purposes. Steps: 1. [Configure Traffic Connector](/traffic-connector/traffic-data-sources) Choose your preferred deployment option to start building a robust API Security program with Akto. # Akto Cloud ## Introduction Akto Cloud is the quickest way to start securing your APIs. As a hosted service, it offers enhanced reliability and security features without the need for complex setup. ## Step 1: Create your account * Navigate to * Sign up for a new account or log in if you already have one
## Step 2: Add API data To analyze and secure your APIs, Akto needs to access your API traffic. You can add this using any of our supported traffic connectors. 1. In the dashboard, look for the `Quick start`
2. Choose your preferred traffic connector from the available options 3. Follow the specific instructions for your chosen connector to start feeding API traffic into Akto
For a full list of supported traffic connectors and detailed integration instructions, visit our [Traffic Data Sources](https://docs.akto.io/traffic-connections/traffic-data-sources) page. ## Step 3: Run test Once you've added your API traffic, you can start running security tests: 1. In the dashboard, click on the "Run Test" button and a modal will pop up, allowing you to select the Tests categories and type of tests you want to test on your collection. 2. Once you select the above, click the "Run once now" button in the modal.
2. You'll be re-directed to the Test Results page – you can view all the test results, including any potential vulnerabilities or issues detected in your APIs
### Need Help? Our support team is ready to assist you in maximizing your API security with Akto Cloud. [Contact Support](mailto:support@akto.io) # Connect Akto with Hybrid SaaS Learn how to send API traffic data to Akto SaaS from your cloud setup. 1\. Go to [app.akto.io](https://app.akto.io) 2\. Login/Signup into your account. 3\. Click on Quick Start tab in left nav.
4\. Search for Hybrid SaaS Connector and click connect.
### Installing Traffic connector You can use either a CloudFormation template, Terraform template or a Helm chart to install Traffic aggregator in your env. #### Terraform 1. To install using Terraform, use the Terraform script [here](https://github.com/akto-api-security/infra/blob/mini_runtime_tf_script/templates/mini-runtime.tf). 1. Please make sure you install it in a private subnet from your application VPC. 2. This private subnet should also have network connectivity (typically via NAT). 2. You can use `https://cyborg.akto.io` as `DatabaseAbstractorUrl` . For `DatabaseAbstractorToken` you can copy it from the helm install command in the above screenshot. 3. Once complete, copy `akto_nlb_dns` from the output. 4. The next step is to install a traffic connector. 1. You can use the above copied `AktoNLBIP` as `AKTO_KAFKA_BROKER_MAL` in your traffic connectors. Note that `AKTO_KAFKA_BROKER_MAL` is inclusive of port (eg `akto-N-.....amazonaws.com:9092`) #### CloudFormation template 1. To install using CloudFormation, run the Cloudformation template [here](https://raw.githubusercontent.com/akto-api-security/infra/feature/quick-setup/templates/mini-runtime.yml). i) Please make sure you install it in a private subnet from your application VPC. ii) This private subnet should also have network connectivity (typically via NAT). 2. You can use `https://cyborg.akto.io` as `DatabaseAbstractorUrl` . For `DatabaseAbstractorToken` you can copy it from the helm install command in the above screenshot. 3. Once complete, go to the **Output** section of CloudFormation Stack and copy `AktoNLBIP`. 4. The next step is to install a traffic connector. 1. You can use the above copied `AktoNLBIP` as `AKTO_KAFKA_BROKER_MAL` in your traffic connectors. Note that `AKTO_KAFKA_BROKER_MAL` is inclusive of port (eg `akto-N-.....amazonaws.com:9092`) #### Helm chart 1\. If you have K8s clusters, you can use helm chart to install Traffic aggregator. 2\. Add akto helm repository. ```bash helm repo add akto https://akto-api-security.github.io/helm-charts/ ``` 3. Install `akto-mini-runtime` helm chart in your kubernetes cluster. 1. Directly using database abstractor token ```bash helm install akto-mini-runtime akto/akto-mini-runtime -n --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorToken="" ``` 2. Storing the database abstractor token in a secret ```bash helm install akto-mini-runtime akto/akto-mini-runtime -n --set mini_runtime.aktoApiSecurityRuntime.env.useSecretsForDatabaseAbstractorToken=true --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorTokenSecrets.token="" ``` 3. Bring your own secret which has the database abstractor token ```bash helm install akto-mini-runtime akto/akto-mini-runtime -n --set mini_runtime.aktoApiSecurityRuntime.env.useSecretsForDatabaseAbstractorToken=true --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorTokenSecrets.existingSecret= ``` 4\. Running the above commands in your k8s cluster will deploy a new Akto Traffic aggregator service. 5\. Run the below command and copy the `CLUSTER-IP` and `PORT` value for Traffic aggregator service. In the below example it will be `10.0.23.145:9092`. You can also use the kubernetes service ip, which in this case will be `akto-mini-runtime-mini-runtime.dev.svc.cluster.local:9092` ```bash kubectl get svc -n ```
6\. The next step is to install a traffic connector. 1. You can use the above copied `IP:PORT` value as `AKTO_KAFKA_BROKER_MAL` in your traffic connectors. Note that `AKTO_KAFKA_BROKER_MAL` is inclusive of port (eg `10.0.23.145:9092` , `akto-mini-runtime-mini-runtime.dev.svc.cluster.local:9092`)
### Linux VM 1. Create a new instance with the following requirements 1. Platform 1. Linux 2. Spec 1. 16 vCPU 2. 32GB RAM 3. 40GB Hard disk 4. Don’t use burstable instances 3. Network 1. Private subnet 2. connectivity to internet (typically via NAT) 3. connectivity to your staging service 4. Security groups 1. Inbound - Open port 9091 (http), 9092 (kafka) 2. Outbound - Open all 2. SSH into this new instance in your Cloud 3. Run `sudo su -` 4. Install docker and docker-compose. 5. Run the following commands to download setup files - ``` wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-mini-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-threat-detection.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env ``` 6. Replace `${AKTO_KAFKA_IP}` in `docker-compose-mini-runtime.yml` with the the `instance-ip` 7. Get your token from Quick Start> Hybrid SaaS > Connect > Copy the token that's in `red` color. 8. Replace the value of `DATABASE_ABSTRACTOR_SERVICE_TOKEN` in `docker-mini-runtime.env` with the token. Don't use double quotes. (The new docker takes double-quotes literally as part of the value!) 9. Replace the value of `AKTO_KAFKA_BROKER_URL` with \:9092. 10. Replace the value of `AKTO_THREAT_PROTECTION_BACKEND_TOKEN` and `DATABASE_ABSTRACTOR_SERVICE_TOKEN` in `docker-threat-detection.env` with the token. 11. Run `docker-compose -f docker-compose-mini-runtime.yml up -d` . If you are using new version of `docker`, you should use `docker compose` instead of `docker-compose` 12. Run `systemctl enable /usr/lib/systemd/system/docker.service` to ensure Docker starts up in case of instance restarts ## How to Set a Custom Mini-Runtime Module Name In your `docker-compose-mini-runtime.yml` file, add the environment variable `MINI_RUNTIME_NAME` under the `akto-mini-runtime` service. ```yaml version: '3.8' services: akto-mini-runtime: image: public.ecr.aws/aktosecurity/akto-api-security-mini-runtime:latest environment: DATABASE_ABSTRACTOR_SERVICE_TOKEN: MINI_RUNTIME_NAME: restart: always ``` Replace `` with the desired module name (e.g., `staging_runtime`, `us_east_1`, `qa_env`). ## Notes: 1. Ensure internet connectivity in Traffic aggregator service. 2. In case of closed network, please whitelist () 3. Ensure that traffic connector is able to connect to Traffic aggregator service 4. Log levels for Akto services can be configured by setting the environment variable `AKTO_LOG_LEVEL` * Supported values include `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` and `OFF`. * Default log level is set to `WARN`. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Migrate From Self Hosted Setup To SaaS ## **Introduction** This guide will help you to move your On-Prem Setup to Akto SaaS setup. In case you want to restore your Akto Data and move it to your SaaS account, proceed with Step 1(Restore Original Data). Else proceed with Step 2(Connect Akto with Hybrid SaaS) ## Step 1: Restore Original Data 1. Run the below command and copy mongo container id ```bash kubectl get pods -n ``` 2. Run the below command ```bash kubectl exec -it bash ``` 3. Run the below command ```bash mongodump --db 1000000 --out /data/dump/1000000 ``` 4. Run the below command ```bash kubectl cp -n default :data/dump/1000000 ~/copy-1000000 -n ``` 5. Run the below command ```bash mkdir akto_data_folder ``` 6. Run the below command ```bash mv ~/copy-1000000 ~/akto_data_folder ``` 7. zip the folder akto\_data\_folder 8. Contact Akto Support to share the file in a secure manner and to restore the data in your SaaS account. 9. Proceed to next step only after you receive an acknowledgement from Akto team. ## Step 2: Connect Akto with Hybrid SaaS 1. Go to app.akto.io 2. Login/Signup into your account. 3. Go to quick start tab and search for connector Hybrid SaaS Connector and click on connect 4. Copy the command provided. 5. Download helm chart for mini-runtime service 6. Run the command copied in step no. 4 7. Setup New DaemonSet Pods with ```bash AKTO_NLB_IP = aktoruntime-mini-runtime.dev.svc.cluster.local:9092 ``` 8. Go to app.akto.io and check if traffic data is getting populated in your account. ## Step 3: Removing Old Akto Helm Setup 1. Once step 2 is finished and Akto is setup with Hybrid SaaS, confirm you can see new traffic in Akto dashboard. 2. Now, we can remove old Akto Helm Setup. Run helm uninstall \ -n 3. Delete old DaemonSet Pods ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Setting up proxy [Akto](https://www.akto.io/) deploys multiple services in your cloud, which primarily include a dashboard, a traffic processing module and a testing module. These modules need internet access. In case, the cluster/VPC in which Akto is deployed, doesn't have internet connectivity, you can configure a proxy as follows to provide internet connectivity to Akto modules. ## Configure the given environment variables to setup proxy 1. `PROXY_URI` This is the URI of your internet proxy. All requests (HTTP/HTTPS) will be proxied through this URI. You can take reference from the below examples to configure it properly. ```bash PROXY_URI=192.168.0.0 // if no protocol is mentioned, we assume the protocol to be HTTP PROXY_URI=http://192.168.0.0 PROXY_URI=https://192.168.0.0 PROXY_URI=http://192.168.0.0:9000 PROXY_URI=https://192.168.0.0:444 PROXY_URI=http://user:password@192.168.0.0 // example for authenticated proxy. By default, the proxy is assumed to be unauthenticated PROXY_URI=user:password@192.168.0.0 PROXY_URI=user:password@192.168.0.0:9000 PROXY_URI=http://user:password@192.168.0.0:9000 PROXY_URI=https://user:password@192.168.0.0:5000 ``` 2. `NO_PROXY` This is a comma separated list of IP/URLs which you do want to be proxied. This may include localhost/127.0.0.1 , internal IPs or any other URL. You can take reference from the below examples to configure it properly. ```bash NO_PROXY=127.0.0.1 NO_PROXY=127.0.0.1,localhost NO_PROXY=127.0.0.1, localhost, 192.168.0.0 NO_PROXY=127.0.0.1,localhost,192.168.0.0,example.com NO_PROXY=127.0.0.1, localhost, 192.168.0.0/20, example.com ``` ## Frequently Asked Questions (FAQs) **The requests are not being proxied through the given proxy** Please check the protocol and port for the proxy you've configured. In case this doesn't help, please reach out to use at `support@akto.io`. **I don't see my error on this list here.** Please send us all details at `support@akto.io` or reach out via Intercom on your Akto dashboard. We will definitely help you out. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Akto Direct connect **Akto Direct Connect** lets you start using Akto in seconds with a **simple 1-line integration**—no need to set up or manage any infrastructure. Your traffic is securely streamed from your cloud to **Akto's hosted Traffic Processor**, where it is analyzed in real time. This fully-managed setup is ideal for teams that want **quick onboarding**, **zero maintenance overhead**, and **fast time-to-value** with API security testing.
### Get Authentication Token 1. Login to Akto dashboard at [app.akto.io](https://app.akto.io) 2. Go to Quick Start > Hybrid Saas > Click on “Connect” button 3. Copy the JWT token/databaseAbstractorToken (marked in red) #### Run the Traffic Collector Replace the CLOUD\_PROCESSOR\_AUTHENTICATION\_TOKEN below with the JWT token copied from previous step ```bash docker run -d \ --name akto-api-security-traffic-collector \ --restart always \ --network host \ --privileged \ --pid=host \ --cap-add SYS_PTRACE \ --cap-add SYS_ADMIN \ --cpus="0.5" \ --memory="512m" \ -v /lib/modules:/lib/modules \ -v /sys/kernel:/sys/kernel \ -v /usr/src:/usr/src \ -v /:/host \ -e AKTO_TRAFFIC_BATCH_TIME_SECS=10 \ -e AKTO_TRAFFIC_BATCH_SIZE=100 \ -e CLOUD_PROCESSOR_MODE=true \ -e CLOUD_PROCESSOR_AUTHENTICATION_TOKEN= \ -e PROBE_ALL_PID=true \ public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf ``` In case you face an issue with the spaces in the command above ```bash docker run -d --name akto-api-security-traffic-collector --restart always --network host --pid=host --privileged --cap-add SYS_PTRACE --cap-add SYS_ADMIN --cpus="0.5" --memory="512m" -v /lib/modules:/lib/modules -v /sys/kernel:/sys/kernel -v /usr/src:/usr/src -v /:/host -e AKTO_TRAFFIC_BATCH_TIME_SECS=10 -e AKTO_TRAFFIC_BATCH_SIZE=100 -e AKTO_KAFKA_BROKER_MAL= -e CLOUD_PROCESSOR_MODE=true -e CLOUD_PROCESSOR_AUTHENTICATION_TOKEN= -e PROBE_ALL_PID=true public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf ``` # Akto Self Hosted Akto can be self-hosted in just 60 seconds. ### Introduction If you're like us, you probably have a lot of data that is only accessible from your private network (locally or behind your [VPN](https://cybernews.com/what-is-vpn/#how-does-a-vpn-work)). That's why we built the self-hosted version of Akto. #### How to deploy? Deploy Akto locally or on your own cloud. Choose any of the below options to get started: 1. [AWS deploy](/getting-started/quick-start-with-akto-self-hosted/aws-deploy) 2. [GCP Deploy](https://docs.akto.io/getting-started/gcp-deploy) 3. [Local Deploy](https://docs.akto.io/getting-started/local-deploy) 4. [Openshift Deploy](https://docs.akto.io/getting-started/openshift-deploy) 5. [Azure Deploy](https://docs.akto.io/getting-started/azure-deploy) 6. [Heroku](https://docs.akto.io/getting-started/heroku) # AWS deploy ### 60 seconds deploy in AWS 🚀 {% tabs %} {% tab title="Akto Setup" %} ![Deployment Architecture](/files/HVsOJ9bIlp3NRl5jISpp) {% endtab %} {% endtabs %} ### Deployment Options Before proceeding with the deployment steps, consider the following options to choose the most suitable deployment method for your environment: 1. **Standard AWS Deployment**: If you have a single VPC and are not using Kubernetes, continue with the steps below. 2. **Kubernetes Users**: If you're using Kubernetes, consider deploying using Helm. Learn more about [Helm deployment](/getting-started/quick-start-with-akto-self-hosted/helm-deploy). 3. **Multiple VPCs**: * For multi-VPC deployment, refer to our [AWS multi-VPC deploy guide](/getting-started/quick-start-with-akto-self-hosted/aws-deploy/aws-multi-vpc-deploy). * For cross-region, cross-VPC deployment, check out our [AWS Cross-Region Cross-VPC deploy guide](/getting-started/quick-start-with-akto-self-hosted/aws-deploy/aws-cross-region-vpc-deploy). 4. **Custom Subdomain**: For custom subdomain setup on AWS, see our [Custom subdomain on Akto on AWS guide](/getting-started/quick-start-with-akto-self-hosted/aws-deploy/aws-ssl). Choose the option that best fits your infrastructure needs. If you're proceeding with the standard AWS deployment, continue with the steps below. ### Prerequisites * An active AWS account * Necessary permissions to create and manage CloudFormation stacks ### Step 1: Fetch the AWS CFT 1. Sign up on [Akto](https://app.akto.io) and download the [AWS CFT](https://github.com/akto-api-security/infra/blob/feature/quick-setup/templates/akto-quick-setup.yaml). ### Step 2: Create stack in AWS 1. Sign into your `AWS account` if you are not logged-in. Go to `Cloudformation` and upload the template we just downloaded, then click next. ![](/files/enxTruyPmzGpfN61LVdt) 2\. This will take you to a pre-filled `quick create stack` like below.
3\. Add your parameters here - `keypair`, `1 private subnetId` and `2 public subnetIds`. Atleast 1 public subnet should be in the same availability zone as private subnet.
4\. Your user email parameter should be the same as the one you used to signup with Akto. 5\. Select `I acknowledge that AWS CloudFormation might create IAM resources.`
6\. Click on `create stack`. ### Step 3: Launch Akto dashboard 1. `Wait` for a couple of minutes before you stack creation is complete. 2. Once your stack is created, `navigate to outputs` sections and `copy Akto dashboard url` into your browser.
3\. `Signup` and start using Akto. ### Post-Deployment After successful deployment, free plan users will be able to see up to 25 APIs. To access more APIs and additional features, consider upgrading to a paid plan. [View our pricing options](https://www.akto.io/pricing). Need help? [Contact](mailto:support@akto.io) our support team for assistance. ### Optional - 1. [Add custom subdomain and SSL certificate to your akto deployment on AWS](/getting-started/quick-start-with-akto-self-hosted/aws-deploy/aws-ssl) 2. [Take periodic snapshot of Akto data](https://github.com/akto-api-security/Documentation/blob/main/getting-started/aws-snapshot-policy.md) # AWS multi-VPC deploy ## Steps to setup Akto in AWS multi-VPC environment ### Step 1: Deploy Akto dashboard and mongo using [helm charts](/getting-started/quick-start-with-akto-self-hosted/helm-deploy) or our [cloud formation templates](/getting-started/quick-start-with-akto-self-hosted/aws-deploy). ### Step 2: Setup VPC peering We need to connect the VPC where Akto is deployed (AktoVPC) and the VPC where App servers (AppServerVPC) are present #### Step 2.a: Initiate VPC peering between AppServerVPC and AktoVPC Initiate VPC peering connection from AppServerVPC to AktoVPC
Once a peering connection request has been initiated, you will see a screen like this
#### Step 2.b: Accept VPC peering between AppServerVPC and AktoVPC Log on to AktoVPC and navigate to VPC > Peering connections. Click on `Accept request` to accept the peering connection request.
Clicking on `Accept request` will open up this pop-up where you can confirm the peering connection request.
After a few seconds the connection status will change to `Active` and you will see a screen like this
#### Step 2.c: Update route tables We need to update route tables of both VPCs to allow traffic to flow between them. **Step 2.c.1: Update route table of AppServerVPC** Log on to AppServerVPC and navigate to VPC > Route tables. Click on `Edit routes` and add a route to AktoVPC CIDR block with the peering connection as the target.
**Step 2.c.2: Update route table of AktoVPC** Log on to AktoVPC and navigate to VPC > Route tables. Click on `Edit routes` and add a route to AppServerVPC CIDR block with the peering connection as the target.
### Step 3: Update security groups to allow traffic between VPCs Update security group for AktoMongoInstance in AktoVPC to allow the data processors to send data to Mongo. Once data processors are up and running (to be setup in step #4), they will start sending data to AktoMongoInstance deployed in AktoVPC. But to make sure that the data reaches mongo instance, we need to update AktoMongoInstance’s security group as follows:
Here we will add Type: Custom TCP, Port range: 27017, CIDR block: 10.0.0.0/16 (Cidr block of the AppServerVPC) ### Step 4: Setup data processors We need to setup data processors in AppServerVPC to send data to AktoMongoInstance deployed in AktoVPC. Use the following cloud formation template to setup data processors in AppServerVPC [here](https://akto-setup.s3.amazonaws.com/templates/data_processing_stack.yml) To setup this stack you will need to give the following paramenters: * SubnetId: This should be the subnet id where Akto data processor will be deployed. * KeyPair: This key pair will be used to login to the data processor for debugging purposes. * MongoIp: Value here will be : mongodb://{{AKTO\_MONGO\_IP}}:27017/admini AKTO\_MONGO\_IP’s value will the AktoMongoInstance's private ip. This can be fetched from AktoVPC > EC2 > AktoMongoInstance > Networking > Private ip address. That's it! Once all these steps are down, you will now see APIs from your app servers show up on your Akto dashboard. # AWS Cross-Region Cross-VPC deploy ## Prerequisites * Setup Akto in a VPC. We’ll call this Security VPC. * Vpc where runtime will be deployed. We’ll call this Application VPC. ## Case 1 - Account and region both are same
### Step 1: Creating a Target Group For Mongo Instance present in Central VPC * Go to Aws Console and search for target groups. Click on create target group
* In the Basic Configuration section, select IP addresses option.
* Add a target group name of your choice, and select TCP protocol and add port 27017. Post that, select Application VPC, and click on next.
* On the next screen, choose “Other private IP address” under Network section. Select the availability zone under Availability zone section
* Enter the private ip of mongo instance present in region 1. Modify the port value to 27017 and click on include as pending below.
* Click on Create target group at the bottom to create the target group ### Step 2: Creating Load Balancer * Go to Aws Console and search for load balancer. Click on create load balancer.
* On the next page, select Network Load Balancer.
* Add a lb name of your choice, and mark it as Internal in the Scheme section.
* In the VPC section, select Application VPC and select the appropriate availability zones.
* Create a new security group with the below inbound rule
* In the listener section, select the target group created in the above step and add the correct port
* Click on Create Load Balancer at the bottom to create the load balancer. ### Step 3: Setting Up Endpoint Service * Go to Aws Console and search for endpoint service. Click on create endpoint service.
* Add a name for your endpoint service and select “Network” Load balancer type. In the available load balancers section below select the load balancer created in previous step.
* Click on create at the bottom.
* Go to Allow Principals tab and add the below principal value.
### Step 4: Setting Up Endpoint * Go to Aws console and search for endpoints. Click on create endpoint
* Add a name for your endpoint and select other endpoint services in the service category. Also mention the service name in the Service Settings section by copying it as mentioned in step 3.
* Copy the service name from the endpoint service created earlier.
* Select Application VPC and select appropriate subnets
* Create a security group and add cidr blocks of Application VPC
* Click on Create Endpoint. ### Step 5: * Copy endpoint url from the above created Endpoint. Append /admini at the end of this url.
* While setting up runtime for your application, use this url as Mongo\_IP. ### In case there are multiple applications - * Scenario 1 - All Applications are in same region No extra steps are required. Use the same Endpoint link as mentioned in Step 5. * Scenario 2 - 1 or more Application in different regions Refer to Case 2 ## Case 2 - Account or region are different ## Prerequisites * Setup Akto in a VPC. We’ll call this Security VPC. * Vpc where runtime will be deployed. We’ll call this Application VPC.: * Create/reuse a separate VPC in a different region in the same account as step 1. We’ll call this Relay VPC.
### Step 1: * Peering Setup - Peer Central And Relay VPC. ### Step 2: Creating a Target Group For Mongo Instance present in Central VPC * Go to Aws Console and search for target groups. Click on create target group
* In the Basic Configuration section, select IP addresses option.
* Add a target group name of your choice, and select TCP protocol and add port 27017. Post that, select the vpc which was used for peering connection in region 2, and click on next.
* On the next screen, choose “Other private IP address” under Network section. Select the availability zone under Availability zone section
* Enter the private ip of mongo instance present in region 1. Modify the port value to 27017 and click on include as pending below.
* Click on Create target group at the bottom to create the target group ### Step 2: Creating Load Balancer * Go to Aws Console and search for load balancer. Click on create load balancer.
* On the next page, select Network Load Balancer.
* Add a lb name of your choice, and mark it as Internal in the Scheme section.
* In the VPC section, select Relay VPC and select the appropriate availability zones.
* Create a new security group with the below inbound rule
* In the listener section, select the target group created in the above step and add the correct port
* Click on Create Load Balancer at the bottom to create the load balancer. ### Step 3: Setting Up Endpoint Service * Go to Aws Console and search for endpoint service. Click on create endpoint service.
* Add a name for your endpoint service and select “Network” Load balancer type. In the available load balancers section below select the load balancer created in previous step.
* Click on create at the bottom.
* Go to Allow Principals tab and add the below principal value.
### Step 4: Setting Up Endpoint * Go to Aws console and search for endpoints. Click on create endpoint
* Add a name for your endpoint and select other endpoint services in the service category. Also mention the service name in the Service Settings section by copying it as mentioned in step 3.
* Copy the service name from the endpoint service created earlier.
* Select Application VPC and select appropriate subnets
* Create a security group and add cidr blocks of Relay Vpc and Application VPC
* Click on Create Endpoint. ### Step 5: * Copy endpoint url from the above created Endpoint. Append /admini at the end of this url.
* While setting up runtime for your application, use this url as Mongo\_IP. ### In case there are multiple applications - * Scenario 1 - All Applications are in same region No extra steps are required. Use the same Endpoint link as mentioned in Step 5. * Scenario 2 - 1 or more Application in different regions 1. Create a new Relay VPC in the different region 2. Repeat all the steps of Case 2 # Custom subdomain on Akto on AWS [Akto](https://www.akto.io/) creates a load balancer for your akto dashboard. You can put this dashboard behind your organization's subdomain for easier access across teams. Moreover, adding SSL certificate make the dashboard more secure. ## To configure HTTPS and add SSL certificate to akto dashboard load-balancer 1. Navigate to AWS dashboard > EC2 > load balancers and select the akto dashboard load balancer.
Navigate to load balancers and select akto dashboard load balancer
2. Go to `Listeners and rules` and select the `HTTP:80` rule.
Select HTTP 80 rule
3. Click on `Edit listener`
Click on edit listener
4. Change protocol from `HTTP` to `HTTPS`.
Change protocol to HTTPS
5. Add your SSL certificate to the listener.
Add SSL cert
6. Click on save changes. The protocol should be changed by this. To make it reachable by the load balancer we would edit its security group.
Save changes
7. On the same page, click on security and click on the associated security group.
Go to the associated security group
8. Click on edit inbound rules.
Edit inbound rules
9. Change the type of protocol from HTTP to HTTPS and save the inbound rule of the security group.
Set type to HTTPS
10. You should now be able to access akto dashboard's load-balancer IP on HTTPS and it should give an invalid SSL certificate error, because the certificate belongs to your organization and would have been mapped to your organization's domain name.
## To configure custom subdomain for akto dashboard load-balancer 1. Navigate to Route 53 on the AWS dashboard. Go to hosted zones.
Go to route 53
2. Select the hosted zone in which you want to route akto dashboard and click on create record.
Create a new record in a hosted zone
3. Select the record name as `akto` and record type as `A - Routes traffic to an IPv4 address and some AWS resources`. Then toggle the alias button.
4. Select on `Application and classic load balancer` in the endpoints menu.
Select on application and classic load balancer
5. Select the region in which the load balancer is deployed.
Select region
6. Choose akto dashboard's load balancer in the menu and click on `Create records`.
choose your LB and create records
Now, you have added a custom subdomain and SSL certificate to your akto deployment on AWS. # Helm Deploy You can install Akto via Helm charts. Read [announcement blog](https://www.akto.io/blog/introducing-akto-with-helm-charts-in-kubernetes). ## Resources Akto's Helm chart repo is on GitHub [here](https://github.com/akto-api-security/helm-charts). You can also find Akto on Helm.sh [here](https://artifacthub.io/packages/helm/akto/akto). ## Prerequisites Please ensure you have the following - 1. A Kubernetes cluster where you have deploy permissions 2. `helm` command installed. Check [here](https://helm.sh/docs/intro/install/) ## Steps Here are the steps to install Akto via Helm charts - 1. Prepare Mongo Connection string - You can create a fresh new Mongo or use existing Mongo if you have Akto installed previously in your cloud. 2. Install Akto via Helm 3. Verify Installation and harden security ### Prepare Mongo Connection string Akto Helm setup needs a Mongo connection string as input. It can come from either of the following - 1. **Your own Mongo** Ensure your machine where you setup Mongo is NOT exposed to public internet. It shouldn't have a public IP. You can setup a Mongo cluster as follows:\ Create the following file: mongo-cluster-setup.yaml ```yaml --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: mongo-storage provisioner: efs.csi.aws.com parameters: provisioningMode: efs-ap fileSystemId: fs-0a64ff88e3f61684d # mention your fs id directoryPerms: "700" gidRangeStart: "1000" gidRangeEnd: "2000" basePath: "/akto1" # optional: specify access point # accessPointId: reclaimPolicy: Retain volumeBindingMode: Immediate --- apiVersion: v1 kind: Service metadata: name: mongo spec: ports: - port: 27017 targetPort: 27017 clusterIP: None selector: app: mongo --- apiVersion: apps/v1 kind: StatefulSet metadata: name: mongo spec: selector: matchLabels: app: mongo serviceName: "mongo" replicas: 3 template: metadata: labels: app: mongo spec: containers: - name: mongo image: mongo:6.0.1 args: ["--dbpath", "/data/db"] startupProbe: exec: command: - mongosh - --eval - "db.adminCommand('ping')" initialDelaySeconds: 1 periodSeconds: 10 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 2 livenessProbe: exec: command: - mongosh - --eval - "db.adminCommand('ping')" initialDelaySeconds: 1 periodSeconds: 10 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 2 readinessProbe: exec: command: - mongosh - --eval - "db.adminCommand('ping')" initialDelaySeconds: 1 periodSeconds: 10 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 2 command: - mongod - "--bind_ip_all" - "--replSet" - rs0 volumeMounts: - name: mongo-volume mountPath: /data/db volumeClaimTemplates: - metadata: name: mongo-volume spec: accessModes: ["ReadWriteOnce"] storageClassName: demo-storage resources: requests: storage: 1Gi ``` Now execute the following command: `kubectl apply -f mongo-cluster-setup.yaml -n {namespace}` Wait for a couple of mins till you see 3 mongo pods with name: mongo-0, mongo-1 and mongo-2 are in running state Once the pods are in running state, execute the following commands to initialize the cluster: ``` kubectl exec -it mongo-0 mongosh -n {{namespace}} # execute the next command from within mongo shell rs.initiate({ _id: "rs0", members: [ {_id: 0, host:"mongo-0.mongo.default.svc.cluster.local:27017"}, {_id: 1, host:"mongo-1.mongo.default.svc.cluster.local:27017"}, {_id: 2, host:"mongo-2.mongo.default.svc.cluster.local:27017"} ] }) ``` The connection string would then be `mongodb://mongo-0.mongo.default.svc.cluster.local:27017,mongo-1.mongo.default.svc.cluster.local:27017,mongo-2.mongo.default.svc.cluster.local:27017/admini` 2. **Mongo Atlas** You can use Mongo Atlas connection as well 1. Go to `Database Deployments` page for your project 2. Click on `Connect` button 3. Choose `Connect your application` option 4. Copy the connection string. It should look like `mongodb://....`
3. **AWS Document DB** If you are on AWS, you can use AWS Document DB too. You can find the connection string on the Cluster page itself.
4. **Existing Akto setup** If you have previously installed Akto via CloudFormation template, and you want to move to Helm, please execute the following steps. This guide should be used only if you are NOT using AWS Traffic Mirroring. If you are indeed using AWS Traffic Mirroring, please contact us at . 1. Go to AWS > EC2 > Auto Scaling Groups and search for `Akto`. 2. Edit all autoscaling groups and set min/max/desired to 0. 3. This shuts down all existing Akto infra and just leaves Akto-Mongo running. 4. **\[Optional - If you want to delete CloudFormation Stacks once migration completes]** - We have to "clone" this Akto Mongo Instance. You can create an AMI and launch a new instance with the same AMI. Alternatively, you can also - * Go to AWS > EC2 > Instances > Search for "Akto Mongo instance". Launch a new instance using this template. * SSH on new Mongo and run `sudo su -` and then `docker stop mongo`. * Run `rm -rf /akto/infra/data/` on new Mongo. * Copy `/akto/infra/data/` from old Mongo instance to this new Mongo instance at the same directory location of `/akto/infra/data/` using SCP * Run `docker start mongo` 5. If you have installed Akto's K8s agent in your K8s cluster in the previous CloudFormation setup, please run `kubectl delete -f akto-daemonset-config.yml` to halt the traffic processing too. 6. Use the private ip of this Mongo instance while installing helm chart (refer [Install Akto via Helm](#install-akto-via-helm) section) 7. Once you setup Akto via Helm chart, try logging in with your previous credentials and check the data. All your data must be retained. 8. Change the `AKTO_NLB` to the output of `kubectl get services/flash-akto-runtime -n staging -o jsonpath="{.spec.clusterIP}"` 9. Run `kubectl apply -f akto-daemonset-config.yml` 10. Confirm Akto dashboard has started receiving new data. 11. Please **Do Not Delete** AWS CloudFormation Stacks. This will delete the Mongo Instance too and you'll lose the data. If you want to delete AWS CloudFormation stacks, please setup new a duplicate Mongo Instance from step (4). Use private IP of this new instance for step (6). 5. **Mongo on K8s with Persistent volume** You can setup a Mongo on K8s cluster itself with a Persistent volume. A sample template is provided [here](https://github.com/akto-api-security/infra/blob/kubernetes/mongo.yml). Use the IP of this service as Mongo private IP in [Install Akto via Helm](#install-akto-via-helm) section. If you are migrating from previous Akto installation, you have to bootstrap the persistent volume with original Mongo Instance's data before you start Mongo service. 6. **Mongo cluster setup via cfn template** Use the following cloud formation template [link](https://github.com/akto-api-security/infra/blob/feature/quick-setup/templates/mongo-cluster-template.yml) This cfn template requires 2 inputs: 1. PrivateSubnetId: Select the private subnet in which you want the cluster to be created. Make sure this subnet has a route to a Nat Gateway connectivity. 2. KeyPair: This keypair will be used to ssh into the instance The default instance type in the template is m6a.large. You can change it as per your requirement in the template. We recommend not to use `t3/t4` type of instances for running a cluster. Once this template is executed successfully you will see 3 EC2 instances created. You can access the connection url from the output section once the cfn execution completes\ \ Note: Please ensure your K8S cluster has connectivity to Mongo. ### Install Akto via Helm 1. Add Akto repo `helm repo add akto https://akto-api-security.github.io/helm-charts` 2. Install Akto via helm `helm install akto akto/akto -n dev --set mongo.aktoMongoConn=""` 3. Run `kubectl get pods -n ` and verify you can see 4 pods
### Verify Installation and harden security 1. Run the following to get Akto dashboard url `kubectl get services/akto-dashboard -n dev | awk -F " " '{print $4;}'` 2. Open Akto dashboard on port 8080. eg `http://a54b36c1f4asdaasdfbd06a259de2-acf687643f6fe4eb.elb.ap-south-1.amazonaws.com:8080/` 3. For good security measures, you should enable HTTPS by adding a certificate and put it behind a VPN. If you are on AWS, follow the guide [here](https://docs.akto.io/getting-started/aws-ssl). ### If Akto Cluster is Deployed in a Separate Kubernetes Cluster If you encounter the error `Can't connect to Kafka` in your daemonset and you have exposed the Akto runtime service via a route that doesn't resemble `*.svc.cluster.local`, you'll need to update the `KAFKA_ADVERTISED_LISTENERS` environment variable in the akto-runtime deployment. Follow these steps: 1. Change the KAFKA\_ADVERTISED\_LISTENERS environment variable to match your route using the following command: `kubectl set env deployment/{deployment-name} KAFKA_ADVERTISED_LISTENERS="LISTENER_DOCKER_EXTERNAL_LOCALHOST://localhost:29092, LISTENER_DOCKER_EXTERNAL_DIFFHOST://{Service_Endpoint}:9092" -n {namespace}` 2. Verify the change with this command: `kubectl get deployment {deployment-name} -o jsonpath="{.spec.template.spec.containers[?(@.name=='kafka1')].env[?(@.name=='KAFKA_ADVERTISED_LISTENERS')].value}" -n {namespace}` Replace {deployment-name}, {Service\_Endpoint}, and {namespace} with your actual deployment name, service DNS, and namespace respectively. # Azure Deploy You can use helm to install Akto in Azure Kubernetes Service(AKS). For detailed steps follow [this](/getting-started/quick-start-with-akto-self-hosted/helm-deploy). # Openshift Deploy Learn how to deploy Akto on Openshift cluster Openshift is RedHat's managed private cluster offering - based on Docker and orchestration by Kubernetes. Steps to get Akto running on your Openshift cluster - 1. You can use same steps as [Helm Deploy](/getting-started/quick-start-with-akto-self-hosted/helm-deploy) to deploy Akto. 2. [Add service account](#service-account-manifest) to get permissions for traffic connector. 3. You can use [eBPF on mTLS](/traffic-connector/ebpf/ebpf-mtls) as your traffic connector. Add the following to the Daemonset connector - > They listen to `any` interface by default - which might NOT be allowed in some Openshift clusters. If that's the case, contact - we can help listen traffic on `br-ex` interface. ```yaml containers: - name: mirror-api-logging ... # add the following lines to add additional privileges privileged: true securityContext: runAsUser: 0 privileged: true ``` #### Service account manifest On Openshift, for a pod to be able to listen to node traffic (eg. a daemonset pod), it needs to be assigned some special permissions. 1\. Create a Service Account ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: akto-daemonset-serviceaccount annotations: "scc.openshift.io/scc": "akto-daemonset-scc" ``` 2. Create a Security Context Constraint. Substitute \ with Akto daemonset yaml namespace. ```yaml apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: akto-ebpf-scc annotations: kubernetes.io/description: "Minimal eBPF SCC for Akto" allowHostDirVolumePlugin: true allowHostIPC: true allowHostNetwork: false allowHostPID: true allowHostPorts: false allowPrivilegedContainer: true allowedCapabilities: - SYS_PTRACE - SYS_ADMIN defaultAddCapabilities: [] requiredDropCapabilities: - ALL readOnlyRootFilesystem: false runAsUser: type: MustRunAsRange uidRangeMin: 100000 uidRangeMax: 2147483647 seLinuxContext: type: MustRunAs fsGroup: type: RunAsAny supplementalGroups: type: RunAsAny users: - system:serviceaccount:akto:pod-watcher volumes: - configMap - secret - emptyDir - projected - hostPath priority: 10 ``` 3. Add SCC to service account ```bash oc adm policy add-scc-to-user akto-daemonset-scc -z akto-daemonset-serviceaccount ``` ## Notes: 1. The SecurityContextConstraints are based on official Redhat documentation, supporting up to [v4.19](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/authentication_and_authorization/managing-pod-security-policies) ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Heroku Coming soon if you have an immediate usecase for this. please email us at # GCP Deploy You can deploy Akto using the GCP packet mirroring template. Here are the steps to deploy: 1. Click on this [link](https://raw.githubusercontent.com/akto-api-security/infra/feature/self_hosting/templates/gcp-mirroring-template.sh) to see the template. 2. Go to your console in GCP and type these commands ``` wget https://raw.githubusercontent.com/akto-api-security/infra/feature/self_hosting/templates/gcp-mirroring-template.sh chmod +x gcp-mirroring-template.sh ``` This will create a template with name gcp-mirroring-template.sh 3\. Make sure you are in the project where you want create resources.
4\. Create a txt file with name inputs.txt with the following input parameters. ``` project-id region network subnet zone ``` Here is an example below: ``` ankitas-playground us-west4 vpc-1 vpc-1-usw4 us-west4-a ``` 5\. Go to the instances you want to mirror and add network tag 'mirror' to them. You can do this by clicking on edit button and scrolling down to the network tags section.
6\. Now start creating resources by writing this command `./gcp-mirroring-template.sh create
{% hint style="warning" %} `Troubleshoot: if you get permission denied error, type and enter the command` chmod +x gcp-mirroring-template.sh {% endhint %} 7\. The above command will create the following resources: * [ ] A load balancer * [ ] An auto scaled instance group added to the load balancer which receives mirrored packets * [ ] One instance with mongo * [ ] One instance with Akto dashboard 8\. Once all the resources are created, go to VM instances in your google cloud.
9\. Click on the akto-dashboard-instance and find the IP.
10\. Copy and paste this IP in your browser and add port 8080 to it ( )
11\. You can signup on Akto dashboard.
{% hint style="info" %} To delete all the resources you created with 'akto' prefix, run the command `./gcp-mirroring-template.sh delete akto y ``` {% endhint %}
### Post-Deployment After successful deployment, free plan users will be able to see up to 25 APIs. To access more APIs and additional features, consider upgrading to a paid plan. [View our pricing options](https://www.akto.io/pricing). Need help? [Contact](mailto:support@akto.io) our support team for assistance. ### Troubleshooting Notes 1. Since the instance group requires health check metrics, please ensure that health check IPs for GCP i.e. 130.211.0.0/22, 35.191.0.0/16 are allowed on port TCP port 8000 for the VM instances. 2. Ensure that internal calls are allowed between created VMs. 3. Open the ports carrying the mirrored traffic on the VMs in the akto-instance-group. Generally traffic is carried on TCP port 80. 4. If you're accessing akto-dashboard from a public network, allow http traffic on it. # Local Deploy ## **Introduction** This guide will help you get the Akto modules running as Docker containers using `Docker Compose`. This is the easiest way to set up Akto in your **local environment**. ## Prerequisites You'll need to have Docker installed in order to run the container. Check out [the Docker documentation](https://docs.docker.com/install/) for instructions. To verify installation run `docker info`. ## Step 1: Use Docker Compose Run the following commands to install Akto. You'll need to have curl and Docker installed in order to run the container.. 1. Clone the Akto repo by using this command ``` git clone https://github.com/akto-api-security/akto.git ``` 2. Go to the cloned directory ``` cd akto ``` 3. Run ``` docker-compose up -d ``` ## Step 2: Create your account Akto should automatically open up in your browser at . Click on the Signup button to get started. If you've already signed up, sign in to the account.
## Step 3: Add API data To analyze and secure your APIs, Akto needs to access your API traffic. You can add this using any of our supported traffic connectors. 1. In the dashboard, look for the `Quick start`
2. Choose your preferred traffic connector from the available options 3. Follow the specific instructions for your chosen connector to start feeding API traffic into Akto
For a full list of supported traffic connectors and detailed integration instructions, visit our [Traffic Data Sources](https://docs.akto.io/traffic-connections/traffic-data-sources) page. ## Step 4: Run test Once you've added your API traffic, you can start running security tests: 1. In the dashboard, click on the "Run Test" button and a modal will pop up, allowing you to select the Tests categories and type of tests you want to test on your collection. 2. Once you select the above, click the "Run once now" button in the modal.
2. You'll be re-directed to the Test Results page – you can view all the test results, including any potential vulnerabilities or issues detected in your APIs
### Need Help? Our support team is ready to assist you in maximizing your API security with Akto Cloud. [Contact Support](mailto:support@akto.io) # FAQs on data concerns ### Is Akto secure? Where's my data stored? ✅ **We treat security seriously at Akto.** Yes, your data is secure, and doesn't leave your cloud. With our self hosted deployment, that you can deploy yourself, in your own VPC, on your own VPS. That way, you are fully in control of the Akto instance, and your data never leaves your VPC. ### What sort of data does Akto store? No data goes out of your VPC. Within your VPC, only metadata concerning your usage is stored, such as: * Usage metrics of Akto users * List of endpoint urls * Key names of request and response only {% hint style="info" %} **Your real-time traffic data is NOT stored by Akto. The traffic data is discarded as soon as it is processed in less than an hour.** {% endhint %} ### What data does Akto read? Akto reads a duplicated stream of your traffic to analyze APIs. After reading, Akto discards the data immediately after processing. We have set a hard limit of 1 hour for traffic data retention. Again, all this is happening in your VPC and no data goes out. ### What outgoing calls happen from within my Akto setup? Akto setup is done is a private subnet which should have internet connectivity (usually via NAT Gateway). We strongly recommend you use a private subnet in Akto setup so that it is NOT reachable from outside your VPC. The outgoing internet-connectivity is required so that we can - 1. Download setup-related files from GitHub & images from DockerHub 2. Send Slack & email (Sendgrid) alerts for new endpoints and security test failures 3. Use AktoGPT. Read [here](https://docs.akto.io/aktogpt#data-concerns) about data concerns # Ask Akto Self-Hosted Deployment ## **Overview** **Ask Akto** is an AI-powered conversational assistant integrated into Akto's security platform that enables users to have real-time conversations about API vulnerabilities, test results, and security insights.
## Key Capabilities * **Interactive Vulnerability Analysis**: Ask questions about test results and vulnerabilities in natural language * **Agentic and agentic AI security Guidance**: Get AI-powered remediation suggestions and security best practices * **Scan Result Analysis**: Deep-dive into why scans passed/failed with AI assistance * **Dashboard Metrics Discussion**: Analyse API collections, endpoints, and risk scores * **Conversation History**: Track and search through past security discussions * **Multi-Conversation Support**: Maintain separate conversation threads for different contexts ## Pre-requisites * Docker and Docker Compose installed * Anthropic API Key * Akto API Security Dashboard running (self-hosted instance) ## Deployment Setup {% stepper %} {% step %} **Create the Deployment Directory** Create a directory that stores the Docker Compose configuration and environment files. ``` mkdir -p ~/akto-agentic-testing cd ~/akto-agentic-testing ``` The directory acts as the working location for the deployment. {% endstep %} {% step %} **Create Docker Compose File** Create a `docker-compose.yml` file with the following configuration: ```yaml version: '3.8' services: agent-testing: container_name: agent-testing image: public.ecr.aws/aktosecurity/akto-agentic-testing:latest ports: - "5500:5500" env_file: - ./docker-agentic-testing-dashboard.env restart: always mcp-server: container_name: mcp-server image: public.ecr.aws/aktosecurity/akto-agentic-testing:mcp_latest ports: - "4000:4000" env_file: - ./docker-mcp-server.env restart: always ``` The Docker Compose configuration defines two services: * **agent-testing** – runs the AI-driven Agentic engine. * **mcp-server** – provides the MCP interface used by the AI agent. {% endstep %} {% step %} **Create Environment Files** Two environment files configure runtime behavior for the containers. **Environment File for Agent Testing Service** Create a file named: `docker-agentic-testing-dashboard.env` ```bash # Anthropic API Configuration ANTHROPIC_API_KEY= # Node Environment NODE_ENV=production # Agent Testing Service Port PORT=5500 # Enable Agentic Mode AGENTIC_MODE=true # MCP Server Connection MCP_SERVER_URL=http://: ``` **Environment variables**
VariablePurpose
ANTHROPIC_API_KEYAPI key used for accessing Anthropic Claude models.
PORTPort exposed by the agent-testing service. Default value: 5500.
MCP_SERVER_URLURL used by the agent-testing service to communicate with the MCP server.
Replace <YOUR_MCP_SERVER_HOST> and <YOUR_MCP_SERVER_PORT> with the MCP server host and port configured in the deployment environment.
**Environment File for MCP Server** Create a file named: `docker-mcp-server.env` ```bash # Dashboard Connection AKTO_BASE_URL=http://: # MCP Server Configuration MCP_MODE=internal MCP_API_KEY="abc" # Debug Logging DEBUG=true ``` **Environment variables**
VariablePurpose
AKTO_BASE_URLBase URL of the Akto Agentic AI Security Dashboard.
Replace <YOUR_AKTO_DASHBOARD_HOST> and <PORT> with the hostname and port configured in the on-prem deployment.
MCP_MODEDeployment mode of the MCP server. Value internal is used for on-prem environments.
MCP_API_KEYAuthentication key used for MCP server access.
{% endstep %} {% step %} **Start the Services** ```bash # From the deployment directory docker-compose up -d # Verify services are running docker-compose ps ``` Expected output: ``` NAME STATUS PORTS agent-testing Up ... 0.0.0.0:5500->5500/tcp mcp-server Up ... 0.0.0.0:4000->4000/tcp ``` {% endstep %} {% step %} **Verify Connectivity** You can verify that both services started successfully by checking the health endpoints. **Agent Testing Service** ```bash curl http://:/health ``` **MCP Server** ```bash curl http://:/health ``` {% endstep %} {% endstepper %} ## Usage Once deployed, **Ask Akto** can be accessed through the API Security Dashboard: 1. Navigate to your Akto dashboard 2. Access the **Ask Akto** feature section 3. Start conversing with the agent. ## Support If you need help with the deployment: * **Discord Community**: Join our community at [discord.gg/Wpc6xVME4s](https://discord.gg/Wpc6xVME4s) * **Email Support**: Contact us at Our team is available 24/7 to assist you with setup, troubleshooting, and best practices. # Run with GitHub Copilot ## Overview You can run Ask Akto with GitHub Copilot as the underlying AI model using the **Bring Your Own Model** configuration. This lets you power your on-prem Ask Akto assistant with GitHub Copilot instead of Anthropic Claude. {% hint style="info" %} You can use this integration only with **on-premises deployments**. {% endhint %} ## Before You Begin Make sure you have: * A running self-hosted Ask Akto deployment if you don't have one yet, follow the [Self-Hosted Deployment](/getting-started/ask-akto-self-hosted-deployment) guide first * Your GitHub Copilot access with a valid API key * Admin access to your Akto dashboard * The following variable added to your **Akto API Security Dashboard env file**, and the service restarted to apply it: ```bash AKTO_MCP_SERVER_URL= ``` {% hint style="warning" %} Although the env var is named `AKTO_MCP_SERVER_URL`, the value should point to your **Agentic Testing module URL**. {% endhint %} ## Configuration {% stepper %} {% step %} ### **Generate Your GitHub Copilot API Key** You need a GitHub **fine-grained personal access token** to authenticate with GitHub Copilot. Here's how to generate one: 1. Go to [github.com](https://github.com) and click your **profile picture** → **Settings** 2. Scroll to the bottom of the left sidebar and click **Developer settings** 3. Go to **Personal access tokens** → **Fine-grained tokens** 4. Click **Generate new token** 5. Give your token a recognisable name (e.g., `akto-copilot`) and set an expiration that suits your policy 6. Under **Permissions** → **Account permissions**, add the following three permissions, all set to **Read-only**: * **Copilot Chat** * **Copilot Editor Context** * **Copilot Requests**
7. Click **Generate token** at the bottom 8. **Copy your token immediately-** GitHub will only show it once You'll use this token as your API key in the next step. {% endstep %} {% step %} ### **Configure GitHub Copilot as Your Model** Add your token to Akto so it can call GitHub Copilot: 1. In your Akto dashboard, go to **Settings → Integrations → Agents** 2. Click **Add Model** 3. Select **GitHub Copilot** as the provider 4. Enter a **Name**, paste your token into the **API Key** field, and pick a supported **Model** 5. Click **Save.** {% hint style="warning" %} ## NOTE Only models that your GitHub Copilot subscription has access to will work. While configuring, make sure to pick a model that's actually available to you. {% endhint %} {% endstep %} {% step %} ### **Update Your Environment File** Open your `docker-agentic-testing-dashboard.env` file and update it with the values below. These override the defaults you set during the [base deployment](/getting-started/ask-akto-self-hosted-deployment#deployment-setup): ```bash # Leave this empty — you're using GitHub Copilot as your model provider ANTHROPIC_API_KEY="" NODE_ENV=production PORT=5500 AGENTIC_MODE=true MCP_SERVER_URL= # Required when you're using GitHub Copilot DASHBOARD_URL= AKTO_API_KEY= ``` **What you need to set (GitHub Copilot specific)**
VariableWhat to set
ANTHROPIC_API_KEYLeave it empty - you're using GitHub Copilot instead. (Used for Claude models when GitHub Copilot is not configured)
AGENTIC_MODEMust be set to true.
MCP_SERVER_URLYour Akto MCP server URL.
DASHBOARD_URLYour Akto Agentic AI Security Dashboard's base URL.
AKTO_API_KEYYour Akto API key for authenticating with the Akto dashboard. Generate it from Settings → Integrations → Automation → Akto API.
{% hint style="warning" %} Make sure you add **all** of the environment variables listed above — including the empty ones like `ANTHROPIC_API_KEY=""`. Missing any of them might cause the service to misbehave or fail to start. {% endhint %} {% endstep %} {% step %} ### **Restart Your Services** Restart your services to apply the updated environment file: ```bash docker compose down && docker compose up -d ``` To confirm everything is running, follow the Verify Connectivity steps from the base deployment guide. {% endstep %} {% endstepper %} ## Support If you need help with the deployment: * **Discord Community**: Join our community at [discord.gg/Wpc6xVME4s](https://discord.gg/Wpc6xVME4s) * **Email Support**: Contact us at Our team is available 24/7 to assist you with setup, troubleshooting, and best practices. # Traffic Data Sources ### Kubernetes
Kubernetes DaemonsetYou can deploy Akto in Kubernetes and collect traffic through a daemonset on your Kubernetes configuration./files/SUahjM9YtaKPVT6M2M1Q/pages/iYvzrAu7CguT468kXVb9
OpenShiftOpenShift should be used as a traffic connector if you are deploying and managing containerized applications using OpenShift./files/nVRId7uQzAUSVaKCDl6V/pages/fKKLLFI9i7vaptlmzgr3
eBPFAkto-eBPF setup is recommended for mTLS systems when TLS termination happens at a proxy./files/Hc2nMfE7P3Qmhq3sgz1Z/pages/RdPmErdJcjf1QeMk5mm6
eBPF on mTLSAkto-eBPF-mTLS setup is recommended for mTLS systems where TLS termination occurs at the application./files/Hc2nMfE7P3Qmhq3sgz1Z/pages/M5a5Pe1qvWEsrgZAJMu2
### API Gateways
ApigeeApigee setup is recommended if you are using Google's Apigee API Management platform to design, secure, and scale your APIs./pages/JH1OmW8yIqKZDHN84CpE/files/6Ab9i1dd0vPEhGPDpGce
Azure API GatewayAzure API Gateway setup is recommended if you are using Azure's API Management service to manage, secure, and analyze your APIs./pages/v3ndPVrKjVABS1z6YBYo/files/smHwrrSwoMrJJo5QGIAF
CloudflareYou should use Cloudflare as a traffic connector if you are leveraging Cloudflare's CDN and security features to manage and optimize your API traffic./pages/dJ9wIuhlODMmYau7jFuY/files/yBhps5Nv6uRZDAAbQEM0
F5F5 setup is recommended if you are using F5's BIG-IP as an API gateway or load balancer to manage and control your API traffic./pages/ZGoj62PYmbhZ52J0JojO/files/w8zod5p0yfxgqknnecJ3
Kong MeshUse this set-up if you are utilizing Kong's service mesh capabilities to manage and secure your microservices and APIs./pages/8c5doDurdWdXUcDvjqF9/files/C1znPLGuz3ZC6FpE9V8G
Layer 7Layer7 is recommended if you are using CA Technologies' Layer7 API Management for securing and managing your APIs./pages/sT0HIvPUetPr0apcFPNA/files/5eJZswceZRbfrnY3ZjoZ
3ScaleThis setup is recommended if your APIs are managed by 3scale./pages/HqIHtWu74Mmtpm8chqIg/files/jJWoLOITRqT7rrfW2Mys
NGINXThis setup is recommended if your APIs are routed by NGINX./pages/B9s3MOHZYWm7tShmZynP/files/i4U09YR0RDXQZPPBkocn
HA ProxyHA Proxy should be used as a traffic connector if you are leveraging HA Proxy for load balancing, high availability, and proxying HTTP and TCP-based applications./pages/CGn9ZF3FaNGesxd30wQq/files/JBLpuuNGG00Qg7fVBGdf
EnvoyAkto-Envoy setup is recommended if your APIs are routed by Envoy./pages/PRFkHXiJ8XYmrsmPSeP5/files/TTSiw2CAEUs1iw1PFhoF
IstioAkto-Istio setup is recommended if your APIs are routed by Istio./pages/rxSll4erNY2bzmW51uBO/files/Dxna5GoZsp142BlQyXEV
KongKong Gateway is an open source API gateway, built for multi-cloud and hybrid, and optimized for microservices and distributed architectures./pages/sVAm3aCwHelRqrjejxEp/files/C1znPLGuz3ZC6FpE9V8G
IBM API ConnectThis setup is recommended if your APIs are managed by IBM API Connect/pages/46iC7R1ZUqCnBSV02ERr/files/IdDWeooTzXj4LaosGfRP
CitrixCitrix setup is recommended if you are using ADC (NetScaler) to manage, secure, and optimize your API traffic./pages/kAVrDIzBCMElRb7vT2Zy/files/EB8rTIdBDT5fAKWTxgDe
Azure App ServicesAzure App Services setup is recommended if you are using Microsoft's web app service with sidecar containers to collect and analyze your API traffic./pages/VsFPYKjZ8CRk9G0qm2rl/files/7yob8JEKLTi2rQuyNI22
MuleSoftMulesoft setup is recommended if you are using API management and ESB capabilities to manage, secure, and analyze your APIs./pages/TCOVJCetYq9oeiMwifLn/files/XHBEdqaVgfZ1GqbreVLP
### Mirroring
AWS MirroringYou can deploy Akto in AWS and collect traffic through traffic mirroring./pages/gPEp4kGRJ7Rtg2ohCdya/files/0uE9KlR9LGYUP3T3rqW9
GCP MirroringThis setup only takes ten minutes. Once you connect GCP, Akto will process GCP traffic to create an API Inventory in real time./pages/2KiafZeeb7QaXst0NezO/files/ow0Zcz0rNTDoRYXSRLNV
### AWS Services
AWS API GatewayAkto-AWS-API-Gateway setup is recommended if you are using AWS API Gateway./pages/qyVRTH58h7efOmEcf7ED/files/hz7o6hpr2N4ESHMhfa7d
AWS EKSYou can deploy Akto in AWS and collect traffic through a daemonset on your AWS EKS configuration./pages/yIylQBR0fp8zTQKdgzdW/files/7LWdCFyhOEADLpFrxQVj
AWS FargateAWS Fargate allows you to use Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances./pages/XoPLBuQy8P5g4Zau300e/files/LjRBZruh6ly88LAAnib0
AWS BeanstalkYou can deploy Akto in AWS and collect traffic through mirroring on your AWS Beanstalk setup./pages/CIOAzaPZUptJbvnXn0LE/files/jm8B59aTEjffhUWRadtI
AWS ECSYou can deploy Akto in AWS and collect traffic through containers on your AWS ECS cluster./pages/sf4YnyRTX16CUS3UAmUq/files/EpSyKE932B2Oi25oczYW
### GCP Services
GCP MirroringThis setup only takes ten minutes. Once you connect GCP, Akto will process GCP traffic to create an API Inventory in real time./files/ow0Zcz0rNTDoRYXSRLNV/pages/wigUw3mbYC6Nz0HuIs0E
ApigeeApigee setup is recommended if you are using Google's Apigee API Management platform to design, secure, and scale your APIs./files/6Ab9i1dd0vPEhGPDpGce/pages/NEBGlgXefxobvny74tUQ
Google Cloud Run FunctionsThis setup is recommended if your applications are deployed using Google Cloud Run Functions./files/imVFyuoqcF8QflRtbYZL/pages/cvYGgdp2ZkLvyTBMDoNc
Google Cloud RunGoogle Cloud Run setup is recommended if you are using Google's serverless platform./files/xc0TYTrjrWeLkQblkdfU/pages/1GN3BuQNPpHTsCluIRMY
GKEThis setup is recommended if you are running containerized applications on Google Kubernetes Engine./files/Udhp8xY7NUScb2ys8q1u/pages/h0RPMVnwFoLJfaYRPqnW
### Azure Services
Azure App ServicesAzure App Services setup is recommended if you are using Microsoft's web app service with sidecar containers to collect and analyze your API traffic./files/7yob8JEKLTi2rQuyNI22/pages/VsFPYKjZ8CRk9G0qm2rl
Azure API MangementThis setup is recommended if you are using Azure's API Management service to manage, secure, and analyze your APIs./files/smHwrrSwoMrJJo5QGIAF/pages/v3ndPVrKjVABS1z6YBYo
AKSThis setup is recommended if you are deploying applications on Azure Kubernetes Service./files/5CKpKGAGvt1DN8vlA8CG/pages/slO4npAmojBBF31jCC3L
Azure OpenShiftAzure OpenShift setup is recommended if your containerized applications are running on Azure Red Hat OpenShift./files/nVRId7uQzAUSVaKCDl6V/pages/76wp1H3nt8EL3vQOkVGI
Azure Container AppThis setup is recommended if your applications are deployed using Azure Container Apps./files/SBX5aX4QrvD55Ry70CuR/pages/XHr4AM6sad4ymTmGIVJv
Azure FunctionsAzure Functions setup is recommended if you are using Azure's serverless compute service./files/39T8kuIVMSC1esh9AfyF/pages/tDtpNViMhmxQUC6pWote
### Akto SDK
GoUse where Go-based services are deployed.https://github.com/akto-api-security/gomiddleware/files/16SKUyUzf7JclMIsBijC
JavaYou can use Akto's Java agent to capture API traffic directly from your Java applications.https://github.com/akto-api-security/java-servlet-api-logging/files/98SnyJNtnZN1vTJymYQX
NodeJSThis setup is ideal for environments where NodeJS-based services are deployed, ensuring seamless integration and real-time traffic monitoring.https://github.com/akto-api-security/express-api-logging/files/B8y0GYEudKXuIstZEN33
PythonUse where Python-based services are deployed.https://github.com/akto-api-security/flask-middleware/files/E3t5YSqWYEvJVcHWaLTf
### Virtual Machines
DockerThis setup is recommended only if other setups for AWS or GCP don't work./pages/AWqylABCOebwFeGqNKoY/files/GT9vFe88RRDSRAFg4mV5
eBPF (bare Linux, TLS)Install the dockerless eBPF tarball on a Linux VM or host to capture TLS traffic without Docker./pages/PErYME4f8pbFIfAp3eWr/files/Hc2nMfE7P3Qmhq3sgz1Z
TCP AgentThis setup is recommended only if other setups for AWS or GCP do not work./pages/LfCPeVu7n0LxxvKIge92/files/q2UamY2Tz2mdBBXyqM0d
### Workflow Automation ### Manual
Burp SuiteYou can deploy Akto on your machine and download Akto's Burp extension to collect API traffic./pages/7V0Vb2dSF6b6e9ZgpYDE/files/eT86MG6BQqmu90TYN7pp
PostmanThis setup is recommended if you have updated API collections maintained in Postman./pages/r9NB0Eo9o2fanTsdKbUi/files/RPakkKe31PPyMjAWnycr
Har File UploadFor a very quick view of your inventory, you can upload a HAR file that contains traffic to Akto./pages/Fm01z3tJSCUKJg2czoa7/files/IqWGyX3shOzIJ1pkzYtT
OpenAPIUpload Open API/Swagger specification file to Akto to create an API inventory./pages/gwLedSLOPVhMScIUiSbR/files/C0TawNtOZLlnDBMtPrIm
SOAP APIUpload WSDL file using Postman to Akto to create an API inventory./pages/NQaqlbKNlswoHdgUQvzM/files/v3PLeg2wrmwehDC5acJD
### Third Party Software
ImpervaImport API definitions discovered by Imperva into Akto's API inventory./pages/DdpTh79DoD4cy3cEvduE/files/iwzczepERECVS2bUsAVF
WizConnect Wiz as a traffic source to periodically import API endpoints discovered by Wiz into Akto's API inventory./pages/o4d9avpsQhsDtMRxdoxm#connect-wiz-traffic-source/files/l5qY7YOg2PUWUDUKcUy9
# eBPF # Connect Akto with eBPF ## Introduction Connecting with Akto's eBPF traffic collector is recommended for mTLS systems. For a better understanding, here's an architecture diagram of the setup.
Deployment for Akto Daemonset

ebpf Deployment

## Adding Akto traffic collector {% stepper %} {% step %} Setup Akto data processor using the guide [here](/getting-started/quick-start-with-akto-cloud/hybrid-saas) {% endstep %} {% step %} Apply the Daemonset configuration given below using `kubectl apply -f akto-daemonset-config.yaml -n `. You will find `AKTO_NLB_IP` after setting up Akto data processor, as mentioned above. {% hint style="success" %} ### eBPF CO-RE Image Option Alternatively, you can use the eBPF CO-RE image for environments where kernel headers are unavailable or kernel versions vary across nodes. ``` public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf_core ``` Just update the `image` field in the YAML below with the CO-RE image URL to use this variant. {% endhint %} ```yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet hostPID: true containers: - name: mirror-api-logging image: public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf resources: limits: cpu: 500m memory: 1Gi requests: cpu: 50m memory: 50Mi env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_KAFKA_BROKER_MAL value: ":9092" - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name securityContext: capabilities: add: - SYS_PTRACE - SYS_ADMIN privileged: true volumeMounts: # needed to load kernel headers - name: lib-modules mountPath: /lib/modules readOnly: true # needed to trace kernel events - name: sys-kernel mountPath: /sys/kernel readOnly: true - name: host mountPath: /host readOnly: true volumes: - name: sys-kernel hostPath: path: /sys/kernel - name: lib-modules hostPath: path: /lib/modules - name: host hostPath: path : / ``` {% endstep %} {% step %} For example, if you've deployed `akto-mini-runtime` using akto's helm charts in `akto` namespace, the `AKTO_NLB_IP` would be `akto-mini-runtime-mini-runtime.akto.svc.cluster.local` . {% endstep %} {% step %} You can add and configure the env variables below to control the daemonset. Here's a diagram of how the module processes traffic:
Traffic processing

eBPF Traffic Processing

```yaml # This helps in filtering traffic sent to akto, based on certain headers. Here is an example for sending traffic only for 'bookinfo' namespace in an istio setup. - name: AKTO_MODULE_DISCOVERY_CONFIG value: '[{"key":{"eq":"x-forwarded-client-cert","ifAbsent":"reject"},"value":{"regex":".*bookinfo.*"}}]' # Time limit ( in seconds ) after which, a traffic stream is processed and marked inactive. The same stream, is not processed again. - name: TRAFFIC_INACTIVITY_THRESHOLD value: "3" # Max traffic connections kept in memory - name: TRAFFIC_MAX_ACTIVE_CONN value: "4096" # Make this flag true to disable egress traffic. It is recommended to keep this false. - name: TRAFFIC_DISABLE_EGRESS value: "false" # Max mem usage after which the pod restarts ( in MB ) - name: AKTO_MEM_THRESH_RESTART value: "500" # Max limit of traffic buffer kept in memory ( in MB ) - name: TRAFFIC_BUFFER_THRESHOLD value: "400" # Ignore traffic coming from unresolved IPs, i.e. requests with host header of the format - name: AKTO_IGNORE_IP_TRAFFIC value: "false" # Ignore traffic coming from AWS cloud metadata IP - name: AKTO_IGNORE_CLOUD_METADATA_CALLS value: "false" # If you only want to trace traffic for which SSL termination happens at proxy/service. - name: CAPTURE_ALL value: "true" ``` {% endstep %} {% step %} You can check your `API inventory` on Akto dashboard to see endpoints being discovered. {% endstep %} {% endstepper %} ## Frequently Asked Questions (FAQs) **The traffic will contain a lot of sensitive data - does it leave my VPC?** Data remains strictly within your VPC. Akto doesn't take data out of your VPC at all. **Does adding DaemonSet have any impact on performance or latency?** Zero impact on latency. The DaemonSet doesn't sit like a proxy. It works on eBPF technology, which works on traces function calls at kernel level. It is very lightweight. We have benchmarked it against traffic as high as 20M API requests/min. It consumes very low resources (CPU & RAM). **How can I control logs generated by akto's eBPF traffic collector ?** You can utilize the `AKTO_LOG_LEVEL` environment variable, which accepts `DBEUG`, `INFO`, `WARN`, `ERROR`, `OFF` as log levels.\ Default level is set to `WARN`. **I don't see my error on this list here.** Please send us all details at or reach out via Intercom on your Akto dashboard. We will definitely help you out. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with eBPF on mTLS ## Introduction If your kubernetes system, has mTLS ( say using istio proxy or similar setup ) and SSL termination happens at the proxy/service, [this other setup](/traffic-connector/ebpf/ebpf) is recommended, please check it out. If your proxy/service acts as a passthrough and the SSL termination happens at the end application itself, then please continue with the current setup. Please note, both these setups have `different docker images`. In case of any queries, please reach out to us at `help@akto.io` . Connecting with Akto's eBPF traffic collector is recommended mTLS systems where TLS termination occurs at application ( a system where your services are just passing the traffic directly to the application ). For a better understanding, here's an architecture diagram of the setup.
Deployment for Akto Daemonset

ebpf Deployment

## Adding Akto traffic collector 1. Setup Akto data processor using the guide [here](/getting-started/quick-start-with-akto-cloud/hybrid-saas) 2. Apply the daemonset configuration given below using `kubectl apply -f akto-daemonset-config.yaml -n `. You will find `AKTO_NLB_IP` after setting up Akto data processor, as mentioned above. ```yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: false dnsPolicy: ClusterFirstWithHostNet hostPID: true containers: - name: mirror-api-logging image: public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf resources: limits: cpu: 500m memory: 1Gi requests: cpu: 50m memory: 50Mi env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_KAFKA_BROKER_MAL value: ":9092" securityContext: capabilities: add: - SYS_PTRACE - SYS_ADMIN privileged: true volumeMounts: # needed to load kernel headers - name: lib-modules mountPath: /lib/modules readOnly: true # needed to trace kernel events - name: sys-kernel mountPath: /sys/kernel readOnly: true # needed to trace SSL user libraries - name: host mountPath: /host readOnly: true volumes: - name: sys-kernel hostPath: path: /sys/kernel - name: lib-modules hostPath: path: /lib/modules - name: host hostPath: path : / ``` If you are on VMs or EC2s instead of a K8s cluster, you can use the following docker command to run the agent - ``` docker run --rm -d \ --name mirror-api-logging \ --network host \ --pid host \ --privileged \ --cap-add SYS_PTRACE \ --cap-add SYS_ADMIN \ --cpus="0.5" \ --memory="512m" \ -e AKTO_TRAFFIC_BATCH_TIME_SECS=10 \ -e AKTO_TRAFFIC_BATCH_SIZE=100 \ -e AKTO_KAFKA_BROKER_MAL=":9092" \ -e PROBE_ALL_PID=true \ -v /usr/src:/usr/src:ro \ -v /lib/modules:/lib/modules:ro \ -v /sys/kernel:/sys/kernel:ro \ -v /:/host:ro \ public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf ``` For `AKTO_NLB_IP` , Use the service IP or load balancer name of Traffic Processor from step (1) 3. You can add and configure the env variables below to control the daemonset. Here's a diagram of how the module processes traffic:
Traffic processing

eBPF Traffic Processing

```yaml # This helps in filtering traffic sent to akto, based on certain headers. Here is an example for sending traffic only for 'bookinfo' namespace in an istio setup. - name: AKTO_MODULE_DISCOVERY_CONFIG value: '[{"key":{"eq":"x-forwarded-client-cert","ifAbsent":"reject"},"value":{"regex":".*bookinfo.*"}}]' # Time limit ( in seconds ) after which, a traffic stream is processed and marked inactive. The same stream, is not processed again. - name: TRAFFIC_INACTIVITY_THRESHOLD value: "3" # Max traffic connections kept in memory - name: TRAFFIC_MAX_ACTIVE_CONN value: "4096" # Make this flag true to disable egress traffic. It is recommended to keep this false. - name: TRAFFIC_DISABLE_EGRESS value: "false" # Max mem usage after which the pod restarts ( in MB ) - name: AKTO_MEM_THRESH_RESTART value: "500" # Max limit of traffic buffer kept in memory ( in MB ) - name: TRAFFIC_BUFFER_THRESHOLD value: "400" # Ignore traffic coming from unresolved IPs, i.e. requests with host header of the format - name: AKTO_IGNORE_IP_TRAFFIC value: "false" # Ignore traffic coming from AWS cloud metadata IP - name: AKTO_IGNORE_CLOUD_METADATA_CALLS value: "false" # The interval poll ( in minutes ) in which the akto module scans the current running processes, to check for new SSL related processes to probe. - name: UPROBE_POLL_INTERVAL value: 20 # If you only want to trace traffic for which SSL termination happens at proxy/service. - name: CAPTURE_ALL value: "true" # If you only want to trace traffic for which SSL termination happens at application. # Note: when CAPTURE_ALL is false and CAPTURE_SSL is true, only application traffic is captured. - name: CAPTURE_SSL value: "true" ``` 4. You can check your `API inventory` on Akto dashboard to see endpoints being discovered. ## Notes: 1. If you're running the daemonset outside of the kubernetes system, set the env `PROBE_ALL_PID` as `true`. ## Frequently Asked Questions (FAQs) **The traffic will contain a lot of sensitive data - does it leave my VPC?** Data remains strictly within your VPC. Akto doesn't take data out of your VPC at all. **Does adding DaemonSet have any impact on performance or latency?** Zero impact on latency. The DaemonSet doesn't sit like a proxy. It works on eBPF technology, which works on traces function calls at kernel level. It is very lightweight. We have benchmarked it against traffic as high as 20M API requests/min. It consumes very low resources (CPU & RAM). **I don't see my error on this list here.** Please send us all details at or reach out via Intercom on your Akto dashboard. We will definitely help you out. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Akto eBPF Traffic Collector Platform Specific This document is for **clients** who install the **dockerless** eBPF bundle (Go binary + module.cc(bcc) + shell wrappers), distributed as a versioned **`.tar.gz`**. Tarball naming convention: `akto-mirroring-module----.tar.gz` *** ## Platform Downloads | Platform | Download URL | | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Amazon Linux 2 — kernel 5.10, x86\_64 | `https://akto.blob.core.windows.net/traffic-collector-binaries/akto-mirroring-module-1.0.0-amzn2-5.10-x86_64.tar.gz` | | Amazon Linux 2023 — kernel 6.1, x86\_64 | `https://akto.blob.core.windows.net/traffic-collector-binaries/akto-mirroring-module-1.0.0-amzn2023-6.1-x86_64.tar.gz` | | Amazon Linux 2023 — kernel 6.1, aarch64 | `https://akto.blob.core.windows.net/traffic-collector-binaries/akto-mirroring-module-1.0.0-amzn2023-6.1-aarch64.tar.gz` | Contact Akto for a download URL if your platform is not listed. *** ## Install ### 1. Download the archive Use the platform-specific URL from the table above. ```bash wget -O akto-mirroring-module----.tar.gz "" ``` (`curl -fL "" -o akto-mirroring-module----.tar.gz` works the same way.) ### 2. Unpack (default layout: `/ebpf`) As **root** (paths in the archive are rooted at `ebpf/`): ```bash sudo mkdir -p /ebpf && sudo tar -xzf akto-mirroring-module----.tar.gz -C /ebpf --strip-components=1 ``` This creates **`/ebpf/`** including: | Path | Role | | ------------------------------------ | ------------------------------------------------------------------------- | | `ebpf/ebpf-logging` | Main Go binary | | `ebpf/---setup.sh` | Platform-specific prerequisite script (e.g. `amzn2-5.10-x86_64-setup.sh`) | | `ebpf/kernel/module.cc` | C kernel code | | `ebpf/ebpf-bcc-run.sh` | Supervisor loop | | `ebpf/run-ebpf-bcc-host.sh` | Host entrypoint (sudo wrapper; **detached by default**) | | `ebpf/uninstall-ebpf-bcc-host.sh` | Stops processes; leaves `${EBPF_ROOT}` on disk | | `ebpf/.env` | Default environment (edit before production) | If you install under a **different** directory, set **`EBPF_ROOT`** consistently (see below) and keep **`ebpf-bcc-run.sh`** and **`.env`** together under that directory. ### 3. Run platform prerequisites The tarball includes a platform-specific setup script that installs required kernel headers and BCC libraries. This must be run before akto ebpf module is started everytime. Run it once after unpacking: | Platform | Script | | --------------------------------------- | ----------------------------------------------- | | Amazon Linux 2 (kernel 5.10, x86\_64) | `sudo bash /ebpf/amzn2-5.10-x86_64-setup.sh` | | Amazon Linux 2023 (kernel 6.1, x86\_64) | `sudo bash /ebpf/amzn2023-6.1-x86_64-setup.sh` | | Amazon Linux 2023 (kernel 6.1, aarch64) | `sudo bash /ebpf/amzn2023-6.1-aarch64-setup.sh` | For reference, upstream BCC installation docs: ### 4. Configure Edit **`/ebpf/.env`** (or **`${EBPF_ROOT}/.env`**). At minimum set **`AKTO_KAFKA_BROKER_MAL`** to your broker (replace the `` placeholder in the shipped template). Typical bare-metal defaults in that file: * **`EBPF_ROOT=/ebpf`** — bundle root. * **`HOST_MAPPING=/`** — host path prefix (use **`/host`** when running inside Docker with `-v /:/host`). * **`ENABLE_LOGS=false`** / **`LOG_FILE=/ebpf/dump.log`** — shipped defaults; if you change **`EBPF_ROOT`**, set **`LOG_FILE`** under that directory (for example **`/opt/akto/ebpf/dump.log`**). ### 5. Run (detached by default) `run-ebpf-bcc-host.sh` starts the supervisor under **`nohup`** and returns immediately. It writes **`${EBPF_ROOT}/ebpf-bcc-run.pid`**. **`nohup.out`** is not used. With **`ENABLE_LOGS=false`**, **`ebpf-bcc-run.sh`** attaches non-TTY stdout/stderr to **`LOG_FILE`** (see **`.env`** / **`MAX_LOG_SIZE`** for rotation). ```bash sudo /ebpf/run-ebpf-bcc-host.sh ``` Follow logs: * **`ebpf-bcc-run.sh`** shell output (memory lines, restarts) and collector when **`ENABLE_LOGS=false`** (bundle default): `tail -f /ebpf/dump.log` or override **`LOG_FILE`** in **`.env`** Attach to the supervisor in the foreground (blocks this shell), for debugging: ```bash sudo /ebpf/run-ebpf-bcc-host.sh -f # or: sudo AKTO_FOREGROUND=true /ebpf/run-ebpf-bcc-host.sh ``` Or with a non-default install root: ```bash sudo EBPF_ROOT=/opt/akto/ebpf /opt/akto/ebpf/run-ebpf-bcc-host.sh ``` Ensure **`EBPF_ROOT`** in the environment matches **`EBPF_ROOT`** in **`.env`** when you use a custom path. ### 6. Uninstall Stops **`ebpf-bcc-run.sh`** / **`ebpf-logging`** for this install (using the pidfile when present, then matching processes). It does **not** remove **`EBPF_ROOT`**. ```bash sudo /ebpf/uninstall-ebpf-bcc-host.sh -y ``` Custom root: ```bash sudo EBPF_ROOT=/opt/akto/ebpf /opt/akto/ebpf/uninstall-ebpf-bcc-host.sh -y ``` Omit **`-y`** for an interactive confirmation (requires a TTY). #### What’s Happening Behind the Scenes? * **eBPF hooks into your Linux kernel** to capture real-time traffic—even if it’s encrypted (TLS). * No code changes, no traffic proxying, no SSL termination. * The collector forwards API traces to Akto for real-time inventory and security analysis. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Kubernetes # Connect Akto with Kubernetes in AWS Learn how to send API traffic data from your Kubernetes cluster to Akto. ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). One such source is your Kubernetes cluster. `Kubernetes` is an open-source container orchestration system for automating software deployment, scaling, and management. You can add Akto DaemonSet to your Kubernetes cluster. It is very lightweight and will run 1 per node in your Kubernetes cluster. It will intercept alll the node traffic and send it to Akto traffic analyzer. Akto's traffic analyzer analyzes this traffic to create your application's APIs request and response, understand API metadata and find misconfigurations. Akto can work with high traffic scale though you can always configure the amount of traffic you want to send to Akto dashboard. ## Overview of Akto-Kubernetes setup
Kubernetes deployment for Akto in AWS

Kubernetes Deployment

This is how your run Akto's traffic collector on your Kubernetes nodes as DaemonSet and send mirrored traffic to Akto. ## Setting up Akto Daemonset pod on your K8s cluster 1. Setup Akto data processor using the guide [here](/getting-started/quick-start-with-akto-cloud/hybrid-saas) 2. Apply the Daemonset configuration given below using `kubectl apply -f auto-daemon set-config.yaml -n `. You will find `AKTO_NLB_IP` after setting up Akto data processor, as mentioned above. ``` apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: mirror-api-logging image: aktosecurity/mirror-api-logging:k8s_agent env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_INFRA_MIRRORING_MODE value: "gcp" - name: AKTO_KAFKA_BROKER_MAL value: ":9092" - name: AKTO_MONGO_CONN value: "mongodb://0.0.0.0:27017" ``` 2. Replace `{NAMESPACE}` with your app namespace and `{APP_NAME}` with the name of your app. If you have installed on *AWS* - * Go to EC2 > Instances > Search for `Akto Mongo Instance` > Copy private IP. * Go to EC2 > Load balancers > Search for `AktoNLB` > Copy its DNS. * Replace `AKTO_NLB_IP` with the DNS name. eg `AktoNLB-ca5f9567a891b910.elb.ap-south-1.amazonaws.com` If you have installed on *GCP*, *Kubernetes* or *OpenShift* - * Get Mongo Service's DNS name from Akto cluster * Get Runtime Service's DNS name from Akto cluster * Replace `AKTO_NLB_IP` with the DNS name. eg. `akto-api-security-runtime.p03.svc.cluster.local`
Replace namespace in text editor

Replace namespace in text editor

3. Create a file `akto-daemonset-config.yaml` with the above YAML config
4. Call `kubectl apply -f akto-daemonset-config.yaml -n ` on your *kubectl* terminal
call yaml

call yaml

5. Run the command `kubectl get daemonsets` in terminal. It should show *akto-k8s* daemonset.
Run the command

Run the command

6. Go to `API Discovery` on Akto dashboard to see your new APIs
Check API Discovery

Check API Discovery

## Frequently Asked Questions (FAQs) **The traffic will contain a lot of sensitive data - does it leave my VPC?** Data remains strictly within your VPC. Akto doesn't take data out of your VPC at all. **Does adding DaemonSet have any impact on performance or latency?** Zero impact on latency. The DaemonSet doesn't sit like a proxy. It simply intercepts traffic - very similar to tcpdump. It is very lightweight. We have benchmarked it against traffic as high as 20M API requests/min. It consumes very low resources (CPU & RAM). ## Troubleshooting Guide **When I hit apply, it says "Something went wrong". How can I fix it?** Akto runs a Cloudformation template behind the scenes to setup the data processing stack and traffic mirroring sessions with your application servers' EC2 instances. This error means the Cloudformation setup failed. 1. Go to AWS > Cloudformation > Search for "mirroring" 2. Click on Akto-mirroring stack and go to Events tab 3. Scroll down to the oldest error event. **The Cloudformation template failed with "Client.InternalError: Client error on launch.". How should I fix it?** This is a known AWS common error. Follow the steps [here](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html#ts-as-instancelaunchfailure-12). **The Cloudformation template failed with "We currently do not have sufficient capacity in the Availability Zone you requested... Launching EC2 instance failed."** You can reinstall Akto in a diff availability zone or you can go to Template tab and save the cloudformation template in a file. Search for "InstanceType" and replace all the occurrences with a type that is available in your availability zone. You can then go to AWS > Cloudformation > Create stack and use this new template to setup Traffic mirroring. **I am seeing kafka related errors in the daemonset logs** If you get an error like "unable to reach host" or "unable to push data to kafka", then do the following steps: 1. Grab the ip of the akto-runtime instance by running "kubectl get service -n {NAMESPACE}" 2. Use helm upgrade to update the value of `kafkaAdvertisedListeners` key to `LISTENER_DOCKER_EXTERNAL_LOCALHOST://localhost:29092,LISTENER_DOCKER_EXTERNAL_DIFFHOST://{IP_FROM_STEP_1}:9092` 3. Put the same ip against the `AKTO_KAFKA_BROKER_MAL` as `{IP_FROM_STEP_1:9092}` in the daemonset config and reapply the daemonset config. **I don't see my error on this list here.** Please send us all details at or reach out via Intercom on your Akto dashboard. We will definitely help you out. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto eBPF with Kubernetes ## Introduction Connecting with Akto's eBPF traffic collector is recommended for mTLS systems. For a better understanding, here's an architecture diagram of the setup.
Deployment for Akto Daemonset

ebpf Deployment

## Adding Akto traffic collector 1. Setup Akto data processor using the guide [here](/getting-started/quick-start-with-akto-cloud/hybrid-saas) 2. Apply the Daemonset configuration given below using `kubectl apply -f auto-daemon set-config.yaml -n `. You will find `AKTO_NLB_IP` after setting up Akto data processor, as mentioned above. ```yaml --- apiVersion: v1 kind: ServiceAccount metadata: name: pod-watcher namespace: {NAMESPACE} --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-watcher-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pod-watcher-role-binding subjects: - kind: ServiceAccount name: pod-watcher namespace: {NAMESPACE} roleRef: kind: ClusterRole name: pod-watcher-role apiGroup: rbac.authorization.k8s.io --- apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: true serviceAccountName: pod-watcher dnsPolicy: ClusterFirstWithHostNet hostPID: true containers: - name: mirror-api-logging image: public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf resources: limits: cpu: 500m memory: 1Gi requests: cpu: 50m memory: 50Mi env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_KAFKA_BROKER_MAL value: ":9092" - name: AKTO_K8_METADATA_CAPTURE value: "true" - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name securityContext: capabilities: add: - SYS_PTRACE - SYS_ADMIN privileged: true volumeMounts: # needed to load kernel headers - name: lib-modules mountPath: /lib/modules readOnly: true # needed to trace kernel events - name: sys-kernel mountPath: /sys/kernel readOnly: true - name: host mountPath: /host readOnly: true volumes: - name: sys-kernel hostPath: path: /sys/kernel - name: lib-modules hostPath: path: /lib/modules - name: host hostPath: path : / ``` 3. You can add and configure the env variables below to control the daemonset. Here's a diagram of how the module processes traffic:
Traffic processing

eBPF Traffic Processing

```yaml # This helps in filtering traffic sent to akto, based on certain headers. Here is an example for sending traffic only for 'bookinfo' namespace in an istio setup. - name: AKTO_MODULE_DISCOVERY_CONFIG value: '[{"key":{"eq":"x-forwarded-client-cert","ifAbsent":"reject"},"value":{"regex":".*bookinfo.*"}}]' # Time limit ( in seconds ) after which, a traffic stream is processed and marked inactive. The same stream, is not processed again. - name: TRAFFIC_INACTIVITY_THRESHOLD value: "30" # Max traffic connections kept in memory - name: TRAFFIC_MAX_ACTIVE_CONN value: "4096" # Make this flag true to disable egress traffic. It is recommended to keep this false. - name: TRAFFIC_DISABLE_EGRESS value: "false" # Max mem usage after which the pod restarts ( in MB ) - name: AKTO_MEM_THRESH_RESTART value: "800" # Max limit of traffic buffer kept in memory ( in MB ) - name: TRAFFIC_BUFFER_THRESHOLD value: "600" # Ignore traffic coming from unresolved IPs, i.e. requests with host header of the format - name: AKTO_IGNORE_IP_TRAFFIC value: "false" # Ignore traffic coming from AWS cloud metadata IP - name: AKTO_IGNORE_CLOUD_METADATA_CALLS value: "false" # The interval poll ( in seconds ) in which data is sent to Akto data processor. - name: KAFKA_POLL_INTERVAL value: "0.5" # If you only want to trace traffic for which SSL termination happens at proxy/service. - name: CAPTURE_ALL value: "false" ``` 4. You can check your `API inventory` on Akto dashboard to see endpoints being discovered. ### Kubernetes Pod Labels Tagging Akto traffic collector can be configured to capture Kubernetes Pod labels with each API request. It operates within the Akto eBPF DaemonSet and leverages the [Kubernetes Informer](https://pkg.go.dev/k8s.io/client-go/informers#pkg-overview) to maintain a local in-memory cache of pods running on each node. This cache is used to identify the labels of pod. #### Env Variables ```sh # This will start capturing the pod labels from all namespaces except # kube-system, kube-public and kube-node-lease - name: AKTO_K8_METADATA_CAPTURE value: "true" # Use this if you want to capture pod labels from a specific namespace only. - name: AKTO_K8_METADATA_CAPTURE_NAMESPACE value: {NAMESPACE} ``` ## Frequently Asked Questions (FAQs) **The traffic will contain a lot of sensitive data - does it leave my VPC?** Data remains strictly within your VPC. Akto doesn't take data out of your VPC at all. **Does adding DaemonSet have any impact on performance or latency?** Zero impact on latency. The DaemonSet doesn't sit like a proxy. It works on eBPF technology, which works on traces function calls at kernel level. It is very lightweight. We have benchmarked it against traffic as high as 20M API requests/min. It consumes very low resources (CPU & RAM). **How can I control logs generated by akto's eBPF traffic collector ?** You can utilize the `AKTO_LOG_LEVEL` environment variable, which accepts `DBEUG`, `INFO`, `WARN`, `ERROR`, `OFF` as log levels.\ Default level is set to `WARN`. **I don't see my error on this list here.** Please send us all details at or reach out via Intercom on your Akto dashboard. We will definitely help you out. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # API Gateways # Connect Akto with Envoy If your API calls are being routed through ENVOY, you can use Akto's ENVOY module to send traffic to Akto dashboard. This module can also be used with Istio service mesh, because it is based on ENVOY proxy. Below guide will help you do this:
## Creating AWS Policy 1\. Go to Quick Start on your Akto dashboard and expand the `Connect traffic data` section.
2\. Scroll down to `Data processors setup` section.
3\. Copy the `policy json` and click on the Akto Dashboard role link.
4\. `Click` on the `JSON` tab and `paste the policy`
5\. Click on `Review policy` button.
6\. Enter *`AktoDashboardPolicy`* as the policy name and `click` on `Create Policy` button
8\. Once the policy is created, go back to the `dashboard`. ## Setting up Data processors 1\. Click on `Setup traffic processors` button.
2\. This will bring up infra that will process your traffic.
3\. Check that you have `AKTO_NLB` var once setup is complete.
## Adding Akto traffic collector 1. Download the following [repository](https://github.com/akto-api-security/envoy-module) to the folder with envoy.yaml file and rename it as "lib". 2. Add the following lines to the docker-compose.yaml file for the envoy proxy container. ``` COPY --chmod=777 ./lib/rdkafka /rdkafka ADD --chmod=777 ./lib/aktoModule.lua /lib/aktoModule.lua RUN apt-get update -y RUN apt-get install librdkafka-dev luarocks -y RUN luarocks install lua-cjson ``` 3. Add the following lines to the envoy.yaml fie under the filters section. ``` http_filters: - name: lua_filter_with_custom_name_0 typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua default_source_code: inline_string: local aktoModule = require("lib.aktoModule") aktoModule.sendToAkto() ``` 4. Add an environment variable for AKTO\_KAFKA\_IP to the docker-compose.yaml file ``` AKTO_KAFKA_IP=:9092 ``` 5. Restart your envoy proxy container. # Connect Akto with NGINX
If your API calls are being routed through NGINX, you can use Akto's NGINX module to send traffic to Akto dashboard. Below guide will help you do this: ## Step 1: Configure Akto Traffic Processor Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). ## Step 2: Add NGINX module {% hint style="info" %} This methods is recommended when you have end to end TLS and SSL termination happens at NGINX. {% endhint %} The Akto nginx module uses the dynamic module functionality supported by nginx. This requires nginx to be build from source for which the exact steps can be slightly varied depending on the linux flavour, the core process though, remains the same. Note: For `AKTO_NLB_IP` in below configurations, use the value of the `mini-runtime` service we deployed in step 1.
Ubuntu / Debian based 1. Record all API calls using `nginx-module-njs`. (njs is a standard NGINX module built and shipped in every release of NGINX). You can install it by running `apt install nginx-module-njs` 2. The data is sent to Akto installed in your VPC using [nginx-kafka-log-module](https://github.com/kaltura/nginx-kafka-log-module). You can install it by using nginx dynamic modules functionality as described [here](https://www.nginx.com/blog/compiling-dynamic-modules-nginx-plus/) 3. Download the [js file](https://raw.githubusercontent.com/akto-api-security/nginx-middleware/master/api_log.js) and save as `/etc/nginx/njs/api_log.js` 4. In your NGINX conf file - `/etc/nginx/nginx.conf` , add the following: ```lua load_module /usr/lib/nginx/modules/ngx_http_js_module.so; load_module /usr/lib/nginx/modules/ngx_http_kafka_log_module.so; ``` add the following lines in `http` section of `/etc/nginx/nginx.conf`: ```lua subrequest_output_buffer_size 8k; js_path "/etc/nginx/njs/"; js_var $responseBo "{}"; js_import main2 from api_log.js; kafka_log_kafka_brokers :9092; kafka_log_kafka_buffer_max_messages 100000; ``` 5\. In `/etc/nginx/conf.d/default.conf`, add 2 lines in `server > location` section ```lua server { location / { ..... js_body_filter main2.to_lower_case buffer_type=buffer; kafka_log kafka:akto.api.logs $responseBo; } } ``` 6\. Restart NGINX by `nginx -s reload`. This will start logging all the request-response logs to akto.
Amazon linux 2 1. sudo su - 2. To set up the yum repository for Amazon Linux 2 for nginx, create the file named `/etc/yum.repos.d/nginx.repo` with the following content. This is needed to install `nginx` (if not present) and `nginx-module-njs`. ```bash [nginx-stable] name=nginx stable repo baseurl=http://nginx.org/packages/amzn2/$releasever/$basearch/ gpgcheck=1 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=true priority=9 [nginx-mainline] name=nginx mainline repo baseurl=http://nginx.org/packages/mainline/amzn2/$releasever/$basearch/ gpgcheck=1 enabled=0 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=true priority=9 ``` 3. If nginx is not present install it using `yum install nginx` else you can skip this step. 4. Check your nginx version using `nginx -v` and download/extract the source for the same using the following commands. ```bash wget http://nginx.org/download/nginx-{version}.tar.gz tar -zxvf nginx-{version}.tar.gz e.g. wget http://nginx.org/download/nginx-1.26.0.tar.gz tar -zxvf nginx-1.26.0.tar.gz ``` 4. Install nginx-module-njs using `yum install nginx-module-njs` ( In case of any problem, please refer to the [official nginx docs to install nginx-module-njs](https://nginx.org/en/docs/njs/install.html) ) 5. We will send data to Akto traffic processor using [nginx-kafka-log-module](https://github.com/kaltura/nginx-kafka-log-module). To clone it run: `git clone https://github.com/kaltura/nginx-kafka-log-module.git` 6. We can install nginx-kafka-log-module using the steps below. For the official nginx docs to install nginx dynamic modules refer [this](https://www.nginx.com/blog/compiling-dynamic-modules-nginx-plus/). ```bash # Enable EPEL repository if not already enabled amazon-linux-extras install epel -y # Install librdkafka and its development package yum install librdkafka librdkafka-devel -y yum install pcre pcre-devel -y yum groupinstall "Development Tools" -y # go to nginx directory, which we downloaded in step 3 cd nginx-1.26.0/ ./configure --with-compat --add-dynamic-module=../nginx-kafka-log-module --with-cc-opt="-I/usr/include" --with-ld-opt="-L/usr/lib" make modules cp objs/ngx_http_kafka_log_module.so /etc/nginx/modules/ ``` 9. Add the Akto njs code to nginx njs directory using the following commands. ```bash mkdir /etc/nginx/njs curl -o /etc/nginx/njs/api_log.js https://raw.githubusercontent.com/akto-api-security/nginx-middleware/master/api_log.js ``` 10. To configure nginx, in your nginx configuration file ( `/etc/nginx/nginx.conf` ), add the following lines to top: ```bash load_module /etc/nginx/modules/ngx_http_js_module.so; load_module /etc/nginx/modules/ngx_http_kafka_log_module.so; ``` 11. Also add this in http section of `/etc/nginx/nginx.conf`. Replace the `AKTO_NLB_IP`, with the one you obtained in setting up data processors. ```bash subrequest_output_buffer_size 8k; js_path "/etc/nginx/njs/"; js_var $responseBo "{}"; js_import main2 from api_log.js; kafka_log_kafka_brokers ":9092"; kafka_log_kafka_buffer_max_messages 100000; ``` 12. Add this to .conf \[ You can get the path of this file in the include section of /etc/nginx/nginx.conf file ]. Make sure that the traffic here is being proxied/sent to your actual application. ``` location / { js_body_filter main2.to_lower_case buffer_type=buffer; kafka_log kafka:akto.api.logs $responseBo; ...... } ``` 13. nginx -s reload \[ Use this command if nginx is already running, else use : systemctl start nginx ]
Amazon linux 2023 1. sudo su - 2. To set up the yum repository for Amazon Linux 2023 for nginx, create the file named `/etc/yum.repos.d/nginx.repo` with the following content. This is needed to install `nginx` (if not present) and `nginx-module-njs`. ```bash [nginx-stable] name=nginx stable repo baseurl=http://nginx.org/packages/amzn/2023/$basearch/ gpgcheck=1 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=true priority=9 [nginx-mainline] name=nginx mainline repo baseurl=http://nginx.org/packages/mainline/amzn/2023/$basearch/ gpgcheck=1 enabled=0 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=true priority=9 ``` 3. If nginx is not present install it using `yum install nginx -y` else you can skip this step. 4. Check your nginx version using `nginx -v` and download/extract the source for the same using the following commands. ```bash wget http://nginx.org/download/nginx-{version}.tar.gz tar -zxvf nginx-{version}.tar.gz e.g. wget http://nginx.org/download/nginx-1.26.0.tar.gz tar -zxvf nginx-1.26.0.tar.gz ``` 4. Install nginx-module-njs using `yum install nginx-module-njs` ( In case of any problem, please refer to the [official nginx docs to install nginx-module-njs](https://nginx.org/en/docs/njs/install.html) ) 5. We will send data to Akto traffic processor using [nginx-kafka-log-module](https://github.com/kaltura/nginx-kafka-log-module). To clone it run: `git clone https://github.com/kaltura/nginx-kafka-log-module.git` 6. We can install nginx-kafka-log-module using the steps below. For the official nginx docs to install nginx dynamic modules refer [this](https://www.nginx.com/blog/compiling-dynamic-modules-nginx-plus/). i. To set up the yum repository for Amazon Linux 2023 for confluent, create the file named `/etc/yum.repos.d/confluent.repo` with the following content. ```bash [Confluent-Clients] name=Confluent Clients repository baseurl=https://packages.confluent.io/clients/rpm/centos/9/$basearch gpgcheck=1 gpgkey=https://packages.confluent.io/clients/rpm/archive.key enabled=1 ``` ii. Run the following commands: ```bash yum install librdkafka1 librdkafka-devel -y yum install pcre pcre-devel -y yum groupinstall "Development Tools" -y # go to nginx directory, which we downloaded in step 3 cd nginx-1.26.0/ ./configure --with-compat --add-dynamic-module=../nginx-kafka-log-module --with-cc-opt="-I/usr/include" --with-ld-opt="-L/usr/lib" make modules cp objs/ngx_http_kafka_log_module.so /etc/nginx/modules/ ``` 7. Add the Akto njs code to nginx njs directory using the following commands. ```bash mkdir /etc/nginx/njs curl -o /etc/nginx/njs/api_log.js https://raw.githubusercontent.com/akto-api-security/nginx-middleware/master/api_log.js ``` 10. To configure nginx, in your nginx configuration file ( `/etc/nginx/nginx.conf` ), add the following lines to top: ```bash load_module /etc/nginx/modules/ngx_http_js_module.so; load_module /etc/nginx/modules/ngx_http_kafka_log_module.so; ``` 11. Also add this in http section of `/etc/nginx/nginx.conf`. Replace the `AKTO_NLB_IP`, with the one you obtained in setting up data processors. ```bash subrequest_output_buffer_size 8k; js_path "/etc/nginx/njs/"; js_var $responseBo "{}"; js_import main2 from api_log.js; kafka_log_kafka_brokers ":9092"; kafka_log_kafka_buffer_max_messages 100000; ``` 12. Add this to .conf \[ You can get the path of this file in the include section of /etc/nginx/nginx.conf file ]. Make sure that the traffic here is being proxied/sent to your actual application. ``` location / { js_body_filter main2.to_lower_case buffer_type=buffer; kafka_log kafka:akto.api.logs $responseBo; ...... } ``` 13. nginx -s reload \[ Use this command if nginx is already running, else use : systemctl start nginx ]
Note: We have benchmarked an nginx server with and without akto nginx traffic module. The results for the same are as follows: | metrics | vanilla nginx | nginx with akto module | | ----------------- | ------------- | ---------------------- | | avg. cpu usage | upto 36% | upto 38% | | avg. memory usage | 0.5% | 0.5% | The server setup being used is an AWS EC2 (t3a.small: 2CPU + 2GB RAM), with around 1600-1800 requests being fired per second to the server continuously for over a minute (\~110k requests per minute). Here nginx is configured as a reverse proxy to a node.js backend server. # Connect Akto with Istio If your API calls are being routed through Istio service mesh, you can use Akto's Istio filter to send traffic to Akto dashboard. Below guide will help you do this:
## Creating AWS Policy 1\. Go to Quick Start on your Akto dashboard and expand the `Connect traffic data` section.
2\. Scroll down to `Data processors setup` section.
3\. Copy the `policy json` and click on the Akto Dashboard role link.
4\. `Click` on the `JSON` tab and `paste the policy`
5\. Click on `Review policy` button.
6\. Enter *`AktoDashboardPolicy`* as the policy name and `click` on `Create Policy` button
8\. Once the policy is created, go back to the `dashboard`. ## Setting up Data processors 1\. Click on `Setup traffic processors` button.
2\. This will bring up infra that will process your traffic.
3\. Check that you have `AKTO_NLB` var once setup is complete.
## Adding Akto traffic collector 1. Download the GitHub repo [here](https://github.com/akto-api-security/istio-filter) and `cd` into it. 2. Create your own Docker image of `istio-proxy` by running following commands: ```bash docker build . -t :istio-proxy docker push :istio-proxy ``` {% hint style="info" %} Please make sure you are building docker image on the same platform as your app server. {% endhint %} 3. Add this custom istio-proxy image to containers you want to collect traffic from. You can get the value of `AKTO_NLB_IP` from the dashboard itself. ```yaml - name: istio-proxy image: /istio-proxy:latest env: - name: AKTO_KAFKA_IP # you will find this on your akto dashboard after you've deployed the Data-processing stack using Akto. value: ":9092" ``` 4. Re-apply the config to restart all your pods with the added `istio-proxy` container. ``` kubectl apply -f ``` 5. Apply `akto-envoy-filter.yaml` to start capturing API calls and send to Akto dashboard. ``` kubectl apply -f akto-envoy-filter.yaml ``` # Connect Akto with HAProxy HAProxy is a high-performance, open-source load balancer and proxy server for TCP and HTTP-based applications. By connecting HAProxy with Akto, you can automatically discover and test the security of all APIs passing through your HAProxy instances, providing comprehensive visibility into your API traffic and ensuring consistent security across your load-balanced infrastructure.
To connect Akto with HAProxy, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add HAProxy connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **HA Proxy** block and click on the **Connect** button to get instructions

HA Proxy connector in Akto

To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Connect Akto with Azure API Management Azure API Management is Microsoft's fully managed service for securing, publishing, and analyzing APIs in the Azure cloud. Integrating Azure API Management with Akto enables automatic discovery and security testing of all APIs running in your Azure environment, providing seamless security coverage across your cloud infrastructure.
To connect Akto with Azure API Management, please follow these steps - ## Step 1: Deploy the Akto Data-Ingestion Service Before configuring the Azure API Management (APIM) Traffic Connector, you need to deploy the Akto Data-Ingestion Service. Ensure that the service is running and accessible via a publicly available URL. ### 1.1 Download the Required Files SSH into the instance where you want to deploy the data-ingestion service and run these commands: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` * Log in to the [Akto Dashboard](https://app.akto.io/). * Navigate to the **Quick Start** tab in the left panel.
* Select **Hybrid SaaS Connector** and copy the token from the **Runtime Service Command** section.
### 1.3 Update the `docker-mini-runtime.env` File * Open the `docker-mini-runtime.env` file and replace `token` with the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` you retrieved earlier. ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` ### 1.4 Deploy the Data-Ingestion Service Run the following command to start the data-ingestion service: ```bash docker-compose -f docker-compose-data-ingestion-runtime.yml up -d ``` ### 1.5 Note the IP Address of the Data-Ingestion Service Ensure the instance is accessible from the network where your Azure APIM is configured. Note the instance's IP address, as it will be required by the Azure APIM connector to send traffic data. *** ## Step 2: Create an API Management Service in Azure Portal 1. Go to the [Azure Portal](https://portal.azure.com/) and navigate to "API Management Services."
2. Click on the **Create** button. 3. Fill in the required details: * **Subscription**: Select your Azure subscription. * **Resource Group**: Choose an existing resource group or create a new one. * **Instance Details**: * **Region**: Select the region for your API Management service. * **Resource Name**: Provide a unique name for the service. * **Organization Name**: Enter your organization’s name. * **Administrator Email**: Provide an administrator email. * **Pricing Tier**: Select the appropriate pricing tier. * **Units**: Define the number of units as per your requirement. 4. Click **Review + Create** and then **Create** to deploy the API Management service.
## Step 3: Import/Create APIs in API Management 1. Once the APIM service is created, navigate to the service in the Azure Portal. 2. Go to the **APIs** section. 3. Either import an existing API or create a new API. 4. Select the API where you want to add the policy for the traffic connector. ## Step 4: Configure the Traffic Connector Policy 1. Navigate to the **Inbound Policies** section of the selected API operation. 2. Click on the **Edit Policy** button.
3. Paste the following policy configuration: ```xml !string.IsNullOrWhiteSpace(r)) .ToArray(); return regexList.Length == 0 || regexList.Any(r => System.Text.RegularExpressions.Regex.IsMatch(context.Request.OriginalUrl.Path, r.Trim())); } catch { return false; } }"> !string.IsNullOrWhiteSpace(r)) .ToArray(); return regexList.Length == 0 || regexList.Any(r => System.Text.RegularExpressions.Regex.IsMatch(context.Request.OriginalUrl.Path, r.Trim())); } catch { return false; } }"> @((string)context.Variables["missingKeys"]) https:///api/ingestData POST application/json @{ try { return "{ \"batchData\": [" + "{ \"path\": \"" + context.Variables.GetValueOrDefault("reqUrl", "") + "\", " + "\"requestHeaders\": " + context.Variables.GetValueOrDefault("reqHeaders", "\"\"") + ", " + "\"responseHeaders\": " + context.Variables.GetValueOrDefault("respHeaders", "\"\"") + ", " + "\"method\": \"" + context.Variables.GetValueOrDefault("reqMethod", "") + "\", " + "\"requestPayload\": " + context.Variables.GetValueOrDefault("reqBody", "\"\"") + ", " + "\"responsePayload\": " + context.Variables.GetValueOrDefault("respBody", "\"\"") + ", " + "\"ip\": \"" + context.Variables.GetValueOrDefault("clientIp", "") + "\", " + "\"time\": \"" + context.Variables.GetValueOrDefault("unixTimestamp", "") + "\", " + "\"statusCode\": \"" + context.Variables.GetValueOrDefault("respStatus", "") + "\", " + "\"type\": \"HTTP/1.1\", " + "\"status\": \"" + context.Variables.GetValueOrDefault("statusMessage", "") + "\", " + "\"akto_account_id\": \"1000000\", " + "\"akto_vxlan_id\": \"0\", " + "\"is_pending\": \"false\", " + "\"source\": \"MIRRORING\" } ] }"; } catch { return "{}"; } } ``` 4. **Important Note**:\ If you remove the `` element from the policy configuration at the API scope, **only** the policies defined at the API scope will be applied. Policies configured at **product**, **global**, or other broader scopes will **not** be inherited or executed. Always include `` in the appropriate sections (``, ``, ``, and ``) unless you explicitly intend to override all inherited behavior. (For more info [click here](https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-policies).) 5. Add the regex patterns for the paths you want to **include** in the `regexList` variable value in the inbound policy, ensuring that the **entire regex is properly escaped**. Separate multiple patterns using `;` (e.g., `"api\/v1\/.*;\/api\/getUsers.*"`). * If you leave the `regexList` variable value empty, all APIs will be processed. 6. Replace `YOUR_AKTO_INGESTION_SERVICE_URL` with the URL of your Akto Data-Ingestion Service (Step 1.5). 7. Click **Save** to apply the policy. ## Step 5: Verify the Integration 1. Send test requests to the configured API endpoint. 2. Check the Akto Data-Ingestion Service logs to verify that the traffic data is being ingested correctly. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with F5 F5 is a leading application security and delivery platform that provides advanced traffic management and security features. Integrating F5 with Akto allows automatic discovery and security testing of all APIs flowing through your F5 infrastructure, ensuring comprehensive security coverage across your application delivery network.
## **Prerequisites** 1. Go to [app.akto.io](https://app.akto.io). Login/Signup into your account. 2. Click on Quick Start tab in left nav 3. Search for Hybrid SaaS Connector and click connect 4. Copy the token as specified under `Runtime Service Command` heading. This will be later used in setting up Akto Traffic Processor
## Setting Up Akto Traffic Collector 1. Create a new instance 2. Login into the instance and save the following file as docker-compose-traffic-collector.yml ```yaml version: '2.1' services: zoo1: image: confluentinc/cp-zookeeper:6.2.1 restart: always hostname: zoo1 user: "0" volumes: - ./data-zoo-data:/var/lib/zookeeper/data - ./data-zoo-logs:/var/lib/zookeeper/log - ./data-zoo-secrets:/etc/zookeeper/secrets container_name: zoo1 ports: - "2181:2181" environment: ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_SERVER_ID: 1 ZOOKEEPER_SERVERS: zoo1:2888:3888 labels: com.centurylinklabs.watchtower.enable: "false" kafka1: image: confluentinc/cp-kafka:6.2.1 restart: always hostname: kafka1 user: "0" ports: - "9092:9092" - "19092:19092" - "29092:29092" - "9999:9999" environment: KAFKA_ADVERTISED_LISTENERS: LISTENER_DOCKER_EXTERNAL_DIFFHOST://${AKTO_KAFKA_IP}:9092, LISTENER_DOCKER_INTERNAL://kafka1:19092,LISTENER_DOCKER_EXTERNAL_LOCALHOST://localhost:29092 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_DOCKER_EXTERNAL_DIFFHOST:PLAINTEXT, LISTENER_DOCKER_INTERNAL:PLAINTEXT,LISTENER_DOCKER_EXTERNAL_LOCALHOST:PLAINTEXT KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_DOCKER_INTERNAL KAFKA_ZOOKEEPER_CONNECT: "zoo1:2181" KAFKA_BROKER_ID: 1 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1 KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1 KAFKA_CREATE_TOPICS: "akto.api.logs:3:3" KAFKA_LOG_RETENTION_CHECK_INTERVAL_MS: 60000 KAFKA_LOG_RETENTION_HOURS: 5 KAFKA_LOG_SEGMENT_BYTES: 104857600 KAFKA_LOG_CLEANER_ENABLE: "true" KAFKA_CLEANUP_POLICY: "delete" KAFKA_LOG_RETENTION_BYTES: 10737418240 volumes: - ./data-kafka-data:/var/lib/kafka/data - ./data-kafka-secrets:/etc/kafka/secrets depends_on: - zoo1 labels: com.centurylinklabs.watchtower.enable: "false" akto-api-security-traffic-collector: image: ayush12493/udp-packet-reassembler:latest env_file: ./docker-akto-collector.env restart: always mem_limit: 2g network_mode: host privileged: true cap_add: - SYS_PTRACE - SYS_ADMIN volumes: - /lib/modules:/lib/modules - /sys/kernel:/sys/kernel - /:/host init-kafka: image: confluentinc/cp-kafka:6.2.1 depends_on: - kafka1 entrypoint: [ '/bin/sh', '-c' ] command: | " # blocks until kafka is reachable kafka-topics --bootstrap-server 172.17.0.1:9092 --list echo -e 'Creating kafka topics' kafka-topics --bootstrap-server 172.17.0.1:9092 --create --if-not-exists --topic akto.api.logs --replication-factor 1 --partitions 2 echo -e 'Successfully created the following topics:' kafka-topics --bootstrap-server 172.17.0.1:9092 --list " ``` 3. Replace ${AKTO\_KAFKA\_IP} in the above file with your instance’s ip 4. Save below snipped as docker-akto-collector.env. Replace \ with your instance ip. ```tcl AKTO_TRAFFIC_BATCH_TIME_SECS=10 AKTO_TRAFFIC_BATCH_SIZE=100 AKTO_KAFKA_BROKER_MAL=:9092 AKTO_BYTES_IN_THRESHOLD=10 ``` 5. Run `docker-compose -f docker-compose-traffic-collector.yml up -d` 6. Expose UDP port 1053 on this instance ## Traffic Processor Setup 1. Login into the Traffic Collector Instance 2. Save the following file as docker-compose-runtime.yml ```yaml version: '2.1' services: akto-api-security-runtime: image: public.ecr.aws/aktosecurity/akto-api-security-mini-runtime:latest env_file: ./docker-mini-runtime.env mem_limit: 8g restart: always ``` 3. Save the following file as docker-mini-runtime.env. Replace with token value copied in Prerequisites step. Replace \ with your instance ip. ``` AKTO_CONFIG_NAME=staging AKTO_KAFKA_TOPIC_NAME=akto.api.logs AKTO_KAFKA_BROKER_URL=traffic_processor_instance_ip>:9092 AKTO_KAFKA_BROKER_MAL=traffic_processor_instance_ip>:9092 AKTO_KAFKA_GROUP_ID_CONFIG=asdf AKTO_KAFKA_MAX_POLL_RECORDS_CONFIG=100 AKTO_ACCOUNT_NAME=Helios AKTO_TRAFFIC_BATCH_SIZE=100 AKTO_TRAFFIC_BATCH_TIME_SECS=10 USE_HOSTNAME=true AKTO_INSTANCE_TYPE=RUNTIME DATABASE_ABSTRACTOR_SERVICE_URL=https://cyborg.akto.io DATABASE_ABSTRACTOR_SERVICE_TOKEN= RUNTIME_MODE=hybrid ``` 4. Run `docker-compose -f docker-compose-traffic-collector.yml up -d` ## F5 Setup ### Node Setup 1. Inside left nav bar go to Local Traffic -> Nodes -> Node List
2. Create a new node in your F5 dashboard. Use the ip of Traffic Collector instance as Address
### Pool Setup 1. Inside left nav bar go to Local Traffic -> Pools -> Pool List
2. Create a new pool in your F5 dashboard. 1. Address - Use the ip of Traffic Collector instance 2. Service Port - 1053
### IRULE 1. Inside left nav bar go to Local Traffic -> iRules -> iRule List
2. Create a new iRule with the following tcl script ```tcl when RULE_INIT { set static::hsl_start "${static::delimiter}HSL_START${static::delimiter}" set static::delimiter "__" set static::request_header_start "${static::delimiter}REQHS${static::delimiter}" set static::request_header_end "${static::delimiter}REQHE${static::delimiter}" set static::header_name "${static::delimiter}HEAN${static::delimiter}" set static::header_value "${static::delimiter}HEAV${static::delimiter}" set static::response_header_start "${static::delimiter}RESPHS${static::delimiter}" set static::response_header_end "${static::delimiter}RESPHE${static::delimiter}" set static::max_collect_len 10000 set static::request_payload "${static::delimiter}REQPS${static::delimiter}" set static::response_payload "${static::delimiter}REQPE${static::delimiter}" set static::hsl_end "${static::delimiter}HSL_END${static::delimiter}" } when CLIENT_ACCEPTED { set hsl [HSL::open -proto UDP -pool trafficpoolnew] set sessionId "[IP::client_addr][TCP::client_port][IP::local_addr][TCP::local_port][expr { int(100000000 * rand()) }]" binary scan [md5 $sessionId] H* correlationId junk } when HTTP_REQUEST { set request_time [clock clicks -milliseconds] set reqHeaderString "${static::request_header_start}" set contentTypeHeaderValue "" foreach aHeader [HTTP::header names] { if { [string tolower $aHeader] == "content-type" } { set contentTypeHeaderValue [HTTP::header value $aHeader] } set lwcasekey [string map -nocase {"\"" "\\\""}[string tolower $aHeader]] set value [string map -nocase {"\"" "\\\""} [HTTP::header value $aHeader]] set headers "${static::header_name}${lwcasekey}${static::header_value}${value}" append reqHeaderString $headers } append reqHeaderString ${static::request_header_end} set uri [HTTP::uri] set method [HTTP::method] set client_addr [IP::client_addr] set local_port [TCP::local_port] set method [HTTP::method] set host [HTTP::host] set request_time [clock clicks -milliseconds] set request_payload "" } when HTTP_REQUEST_DATA { if {[HTTP::payload length] > 0 } { set capture_length [HTTP::payload length] if { $capture_length > $static::max_collect_len } { set capture_length $static::max_collect_len } set request_payload [b64encode [string range "[HTTP::payload]" 0 $capture_length ]] } } when HTTP_RESPONSE { set response_time [clock clicks -milliseconds] set resHeaderString "${static::response_header_start}" foreach aHeader [HTTP::header names] { set lwcasekey [string map -nocase {"\"" "\\\""}[string tolower $aHeader]] set value [string map -nocase {"\"" "\\\""} [HTTP::header value $aHeader]] set headers "${static::header_name}${lwcasekey}${static::header_value}${value}" append resHeaderString $headers } append resHeaderString "${static::response_header_end}" HTTP::collect $static::max_collect_len set forwarded_data 0 if { [HTTP::header exists "Content-Length"] && [HTTP::header value "Content-Length"] == 0 } { set response_payload "" HSL::send $hsl "${static::hsl_start}$correlationId $method $uri $client_addr $local_port [HTTP::status] $host [HTTP::version] $request_time $response_time $reqHeaderString $resHeaderString ${static::request_payload}$request_payload ${static::response_payload}$response_payload ${static::hsl_end}\n" set forwarded_data 1 } } when HTTP_RESPONSE_DATA { set response_payload "" if { [HTTP::payload length] > 0 } { set capture_length [HTTP::payload length] if { $capture_length > $static::max_collect_len } { set capture_length $static::max_collect_len } set response_payload [b64encode [string range "[HTTP::payload]" 0 $capture_length]] } if { $forwarded_data != 1 } { HSL::send $hsl "${static::hsl_start} ${static::hsl_start} ${static::hsl_start} ${static::hsl_start} ${static::hsl_start} ${static::hsl_start} $correlationId $method $uri $client_addr $local_port [HTTP::status] $host [HTTP::version] $request_time $response_time $reqHeaderString $resHeaderString ${static::request_payload}$request_payload ${static::response_payload}$response_payload ${static::hsl_end}\n" } } ``` 3. Attach the iRule to your virtual server by going to resources section under your virtual server.
# Connect Akto with Internet Information Services (IIS) Microsoft IIS (Internet Information Services) is a widely used web server for hosting web applications on Windows. Integrating IIS with Akto enables you to automatically mirror API traffic (including headers and payloads) to the Akto backend, empowering deep visibility and continuous API security analysis. To connect Akto with your IIS server, follow the steps below: *** ## Step 1: Deploy the Akto Data-Ingestion Service Before configuring the IIS Traffic Connector, you need to deploy the Akto Data-Ingestion Service. Ensure that the service is running and accessible via a publicly available URL. ### 1.1 Download the Required Files SSH into the instance where you want to deploy the data-ingestion service and run these commands: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-mini-runtime-data-ingestion.yaml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-threat-detection.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` * Log in to the [Akto Dashboard](https://app.akto.io/) * Navigate to the **Quick Start** tab in the left panel
* Select **Hybrid SaaS Connector**
* Copy the token from the **Runtime Service Command** section ### 1.3 Update the `docker-mini-runtime.env` File Open the `docker-mini-runtime.env` file and replace `token` with the token you just copied: ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` ### 1.4 Deploy the Data-Ingestion Service Run the following command: ```bash docker-compose -f docker-compose-mini-runtime-data-ingestion.yaml up -d ``` ### 1.5 Note the IP Address of the Data-Ingestion Service Ensure this IP is reachable from your IIS server. You will need this to forward the traffic data to Akto. *** ## Step 2: Install the IIS Traffic Connector Akto provides a native IIS module that can capture HTTP request and response headers and payloads. This module supports both 64-bit and 32-bit environments. 👉 **Important:** You must download and use only one DLL — either 64-bit or 32-bit depending on your system. Regardless of which one you choose, always rename it to `AktoNativeIisTrafficCollector.dll`, move it to `C:\akto_configs`, and use that same name everywhere. *** ### 2.1 Prepare Configuration File 1. Create a folder at the root of your C drive: ```powershell mkdir C:\akto_configs ``` 2. Inside it, create a file named `config.json` with the following content: ```json { "backendUrl": "http://DATA-INGESTION-SERVICE-URL:9091/api/ingestData", "logLevel": "INFO", "maxPayloadSize": 1048576, "maxQueueSize": 1000 } ``` Replace `DATA-INGESTION-SERVICE-URL` with the address of your deployed Akto ingestion service. **Configuration Fields:** * `backendUrl` - The URL of your Akto data-ingestion service endpoint * `logLevel` - Controls the logging verbosity. Accepted values: `INFO`, `WARN`, `NONE`, `ERROR`, or `DEBUG` * `maxPayloadSize` - Maximum size (in bytes) of request + response to capture. Only traffic with total size less than this value will be captured. Example: `1048576` for 1MB * `maxQueueSize` - Maximum number of requests to store in memory before flushing to Akto. Controls memory usage and batch size *** ### 2.2 Install the Module Globally (Recommended) You need to register the Akto IIS module globally so it applies to all websites. 1. Download the correct DLL for your environment (pick **only one**). You can also simply paste the link in browser and download the DLL file. ```powershell # For 64-bit IIS Invoke-WebRequest -Uri https://github.com/akto-api-security/iis-collector-native-module/raw/refs/heads/master/x64/Release/AktoNativeIisTrafficCollector.dll -OutFile C:\akto_configs\AktoNativeIisTrafficCollector.dll # For 32-bit IIS Invoke-WebRequest -Uri https://github.com/akto-api-security/iis-collector-native-module/raw/refs/heads/master/x86/Release/AktoNativeIisTrafficCollector.dll -OutFile C:\akto_configs\AktoNativeIisTrafficCollector.dll ``` 2. Open an **elevated command prompt (Administrator)** and run the following commands: ```cmd %windir%\system32\inetsrv\appcmd.exe install module /name:AktoTrafficConnector /image:"C:\akto_configs\AktoNativeIisTrafficCollector.dll" /add:true %windir%\system32\inetsrv\appcmd.exe set config /section:system.webServer/globalModules /+[name='AktoNativeIisTrafficCollector',image='C:\akto_configs\AktoNativeIisTrafficCollector.dll'] %windir%\system32\inetsrv\appcmd.exe list config /section:system.webServer/globalModules ``` These commands: * Register the `AktoTrafficConnector` module in IIS * Add it for **all sites** so that traffic from every hosted website is mirrored * Explicitly add `AktoNativeIisTrafficCollector` to the global modules section * List all registered global modules for verification 3. Restart your IIS server: ```bash iisreset ``` *** ### 2.3 Add Module to a Specific Website Only (Alternative Method) If you want to install the module for **just one website**, follow these steps: 1. Copy the correct DLL into a directory named `bin` under your site’s root folder (e.g., `C:\inetpub\wwwroot\MySite\bin`). 2. Update the `web.config` of that website: ```xml ``` 3. Ensure the app pool identity has read access to this folder and its DLLs. 4. Restart your IIS server: ```bash iisreset ``` *** ## Step 3: Verify the Integration Once installed: 1. Make a few requests to your IIS-hosted APIs. 2. In your Akto dashboard, go to the **API Collections** tab and confirm that traffic is appearing. If no traffic is appearing, check: * IIS logs for module load errors. * Check logs in `C:\akto_configs\logs\log_20xx.txt` * Akto Data-Ingestion Service logs to ensure it’s receiving traffic. *** ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24×7 available through the following: 1. In-app `Intercom` support — message us via the chat icon in the Akto dashboard. 2. Join our [Discord channel](https://www.akto.io/community) for community support. 3. Email us at . 4. Visit our [Contact page](https://www.akto.io/contact-us). # Connect Akto with 3Scale Red Hat 3Scale API Management platform helps organizations share, secure, distribute, and control their APIs. Connecting 3Scale with Akto enables automatic discovery and security testing of all APIs managed through your 3Scale infrastructure, providing comprehensive API security coverage across your Red Hat ecosystem. To connect Akto with 3Scale, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add 3Scale connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **3Scale** block and click on the **Connect** button to get instructions
To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Connect Akto with Layer7 API Gateway Layer7 API Gateway, part of Broadcom's API management suite, provides enterprise-grade API security and management capabilities for large organizations. Integrating Layer7 with Akto allows automatic discovery and security testing of all APIs managed through your Layer7 gateway, helping maintain robust security standards across your API infrastructure.
To connect Akto with Broadcom Layer7 API Gateway, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add Layer7 API Gateway connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **Layer7 API Gateway** block and click on the **Connect** button to get instructions
To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Connect Akto with Citrix Citrix is a comprehensive application delivery and security solution that manages and optimizes application traffic across enterprise networks. Integrating Citrix with Akto enables automatic discovery and security testing of all APIs flowing through your Citrix infrastructure, ensuring consistent security monitoring across your application delivery network.
To connect Akto with Citrix Netscaler Gateway, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add Citrix Netscaler Gateway connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **Citrix** block and click on the **Connect** button to get instructions
To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Connect Akto with Kong Discover and monitor every API flowing through your **Kong API Gateway** with Akto. The `akto-api-discovery` plugin captures request and response metadata from traffic passing through Kong and asynchronously ships it to Akto's ingest service for automatic API discovery, schema inference, sensitive data detection, and security testing. The plugin is built around a strict guarantee: **it never affects the original request, response, status code, or latency** — even if the Akto backend is slow or completely unreachable.
Kong API Discovery
## Prerequisites Before you begin, make sure you have: * Kong Gateway **2.0 or later** already running with your services and routes configured * Access to Kong's Admin API (default: `http://localhost:8001`) * A server or Kubernetes cluster to host the Akto ingest backend * Your **Akto API Token** (available from your Akto dashboard → Quick Start → Hybrid SaaS → Connect → Copy your `databaseAbstractorToken`) *** ## Step 1: Install the Plugin in Kong {% stepper %} {% step %} **Download the Plugin Files** Clone the Akto Kong integration repository: ```bash git clone https://github.com/akto-api-security/kong-integration.git cd kong-integration ``` Inside the `api_plugin/` directory you will find two files: * `handler.lua` — plugin logic * `schema.lua` — configuration schema {% hint style="info" %} You only need these two files. Nothing else from the repository is required for the plugin itself. {% endhint %} {% endstep %} {% step %} **Copy the Plugin Files into Kong** Create the plugin directory inside Kong and copy both files into it: ```bash mkdir -p /usr/local/share/lua/5.1/kong/plugins/akto-api-discovery cp api_plugin/handler.lua /usr/local/share/lua/5.1/kong/plugins/akto-api-discovery/ cp api_plugin/schema.lua /usr/local/share/lua/5.1/kong/plugins/akto-api-discovery/ ``` **Using Docker?** Mount the plugin directory as a volume instead: ```yaml volumes: - /path/to/kong-integration/api_plugin:/usr/local/share/lua/5.1/kong/plugins/akto-api-discovery:ro ``` {% endstep %} {% step %} **Register the Plugin with Kong** Add `akto-api-discovery` to Kong's plugins list. How you do this depends on how Kong is configured: **Via `kong.conf`:** ``` plugins = bundled,akto-api-discovery ``` **Via environment variable:** ```bash KONG_PLUGINS=bundled,akto-api-discovery ``` {% hint style="info" %} If you are using Docker Compose, set this as an environment variable on the Kong service. {% endhint %} {% endstep %} {% step %} **Restart Kong** ```bash kong restart ``` Or if using Docker: ```bash docker compose restart kong ``` {% endstep %} {% endstepper %} *** ## Step 2: Enable the Plugin on Your Service or Route You can attach the plugin to a specific service, a specific route, or globally across all traffic. **Enable on a specific service** (recommended — scopes discovery to one upstream service): ```bash curl -X POST http://localhost:8001/services//plugins \ --data "name=akto-api-discovery" \ --data "config.service_url=http://" ``` **Enable on a specific route:** ```bash curl -X POST http://localhost:8001/routes//plugins \ --data "name=akto-api-discovery" \ --data "config.service_url=http://" ``` **Enable globally** (monitors all traffic through Kong): ```bash curl -X POST http://localhost:8001/plugins \ --data "name=akto-api-discovery" \ --data "config.service_url=http://" ``` Replace `` with your Akto ingest service URL: * **If Akto provided you a URL** (e.g., `https://17*******0-ingest.akto.io`), use that directly. * **Otherwise**, complete Step 3 to self-host the backend and use the URL you get from there. {% hint style="info" %} **Configuration Parameters** {% endhint %} | Parameter | Required | Default | Description | | ------------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------- | | `service_url` | Yes | — | Base URL of your deployed Akto ingest backend (e.g., `http://10.0.1.4:8080`). The plugin POSTs to `/api/ingestData`. | | `timeout` | No | `30000` | Request timeout in milliseconds for the async ingest call. The plugin enforces a hard cap regardless of this value. | | `log_level` | No | `warn` | One of `debug`, `info`, `warn`, `error`. Keep at `warn` in production; use `info` or `debug` only for troubleshooting. | You can also configure the plugin via **Kong Manager UI**: go to **Plugins → New Plugin → search for `akto-api-discovery`**. *** ## Step 3: Deploy the Akto Ingest Backend {% hint style="info" %} If you already have the Akto ingest backend deployed (or have been given a `service_url` by your team), skip this step and use that URL directly in Step 2. {% endhint %} The ingest backend is a set of services that receive traffic metadata from the Kong plugin and store it for API discovery and analysis. You can deploy it using **Docker Compose** (any Linux VM) or **Helm** (Kubernetes). ### Option A: Docker Compose — Any Linux VM This is the fastest way to get started. You need a Linux server with at least **4 vCPUs and 8 GB RAM**. The Docker Compose file is available at:\ [`docker-compose-mini-runtime-data-ingestion.yaml`](https://github.com/akto-api-security/infra/blob/feature/quick-setup/docker-compose-mini-runtime-data-ingestion.yaml) {% stepper %} {% step %} **Clone the Repository** ```bash git clone -b feature/quick-setup https://github.com/akto-api-security/infra.git cd infra ``` {% endstep %} {% step %} **Configure Environment Files** Two env files must be present alongside the compose file before you start the services. **`docker-mini-runtime.env`** — controls the runtime service. The only value you must change is your Akto API token: ```bash # Create the file (it does not have a template to copy in this repo — create it fresh) cat > docker-mini-runtime.env < RUNTIME_MODE=hybrid AKTO_THREAT_ENABLED=true EOF ``` Replace `` with your token from the Akto dashboard. **`data-ingestion-docker.env`** — controls the data ingestion service. No changes needed for a standard setup: ```bash cat > data-ingestion-docker.env <" > .env ``` {% hint style="warning" %} Never commit these env files to version control — they contain your API token. {% endhint %} {% endstep %} {% step %} **Start the Services** ```bash docker compose -f docker-compose-mini-runtime-data-ingestion.yaml up -d ``` This starts the following services: | Service | Host Port | Purpose | | --------------------------- | --------- | --------------------------------------------------------------------------- | | `zoo1` | 2181 | ZooKeeper (Kafka coordination) | | `kafka1` | 9092 | Kafka message broker | | `akto-api-security-runtime` | — | Processes API traffic from Kafka for discovery and schema inference | | `data-ingestion-service` | **9091** | Receives traffic from Kong and ingests it — **this is the plugin endpoint** | | `redis` | 6379 | Used by the threat detection service | | {% endstep %} | | | {% step %} **Verify All Services Are Running** ```bash docker compose -f docker-compose-mini-runtime-data-ingestion.yaml ps ``` All services should show status `Up`. If any are restarting, check their logs: ```bash docker compose -f docker-compose-mini-runtime-data-ingestion.yaml logs data-ingestion-service docker compose -f docker-compose-mini-runtime-data-ingestion.yaml logs akto-api-security-runtime ``` {% endstep %} {% step %} **Update the Kong Plugin with the Service URL** Your ingest service is now available at `http://:9091`. Update the Kong plugin configuration: ```bash # Update an existing plugin (replace with your plugin's ID) curl -X PATCH http://localhost:8001/plugins/ \ --data "config.service_url=http://:9091" ``` Or if you haven't enabled the plugin yet, use this URL in the Step 2 commands above. {% hint style="info" %} If your Kong instance and ingest server are on different networks, make sure port `9091` is accessible from the Kong host. If you want HTTPS, place a reverse proxy (nginx, Caddy) or load balancer in front of the ingest service. {% endhint %} {% endstep %} {% endstepper %} *** ### Option B: Kubernetes (Helm Chart) Use this option if your infrastructure runs on Kubernetes. The `akto-mini-runtime` chart deploys Kafka, the runtime, and the data ingestion service together in a single release. Chart source: [`charts/mini-runtime`](https://github.com/akto-api-security/helm-charts/tree/master/charts/mini-runtime) {% stepper %} {% step %} **Add the Akto Helm Repository** ```bash helm repo add akto https://akto-api-security.github.io/helm-charts helm repo update ``` {% endstep %} {% step %} **Install the Chart** ```bash helm install akto-mini-runtime akto/akto-mini-runtime \ -n \ --create-namespace \ --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorUrl="https://cyborg.akto.io" \ --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorToken="" \ --set mini_runtime.aktoApiSecurityRuntime.env.aktoLogLevel="WARN" ``` Replace `` with your token from the Akto dashboard. {% hint style="info" %} To customise resource limits, replicas, external Kafka, or other settings, download the default `values.yaml` and pass it with `-f values.yaml`: ```bash helm show values akto/akto-mini-runtime > values.yaml # edit values.yaml, then: helm install akto-mini-runtime akto/akto-mini-runtime -n -f values.yaml ``` {% endhint %} {% endstep %} {% step %} **Verify All Pods Are Running** ```bash kubectl get pods -n ``` You should see pods for Kafka, the runtime, and the data ingestion service all in `Running` status. If any pod is stuck in `CrashLoopBackOff` or `Pending`, check its logs: ```bash kubectl logs -n ``` {% endstep %} {% step %} **Get the Ingest Service URL** ```bash kubectl get services -n ``` Locate the `data-ingestion-service` entry. Use its `CLUSTER-IP` and port `9091` for in-cluster access (e.g., `http://data-ingestion-service..svc.cluster.local:9091`), or set up an `Ingress` / `LoadBalancer` service for access from outside the cluster. Update the Kong plugin `config.service_url` with this URL. {% endstep %} {% endstepper %} *** ## How the Plugin Works The plugin is intentionally minimal on the request path and does all heavy work in the background. | Phase | What happens | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `access` | Opportunistically reads the request body **only if Kong has already buffered it**. Never forces buffering — that would add upload-time latency. | | `body_filter` | Copies response bytes already in nginx's memory into a small buffer. Never modifies the bytes sent to the client. Capped at 256 KB per response. | | `log` | Runs **after** the response is fully sent to the client. Snapshots metadata and fires an `ngx.timer.at(0,...)` callback. All JSON encoding and the HTTP call to Akto happen inside that timer. | | Async timer | Detached light-thread. Posts to `/api/ingestData`. Uses aggressive timeouts (3s connect, 5s send, 3s read) and an in-flight cap of 20 timers so a slow Akto can never build a backlog. | **Latency impact: near zero.** In paired benchmarks against an identical backend, the plugin adds **+0.03 ms at p50, +1.96 ms at p95, and +5.19 ms at p99**. Per individual paired request, the plugin is "slower" only 52% of the time — statistically indistinguishable from baseline. **Fail-open by design.** Every phase is wrapped in `pcall`. If Akto is unreachable, the timer fails inside its detached coroutine and is silently dropped — your client traffic is never affected, never delayed, never blocked. *** ## Verify the Integration After setup, send a test request through Kong (use the port Kong is listening on in your environment): ```bash curl -X GET http://:/ ``` Check Kong logs to confirm the plugin is active. Set `KONG_LOG_LEVEL=info` (or set `config.log_level=info` on the plugin) to see per-request logs: ```bash # Docker docker compose logs kong | grep "\[akto-api\]" # Kubernetes kubectl logs -n | grep "\[akto-api\]" ``` You should see lines like: ``` [akto-api] [async] → GET /your-route 200 [akto-api] [async] ingest ok ``` Once the data is flowing, your discovered APIs will start appearing in the **Akto Dashboard → Inventory** within a few minutes. *** ## Troubleshooting **Plugin not loading after restart**\ Verify that `akto-api-discovery` appears in `KONG_PLUGINS` and that both `handler.lua` and `schema.lua` are present in the correct directory. Run `kong check` to validate the configuration. **`[akto-api] [async] connect failed (Akto unreachable)`**\ The ingest service is not reachable from Kong within the 3-second connect timeout. Check: 1. The `config.service_url` is correct and reachable from the Kong host 2. Firewall/NSG rules allow traffic on port `8080` (or your configured port) 3. The hostname resolves correctly inside Kong's container (use the container's internal hostname, not `localhost`, when both run in Docker) **`[akto-api] ingest dropped — N timers in-flight`**\ The plugin's in-flight timer guard fired (max 20 concurrent ingests per worker). This usually means the Akto ingest backend is slow or unreachable. Your client traffic is **not affected** — only some ingest samples are dropped. Investigate the ingest backend's health. **No `[akto-api]` lines in Kong logs**\ The plugin defaults to `log_level=warn`, which only logs failures. To see per-request `[async] ingest ok` lines, set `config.log_level=info` on the plugin. Also ensure `KONG_LOG_LEVEL=info` (or lower) in Kong itself. **Request body is empty in ingested data**\ By design, the plugin does not force request-body buffering — doing so would add upload-time latency to every POST/PUT/PATCH request. The request body is captured only when another plugin or Kong itself has already buffered it. Response body, headers, method, path, and status code are always captured. *** ## Get Support * Raise an issue in the [Kong Integration GitHub repository](https://github.com/akto-api-security/kong-integration) * Contact the team via Slack or your assigned support channel * For enterprise support, email the engineering team with your Kong version, plugin version, and relevant log snippets # Connect Akto with Kong Mesh Kong Mesh is a service mesh platform that manages service-to-service communication in modern cloud-native applications. Integrating Kong Mesh with Akto will allow you to automatically discover and test the security of internal APIs and service communications within your mesh environment, ensuring your microservices are protected against potential vulnerabilities. To connect Akto with Kong Mesh, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add Kong Mesh connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **Kong Mesh** block and click on the **Connect** button to get instructions
To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Connect Akto with Cloudflare Cloudflare is a global network security platform that provides CDN, DDoS protection, and API security services. Integrating Cloudflare with Akto will enable automatic discovery of all APIs passing through your Cloudflare infrastructure, helping you maintain continuous visibility and protection of your edge-distributed APIs.
## Purpose Connect your Cloudflare web application / MCP server to Akto for: * **Traffic data ingestion** - Automatic API discovery and monitoring * **MCP Guardrails** - Real-time security scanning and threat detection for AI agent interactions ## Quick Navigation * [Deployment Options](#deployment-options) * [Architecture Diagram](#architecture-mcp-guardrails-and-data-ingestion) * [Worker Deployment: akto-guardrails-executor](#worker-deployment-akto-guardrails-executor) * [Worker Deployment: akto-ingest-guardrails](#worker-deployment-akto-ingest-guardrails) * [Updating Your Server Code: akto-ingestion-publisher](#updating-your-server-code-akto-ingestion-publisher) * [Verification Steps](#verification-steps) * [Get Support](#get-support) ## Deployment Options Choose the deployment path that fits your needs: ### Option 1: Data Ingestion Only (Without Guardrails) If you only need API discovery and monitoring without MCP guardrails: 1. [**Deploy akto-ingest-guardrails Worker**](#worker-deployment-akto-ingest-guardrails) (set `ENABLE_MCP_GUARDRAILS` to `false`) 2. [**Update Your Server Code**](#updating-your-server-code-akto-ingestion-publisher) to enable traffic collection ### Option 2: Data Ingestion with MCP Guardrails If you need both API discovery and real-time MCP security guardrails: 1. [**Deploy akto-guardrails-executor Worker**](#worker-deployment-akto-guardrails-executor) - Executes guardrail policies 2. [**Deploy akto-ingest-guardrails Worker**](#worker-deployment-akto-ingest-guardrails) - Orchestrates ingestion and guardrails (set `ENABLE_MCP_GUARDRAILS` to `true`) 3. [**Update Your Server Code**](#updating-your-server-code-akto-ingestion-publisher) to enable traffic collection *** ## Architecture ### Data Ingestion Only This diagram shows the architecture for **Option 1** - data ingestion without MCP guardrails. Your Cloudflare Worker collects traffic data and sends it to the Akto Ingest-Guardrails Worker (with `ENABLE_MCP_GUARDRAILS=false`), which then forwards the data to Akto for API discovery and monitoring.

Data Ingestion Only Architecture

### Data Ingestion with MCP Guardrails This diagram shows the architecture for **Option 2** - data ingestion with MCP guardrails enabled. Your Cloudflare Worker sends traffic to the Akto Ingest-Guardrails Worker (with `ENABLE_MCP_GUARDRAILS=true`), which coordinates with the Akto Guardrails Executor to enforce security policies before sending data to Akto.

Data Ingestion with MCP Guardrails Architecture

*** ## Worker Deployment Details ### Worker Deployment: akto-guardrails-executor The Agent Guard Executor service is **required only for MCP Guardrails**. Skip this section if you only need data ingestion without guardrails. The MCP Guardrails Worker will communicate with this service via Cloudflare worker-to-worker binding to execute guardrail policies. #### Prerequisites * Docker with buildx * Node.js 18+ * Wrangler CLI authenticated with your Cloudflare account #### 1. Checkout Worker Code Clone the worker code from the repository: ```bash # Clone the Akto Cloudflare deployments repository git clone https://github.com/akto-api-security/akto-cloudflare-deployments.git cd akto-cloudflare-deployments # Switch to the ingestion-and-guardrails branch git checkout feature/ingestion-and-guardrails # Pull the latest changes to ensure you have the most recent version git pull origin feature/ingestion-and-guardrails # Navigate to the guardrails executor worker directory cd workers/akto-guardrails-executor ``` Alternatively, download and extract the zip file: ```bash # Download the repository as a zip file curl -L -o akto-cloudflare-deployments.zip https://github.com/akto-api-security/akto-cloudflare-deployments/archive/refs/heads/feature/ingestion-and-guardrails.zip # Extract the zip file unzip akto-cloudflare-deployments.zip # Navigate to the guardrails executor worker directory cd akto-cloudflare-deployments-feature-ingestion-and-guardrails/workers/akto-guardrails-executor ``` #### 2. Install Dependencies ```bash npm install ``` #### 3. Pull and Push Agent Guard Executor Container Image Pull, rebuild, and push the Agent Guard Executor container image to Cloudflare registry: ```bash # Pull the image docker pull --platform linux/amd64 public.ecr.aws/aktosecurity/akto-agent-guard-executor:1.12.1_local # Rebuild for linux/amd64 (required) docker buildx build --platform linux/amd64 --load -t agent-guard-executor:testing - <<'EOF' FROM public.ecr.aws/aktosecurity/akto-agent-guard-executor:1.12.1_local EOF # Push to Cloudflare registry npx wrangler containers push agent-guard-executor:testing ``` #### 4. Configure Worker Update the `wrangler.jsonc` file in the `akto-guardrails-executor` directory. Replace the image path with your Cloudflare registry URL: ```json "image": "registry.cloudflare.com//agent-guard-executor:testing" ``` #### 5. Deploy Worker ```bash npx wrangler deploy ``` After deploying the Agent Guard Executor Worker, note its worker name - you'll use it to configure the worker-to-worker service binding in the next section. *** ### Worker Deployment: akto-ingest-guardrails The Akto Ingest-Guardrails Worker is **required for both deployment options**: * **Data Ingestion Only**: Set `ENABLE_MCP_GUARDRAILS` to `false` * **Data Ingestion with Guardrails**: Set `ENABLE_MCP_GUARDRAILS` to `true` (requires `akto-guardrails-executor` deployed first) This worker handles traffic data ingestion to Akto and optionally orchestrates MCP guardrail enforcement based on configured policies. #### Prerequisites * Node.js 18+ * Wrangler CLI authenticated with your Cloudflare account * Docker with buildx * If enabling guardrails: `akto-guardrails-executor` Worker deployed (see previous section) #### 1. Checkout Worker Code If you cloned the repository in the previous section: ```bash # Navigate to the ingest-guardrails worker directory from the repository root cd akto-cloudflare-deployments/workers/akto-ingest-guardrails ``` If you downloaded the zip file in the previous section: ```bash # Navigate to the ingest-guardrails worker directory from the extracted folder cd akto-cloudflare-deployments-feature-ingestion-and-guardrails/workers/akto-ingest-guardrails ``` If you haven't cloned or downloaded yet, use one of these options: **Option A: Clone the repository** ```bash # Clone the Akto Cloudflare deployments repository git clone https://github.com/akto-api-security/akto-cloudflare-deployments.git cd akto-cloudflare-deployments # Switch to the ingestion-and-guardrails branch git checkout feature/ingestion-and-guardrails # Pull the latest changes to ensure you have the most recent version git pull origin feature/ingestion-and-guardrails # Navigate to the ingest-guardrails worker directory cd workers/akto-ingest-guardrails ``` **Option B: Download and extract the zip file** ```bash # Download the repository as a zip file curl -L -o akto-cloudflare-deployments.zip https://github.com/akto-api-security/akto-cloudflare-deployments/archive/refs/heads/feature/ingestion-and-guardrails.zip # Extract the zip file unzip akto-cloudflare-deployments.zip # Navigate to the ingest-guardrails worker directory cd akto-cloudflare-deployments-feature-ingestion-and-guardrails/workers/akto-ingest-guardrails ``` #### 2. Install Dependencies ```bash npm install ``` #### 3. Push Mini Runtime Service Container Image Pull, rebuild, and push the Mini Runtime Service container image: ```bash # Pull the base image docker pull --platform linux/amd64 aktosecurity/mini-runtime-service:latest # Rebuild for linux/amd64 (required) docker buildx build --platform linux/amd64 --load -t mrs:testing - <<'EOF' FROM aktosecurity/mini-runtime-service:latest EOF # Push to Cloudflare registry npx wrangler containers push mrs:testing ``` #### 4. Configure Worker Update the `wrangler.jsonc` file: 1. Set the container image path with your Cloudflare account ID: ```json "image": "registry.cloudflare.com//mrs:testing" ``` 2. Configure the `ENABLE_MCP_GUARDRAILS` environment variable: * **For data ingestion only (Option 1)**: Set to `"false"` * **For data ingestion with guardrails (Option 2)**: Set to `"true"` ```json "vars": { "ENABLE_MCP_GUARDRAILS": "false" } ``` 3. **If enabling guardrails** (Option 2): Configure service bindings to connect with the Agent Guard Executor Worker deployed in the previous section. 4. **Optional - Setup KV Namespace for Rate Limiting**: Rate limiting for MCP guardrails is controlled by this KV namespace binding. To disable rate limiting, skip this step or comment out the `kv_namespaces` block in `wrangler.jsonc`. Create KV namespace (if not already exists): ```bash npx wrangler kv namespace create "AKTO_GUARDRAILS_RATE_LIMIT_KV" ``` Uncomment and update the `kv_namespaces` block in `wrangler.jsonc` with the generated ID: ```jsonc "kv_namespaces": [ { "binding": "AKTO_GUARDRAILS_RATE_LIMIT_KV", "id": "" } ] ``` If the namespace already exists, get the ID from Cloudflare UI: **Storage & Databases > Workers KV > AKTO\_GUARDRAILS\_RATE\_LIMIT\_KV** **Rate Limiting Configuration:** Rate limiting is applied globally across all MCP tool calls and tracked per IP per tool by default. **Configuration Source:** Rate limit rules are automatically fetched from the backend. Configure via: **Akto Dashboard**: Settings > Threat Configuration The worker uses the first STATIC rule configuration: * `maxRequests` - Maximum number of requests allowed * `period` - Time window in minutes Rate limits are tracked per IP per tool by default. **Fallback Configuration:** If the backend is unavailable or no static rule is found, defaults are used: * Limit: 100 requests * Window: 300 seconds (5 minutes) * Tracking: Per IP per tool #### 5. Set Secrets Set the required secrets for the worker: ```bash wrangler secret put DATABASE_ABSTRACTOR_SERVICE_TOKEN wrangler secret put THREAT_BACKEND_TOKEN ``` **Environment Variables:** * `DATABASE_ABSTRACTOR_SERVICE_URL`: "" * `THREAT_BACKEND_URL`: "" * `ENABLE_MCP_GUARDRAILS`: "true" (set to "false" for ingestion-only deployment) #### 6. Deploy Worker ```bash npx wrangler deploy ``` **Important Notes:** * This worker is private and does not expose a public HTTP URL (set via `workers_dev: false`) * Worker-to-worker binding enables secure communication with the Agent Guard Executor Worker (if guardrails enabled) * The worker orchestrates guardrail checks based on your configured security and audit policies (if guardrails enabled) * Rate limiting requires KV namespace to be set up (optional) * Rate limits are distributed across Cloudflare edge locations via KV *** ### Updating Your Server Code: akto-ingestion-publisher After deploying the `akto-ingest-guardrails` worker, you need to update your Cloudflare server code to enable traffic data collection and send it to Akto. #### Integration Guide **1. Copy the Akto Integration Code** Reference the example worker from the [akto-ingestion-publisher](https://github.com/akto-api-security/akto-cloudflare-deployments/tree/feature/ingestion-and-guardrails/workers/akto-ingestion-publisher) directory and copy the `src/akto/` folder to your project. This directory contains: * `ingest-data.ts` - Main ingestion entry point * `akto-ingestion-client.ts` - Singleton client for Akto service communication * `models.ts` - Data models and payload builder * `validations.ts` - Traffic capture validation logic * `utils.ts` - Contains utilities for traffic ingestion to Akto **2. Update Your Worker's Fetch Handler** > **Note:** Replace `yourRequestHandler` with your actual request handler function in the code below. ```typescript import { replicateRequest, replicateResponse } from "./akto/utils"; import { ingestTrafficToAkto } from "./akto/ingest-data"; import { AktoIngestionClient } from "./akto/akto-ingestion-client"; export default { async fetch(request: Request, env: any, ctx: ExecutionContext): Promise { // Initialize Akto client on first request AktoIngestionClient.init(env.AKTO_INGESTION_WORKER); // Replicate the request at the start const [requestForMainExecution, requestForAktoIngestion] = await replicateRequest(request); // Forward to your application handler (replace with your logic) const response = await yourRequestHandler(requestForMainExecution, env, ctx); const [responseForMainExecution, responseForAktoIngestion] = replicateResponse(response); // Ingest traffic data to Akto in background (non-blocking) ctx.waitUntil( ingestTrafficToAkto(requestForAktoIngestion, responseForAktoIngestion) ); // Return response to client return responseForMainExecution; }, }; ``` **3. Add Service Binding to Your wrangler.jsonc** Add the following service binding configuration to connect your worker with the `akto-ingest-guardrails` worker: ```json { "services": [ { "binding": "AKTO_INGESTION_WORKER", "service": "akto-ingest-guardrails" } ] } ``` **Important Notes:** * Traffic collection happens asynchronously using `ctx.waitUntil()` - it won't block your main response * Only captures allowed content types (JSON, XML, GRPC, form-urlencoded, etc.) * Replicates original server request and response to avoid conflict with main execution flow * All Akto-related logs are prefixed with `[Akto]` for easy filtering ## Verification Steps After completing the deployment and server code updates, verify that the integration is working correctly: 1. Send test traffic through your Cloudflare Worker 2. Check Cloudflare Worker logs for Akto-related messages (prefixed with `[Akto]`) 3. Navigate to the [Akto Dashboard](https://app.akto.io/) 4. Go to **API Collections** and select your hostname 5. Verify that API traffic data (requests and responses) are being captured 6. **If using MCP Guardrails**: Verify guardrail execution by checking: * Cloudflare Worker logs for guardrail-related messages * Akto dashboard under **Agentic Protection** for detected threats and policy violations *** ## Get Support Contact Akto support if you encounter any issues during setup: There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with Cloudflare Worker Proxy Cloudflare is a global network security platform that provides CDN, DDoS protection, and API security services. Integrating Cloudflare with Akto enables automatic discovery of all APIs passing through your Cloudflare infrastructure, helping you maintain continuous visibility and protection of your edge-distributed APIs.
To connect Akto with Cloudflare, follow these steps - *** ## Step 1: Deploy the Akto Data-Ingestion Service Before configuring the Cloudflare Worker Traffic Connector, you need to deploy the Akto Data-Ingestion Service. Ensure that the service is running and accessible via a publicly available URL. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/quick-start-with-akto-cloud/hybrid-saas#linux-vm). Ensure this instance is publicly accessible, as it will receive traffic logs from your Cloudflare Worker. *** ## Step 2: Set Up Your Cloudflare Worker Script 1. Navigate to the [Cloudflare Dashboard](https://dash.cloudflare.com/) and select your account. 2. Go to **Workers & Pages**.
3. Click **Create** and choose **Worker**.
4. Click the **Hello World** button and deploy it.
5. Click **Edit code** and replace the default script with your Worker code that proxies traffic and mirrors it to Akto using **service binding**. ```javascript export default { async fetch(request, env, ctx) { console.log("🚀 Worker handling:", request.method, request.url); // Detect WebSocket upgrade const upgradeHeader = request.headers.get("Upgrade") || ""; const isWebSocket = upgradeHeader.toLowerCase() === "websocket"; if (isWebSocket) { console.log("🔄 WebSocket upgrade detected"); // Just proxy the connection const response = await fetch(request); // Clone headers only (no body to tee here) ctx.waitUntil(logTraffic(request, response, env, { isWebSocket: true })); return response; } // Normal HTTP(S) traffic let requestForFetch, requestForLog; if (request.body) { const [req1, req2] = request.body.tee(); requestForFetch = new Request(request, { body: req1 }); requestForLog = new Request(request, { body: req2 }); } else { requestForFetch = request; requestForLog = request.clone(); } const response = await fetch(requestForFetch); console.log("⬅️ Upstream response:", response.status); let responseForClient, responseForLog; if (response.body) { const [res1, res2] = response.body.tee(); responseForClient = new Response(res1, response); responseForLog = new Response(res2, response); } else { responseForClient = response; responseForLog = response.clone(); } ctx.waitUntil(logTraffic(requestForLog, responseForLog, env)); return responseForClient; }, }; async function logTraffic(request, response, env, opts = {}) { try { console.log("📝 logTraffic running..."); const reqContentType = request.headers.get("content-type") || ""; const resContentType = response.headers.get("content-type") || ""; const status = response.status; let reqBody = ""; let resBody = ""; if (!opts.isWebSocket) { // Only attempt to read bodies for HTTP reqBody = await readBodyAsText(request); resBody = await readBodyAsText(response); if (!(status >= 200 && status < 400)) { console.log("⚠️ Skipped log: status", status); return; } if (!reqContentType && !resContentType) { console.log("⚠️ Skipped log: no content-type in request or response"); return; } if (!shouldCapture(reqContentType) && !shouldCapture(resContentType)) { console.log("⚠️ Skipped log: not a target content-type", { reqContentType, resContentType }); return; } } const url = new URL(request.url); const logEntry = { path: url.pathname, method: request.method, requestHeaders: JSON.stringify(Object.fromEntries(request.headers)), responseHeaders: JSON.stringify(Object.fromEntries(response.headers)), requestPayload: reqBody, responsePayload: resBody, ip: request.headers.get("cf-connecting-ip") || "127.0.0.1", time: Math.floor(Date.now() / 1000).toString(), statusCode: status.toString(), type: opts.isWebSocket ? "WebSocket" : "HTTP/1.1", status: response.statusText || "OK", akto_account_id: "1000000", akto_vxlan_id: "0", is_pending: "false", source: "MIRRORING", tag: "{\n \"service\": \"cloudflare\"\n}" }; console.log("📤 Sending log entry to webhook..."); const aktoReq = new Request("https:///api/ingestData", { method: "POST", headers: { "content-type": "application/json", "x-api-key": "YOUR_AKTO_API_KEY" }, body: JSON.stringify({ batchData: [logEntry] }), }); // await env..fetch(aktoReq); const aktoResp = await fetch(aktoReq); if(aktoResp.status == 200) { console.log("✅ Log sent to akto"); } else { console.log("❌ Failed to send data to Akto. Response Status: " + aktoResp?.status); } } catch (err) { console.error("❌ Log error:", err); } } function shouldCapture(contentType) { const targets = ["json", "xml", "x-www-form-urlencoded", "soap", "grpc"]; return targets.some((t) => contentType.toLowerCase().includes(t)); } async function readBodyAsText(obj, maxSize = 64 * 1024) { try { const buf = await obj.arrayBuffer(); const bytes = new Uint8Array(buf).slice(0, maxSize); return new TextDecoder().decode(bytes); } catch { return ""; } } ``` ### Important Notes while editing the Worker code * Replace `` with the URL of the Akto Data-Ingestion Service you deployed in **Step 1**. * Replace `YOUR_AKTO_API_KEY` with your API key from Akto. You can find it inside **Akto Dashboard → Settings → Integrations → Akto API**. * If you are using Cloudflare **Service Binding** to send traffic to your ingestion service hosted inside a Cloudflare container, use the following line instead of a public URL: ```javascript // use this line to send data internally to data ingestion service // hosted in your Cloudflare container await env..fetch(aktoReq); // for example await env.data_inject_worker.fetch(aktoReq); ``` *** ## Step 3: Configure Worker Routing If you'd like to route specific domains or paths through this Worker: 1. In the Cloudflare Dashboard, go to **Workers & Pages**. 2. Under **Overview**, select your Worker. 3. Navigate to **Settings** > **Domains & Routes**. 4. Click **Add Route**. 5. Select the appropriate zone (domain), and enter a route pattern such as: ``` *.yourdomain.com/* ``` This ensures all traffic matching the route is intercepted and mirrored to Akto. *** ## Step 4: Verify the Setup 1. Confirm that API traffic data (requests and responses) are captured on the Akto dashboard under the respective API collection. 2. Check logs of your Worker for any initialization or forwarding messages. 3. Go back to the [Akto Dashboard](https://app.akto.io/). 4. Navigate to **API Collections** > **Hostname**. 5. You should start seeing the traffic from your Cloudflare Worker. *** ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24x7 available on the following: 1. In-app `intercom` support — message us inside the Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Reach us [here](https://www.akto.io/contact-us). # Connect Akto with IBM Connect IBM API Connect is IBM's comprehensive API management solution designed specifically for enterprises running hybrid cloud environments. By integrating IBM API Connect with Akto, you'll be able to automatically discover and test the security of all APIs across your IBM Cloud and on-premise environments, helping you maintain consistent security standards across your entire API infrastructure.
To connect Akto with IBM API Connect, follow the steps below. *** ## Step 1: Deploy the Akto Data-Ingestion Service Before configuring your API Connect global policies, ensure that the Akto Data-Ingestion Service is up and running. ### 1.1 Download Required Files SSH into the server where you want to deploy the data-ingestion service and run the following commands: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the Akto Token 1. Log in to the [Akto Dashboard](https://app.akto.io/). 2. Navigate to the **Quick Start** tab.
3. Select **Hybrid SaaS Connector** and copy the token shown under **Runtime Service Command**.
### 1.3 Configure the Environment File Edit the `docker-mini-runtime.env` file and add your Akto token: ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=your_token_here ``` ### 1.4 Deploy the Service Start the data-ingestion service using Docker: ```bash docker-compose -f docker-compose-data-ingestion-runtime.yml up -d ``` Make sure this instance is accessible over the network from IBM API Connect's gateway service. *** ## Step 2: Deploy Akto Gateway Interceptor Scripts IBM API Connect allows global prehook and posthook scripts to intercept API traffic. You’ll use custom GatewayScript-based policies to forward request and response data to Akto. ### 2.1 Download the Pre and Post Global Policy Files Make sure you have the following two files: * `global-pre.yaml` ```yaml global-policy: 1.0.0 info: name: akto_global_pre title: Akto IBM Agent PreRequest version: 1.0.0 mode: after-builtin gateways: - datapower-api-gateway assembly: execute: - gatewayscript: version: 2.0.0 title: akto-ibm-agent source: | context.set("start_time", new Date().getTime()); context.request.body.readAsBuffer(function (error, buffer) { try { if (!error && buffer && buffer.length > 0) { var bufferStr = new Buffer(buffer).toString("base64"); context.set("request_body", bufferStr); } else { context.set("request_body", ""); } } catch (e) { context.set("request_body", ""); } }); ``` * `global-post.yaml` ```yaml global-policy: 1.0.0 info: name: akto_global_post title: Akto IBM Agent PostRequest version: 1.1.0 gateways: - datapower-api-gateway assembly: execute: - gatewayscript: version: 2.0.0 title: akto-ibm-agent source: | var urlopen = require("urlopen"); var ingestionBaseUrl = "http://data-ingestion-service-ip"; var samplingRate = 1.0; // 1.0 = 100%, 0.1 = 10%, 0.5 = 50% var friendlyHttpStatus = { '200': 'OK', '201': 'Created', '202': 'Accepted', '203': 'Non-Authoritative Information', '204': 'No Content', '205': 'Reset Content', '206': 'Partial Content', '300': 'Multiple Choices', '301': 'Moved Permanently', '302': 'Found', '303': 'See Other', '304': 'Not Modified', '305': 'Use Proxy', '306': 'Unused', '307': 'Temporary Redirect', '400': 'Bad Request', '401': 'Unauthorized', '402': 'Payment Required', '403': 'Forbidden', '404': 'Not Found', '405': 'Method Not Allowed', '406': 'Not Acceptable', '407': 'Proxy Authentication Required', '408': 'Request Timeout', '409': 'Conflict', '410': 'Gone', '411': 'Length Required', '412': 'Precondition Required', '413': 'Request Entry Too Large', '414': 'Request-URI Too Long', '415': 'Unsupported Media Type', '416': 'Requested Range Not Satisfiable', '417': 'Expectation Failed', '418': 'I\'m a teapot', '429': 'Too Many Requests', '500': 'Internal Server Error', '501': 'Not Implemented', '502': 'Bad Gateway', '503': 'Service Unavailable', '504': 'Gateway Timeout', '505': 'HTTP Version Not Supported', }; function lowerHeaders(headers) { var key, keys = Object.keys(headers); var loweredHeaders = {}; var n = keys.length; for (var i = 0; i < n; i++) { key = keys[i]; if (typeof headers[key] == "object") { if (Array.isArray(headers[key])) { loweredHeaders[key.toLowerCase()] = headers[key].join(",").toString(); continue; } else { continue; } } loweredHeaders[key.toLowerCase()] = headers[key]; } return loweredHeaders; } var headers = context.get("request.headers"); var contentType = headers["content-type"] || headers["Content-Type"] || ""; var request_headers = lowerHeaders(headers); var resp_headers = context.get("message.headers"); var response_headers = lowerHeaders(resp_headers); if (contentType.indexOf("application/json") !== -1) { var req_body_base64 = context.get("request_body") || ""; var req_body_str = ""; var allStrings = true; if (req_body_base64.length > 0) { try { var req_buffer = new Buffer(req_body_base64, "base64"); req_body_str = req_buffer.toString("utf-8"); var parsedJson = JSON.parse(req_body_str); for (var key in parsedJson) { if (typeof parsedJson[key] !== "string") { allStrings = false; break; } } if (!allStrings) { req_body_str = ""; } } catch (e) { req_body_str = ""; } } var path = context.get("api.org.name") + "/" + context.get("api.catalog.path") + "/" + context.get("request.path") + context.get("request.search"); var verb = context.get("request.verb"); var host = context.get("api.endpoint.hostname"); var status = context.get("message.status.code"); var client_addr = context.get("session.clientAddress"); var http_version = "HTTP/" + (context.get("request.version") || "1.1"); var start_time = context.get("start_time"); if (Math.random() > samplingRate) { return; } context.message.body.readAsBuffer(function (error, buffer) { var res_body = ""; if (!error && buffer != null && buffer.length > 0) { try { res_body = buffer.toString("utf-8"); } catch (e) { res_body = ""; } context.message.body.write(buffer); } var sendData = { batchData: [ { path: path, requestHeaders: JSON.stringify(request_headers), responseHeaders: JSON.stringify(response_headers), method: verb, requestPayload: req_body_str, responsePayload: res_body, ip: client_addr || "0.0.0.0", time: "" + Math.floor(start_time / 1000), statusCode: "" + status, type: "HTTP/" + http_version, status: "" + friendlyHttpStatus[(status + "")], akto_account_id: "1000000", akto_vxlan_id: "0", is_pending: "false", source: "MIRRORING" } ] }; var healthCheckRequest = { target: ingestionBaseUrl + "/healthCheck", method: "GET", timeout: 1, }; urlopen.open(healthCheckRequest, function (healthError, healthResponse) { if (healthError) { console.error("Health check failed, skipping data ingestion: " + healthError); return; } healthResponse.discard(); var request_final = { target: ingestionBaseUrl + "/api/ingestData", method: "POST", headers: { "content-type": "application/json", }, timeout: 1, data: JSON.stringify(sendData), }; urlopen.open(request_final, function (error, response) { if (error) { console.error( "error: " + error + " info: connection failed trying to secure backup" ); return; } response.discard(); }); }); }); } ``` These files define global prehook and posthook behavior using GatewayScript. ### 2.2 Run the Setup Script We provide a shell script to automatically upload and configure these global policies. #### Script: `setup-akto-gateway-hooks.sh` ```bash #!/bin/bash server="your_server_here" org="your_org_here" gateway="your_gateway_here" data_ingestion_service_ip="your_data-ingestion-service-ip_here" catalog="your_catalog_here" echo $data_ingestion_service_ip sed -i '' "s|data-ingestion-service-ip|${data_ingestion_service_ip}|g" global-post.yaml apic global-policies:create --catalog $catalog --configured-gateway-service $gateway --org $org --server $server --scope catalog global-pre.yaml > temp preurl=$(cut -d " " -f 4 temp) echo -e "global_policy_url: >-\n $preurl" > GlobalPolicy.yaml apic global-policy-prehooks:create --catalog $catalog --configured-gateway-service $gateway --org $org --server $server --scope catalog GlobalPolicy.yaml apic global-policies:create --catalog $catalog --configured-gateway-service $gateway --org $org --server $server --scope catalog global-post.yaml > temp posturl=$(cut -d " " -f 4 temp) echo -e "global_policy_url: >-\n $posturl" > GlobalPolicy.yaml apic global-policy-posthooks:create --catalog $catalog --configured-gateway-service $gateway --org $org --server $server --scope catalog GlobalPolicy.yaml ``` ### 2.3 Modify the Script Update the following variables in the script: ```bash server="https://" org="" gateway="" data_ingestion_service_ip="" catalog="" ``` ### 2.4 Execute the Script Make the script executable and run it: ```bash chmod +x setup-akto-gateway-hooks.sh ./setup-akto-gateway-hooks.sh ``` This will upload and register both prehook and posthook global policies with your IBM API Connect Gateway. *** ## Step 3: Confirm Traffic is Flowing to Akto After setup: * Make a few API calls from your applications. * Go to the **API Collections** in Akto dashboard. * You should begin seeing real-time API traffic, including headers, payloads, status codes, and timestamps. *** ## Notes * Ensure that your gateway has outbound access to the Akto Data-Ingestion Service. # Connect Akto with Mulesoft Flex Gateway Learn about how to send API traffic data using Mulesoft Flex Policy to Akto from your environment.
## Connect Akto with Mulesoft Flex Gateway ### Setup Akto Runtime and Data Ingestion Service Follow these steps to add setup Akto Runtime and Data Ingestion Service - 1\. SSH into the instance where you want to deploy the above Akto services 2\. Run the following commands to download docker compose and env files ``` wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` 3\. Modify ${AKTO\_KAFKA\_IP} in docker-compose-data-ingestion-runtime.yml with the ip of your instance on which runtime will be deployed 4\. Go to , and create your akto account. Login into your Account 5\. Click on Quick Start tab in left nav.
6\. Search for Hybrid SaaS Connector and click connect.
7\. Copy the token value under `Runtime Service Command` section. Replace the token string with the earlier copied value in docker-mini-runtime.env file. ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` 8\. Run `docker-compose -f docker-compose-data-ingestion-runtime.yml -d` 9\. Make sure this instance is reachable from the instances where your api's are hosted, on which policy will be applied ## Connect Akto with Mulesoft Flex Gateway ### Setup Flex Policy 1\. Follow PDK Prerequisites on the Mulesoft documentation site, and setup the basic requirements 2\. Initialise a new project `anypoint-cli-v4 pdk policy-project create --name ` 3\. Clone the [repo](https://github.com/akto-api-security/mulesoft-policy). 4\. Copy content of gcl.yaml, lib.rs, Corgo.toml files, and paste these files in your project at respective locations. 5\. Compile the project by running ``` make build-asset-files cargo build make build ``` 6\. Publish the policy to mulesoft exchange by running `make publish` 7\. Select your api's on which you want to apply Akto Policy. 8\. Copy the instance ip where Akto Runtime was deployed, and replace \ in the below string and use it as input param `ingestionUrl` to the policy `https://:9091/api/ingestData`
# Connect Akto with Apigee Apigee is Google Cloud's full-lifecycle API management platform that helps enterprises design, secure, and scale APIs. Integrating Apigee with Akto enables automatic discovery and security testing of all APIs managed through your Apigee gateway, providing comprehensive visibility and continuous security assessment of your API infrastructure.
*** ## Step 1: Deploy the Akto Data-Ingestion Service Before setting up the Apigee connector, deploy the Akto Data-Ingestion Service by following these steps: ### 1.1 Download the Required Files SSH into the instance where you want to deploy the data-ingestion service and run these commands: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` * Log in to the [Akto Dashboard](https://app.akto.io/). * Navigate to the **Quick Start** tab in the left panel.
* Select **Hybrid SaaS Connector** and copy the token from the **Runtime Service Command** section.
### 1.3 Update the `docker-mini-runtime.env` File * Open the `docker-mini-runtime.env` file and replace `token` with the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` you retrieved earlier. ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` ### 1.4 Deploy the Data-Ingestion Service Run the following command to start the data-ingestion service: ```bash docker-compose -f docker-compose-data-ingestion-runtime.yml up -d ``` ### 1.5 Note the IP Address of the Data-Ingestion Service Ensure the instance is accessible from the network where your Apigee API proxy is configured. Note the instance's IP address, as it will be required by the Apigee connector to send traffic data. *** ## Step 2: Configure Apigee to Use the Akto Data-Ingestion Service You can choose either option below for Step 2: * **Option A:** Manual setup from the GCP Apigee UI. * **Option B:** Automated setup using Terraform scripts from Akto's infra repository. Both options configure Akto ingestion in Apigee. Option B is recommended for repeatable CI/CD-friendly deployments. ### 2.1 Create or Choose an Apigee Environment To configure the Akto connector, you need an **Intermediate** or **Comprehensive** environment in Apigee, as the JavaScript policy is not supported in the **Base** environment. #### Steps to Create an Environment: 1. Log in to the [Apigee Management Console](https://console.cloud.google.com/apigee/overview). 2. Navigate to **Management → Environments** from the left-side navigation bar.
3. Click **+ Create Environment**.
4. Provide the required details: * **Name**: Specify a name for your environment. * **Environment Type**: Choose **Intermediate** or **Comprehensive**. 5. Click **Create** to finalize your environment setup.
If you already have an **Intermediate** or **Comprehensive** environment, you can skip this step and proceed to the next section. ### 2.2 Option A: Manual Setup from GCP UI (Shared Flow + Flow Hook) This is the manual environment-wide setup. 1. In Apigee, go to **Proxy development → Shared Flows** and click **+ Create**.
2. Create a shared flow (for example: `akto-traffic-collector`). 3. Open the shared flow, go to **Develop → default**, and add two Steps in order: first `AktoJavascript`, then `ML-SendAktoTcpSyslog`. 4. In the same shared flow, click **Policies +** and add a **JavaScript** policy named `AktoJavascript`.
5. Open the JavaScript policy XML (Under Policies section) and set it as: ```xml AktoJavascript jsc://AktoJavascript.js ``` 6. Create a JS resource file named `AktoJavascript.js` and paste the script below. 7. Click **Policies +** again and add a **MessageLogging** policy named `ML-SendAktoTcpSyslog`. Set the policy XML as: ```xml ML-SendAktoTcpSyslog {akto.log.payload} YOUR_DATA_INGESTION_SERVICE_IP 5140 TCP false ``` 8. Save and deploy the shared flow to your target environment.
9. Go to **Management → Environments → your\_environment → Flow Hooks**. 10. Attach the shared flow to a hook point (recommended: `PostProxyFlowHook`).
```javascript var requestPath = context.getVariable("request.uri"); var queryString = context.getVariable("request.querystring"); var requestHeaders = context.getVariable("request.headers.names"); var requestPayload = context.getVariable("request.content"); var clientIp = context.getVariable("request.header.x-forwarded-for"); var method = context.getVariable("request.verb"); var responseHeaders = context.getVariable("response.headers.names"); var responsePayload = context.getVariable("response.content"); var statusCode = context.getVariable("response.status.code"); var statusText = context.getVariable("response.reason.phrase") || "OK"; var rawTime = context.getVariable("system.timestamp"); var epochTime = Math.floor(rawTime / 1000); var requestHeadersRes = {}; requestHeaders = (requestHeaders + '').slice(1, -1).split(', '); requestHeaders.forEach(function(x) { requestHeadersRes[x] = context.getVariable("request.header." + x); }); var responseHeadersRes = {}; responseHeaders = (responseHeaders + '').slice(1, -1).split(', '); responseHeaders.forEach(function(x) { responseHeadersRes[x] = context.getVariable("response.header." + x); }); var payload = { batchData: [{ path: requestPath + (queryString ? "?" + queryString : ""), requestHeaders: JSON.stringify(requestHeadersRes), responseHeaders: JSON.stringify(responseHeadersRes), method: method, requestPayload: requestPayload || "", responsePayload: responsePayload || "", ip: clientIp || "0.0.0.0", time: "" + epochTime, statusCode: "" + statusCode, type: "HTTP/1.1", status: statusText, akto_account_id: "1000000", akto_vxlan_id: "0", is_pending: "false", source: "MIRRORING" }] }; context.setVariable("akto.log.payload", JSON.stringify(payload)); ``` Important policy behavior: * Both `AktoJavascript` and `ML-SendAktoTcpSyslog` must have `continueOnError="true"`. * Both policies must be added as Steps in the shared flow **default** section in order: JS first, then MessageLogging. * Replace `YOUR_DATA_INGESTION_SERVICE_IP` in the MessageLogging policy with the IP noted in Step 1.5. ### 2.3 Option B: Terraform Automation Use Terraform from: * **Repository:** * **Branch:** `feature/quick-setup` * **Folder:** `apigee-connect-terraform` 1. Clone and switch to the required branch: ```bash git clone https://github.com/akto-api-security/infra.git cd infra git checkout feature/quick-setup cd apigee-connect-terraform ``` 2. Provide the required values in a `terraform.tfvars` file inside `apigee-connect-terraform`. If the repository contains `terraform.tfvars.example`, copy it first: ```bash cp terraform.tfvars.example terraform.tfvars ``` Otherwise create `terraform.tfvars` manually with: ```hcl gcp_project_id = "your-gcp-project-id" apigee_environment = "your-apigee-environment-name" data_ingestion_service_url = "your-data-ingestion-service-ip:5140" ``` 3. Run Terraform: ```bash terraform init terraform apply -var-file="terraform.tfvars" ``` This automation creates and deploys the Apigee shared flow and attaches it to the selected environment flow hook. ### 2.4 Test the Integration * Send test API traffic through Apigee. * Verify in the Akto dashboard that traffic is being ingested. *** ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Mirroring # Connect Akto with AWS Traffic Mirroring Learn how to send API traffic data using AWS traffic mirroring to Akto from your environment. ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). One such source is AWS Traffic Mirroring. Traffic Mirroring is an Amazon VPC feature that you can use to copy network traffic from an elastic network interface of type `interface`. {% hint style="info" %} [Traffic mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) is non intrusive and allows you to send traffic to Akto in a completely out-of-band manner. {% endhint %} Traffic mirroring is our recommended way to receive data as it is completely non-intrusive. Akto's traffic analyzer analyzes this traffic to create your application's APIs request and response, understand API metadata and find misconfigurations. Akto can work with high traffic scale though you can always configure the amount of traffic you want to send to Akto dashboard. ## Pre-requisites to add data to Akto AWS using Traffic Mirroring 1. You should have installed Akto dashboard in the same VPC as your application server EC2 instances 2. You have permissions to create and assign roles to InstanceProfiles 3. Your application should be receiving unencrypted traffic. SSL, if any, should be terminated before it reaches your application server EC2 instance. Usually, SSL termination happens at API Gateway or Load balancer. 4. Not all AWS Instances support traffic mirroring. If you have any of [these instance types](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-limits.html#traffic-mirroring-limitations), we suggest you go with a different AWS traffic connector. ## Configuring Traffic Mirroring in Akto Dashboard To start capturing traffic from your staging, production ( or any other environment), you will need to sign-in to your dashboard and follow the steps below. 1. Navigate to the `Quick Start` page on dashboard.
Click on Quickstart

Click on Quickstart

2\. Click `connect traffic data`.
Click on connect traffic data

Click on connect traffic data

### Creating AWS Policy Below steps create a policy with AWS permissions in your account that allows Akto to capture API traffic from your selected loadbalancers. 1. Grab the policy JSON from your Akto dashboard in the first step as shown in the screenshot. `Click` on the link mentioned in `Step 1`.
Click on AWS policy link

Click on AWS policy link

2\. This will take you to the policy page of AWS. Navigate to `JSON` tab.
Policy page of AWS

Policy page of AWS

3\. `Copy the policy` from dashboard and `paste` here.
Copy policy JSON

Copy policy JSON

4\. `Click on review policy`.
Paste in AWS

Paste in AWS

5\. Name the policy `AktoDashboardPolicy`. 6\. Click `create policy`. Once policy is created, go back to the dashboard.
Policy created in AWS

Policy created in AWS

You have now given Akto the permissions to read loadbalancer names from your AWS account. ### Selecting loadbalancers to mirror traffic to Akto 1. Refresh the dashboard now. 2. You will be able to see a list of all the `loadbalancers`. 3. `Select loadbalancers` under my connections section. Select only those loadbalancers from which you want to mirror the traffic to Akto dashboard.
Select Loadbalancer in Akto

Select Loadbalancer in Akto

4\. Click `Apply` to start traffic mirroring.
Click apply

Click apply

5\. `Wait` for a couple of minutes. Mirroring is being setup on the loadbalancers you selected above.
Wait for a few mins

Wait for a few mins

6\. Once mirroring is complete, head to the `API discovery page` and see all the APIs Akto has discovered. ### What's next? You can now go to your API Inventory to see all the API traffic Akto has captured. Head to [API Discovery](/api-inventory/concepts/api-collection) to learn more. Once you start seeing inventory, you can run API Security tests on your APIs. See [Akto's test library](https://www.akto.io/test-library) to select tests you want to run on your APIs. ## Frequently Asked Questions (FAQs) **The mirrored traffic will contain a lot of sensitive data - does it leave my VPC?** Mirrored data remains strictly within your VPC. You can verify it by looking at VPC > Traffic mirror Targets. The NLB there & its listeners are all within your VPC. Akto doesn't take data out of your VPC at all. **Does Traffic mirroring have any impact on performance, latency or network bandwidth?** AWS Traffic mirroring is guaranteed to have 0 impact on performance and latency. It will definitely double your instance bandwidth usage. In case of bandwidth congestion, AWS will always prioritize your production traffic. You can read more about it [here from AWS documentation](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-limits.html#traffic-mirroring-bandwidth). **My traffic volume is of the order of TBs/hour. How much will traffic mirroring cost me?** AWS Traffic mirroring is independent of volume of traffic. It is proportional to number of traffic mirroring sessions and not related to volume of data. See [AWS pricing details](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html#pricing) here. **Do I have to install an agent or any service on my application server?** No. AWS Traffic mirroring is a completely non-intrusive way to collect and analyze server-side traffic. Absolutely no need to install or change any of your network settings at all. **I already have traffic mirroring setup on my application servers. Can I still use traffic mirroring?** AWS can't send same mirrored traffic to 2 diff targets. You should delete the existing session or use a diff traffic connector. ## Troubleshooting Guide **I can't see my Load balancer in the AWS Traffic mirroring section on Akto dashboard** Most likely, it is not in the same VPC as Akto dashboard. Please ensure your Akto dashboard is setup in the same VPC as your application server. **When I hit apply, it says "Something went wrong". How can I fix it?** Akto runs a Cloudformation template behind the scenes to setup the data processing stack and traffic mirroring sessions with your application servers' EC2 instances. This error means the Cloudformation setup failed. 1. Go to AWS > Cloudformation > Search for "mirroring" 2. Click on Akto-mirroring stack and go to Events tab 3. Scroll down to the oldest error event. **The Cloudformation template failed with "Client.InternalError: Client error on launch.". How should I fix it?** This is a known AWS common error. Follow the steps [here](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html#ts-as-instancelaunchfailure-12). **The Cloudformation template failed with "We currently do not have sufficient capacity in the Availability Zone you requested... Launching EC2 instance failed."** You can reinstall Akto in a diff availability zone or you can go to Template tab and save the cloudformation template in a file. Search for "InstanceType" and replace all the occurrences with a type that is available in your availability zone. You can then go to AWS > Cloudformation > Create stack and use this new template to setup Traffic mirroring. **I don't see my error on this list here.** Please send us all details at or reach out via Intercom on your Akto dashboard. We will definitely help you out. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. # Connect Akto with GCP Packet Mirroring Learn how to deploy Akto in GCP and add traffic to Akto using GCP Packet Mirroring ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). One such source is GCP Packet Mirroring. Packet Mirroring is a GCP feature that clones the traffic of specified instances in your Virtual Private Cloud (VPC) network and forwards it to Akto. Packet Mirroring captures all traffic and packet data, including payloads and headers. The capture can be configured for both egress and ingress traffic, only ingress traffic, or only egress traffic. {% hint style="info" %} [Packet mirroring](https://cloud.google.com/vpc/docs/packet-mirroring) is non intrusive and allows you to send traffic to Akto in a completely out-of-band manner. {% endhint %} Packet mirroring is our recommended way to receive data as it is completely non-intrusive. Akto's traffic analyzer analyzes this traffic to create your application's APIs request and response, understand API metadata and find misconfigurations. Akto can work with high traffic scale though you can always configure the amount of traffic you want to send to Akto dashboard. ## Pre-requisites to add data to Akto using Packet Mirroring Make sure, the GCP account in which the resources will be created has provisioned enough compute to be able to deploy [Akto](https://www.akto.io) and has sufficient permission levels to create resources. ## Steps to deploy Akto in GCP You can deploy Akto using the `Akto's GCP packet mirroring template`. Here are the steps to deploy: 1. Open GCP Cloud Shell from your GCP Account. You can find the setup script for Akto [here](https://raw.githubusercontent.com/akto-api-security/infra/feature/self_hosting/templates/gcp-mirroring-template.sh). Download it on your shell from the command {% code overflow="wrap" %} ``` wget https://raw.githubusercontent.com/akto-api-security/infra/feature/self_hosting/templates/gcp-mirroring-template.sh ``` {% endcode %} 2. Change the permissions so that you can execute it `- chmod +x gcp-mirroring-template.sh` 3. This will create a template with name `gcp-mirroring-template.sh` 4. Make sure you are in the project where you want to create resources. 5. Create a `.txt file` with name `inputs.txt` with the following input parameters. ``` project-id region network subnet zone ``` Here is an example of the txt file below: ``` ankitas-playground us-west4 vpc-1 vpc-1-usw4 us-west4-a ``` 6. Go to the instances you want to mirror and add network tag 'mirror' to them. 7. Now start creating resources by writing this command `./gcp-mirroring-template.sh create ) 12. You can now signup on Akto dashboard. ### What's next? You can now go to your API Inventory to see all the API traffic Akto has captured. Head to [API Discovery](/api-inventory/concepts/api-collection) to learn more. Once you start seeing inventory, you can run API Security tests on your APIs. See [Akto's test library](https://www.akto.io/test-library) to select tests you want to run on your APIs. ## Steps to Uninstall and delete Akto resources In case you are done using Akto and want to uninstall, follow these steps: 1. Create delete.txt with the following inputs: ``` akto y ``` 2. To delete all the resources you created with 'akto' prefix, run the command `./gcp-mirroring-template.sh delete Packet mirroring 2. Check if the VM ports at which your traffic is being generated is open in the Akto runtime machines. Say, if the traffic is being generated at port 3000 on the VM, open the same port on the akto runtime machine. 3. The Akto runtime processes traffic data every 15-20 minutes, so the traffic logged may not be visible instantly on the akto dashboard. 4. If this doesn’t solve your issue, contact our support at ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # AWS Services
# Connect Akto with AWS Beanstalk AWS Elastic Beanstalk is an AWS service that abstracts away the infrastructure complexity, making it easy to deploy and run applications in multiple languages like Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker. By integrating AWS Elastic Beanstalk with Akto, you'll be able to automatically discover and test APIs running on your Elastic Beanstalk environments, ensuring security testing is part of your seamless deployment process. To connect Akto with AWS Beanstalk, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add AWS Beanstalk connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **AWS Beanstalk** block and click on the **Connect** button to get instructions
# Connect Akto with AWS API Gateway AWS API Gateway is a fully managed service from AWS that helps developers create, publish, monitor, and secure APIs at scale. By integrating AWS API Gateway with Akto, you'll automatically discover and test the security of all your REST APIs, HTTP APIs, and WebSocket APIs deployed through API Gateway, ensuring comprehensive API security across your AWS infrastructure.
To connect Akto with AWS API Gateway, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add AWS API Gateway connector 1. Go to **API gateway** in AWS console 2. Go to your API, click on `Stages` from the left menu.
3. Scroll down to `Logs and tracing` section and click on `Edit`.
4. Select `Error and info logs` and `Data tracing` and save these settings. ``` { "requestId":"$context.requestId", "extendedRequestId":"$context.extendedRequestId","ip": "$context.identity.sourceIp", "caller":"$context.identity.caller", "user":"$context.identity.user", "requestTime":"$context.requestTime", "httpMethod":"$context.httpMethod", "resourcePath":"$context.resourcePath", "status":"$context.status", "protocol":"$context.protocol", "responseLength":"$context.responseLength" } ```
5. Find out the `cloudwatch log group` for your API gateway for the stage which has the above logs enabled and save it. We'll need it later. 6. Deploy the connector (Kubernetes, Docker Compose, or CloudFormation). 1. For `LOG_GROUP_NAME`, use the CloudWatch log group name (from API Gateway Stage logs). You can use comma-separated (,) names to add multiple log group names. 2. For `AWS_REGION`, use the AWS region where that log group exists. 3. For `AKTO_KAFKA_BROKER_MAL`, use the Akto mini-runtime Kafka endpoint (`:9092`). 4. For Kubernetes and Docker Compose: For `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_SESSION_TOKEN`, use credentials that have permission to read the above CloudWatch log group. (CloudFormation uses IAM instance role—no credentials needed.) 5. For `DATABASE_ABSTRACTOR_TOKEN`, copy the token from Akto dashboard. 6. Use one of the deployment options below. ### Option A: Kubernetes deployment ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-gateway-logging spec: replicas: 1 selector: matchLabels: app: api-gateway-logging template: metadata: labels: app: api-gateway-logging spec: containers: - image: aktosecurity/mirror-api-logging:api-gateway-logging-openapi name: api-gateway-logging imagePullPolicy: Always resources: {} env: - name: AKTO_BYTES_IN_THRESHOLD value: "100" - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_KAFKA_BROKER_MAL value: "" - name: AWS_ACCESS_KEY_ID value: "" - name: AWS_SECRET_ACCESS_KEY value: "" - name: AWS_SESSION_TOKEN value: "" - name: CLOUDWATCH_READ_BATCH_SIZE value: "5" - name: LOG_GROUP_NAME value: "" - name: AWS_REGION value: "" - name: DATABASE_ABSTRACTOR_TOKEN value: "" - name: DISCOVER_OPENAPI_SPEC value: "true" - name: OPENAPI_DISCOVERY_INTERVAL_MINUTES value: "15" ``` ### Option B: Docker Compose Create a `docker-compose.yml` and `watchtower.env` on your connector host: *docker-compose.yml:* ```yaml version: "3.9" services: api-gateway-logging: image: aktosecurity/mirror-api-logging:api-gateway-logging-openapi pull_policy: always container_name: api-gateway-logging restart: unless-stopped environment: AKTO_BYTES_IN_THRESHOLD: "100" AKTO_TRAFFIC_BATCH_TIME_SECS: "10" AKTO_TRAFFIC_BATCH_SIZE: "100" AKTO_KAFKA_BROKER_MAL: "" AWS_ACCESS_KEY_ID: "" AWS_SECRET_ACCESS_KEY: "" AWS_SESSION_TOKEN: "" CLOUDWATCH_READ_BATCH_SIZE: "5" LOG_GROUP_NAME: "" AWS_REGION: "" DATABASE_ABSTRACTOR_TOKEN: "" DISCOVER_OPENAPI_SPEC: "true" OPENAPI_DISCOVERY_INTERVAL_MINUTES: "15" watchtower: image: containrrr/watchtower restart: always volumes: - /var/run/docker.sock:/var/run/docker.sock env_file: ./watchtower.env labels: com.centurylinklabs.watchtower.enable: "false" ``` *watchtower.env:* ```bash WATCHTOWER_CLEANUP=true WATCHTOWER_POLL_INTERVAL=1800 ``` Run: ```bash docker compose up -d docker compose logs -f --tail=200 api-gateway-logging ``` ### Option C: CloudFormation (Automated deployment) Download the CloudFormation scripts from the Akto infra repository: * Repo path: * Use folder: `api-gateway-connect-cloudformation` Example: ```bash git clone -b feature/quick-setup https://github.com/akto-api-security/infra.git cd infra/api-gateway-connect-cloudformation cp parameters.example.json parameters.json ``` Update `parameters.json` with your values, then deploy: ```bash ./deploy.sh akto-api-gateway-connector ap-south-1 ``` This CloudFormation option creates the connector EC2 instance and runs the API Gateway connector automatically using Docker Compose. ## Environment variables reference | Variable | What to set | Where to get it | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | `AKTO_BYTES_IN_THRESHOLD` | Keep default (`100`) unless tuning needed | Akto connector runtime tuning value | | `AKTO_TRAFFIC_BATCH_TIME_SECS` | Keep default (`10`) unless tuning needed | Akto connector runtime tuning value | | `AKTO_TRAFFIC_BATCH_SIZE` | Keep default (`100`) unless tuning needed | Akto connector runtime tuning value | | `AKTO_KAFKA_BROKER_MAL` | `:9092` | If mini-runtime is deployed using CloudFormation, go to stack **Outputs**, copy `AktoNLB`, and append `:9092` | | `AWS_ACCESS_KEY_ID` | Access key ID (Kubernetes, Docker Compose only) | IAM user or temporary STS credentials with CloudWatch Logs read permissions | | `AWS_SECRET_ACCESS_KEY` | Secret access key (Kubernetes, Docker Compose only) | IAM user or temporary STS credentials | | `AWS_SESSION_TOKEN` | Session token if using temporary credentials (Kubernetes, Docker Compose only) | STS/assumed role session; leave empty for long-lived IAM user keys | | `CLOUDWATCH_READ_BATCH_SIZE` | Keep default (`5`) unless tuning needed | Connector tuning value | | `LOG_GROUP_NAME` | API Gateway execution/access log group name (Use comma-separated names to suppport more than one log group) | CloudWatch Logs console (for your API Gateway stage) | | `AWS_REGION` | Region of API Gateway + CloudWatch log group | AWS region (example: `ap-south-1`) | | `DATABASE_ABSTRACTOR_TOKEN` | Database abstractor token | Akto Dashboard > Quick Start > Hybrid SaaS > Runtime Service Command section | | `DISCOVER_OPENAPI_SPEC` | `"true"` to enable OpenAPI discovery | Connector feature flag | | `OPENAPI_DISCOVERY_INTERVAL_MINUTES` | Discovery interval (default `15`) | Connector tuning value | Notes: 1. To create AWS CLI credentials, you can take reference from the [official AWS docs](https://docs.aws.amazon.com/sdkref/latest/guide/access-iam-users.html). 2. For AWS IAM policy permissions for cloudwatch, you can refer [here](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#apigateway-cloudwatch-log-formats). ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with AWS Lambda AWS Lambda is Amazon’s serverless compute service that lets you run code without provisioning or managing servers. Integrating AWS Lambda with Akto via the Golang Runtime API Proxy Extension enables automatic discovery of all API traffic processed by your Lambda functions.

Image source: Amazon Web Services Documentation

To connect Akto with AWS Lambda functions, please follow these steps: *** ## Step 1: Deploy the Akto Data-Ingestion Service Before configuring the AWS Lambda Traffic Connector Extension, you must deploy the Akto Data-Ingestion Service. Ensure that the service is running and accessible via a publicly available URL. ### 1.1 Download the Required Files SSH into the instance where you want to deploy the data-ingestion service and run these commands: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` * Log in to the [Akto Dashboard](https://app.akto.io/). * Navigate to the **Quick Start** tab from the left panel.
* Select **Hybrid SaaS Connector** and copy the token from the **Runtime Service Command** section.
### 1.3 Update the `docker-mini-runtime.env` File Open the `docker-mini-runtime.env` file and replace `token` with the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` you retrieved earlier. ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` ### 1.4 Deploy the Data-Ingestion Service Run the following command to start the data-ingestion service: ```bash docker-compose -f docker-compose-data-ingestion-runtime.yml up -d ``` ### 1.5 Note the IP Address of the Data-Ingestion Service Ensure the instance is accessible from the network where your AWS Lambda functions will send traffic. Note the public IP address or public DNS name. *** ## Step 2: Setup AWS Lambda Runtime API Proxy Extension Now that the Akto Data-Ingestion Service is deployed, follow these steps to setup and connect your AWS Lambda functions with Akto. ### 2.1 Clone the Extension Repository Clone the repository containing the Golang Lambda Runtime API Proxy Extension to your local machine or CI/CD environment: ```bash git clone https://github.com/akto-api-security/golang-lambda-runtime-api-proxy-extension.git cd golang-lambda-runtime-api-proxy-extension ``` *** ### 2.2 Modify the `Makefile` Update the following variables inside the provided `Makefile`: ```makefile BASENAME := $(shell basename $(CURDIR)) ARTIFACTS_DIR ?= out targetArch := amd64 extensionName := golang-lambda-runtime-api-proxy-extension FUNCTION_NAME := # Change this to your actual Lambda function name LAYER_NAME := $(extensionName)-layer ``` * `FUNCTION_NAME`: Provide your target AWS Lambda function name. * Optionally, update `AKTO_MIRRORING_URL` later during function configuration to point to your deployed Akto Data-Ingestion Service. *** ### 2.3 Build and Deploy the Extension Run the following command to build and package the extension: ```bash make all ``` This will: * Build the extension binary for Linux (`amd64`) architecture. * Package the binary and wrapper script into a zip file inside the `out/` directory. *** ### 2.4 Publish the Extension as a Lambda Layer After building, publish the extension as a Lambda Layer by running: ```bash make publishLayerVersion ``` This command will output the **Layer Version ARN** needed in the next step. *** ### 2.5 Attach the Extension Layer to Your Lambda Function Finally, run: ```bash make updateFunctionConfiguration ``` This will: * Attach the newly published layer to your Lambda function. * Set necessary environment variables: * `AWS_LAMBDA_EXEC_WRAPPER=/opt/wrapper-script.sh` * `AKTO_MIRRORING_URL=https:///api/ingestData` (Replace with your Akto Data-Ingestion Service address) **Example**: ```bash make updateFunctionConfiguration FUNCTION_NAME=my-production-lambda AKTO_MIRRORING_URL=https://1.2.3.4/api/ingestData ``` > **Note:** Before running this command, make sure **jq** is installed on your system. You can install it using your package manager, e.g., `sudo apt install jq` on Debian-based systems, `brew install jq` on macOS, or `winget install jqlang.jq` on Windows. ### 2.6 API Inventory with Source Location Once your Lambda extension is connected, Akto automatically tags API Collection with the source, like `service=lambda`. This helps you easily track and filter API Collection based on their origin. You can view this under **API Discovery > API Collections**.
*** ## Step 3: Verify the Setup 1. Invoke your Lambda function manually or through an event. 2. Confirm that API traffic data (requests and responses) are captured on the Akto dashboard under the respective api collection. 3. Check logs of your Lambda function for any initialization messages from the extension. If you face any issues, ensure: * The Akto Data-Ingestion Service is reachable publicly. * The correct ingestion URL is set in `AKTO_MIRRORING_URL`. * Proper IAM permissions are granted if needed for the Lambda function. *** ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with AWS AppSync using Lambda Data Source AWS AppSync is a fully managed GraphQL service from AWS. It allows you to build scalable applications by connecting to data sources like Lambda functions. By integrating AppSync with Akto using the Golang Runtime API Proxy Extension on AWS Lambda, you can automatically capture and monitor API traffic flowing through your GraphQL operations. To connect Akto with AWS AppSync through Lambda functions, follow the steps below: *** ## Step 1: Deploy the Akto Data-Ingestion Service Before setting up the AppSync and Lambda integration, you need to deploy the Akto Data-Ingestion Service. ### 1.1 Download the Required Files SSH into the instance where you want to deploy the data-ingestion service and run: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` * Log in to the [Akto Dashboard](https://app.akto.io/). * Navigate to the **Quick Start** tab from the left panel.
* Select **Hybrid SaaS Connector** and copy the token from the **Runtime Service Command** section.
### 1.3 Update the `docker-mini-runtime.env` File Edit the file to include your token: ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` ### 1.4 Deploy the Data-Ingestion Service Start the service: ```bash docker-compose -f docker-compose-data-ingestion-runtime.yml up -d ``` ### 1.5 Note the IP Address of the Data-Ingestion Service Ensure this instance is reachable from your Lambda environment. Note its public IP address or DNS name. *** ## Step 2: Setup Lambda Extension for AppSync Resolver Integration Now that the Akto Data-Ingestion Service is running, follow these steps to configure your AWS Lambda function and integrate it with AppSync. ### 2.1 Clone the Extension Repository ```bash git clone https://github.com/akto-api-security/golang-lambda-runtime-api-proxy-extension.git cd golang-lambda-runtime-api-proxy-extension ``` *** ### 2.2 Modify the `Makefile` Update these values in the `Makefile`: ```makefile BASENAME := $(shell basename $(CURDIR)) ARTIFACTS_DIR ?= out targetArch := amd64 extensionName := golang-lambda-runtime-api-proxy-extension FUNCTION_NAME := LAYER_NAME := $(extensionName)-layer ``` * Replace `` with your actual Lambda name. * You'll update the ingestion URL during function configuration. *** ### 2.3 Build the Extension ```bash make all ``` This packages the Lambda Runtime API Proxy Extension for deployment. *** ### 2.4 Publish as a Lambda Layer ```bash make publishLayerVersion ``` Copy the output **Layer ARN**. *** ### 2.5 Attach Extension Layer and Configure the Lambda Function Run: ```bash make updateFunctionConfiguration FUNCTION_NAME= AKTO_MIRRORING_URL=https:///api/ingestData ``` This will: * Attach the layer * Set required environment variables: * `AWS_LAMBDA_EXEC_WRAPPER=/opt/wrapper-script.sh` * `AKTO_MIRRORING_URL=https:///api/ingestData` ### 2.6 API Inventory with Source Location Once your Lambda extension is connected, Akto automatically tags API Collection with the source, like `service=lambda`. This helps you easily track and filter API Collection based on their origin. You can view this under **API Discovery > API Collections**.
*** ## Step 3: Add Lambda as a Data Source in AppSync Now that your Lambda function is ready: 1. Go to the [AWS AppSync console](https://console.aws.amazon.com/appsync/). 2. Open your GraphQL API. 3. Navigate to **Data Sources**. 4. Choose **New** and add your Lambda function as a data source. 5. Name it appropriately and attach the IAM role if required. *** ## Step 4: Modify Your Resolver to Include Akto Payload Whether you're using **VTL** or **JavaScript**, you must ensure your AppSync resolver sends an enriched payload to Lambda. This allows Akto to inspect incoming request context for observability. ### VTL (Velocity Template Language) Example (Unit Resolver) ```vtl { "version": "2018-05-29", "operation": "Invoke", "payload": { ... ... "akto_data": { "path": "/graphql", "requestHeaders": $util.toJson($context.request.headers), "method": "$util.defaultIfNull($context.request.headers['x-forwarded-method'], 'POST')", "requestPayload": "$util.escapeJavaScript($util.toJson({ operationName: $context.info.fieldName, query: "", variables: $context.arguments }))", "ip": "$util.defaultIfNull($context.request.headers['x-forwarded-for'], '')", "traffic_source": "AppSync" } } } ``` ### JavaScript Resolver (Pipeline or Unit) ```js export function request(ctx) { return { operation: "Invoke", payload: { ... ... akto_data: { path: '/graphql', requestHeaders: (ctx.request?.headers || {}), method: ctx.request?.headers?.['x-forwarded-method'] || 'POST', requestPayload: { operationName: ctx.info.fieldName, query: "", variables: ctx.arguments || {} }, ip: ctx.request?.headers?.['x-forwarded-for'] || '', traffic_source: 'AppSync', } } }; } ``` > 📝 **Note:** Ensure `akto_data` includes the necessary context Akto requires. *** ## Step 5: Verify the Setup 1. Trigger a GraphQL query or mutation in your AppSync API. 2. Observe your Lambda logs to ensure Akto extension starts correctly. 3. Log in to [Akto Dashboard](https://app.akto.io/) and check if API traffic is captured under the associated collection. *** ### Need Help? If you run into any issues or want help with customizing your integration: 1. Reach out via in-app `intercom` on the Akto Dashboard. 2. Join our [Discord community](https://www.akto.io/community). 3. Email us at . 4. Visit [akto.io/contact-us](https://www.akto.io/contact-us) for further assistance. # Connect Akto with AWS API Gateway with CloudWatch OAM AWS API Gateway is a fully managed service from AWS that helps developers create, publish, monitor, and secure APIs at scale. By integrating AWS API Gateway with Akto, you'll automatically discover and test the security of all your REST APIs, HTTP APIs, and WebSocket APIs deployed through API Gateway, ensuring comprehensive API security across your AWS infrastructure.
To connect Akto with AWS API Gateway using **CloudWatch OAM**, follow these steps: *** ## Step 1: Set Up and Configure API Gateway ### 1.1 Set up Akto Traffic Processor Follow the steps mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas) to set up the Akto Traffic Processor. ### 1.2 Add AWS API Gateway Connector 1. Go to **API Gateway** in the AWS Console. 2. Navigate to your API and click on `Stages` from the left menu.
3. Scroll down to the `Logs and tracing` section and click on `Edit`.
4. Select `Error and info logs` and `Data tracing` and save these settings. ``` { "requestId":"$context.requestId", "extendedRequestId":"$context.extendedRequestId","ip": "$context.identity.sourceIp", "caller":"$context.identity.caller", "user":"$context.identity.user", "requestTime":"$context.requestTime", "httpMethod":"$context.httpMethod", "resourcePath":"$context.resourcePath", "status":"$context.status", "protocol":"$context.protocol", "responseLength":"$context.responseLength" } ```
5\. Find out the \`CloudWatch log group\` for your API Gateway for the stage which has the above logs enabled and save it's arn. You'll need it later. *** ## Step 2: Linking CloudWatch OAM Accounts > **Note:** Follow the OAM step only if you have an EKS cluster in one account and a CloudWatch log group in another account. Otherwise, you can skip this step. ### Why Use CloudWatch OAM? CloudWatch OAM allows you to monitor and manage metrics and logs across multiple AWS accounts and regions, providing centralized visibility and simplified access management. For more details, refer to the official AWS documentation: [AWS OAM API Reference](https://docs.aws.amazon.com/OAM/latest/APIReference/Welcome.html) ### 2.1: Configure the Monitoring Account 1. Open the **CloudWatch console** in the monitoring account (where your EKS cluster is located). 2. In the left navigation bar, go to **Settings**. 3. Under **Monitoring account configuration**, choose **Configure**. 4. For **Select data**, choose the types of data this monitoring account will be able to view from the source accounts: * Logs * Metrics * *(Generally, we only need logs.)* 5. Under **List source accounts**, enter the **account IDs** of the source accounts (where your CloudWatch log groups are located) that this monitoring account will view. 6. Under **Define a label to identify your source account**, choose whether to use **account names** or **email addresses**. 7. Click **Configure**. ### 2.2: Configure the Source Account 1. In **Settings**, under **Monitoring account configuration**, go to **Resources to link accounts**. 2. Choose **Any account** to generate a **URL** for linking source accounts. 3. Copy the generated **URL**. 4. **Sign in** to the account you want to set as a **source account**. 5. Enter the **copied URL** in your browser to open the CloudWatch settings page. 6. Under **Select data**, choose the data types that will be shared with the monitoring account: * Logs * Metrics * *(Generally, only logs are needed, and specific logs can be filtered.)* **For more information on filtering logs, refer to:** [AWS Log Group Configuration](https://docs.aws.amazon.com/OAM/latest/APIReference/API_LogGroupConfiguration.html). 7. Ensure **Enter monitoring account configuration ARN** is **not changed**. 8. Under **Define a label to identify your source account**, the label choice from the monitoring account is pre-filled. Optionally, choose **Edit** to modify it. 9. Click **Link**. 10. Enter **Confirm** in the box and click **Confirm**. The **linking process might take a few minutes** to complete. ## Step 3: Set Up an EKS Cluster If you don’t have an existing EKS cluster, you can create one using the AWS Console: 1. Go to the **Amazon EKS** service in the AWS Management Console. 2. Click on **Create Cluster**. 3. Provide a name for your cluster and select the Kubernetes version. 4. Choose the networking settings (VPC, subnets, security groups). 5. Select an IAM role for the cluster. 6. Select an IAM role for the node. 7. Configure other optional settings and click **Create**. 8. Copy the OpenID Connect (OIDC) provider URL from the Overview section of your EKS cluster. (You can find this under **EKS > Your Cluster > Overview > Details**.) *** ## Step 4: Create an IAM Role for Service Account ### 4.1 Create an IAM Policy 1. Go to the **IAM** service in the AWS Console. 2. Click **Policies** on the left panel, then click **Create policy**. 3. Select **JSON** as Policy editor. 4. Paste the following JSON schema in the policy editor. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:GetLogEvents", "logs:FilterLogEvents" ], "Resource": [ "" ] } ] } ``` * Replace `` with the CloudWatch log group arn saved in Step 1.2. 5. Click **Next** and review the permissions. 6. After reviewing the permissions, click the **Save Changes** button. ### 4.2 Create an IAM Role 1. Go to the **IAM** service in the AWS Console. 2. Click **Roles** on the left panel, then click **Create role**. 3. Select **Web Identity** as the trusted entity. 4. Choose your EKS OIDC provider and enter the audience as `sts.amazonaws.com`. 5. Click **Next** and move to the permissions step. 6. Choose the policy we created in the previous step (4.1). 7. Click **Next**, give the role a name, and create the role. (Save the role name as it will be needed later.) ### 4.3 Update Trust Policy After creating the role, modify the trust policy in the **Trust relationships** section of the role created in the previous step. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks..amazonaws.com/id/:aud": "sts.amazonaws.com", "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::service-account-eks" } } } ] } ``` * Replace `` with your AWS region. (Find it in the top-right corner of the AWS Console.) * Replace `` with your AWS account ID. (You can find this under **IAM > Account Settings**.) * Replace `` with the OIDC provider ID from Step 2. * Replace `` with the Kubernetes namespace where the service account will be deployed. (Use `kubectl get namespaces` to check existing namespaces.) Save the trust policy. *** ## Step 5: Attach IAM Role to EKS Service Account 1. Create a `service-account.yaml` file with the following content: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: service-account-eks namespace: annotations: eks.amazonaws.com/role-arn: arn:aws:iam:::role/ ``` * Replace `` with your AWS account ID. * Replace `` with the IAM role name created in Step 4.2. * Replace `` with the Kubernetes namespace where the service account will be deployed (use `kubectl get namespaces` to check existing namespaces). This should be the same as the one used in step 4.3. 2. Apply the `service-account.yaml` file to your EKS cluster using the following `kubectl` command: `kubectl apply -f service-account.yaml` *** ## Step 6: Update the Kubernetes Deployment YAML 1. For `LOG_GROUP_NAME` and `AWS_REGION`, use the log group arn we saved earlier and the aws region it is deployed in. 2. For `AKTO_KAFKA_BROKER_MAL`, use the value of the `mini-runtime` service we deployed in step 1.1. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-gateway-logging namespace: spec: replicas: 1 selector: matchLabels: app: api-gateway-logging template: metadata: labels: app: api-gateway-logging spec: serviceAccountName: service-account-eks containers: - image: aktosecurity/mirror-api-logging:api-gateway-logging name: api-gateway-logging imagePullPolicy: Always resources: {} env: - name: AKTO_BYTES_IN_THRESHOLD value: "100" - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_KAFKA_BROKER_MAL value: "" - name: CLOUDWATCH_READ_BATCH_SIZE value: "5" - name: LOG_GROUP_NAME value: "" - name: AWS_REGION value: "" ``` * Replace `` with the Kubernetes namespace used in Step 5. Notes: 1. For assigning an IAM role to a Kubernetes service account, you can refer [here](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html). *** ## Get Support for your Akto setup * **In-app support**: Message us in the Akto dashboard. * **Join our** [**Discord channel**](https://www.akto.io/community) **for community support.** * **Email**: Contact `help@akto.io`. * **Contact us** [**here**](https://www.akto.io/contact-us). # Connect Akto with AWS API Gateway with service account (Temporary Credentials) AWS API Gateway is a fully managed service from AWS that helps developers create, publish, monitor, and secure APIs at scale. By integrating AWS API Gateway with Akto, you'll automatically discover and test the security of all your REST APIs, HTTP APIs, and WebSocket APIs deployed through API Gateway, ensuring comprehensive API security across your AWS infrastructure.
To connect Akto with AWS API Gateway using **Service Accounts (IRSA)**, follow these steps: *** ## Step 1: Set Up and Configure API Gateway ### 1.1 Set up Akto Traffic Processor Follow the steps mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas) to set up the Akto Traffic Processor. ### 1.2 Add AWS API Gateway Connector 1. Go to **API Gateway** in the AWS Console. 2. Navigate to your API and click on `Stages` from the left menu.
3. Scroll down to the `Logs and tracing` section and click on `Edit`.
4. Select `Error and info logs` and `Data tracing` and save these settings. ``` { "requestId":"$context.requestId", "extendedRequestId":"$context.extendedRequestId","ip": "$context.identity.sourceIp", "caller":"$context.identity.caller", "user":"$context.identity.user", "requestTime":"$context.requestTime", "httpMethod":"$context.httpMethod", "resourcePath":"$context.resourcePath", "status":"$context.status", "protocol":"$context.protocol", "responseLength":"$context.responseLength" } ```
5\. Find out the \`CloudWatch log group\` for your API Gateway for the stage which has the above logs enabled and save its ARN. You'll need it later. *** ## Step 2: Set Up Cross-Account IAM Role for Cloudwatch Logs and API Specs If your EKS cluster and CloudWatch log groups are in different AWS accounts, follow these steps to enable access using IAM roles with temporary credentials. This role allows Akto to read API Gateway logs and to discover your API specs for the dashboard. ### 2.1 Create IAM Role in CloudWatch Account 1. Go to the **IAM** service in the AWS Console of the account where CloudWatch logs are stored. 2. Click **Roles** on the left panel, then click **Create role**. 3. Choose **Another AWS account** as the trusted entity. 4. Enter the AWS Account ID of the EKS cluster account. 5. Click **Next**, and in the permissions step, create a new policy or attach an existing one with the following permissions: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:GetLogEvents", "logs:FilterLogEvents" ], "Resource": "arn:aws:logs:::log-group:*" }, { "Effect": "Allow", "Action": [ "apigateway:GET" ], "Resource": [ "arn:aws:apigateway:*::/restapis", "arn:aws:apigateway:*::/restapis/*", "arn:aws:apigateway:*::/apis", "arn:aws:apigateway:*::/apis/*" ] } ] } ``` 6. Replace `` and `` with actual values. 7. Click **Next**, name the role (e.g., `CrossAccountCloudWatchRole`), and create the role. ### 2.2 Update Trust Policy After creating the role, modify the **Trust relationships** section to allow access from the EKS IRSA role: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::role/" }, "Action": "sts:AssumeRole" } ] } ``` * Replace `` with the AWS account ID where EKS is running. * Replace `` with the IAM role attached to the EKS service account. *** ## Step 3: Create an IAM Role for EKS Service Account ### 3.1 Create an IAM Policy in EKS Account 1. Go to **IAM** service in the AWS Console of the EKS cluster account. 2. Click **Policies**, then **Create policy**. 3. Use the following JSON policy: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam:::role/CrossAccountCloudWatchRole" } ] } ``` 4. Replace `` with the AWS account ID where CloudWatch logs are stored. 5. Click **Next**, give the policy a name (e.g., `EKSCloudWatchAccess`), and create it. ### 3.2 Create IAM Role for Service Account 1. In the EKS cluster account, go to **IAM** and click **Roles** > **Create role**. 2. Select **Web Identity** as the trusted entity. 3. Choose your EKS OIDC provider and enter `sts.amazonaws.com` as the audience. 4. Attach the policy created in Step 3.1. 5. Name the role (e.g., `EKSCloudWatchRole`) and create it. ### 3.3 Update Trust Policy for IRSA Role Modify the trust policy for the role created in Step 3.2: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::service-account-eks" } } } ] } ``` * Replace placeholders with actual values. *** ## Step 4: Attach IAM Role to EKS Service Account 1. Create a `service-account.yaml` file: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: service-account-eks namespace: annotations: eks.amazonaws.com/role-arn: arn:aws:iam:::role/EKSCloudWatchRole ``` 2. Apply the service account: ```sh kubectl apply -f service-account.yaml ``` Now, the EKS pod using this service account can assume the cross-account IAM role to access CloudWatch logs securely. ## Step 5: Update the Kubernetes Deployment YAML ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-gateway-logging namespace: spec: replicas: 1 selector: matchLabels: app: api-gateway-logging template: metadata: labels: app: api-gateway-logging spec: serviceAccountName: service-account-eks containers: - image: aktosecurity/mirror-api-logging:api-gateway-logging-temp-cred name: api-gateway-logging imagePullPolicy: Always resources: {} env: - name: AKTO_BYTES_IN_THRESHOLD value: "100" - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_KAFKA_BROKER_MAL value: "" - name: CLOUDWATCH_READ_BATCH_SIZE value: "5" - name: CROSS_ACCOUNT_ROLE_ARN value: "" - name: LOG_GROUP_PREFIX value: "API-Gateway-Execution-Logs" - name: SESSION_NAME value: "" - name: AWS_REGION value: "" - name: DATABASE_ABSTRACTOR_TOKEN value: "" - name: DISCOVER_OPENAPI_SPEC value: "true" - name: OPENAPI_DISCOVERY_INTERVAL_MINUTES value: "15" ``` * Replace `` with the Kubernetes namespace used in Steps 3.3 and 4. * For `AKTO_KAFKA_BROKER_MAL`, use the value of the `mini-runtime` service deployed in Step 1.1. * For `LOG_GROUP_PREFIX`, the default is `API-Gateway-Execution-Logs`; change it only if your log groups use a different prefix. * Replace `DATABASE_ABSTRACTOR_TOKEN` with the database abstractor token from the Akto dashboard (needed for fetching role ARNs and for API spec discovery). * For `SESSION_NAME`, use any name you want for the session. * Replace `AWS_REGION` with the AWS region where your EKS cluster is located. * **DISCOVER\_OPENAPI\_SPEC**: Set to `"true"` to have Akto discover and sync your API Gateway API specs to the dashboard; set to `"false"` to only mirror traffic from logs. * **OPENAPI\_DISCOVERY\_INTERVAL\_MINUTES**: How often (in minutes) Akto checks for new or updated API specs when discovery is enabled (default: 15). ## Note: 1. If fetching logs from multiple accounts, make sure that the cross account role \[ generally which belongs to the monitoring account ] attached to the module can read logs from all the aforementioned accounts. 2. If adding multiple role ARNs, in Akto, make sure that the eks pod created here, has the correct IAM policies to be able to assume these role ARNs. *** With this setup, Akto can fetch CloudWatch logs from API Gateway across AWS accounts and, when enabled, discover and sync your API specs to the dashboard—all using temporary credentials. *** ## Get Support for your Akto setup * **In-app support**: Message us in the Akto dashboard. * **Join our** [**Discord channel**](https://www.akto.io/community) **for community support.** * **Email**: Contact `help@akto.io`. * **Contact us** [**here**](https://www.akto.io/contact-us). # Connect Akto with AWS Fargate Learn about how to send API traffic data using AWS Fargate to Akto from your environment. ## Introduction You can use Akto traffic collectors to collect and send traffic to Akto. Your APIs from this traffic will show up in Akto dashboard. ## Creating AWS Policy 1\. Go to Quick Start on your Akto dashboard and expand the `Connect traffic data` section.
2\. Scroll down to `Data processors setup` section.
3\. Copy the `policy json` and click on the Akto Dashboard role link.
4\. `Click` on the `JSON` tab and `paste the policy`
5\. Click on `Review policy` button.
6\. Enter *`AktoDashboardPolicy`* as the policy name and `click` on `Create Policy` button
8\. Once the policy is created, go back to the `dashboard`. ## Setting up Data processors 1\. Click on `Setup traffic processors` button.
2\. This will bring up infra that will process your traffic.
3\. Check that you have `AKTO_NLB` var once setup is complete.
## Add Akto traffic collector container 1\. Create a container with the following config ``` ... { "name": "akto-traffic-collector", "image": "aktosecurity/mirror-api-logging:k8s_agent", "environment": [ { "name": "AKTO_TRAFFIC_BATCH_TIME_SECS", "value": "10" }, { "name": "AKTO_TRAFFIC_BATCH_SIZE", "value": "100" }, { "name": "AKTO_INFRA_MIRRORING_MODE", "value": "gcp" }, { "name": "AKTO_KAFKA_BROKER_MAL", "value": ":9092" }, { "name": "AKTO_MONGO_CONN", "value": "mongodb://0.0.0.0:27017" } ] } ``` 2. Replace `` by the value shown on the dashboard. 3. Create a container in your Fargate setup with the above config.
# Connect Akto with AWS EKS Learn about how to send API traffic data using AWS EKS to Akto from your environment. ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). One such source is AWS EKS.
## Configuring Daemonset Follow these steps to add daemonset config to your Kubernetes setup - 1\. Go to Quick Start on your Akto dashboard and expand the `Connect traffic data` section.
2\. Scroll down to `Kubernetes Daemonset` section.
## Creating AWS Policy 1\. Copy the `policy json` and click on the Akto Dashboard role link.
2\. `Click` on the `JSON` tab and `paste the policy`
3\. Click on `Review policy` button.
4\. Enter *`AktoDashboardPolicy`* as the policy name and `click` on `Create Policy` button
7\. Once the policy is created, go back to the `dashboard`. ## Setting up Daemonset stack 1\. You should now see a `Setup daemonset stack` button. `Click` on this button to setup a traffic processing stack. {% hint style="info" %} This will process your API traffic data and populate APIs on the dashboard. This might take a few minutes to complete. {% endhint %}
2\. Once complete, you should now see a daemonset config. `Copy the config` and paste in a `text editor`.
3\. Replace `{NAMESPACE}` with your app namespace and `{APP_NAME}` with the name of your app
4\. Create a file `akto-daemonset-config.yaml` with the above YAML config
5\. Call `kubectl apply -f akto-daemonset-config.yaml -n ` on your *kubectl* terminal
6\. Run the command `kubectl get daemonsets` in terminal. It should show *akto-k8s* daemonset.
7\. Go to `API Discovery` on Akto dashboard to see your new APIs
### What's next? You can now go to your API Inventory to see all the API traffic Akto has captured. Head to [API Discovery](/api-inventory/concepts/api-collection) to learn more. Once you start seeing inventory, you can run API Security tests on your APIs. See [Akto's test library](https://www.akto.io/test-library) to select tests you want to run on your APIs. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. # Connect Akto with AWS ECS
## Introduction Learn about how to send API traffic data from AWS ECS setup to Akto from your environment. Depending on your ECS infrastructure type refer to these respective sections: 1. [FARGATE infrastructure](#adding-akto-traffic-collector-to-ecs-fargate-cluster) 2. [EC2 instances infrastructure](#adding-akto-traffic-collector-to-ecs-ec2-instances-cluster) ## Adding Akto traffic collector to ECS FARGATE cluster When the ECS cluster is running on AWS FARGATE infrastructure, we will add a container to the task definition of the task, from which we want to monitor. Refer the below image to check your cluster type.
ECS FARGATE infrastructure type

ECS FARGATE infrastructure type

1. Setup Akto data processor using the guide [here](/getting-started/quick-start-with-akto-self-hosted/helm-deploy). Keep the value `AKTO_NLB_IP` handy, as we will need them later. 2. Add a container with the configuration defined below. Please replace the `AKTO_NLB_IP` variable, as obtained from [step 1](#adding-akto-traffic-collector-to-ecs-fargate-cluster). ```bash { "name": "mirror-api-logging", "image": "aktosecurity/mirror-api-logging:k8s_agent", "cpu": 1024, "memory": 1024, "portMappings": [], "essential": false, "environment": [ { "name": "AKTO_TRAFFIC_BATCH_TIME_SECS", "value": "10" }, { "name": "AKTO_MONGO_CONN", "value": "mongodb://0.0.0.0:27017/admini" }, { "name": "AKTO_TRAFFIC_BATCH_SIZE", "value": "10" }, { "name": "AKTO_INFRA_MIRRORING_MODE", "value": "gcp" }, { "name": "AKTO_KAFKA_BROKER_MAL", "value": ":9092" } ], "environmentFiles": [], "mountPoints": [], "volumesFrom": [], "systemControls": [] } ```
ECS task definition

ECS task definition

3. After adding this definition to the task, update the task revision in the service.
Update ECS service

Update ECS service

4. The containers for the task should show both your primary container and mirror-api-logging container.
Updated service

Updated service

## Adding Akto traffic collector to ECS EC2 instances cluster When the ECS cluster is a EC2 instances cluster, we will create a task definition for the mirror-api-logging container and run the task as a daemonset.
Cluster configuration

Cluster configuration

1. Setup Akto data processor using the guide [here](/getting-started/quick-start-with-akto-self-hosted/helm-deploy). Keep the value `AKTO_NLB_IP` handy, as we will need them later. 2. We will create a new task definition with launch type as EC2 instances, network mode host and the container details as follows. You can directly create a new task definition using the JSON given below. You can also refer the screenshots attached. Please replace the `AKTO_NLB_IP` variable, as obtained from [step 1](#adding-akto-traffic-collector-to-ecs-ec2-instances-cluster). ```bash { "family": "mirror-api-logging", "containerDefinitions": [ { "name": "mirror-api-logging", "image": "aktosecurity/mirror-api-logging:k8s_agent", "cpu": 1024, "memory": 1024, "portMappings": [], "essential": true, "environment": [ { "name": "AKTO_TRAFFIC_BATCH_TIME_SECS", "value": "10" }, { "name": "AKTO_MONGO_CONN", "value": "mongodb://0.0.0.0:27017/admini" }, { "name": "AKTO_TRAFFIC_BATCH_SIZE", "value": "10" }, { "name": "AKTO_INFRA_MIRRORING_MODE", "value": "gcp" }, { "name": "AKTO_KAFKA_BROKER_MAL", "value": ":9092" } ], "environmentFiles": [], "mountPoints": [], "volumesFrom": [], "ulimits": [], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-create-group": "true", "awslogs-group": "/ecs/mirror-api-logging", "awslogs-region": "ap-south-1", "awslogs-stream-prefix": "ecs" }, "secretOptions": [] }, "systemControls": [] } ], "executionRoleArn": "", "networkMode": "host", "requiresCompatibilities": [ "EC2" ], "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" } } ```
Task configuration

Task configuration

Task configuration

Task configuration

Task configuration

Task configuration

Task configuration

Task configuration

3. We will create a daemonset service with launch type EC2. Go to services tab in the ECS cluster and click on `Create`.
Daemonset configuration

Daemonset configuration

4. Select `Launch type` in `Compute options` and `EC2` in `Launch type`.
Daemonset configuration

Daemonset configuration

5. Select `Service` in `Application type`, select `mirror-api-logging` in `Family` ( The task definition we just created ), enter `mirror-api-logging` as `Service name` and set the `Service type` as `Daemon`. Then click on `Create` on the bottom of the page.
Daemonset configuration

Daemonset configuration

6. Voila, you have created a daemonset in ECS. You should see the traffic in Akto dashboard in some time. # GCP Services
# Connect Akto with GCP Packet Mirroring Learn how to deploy Akto in GCP and add traffic to Akto using GCP Packet Mirroring ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). One such source is GCP Packet Mirroring.
Packet Mirroring is a GCP feature that clones the traffic of specified instances in your Virtual Private Cloud (VPC) network and forwards it to Akto. Packet Mirroring captures all traffic and packet data, including payloads and headers. The capture can be configured for both egress and ingress traffic, only ingress traffic, or only egress traffic. {% hint style="info" %} [Packet mirroring](https://cloud.google.com/vpc/docs/packet-mirroring) is non intrusive and allows you to send traffic to Akto in a completely out-of-band manner. {% endhint %} Packet mirroring is our recommended way to receive data as it is completely non-intrusive. Akto's traffic analyzer analyzes this traffic to create your application's APIs request and response, understand API metadata and find misconfigurations. Akto can work with high traffic scale though you can always configure the amount of traffic you want to send to Akto dashboard.
## Pre-requisites to add data to Akto using Packet Mirroring Make sure, the GCP account in which the resources will be created has provisioned enough compute to be able to deploy [Akto](https://www.akto.io) and has sufficient permission levels to create resources. ## Steps to deploy Akto in GCP You can deploy Akto using the `Akto's GCP packet mirroring template`. Here are the steps to deploy: 1. Open GCP Cloud Shell from your GCP Account. You can find the setup script for Akto [here](https://raw.githubusercontent.com/akto-api-security/infra/feature/self_hosting/templates/gcp-mirroring-template.sh). Download it on your shell from the command {% code overflow="wrap" %} ``` wget https://raw.githubusercontent.com/akto-api-security/infra/feature/self_hosting/templates/gcp-mirroring-template.sh ``` {% endcode %} 2. Change the permissions so that you can execute it `- chmod +x gcp-mirroring-template.sh` 3. This will create a template with name `gcp-mirroring-template.sh` 4. Make sure you are in the project where you want to create resources. 5. Create a `.txt file` with name `inputs.txt` with the following input parameters. ``` project-id region network subnet zone ``` Here is an example of the txt file below: ``` ankitas-playground us-west4 vpc-1 vpc-1-usw4 us-west4-a ``` 6. Go to the instances you want to mirror and add network tag 'mirror' to them. 7. Now start creating resources by writing this command `./gcp-mirroring-template.sh create ) 12. You can now signup on Akto dashboard. ### What's next? You can now go to your API Inventory to see all the API traffic Akto has captured. Head to [API Discovery](/api-inventory/concepts/api-collection) to learn more. Once you start seeing inventory, you can run API Security tests on your APIs. See [Akto's test library](https://www.akto.io/test-library) to select tests you want to run on your APIs. ## Steps to Uninstall and delete Akto resources In case you are done using Akto and want to uninstall, follow these steps: 1. Create delete.txt with the following inputs: ``` akto y ``` 2. To delete all the resources you created with 'akto' prefix, run the command `./gcp-mirroring-template.sh delete Packet mirroring 2. Check if the VM ports at which your traffic is being generated is open in the Akto runtime machines. Say, if the traffic is being generated at port 3000 on the VM, open the same port on the akto runtime machine. 3. The Akto runtime processes traffic data every 15-20 minutes, so the traffic logged may not be visible instantly on the akto dashboard. 4. If this doesn’t solve your issue, contact our support at ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with Apigee Apigee is Google Cloud's full-lifecycle API management platform that helps enterprises design, secure, and scale APIs. Integrating Apigee with Akto enables automatic discovery and security testing of all APIs managed through your Apigee gateway, providing comprehensive visibility and continuous security assessment of your API infrastructure.
*** ## Step 1: Deploy the Akto Data-Ingestion Service Before setting up the Apigee connector, deploy the Akto Data-Ingestion Service by following these steps: ### 1.1 Download the Required Files SSH into the instance where you want to deploy the data-ingestion service and run these commands: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` * Log in to the [Akto Dashboard](https://app.akto.io/). * Navigate to the **Quick Start** tab in the left panel.
* Select **Hybrid SaaS Connector** and copy the token from the **Runtime Service Command** section.
### 1.3 Update the `docker-mini-runtime.env` File * Open the `docker-mini-runtime.env` file and replace `token` with the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` you retrieved earlier. ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` ### 1.4 Deploy the Data-Ingestion Service Run the following command to start the data-ingestion service: ```bash docker-compose -f docker-compose-data-ingestion-runtime.yml up -d ``` ### 1.5 Note the IP Address of the Data-Ingestion Service Ensure the instance is accessible from the network where your Apigee API proxy is configured. Note the instance's IP address, as it will be required by the Apigee connector to send traffic data. *** ## Step 2: Configure Apigee to Use the Akto Data-Ingestion Service You can choose either option below for Step 2: * **Option A:** Manual setup from the GCP Apigee UI. * **Option B:** Automated setup using Terraform scripts from Akto's infra repository. Both options configure Akto ingestion in Apigee. Option B is recommended for repeatable CI/CD-friendly deployments. ### 2.1 Create or Choose an Apigee Environment To configure the Akto connector, you need an **Intermediate** or **Comprehensive** environment in Apigee, as the JavaScript policy is not supported in the **Base** environment. #### Steps to Create an Environment: 1. Log in to the [Apigee Management Console](https://console.cloud.google.com/apigee/overview). 2. Navigate to **Management → Environments** from the left-side navigation bar.
3. Click **+ Create Environment**.
4. Provide the required details: * **Name**: Specify a name for your environment. * **Environment Type**: Choose **Intermediate** or **Comprehensive**. 5. Click **Create** to finalize your environment setup.
If you already have an **Intermediate** or **Comprehensive** environment, you can skip this step and proceed to the next section. ### 2.2 Option A: Manual Setup from GCP UI (Shared Flow + Flow Hook) This is the manual environment-wide setup. 1. In Apigee, go to **Proxy development → Shared Flows** and click **+ Create**.
2. Create a shared flow (for example: `akto-traffic-collector`). 3. Open the shared flow, go to **Develop → default**, and add two Steps in order: first `AktoJavascript`, then `ML-SendAktoTcpSyslog`. 4. In the same shared flow, click **Policies +** and add a **JavaScript** policy named `AktoJavascript`.
5. Open the JavaScript policy XML (Under Policies section) and set it as: ```xml AktoJavascript jsc://AktoJavascript.js ``` 6. Create a JS resource file named `AktoJavascript.js` and paste the script below. 7. Click **Policies +** again and add a **MessageLogging** policy named `ML-SendAktoTcpSyslog`. Set the policy XML as: ```xml ML-SendAktoTcpSyslog {akto.log.payload} YOUR_DATA_INGESTION_SERVICE_IP 5140 TCP false ``` 8. Save and deploy the shared flow to your target environment.
9. Go to **Management → Environments → your\_environment → Flow Hooks**. 10. Attach the shared flow to a hook point (recommended: `PostProxyFlowHook`).
```javascript var requestPath = context.getVariable("request.uri"); var queryString = context.getVariable("request.querystring"); var requestHeaders = context.getVariable("request.headers.names"); var requestPayload = context.getVariable("request.content"); var clientIp = context.getVariable("request.header.x-forwarded-for"); var method = context.getVariable("request.verb"); var responseHeaders = context.getVariable("response.headers.names"); var responsePayload = context.getVariable("response.content"); var statusCode = context.getVariable("response.status.code"); var statusText = context.getVariable("response.reason.phrase") || "OK"; var rawTime = context.getVariable("system.timestamp"); var epochTime = Math.floor(rawTime / 1000); var requestHeadersRes = {}; requestHeaders = (requestHeaders + '').slice(1, -1).split(', '); requestHeaders.forEach(function(x) { requestHeadersRes[x] = context.getVariable("request.header." + x); }); var responseHeadersRes = {}; responseHeaders = (responseHeaders + '').slice(1, -1).split(', '); responseHeaders.forEach(function(x) { responseHeadersRes[x] = context.getVariable("response.header." + x); }); var payload = { batchData: [{ path: requestPath + (queryString ? "?" + queryString : ""), requestHeaders: JSON.stringify(requestHeadersRes), responseHeaders: JSON.stringify(responseHeadersRes), method: method, requestPayload: requestPayload || "", responsePayload: responsePayload || "", ip: clientIp || "0.0.0.0", time: "" + epochTime, statusCode: "" + statusCode, type: "HTTP/1.1", status: statusText, akto_account_id: "1000000", akto_vxlan_id: "0", is_pending: "false", source: "MIRRORING" }] }; context.setVariable("akto.log.payload", JSON.stringify(payload)); ``` Important policy behavior: * Both `AktoJavascript` and `ML-SendAktoTcpSyslog` must have `continueOnError="true"`. * Both policies must be added as Steps in the shared flow **default** section in order: JS first, then MessageLogging. * Replace `YOUR_DATA_INGESTION_SERVICE_IP` in the MessageLogging policy with the IP noted in Step 1.5. ### 2.3 Option B: Terraform Automation Use Terraform from: * **Repository:** * **Branch:** `feature/quick-setup` * **Folder:** `apigee-connect-terraform` 1. Clone and switch to the required branch: ```bash git clone https://github.com/akto-api-security/infra.git cd infra git checkout feature/quick-setup cd apigee-connect-terraform ``` 2. Provide the required values in a `terraform.tfvars` file inside `apigee-connect-terraform`. If the repository contains `terraform.tfvars.example`, copy it first: ```bash cp terraform.tfvars.example terraform.tfvars ``` Otherwise create `terraform.tfvars` manually with: ```hcl gcp_project_id = "your-gcp-project-id" apigee_environment = "your-apigee-environment-name" data_ingestion_service_url = "your-data-ingestion-service-ip:5140" ``` 3. Run Terraform: ```bash terraform init terraform apply -var-file="terraform.tfvars" ``` This automation creates and deploys the Apigee shared flow and attaches it to the selected environment flow hook. ### 2.4 Test the Integration * Send test API traffic through Apigee. * Verify in the Akto dashboard that traffic is being ingested. *** ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with Google Cloud Run Functions Cloud Run functions is a lightweight compute solution for developers to create single-purpose, stand-alone functions that respond to Cloud events without the need to manage a server or runtime environment.
To connect Akto with Google Cloud, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add Google Cloud connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **Google Cloud** block and click on the **Connect** button to get instructions
To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Connect Akto with Google Cloud Run Cloud Run is a fully-managed container runtime that automatically scales your code, in a container, from zero to as many instances as needed to handle all incoming requests. Cloud Run sidecars allow you to start independent sidecar containers that run alongside the main container serving web requests.
\ To connect Akto with Google Cloud Run, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add Google Cloud Run connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **Google Cloud Run** block and click on the **Connect** button to get instructions
To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Connect Akto with GKE
GKE is the industry's first fully managed Kubernetes service with full Kubernetes API, release channels, and multi-cluster support.
## Setting up Akto Daemonset pod on your K8s cluster 1. Once complete, you should now see a daemonset config. `Copy the config` and paste in a `text editor`. ``` apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: mirror-api-logging image: aktosecurity/mirror-api-logging:k8s_agent env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_INFRA_MIRRORING_MODE value: "gcp" - name: AKTO_KAFKA_BROKER_MAL value: ":9092" - name: AKTO_MONGO_CONN value: "mongodb://0.0.0.0:27017" ``` 2. Replace `{NAMESPACE}` with your app namespace and `{APP_NAME}` with the name of your app. If you have installed on *AWS* - * Go to EC2 > Instances > Search for `Akto Mongo Instance` > Copy private IP. * Go to EC2 > Load balancers > Search for `AktoNLB` > Copy its DNS. * Replace `AKTO_NLB_IP` with the DNS name. eg `AktoNLB-ca5f9567a891b910.elb.ap-south-1.amazonaws.com` If you have installed on *GCP*, *Kubernetes* or *OpenShift* - * Get Mongo Service's DNS name from Akto cluster * Get Runtime Service's DNS name from Akto cluster * Replace `AKTO_NLB_IP` with the DNS name. eg. `akto-api-security-runtime.p03.svc.cluster.local`
Replace namespace in text editor

Replace namespace in text editor

3. Create a file `akto-daemonset-config.yaml` with the above YAML config 4. Call `kubectl apply -f akto-daemonset-config.yaml -n ` on your *kubectl* terminal 5. Run the command `kubectl get daemonsets` in terminal. It should show *akto-k8s* daemonset. 6. Go to `API Discovery` on Akto dashboard to see your new APIs
Check API Discovery

Check API Discovery

## Frequently Asked Questions (FAQs) **The traffic will contain a lot of sensitive data - does it leave my VPC?** Data remains strictly within your VPC. Akto doesn't take data out of your VPC at all. **Does adding DaemonSet have any impact on performance or latency?** Zero impact on latency. The DaemonSet doesn't sit like a proxy. It simply intercepts traffic - very similar to tcpdump. It is very lightweight. We have benchmarked it against traffic as high as 20M API requests/min. It consumes very low resources (CPU & RAM). ## Troubleshooting Guide **When I hit apply, it says "Something went wrong". How can I fix it?** Akto runs a Cloudformation template behind the scenes to setup the data processing stack and traffic mirroring sessions with your application servers' EC2 instances. This error means the Cloudformation setup failed. 1. Go to AWS > Cloudformation > Search for "mirroring" 2. Click on Akto-mirroring stack and go to Events tab 3. Scroll down to the oldest error event. **The Cloudformation template failed with "Client.InternalError: Client error on launch.". How should I fix it?** This is a known AWS common error. Follow the steps [here](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html#ts-as-instancelaunchfailure-12). **The Cloudformation template failed with "We currently do not have sufficient capacity in the Availability Zone you requested... Launching EC2 instance failed."** You can reinstall Akto in a diff availability zone or you can go to Template tab and save the cloudformation template in a file. Search for "InstanceType" and replace all the occurrences with a type that is available in your availability zone. You can then go to AWS > Cloudformation > Create stack and use this new template to setup Traffic mirroring. **I am seeing kafka related errors in the daemonset logs** If you get an error like "unable to reach host" or "unable to push data to kafka", then do the following steps: 1. Grab the ip of the akto-runtime instance by running "kubectl get service -n {NAMESPACE}" 2. Use helm upgrade to update the value of `kafkaAdvertisedListeners` key to `LISTENER_DOCKER_EXTERNAL_LOCALHOST://localhost:29092,LISTENER_DOCKER_EXTERNAL_DIFFHOST://{IP_FROM_STEP_1}:9092` 3. Put the same ip against the `AKTO_KAFKA_BROKER_MAL` as `{IP_FROM_STEP_1:9092}` in the daemonset config and reapply the daemonset config. **I don't see my error on this list here.** Please send us all details at or reach out via Intercom on your Akto dashboard. We will definitely help you out. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Azure Services
# Connect Akto with Azure App Services
## Introduction Learn about how to send API traffic data from Azure App Services Web App to Akto.
## Prerequisites 1. Your Web App should have sidecar support enabled at the time of creation.
Sidecar Enabled
## Adding Akto traffic collector to Azure App Services Web App 1. Open Azure Portal and click on App Services in the left navbar.
App Services
2. Click on the web app for which you want to setup traffic mirroring. 3. Click on Environment Variables under the Settings tab in left navbar.
Environment Variables
4. Add the following env variables. ```bash AKTO_INFRA_MIRRORING_MODE=gcp AKTO_KAFKA_BROKER_MAL= // modify this value with Akto Runtime Load Balancer DNS AKTO_MONGO_CONN=mongodb://0.0.0.0:27017 AKTO_TRAFFIC_BATCH_SIZE=100 AKTO_TRAFFIC_BATCH_TIME_SECS=10 ``` Click on Apply for the changes to be reflected. 5. Go to your web app, and click on Deployment Center under the Deployment tab in left navbar.
Deployment Center
6. Click on Add button, and add the akto traffic mirroring sidecar.
Add Container
7. Enter the following values to spawn a new Akto mirroring container ```bash Name -> mirroring Image source -> Docker Hub or other registeries Image Type -> Public Registry server URL -> index.docker.io Image and tag -> aktosecurity/mirror-api-logging:k8s_agent Port -> 90 ```
Mirroring Container
8. Click on Apply, and traffic should start population in a couple of minutes. # Connect Akto with Azure API Management Azure API Management is Microsoft's fully managed service for securing, publishing, and analyzing APIs in the Azure cloud. Integrating Azure API Management with Akto enables automatic discovery and security testing of all APIs running in your Azure environment, providing seamless security coverage across your cloud infrastructure.
To connect Akto with Azure API Management, please follow these steps - ## Step 1: Deploy the Akto Data-Ingestion Service Before configuring the Azure API Management (APIM) Traffic Connector, you need to deploy the Akto Data-Ingestion Service. Ensure that the service is running and accessible via a publicly available URL. ### 1.1 Download the Required Files SSH into the instance where you want to deploy the data-ingestion service and run these commands: ```bash wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-compose-data-ingestion-runtime.yml wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/data-ingestion-docker.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/docker-mini-runtime.env wget https://raw.githubusercontent.com/akto-api-security/infra/refs/heads/feature/quick-setup/watchtower.env ``` ### 1.2 Retrieve the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` * Log in to the [Akto Dashboard](https://app.akto.io/). * Navigate to the **Quick Start** tab in the left panel.
* Select **Hybrid SaaS Connector** and copy the token from the **Runtime Service Command** section.
### 1.3 Update the `docker-mini-runtime.env` File * Open the `docker-mini-runtime.env` file and replace `token` with the `DATABASE_ABSTRACTOR_SERVICE_TOKEN` you retrieved earlier. ```plaintext DATABASE_ABSTRACTOR_SERVICE_TOKEN=token ``` ### 1.4 Deploy the Data-Ingestion Service Run the following command to start the data-ingestion service: ```bash docker-compose -f docker-compose-data-ingestion-runtime.yml up -d ``` ### 1.5 Note the IP Address of the Data-Ingestion Service Ensure the instance is accessible from the network where your Azure APIM is configured. Note the instance's IP address, as it will be required by the Azure APIM connector to send traffic data. *** ## Step 2: Create an API Management Service in Azure Portal 1. Go to the [Azure Portal](https://portal.azure.com/) and navigate to "API Management Services."
2. Click on the **Create** button. 3. Fill in the required details: * **Subscription**: Select your Azure subscription. * **Resource Group**: Choose an existing resource group or create a new one. * **Instance Details**: * **Region**: Select the region for your API Management service. * **Resource Name**: Provide a unique name for the service. * **Organization Name**: Enter your organization’s name. * **Administrator Email**: Provide an administrator email. * **Pricing Tier**: Select the appropriate pricing tier. * **Units**: Define the number of units as per your requirement. 4. Click **Review + Create** and then **Create** to deploy the API Management service.
## Step 3: Import/Create APIs in API Management 1. Once the APIM service is created, navigate to the service in the Azure Portal. 2. Go to the **APIs** section. 3. Either import an existing API or create a new API. 4. Select the API where you want to add the policy for the traffic connector. ## Step 4: Configure the Traffic Connector Policy 1. Navigate to the **Inbound Policies** section of the selected API operation. 2. Click on the **Edit Policy** button.
3. Paste the following policy configuration: ```xml !string.IsNullOrWhiteSpace(r)) .ToArray(); return regexList.Length == 0 || regexList.Any(r => System.Text.RegularExpressions.Regex.IsMatch(context.Request.OriginalUrl.Path, r.Trim())); } catch { return false; } }"> !string.IsNullOrWhiteSpace(r)) .ToArray(); return regexList.Length == 0 || regexList.Any(r => System.Text.RegularExpressions.Regex.IsMatch(context.Request.OriginalUrl.Path, r.Trim())); } catch { return false; } }"> @((string)context.Variables["missingKeys"]) https:///api/ingestData POST application/json @{ try { return "{ \"batchData\": [" + "{ \"path\": \"" + context.Variables.GetValueOrDefault("reqUrl", "") + "\", " + "\"requestHeaders\": " + context.Variables.GetValueOrDefault("reqHeaders", "\"\"") + ", " + "\"responseHeaders\": " + context.Variables.GetValueOrDefault("respHeaders", "\"\"") + ", " + "\"method\": \"" + context.Variables.GetValueOrDefault("reqMethod", "") + "\", " + "\"requestPayload\": " + context.Variables.GetValueOrDefault("reqBody", "\"\"") + ", " + "\"responsePayload\": " + context.Variables.GetValueOrDefault("respBody", "\"\"") + ", " + "\"ip\": \"" + context.Variables.GetValueOrDefault("clientIp", "") + "\", " + "\"time\": \"" + context.Variables.GetValueOrDefault("unixTimestamp", "") + "\", " + "\"statusCode\": \"" + context.Variables.GetValueOrDefault("respStatus", "") + "\", " + "\"type\": \"HTTP/1.1\", " + "\"status\": \"" + context.Variables.GetValueOrDefault("statusMessage", "") + "\", " + "\"akto_account_id\": \"1000000\", " + "\"akto_vxlan_id\": \"0\", " + "\"is_pending\": \"false\", " + "\"source\": \"MIRRORING\" } ] }"; } catch { return "{}"; } } ``` 4. **Important Note**:\ If you remove the `` element from the policy configuration at the API scope, **only** the policies defined at the API scope will be applied. Policies configured at **product**, **global**, or other broader scopes will **not** be inherited or executed. Always include `` in the appropriate sections (``, ``, ``, and ``) unless you explicitly intend to override all inherited behavior. (For more info [click here](https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-policies).) 5. Add the regex patterns for the paths you want to **include** in the `regexList` variable value in the inbound policy, ensuring that the **entire regex is properly escaped**. Separate multiple patterns using `;` (e.g., `"api\/v1\/.*;\/api\/getUsers.*"`). * If you leave the `regexList` variable value empty, all APIs will be processed. 6. Replace `YOUR_AKTO_INGESTION_SERVICE_URL` with the URL of your Akto Data-Ingestion Service (Step 1.5). 7. Click **Save** to apply the policy. ## Step 5: Verify the Integration 1. Send test requests to the configured API endpoint. 2. Check the Akto Data-Ingestion Service logs to verify that the traffic data is being ingested correctly. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with AKS
AKS offers the quickest way to start developing and deploying cloud-native apps in Azure, datacenters, or at the edge, with built-in code-to-cloud pipelines and guardrails.
## Setting up Akto Daemonset pod on your K8s cluster 1. Once complete, you should now see a daemonset config. `Copy the config` and paste in a `text editor`. ``` apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: mirror-api-logging image: aktosecurity/mirror-api-logging:k8s_agent env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_INFRA_MIRRORING_MODE value: "gcp" - name: AKTO_KAFKA_BROKER_MAL value: ":9092" - name: AKTO_MONGO_CONN value: "mongodb://0.0.0.0:27017" ``` 2. Replace `{NAMESPACE}` with your app namespace and `{APP_NAME}` with the name of your app. If you have installed on *AWS* - * Go to EC2 > Instances > Search for `Akto Mongo Instance` > Copy private IP. * Go to EC2 > Load balancers > Search for `AktoNLB` > Copy its DNS. * Replace `AKTO_NLB_IP` with the DNS name. eg `AktoNLB-ca5f9567a891b910.elb.ap-south-1.amazonaws.com` If you have installed on *GCP*, *Kubernetes* or *OpenShift* - * Get Mongo Service's DNS name from Akto cluster * Get Runtime Service's DNS name from Akto cluster * Replace `AKTO_NLB_IP` with the DNS name. eg. `akto-api-security-runtime.p03.svc.cluster.local`
Replace namespace in text editor

Replace namespace in text editor

3. Create a file `akto-daemonset-config.yaml` with the above YAML config 4. Call `kubectl apply -f akto-daemonset-config.yaml -n ` on your *kubectl* terminal 5. Run the command `kubectl get daemonsets` in terminal. It should show *akto-k8s* daemonset. 6. Go to `API Discovery` on Akto dashboard to see your new APIs
Check API Discovery

Check API Discovery

## Frequently Asked Questions (FAQs) **The traffic will contain a lot of sensitive data - does it leave my VPC?** Data remains strictly within your VPC. Akto doesn't take data out of your VPC at all. **Does adding DaemonSet have any impact on performance or latency?** Zero impact on latency. The DaemonSet doesn't sit like a proxy. It simply intercepts traffic - very similar to tcpdump. It is very lightweight. We have benchmarked it against traffic as high as 20M API requests/min. It consumes very low resources (CPU & RAM). ## Troubleshooting Guide **When I hit apply, it says "Something went wrong". How can I fix it?** Akto runs a Cloudformation template behind the scenes to setup the data processing stack and traffic mirroring sessions with your application servers' EC2 instances. This error means the Cloudformation setup failed. 1. Go to AWS > Cloudformation > Search for "mirroring" 2. Click on Akto-mirroring stack and go to Events tab 3. Scroll down to the oldest error event. **The Cloudformation template failed with "Client.InternalError: Client error on launch.". How should I fix it?** This is a known AWS common error. Follow the steps [here](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html#ts-as-instancelaunchfailure-12). **The Cloudformation template failed with "We currently do not have sufficient capacity in the Availability Zone you requested... Launching EC2 instance failed."** You can reinstall Akto in a diff availability zone or you can go to Template tab and save the cloudformation template in a file. Search for "InstanceType" and replace all the occurrences with a type that is available in your availability zone. You can then go to AWS > Cloudformation > Create stack and use this new template to setup Traffic mirroring. **I am seeing kafka related errors in the daemonset logs** If you get an error like "unable to reach host" or "unable to push data to kafka", then do the following steps: 1. Grab the ip of the akto-runtime instance by running "kubectl get service -n {NAMESPACE}" 2. Use helm upgrade to update the value of `kafkaAdvertisedListeners` key to `LISTENER_DOCKER_EXTERNAL_LOCALHOST://localhost:29092,LISTENER_DOCKER_EXTERNAL_DIFFHOST://{IP_FROM_STEP_1}:9092` 3. Put the same ip against the `AKTO_KAFKA_BROKER_MAL` as `{IP_FROM_STEP_1:9092}` in the daemonset config and reapply the daemonset config. **I don't see my error on this list here.** Please send us all details at or reach out via Intercom on your Akto dashboard. We will definitely help you out. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with Azure OpenShift
Azure Red Hat OpenShift provides highly available, fully managed OpenShift clusters on demand, monitored and operated jointly by Microsoft and Red Hat.
1. [Add service account](#service-account-manifest) to get permissions for traffic connector. 2. You can use [Kubernetes Daemonset connector](/traffic-connector/kubernetes/kubernetes) or [eBPF on mTLS](/traffic-connector/ebpf/ebpf-mtls) as your traffic connector. Add the following to the Daemonset connector - > They listen to `any` interface by default - which might NOT be allowed in some Openshift clusters. If that's the case, contact - we can help listen traffic on `br-ex` interface. ```yaml containers: - name: mirror-api-logging ... # add the following lines to add additional privileges privileged: true securityContext: runAsUser: 0 privileged: true ``` #### Service account manifest On Openshift, for a pod to be able to listen to node traffic (eg. a daemonset pod), it needs to be assigned some special permissions. 1\. Create a Service Account ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: akto-daemonset-serviceaccount annotations: "scc.openshift.io/scc": "akto-daemonset-scc" ``` 2. Create a Security Context Constraint. Substitute \ with Akto daemonset yaml namespace. ```yaml apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: akto-daemonset-scc allowPrivilegedContainer: true allowHostNetwork: true requiredDropCapabilities: - NET_ADMIN seLinuxContext: type: RunAsAny runAsUser: type: RunAsAny runAsUser: type: RunAsAny seLinuxContext: type: MustRunAs users: - system:serviceaccount::akto-daemonset-serviceaccount ``` 3. Add SCC to service account ```bash oc adm policy add-scc-to-user akto-daemonset-scc -z akto-daemonset-serviceaccount ``` # Connect Akto with Azure Container App
1. Use the following env vars to configure the sidecar ``` AKTO_INFRA_MIRRORING_MODE=gcp AKTO_KAFKA_BROKER_MAL= // modify this value with Akto Runtime Load Balancer DNS AKTO_MONGO_CONN=mongodb://0.0.0.0:27017 AKTO_TRAFFIC_BATCH_SIZE=100 AKTO_TRAFFIC_BATCH_TIME_SECS=10 ``` 2. Click on Add button, and add the akto traffic mirroring sidecar.
Add Container
3. Enter the following values to spawn a new Akto mirroring container ```bash Name -> mirroring Image source -> Docker Hub or other registeries Image Type -> Public Registry server URL -> index.docker.io Image and tag -> aktosecurity/mirror-api-logging:k8s_agent Port -> 90 ```
Mirroring Container
4. Click on Apply, and traffic should start population in a couple of minutes. # Connect Akto with Azure Functions Azure Functions is a serverless solution that allows you to write less code, maintain less infrastructure, and save on costs. Instead of worrying about deploying and maintaining servers, the cloud infrastructure provides all the up-to-date resources needed to keep your applications running.
To connect Akto with Azure Functions, follow these steps - 1. Set up and configure Akto Traffic Processor. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). 2. Add Azure Functions connector 1. Go to **Quick Start** in Akto Dashboard 2. Scroll to **Azure Functions** block and click on the **Connect** button to get instructions
To enable this premium connector for your account, please reach out to our team at for pricing and setup information. # Akto SDK You can use our SDKs ( currently [Java](https://github.com/akto-api-security/java-servlet-api-logging), [Python Flask](https://github.com/akto-api-security/flask-middleware), [Ruby](https://github.com/akto-api-security/ruby-middleware), [NodeJs](https://github.com/akto-api-security/express-api-logging), [Go](https://github.com/akto-api-security/gomiddleware) supported, we are adding more languages every week ) to create a data pipeline. {% hint style="info" %} Akto's SDKs will run in an asynchronous manner and hence won't have any impact on your production performance. {% endhint %} # Virtual Machines # Connect Akto with Docker ## Introduction You can add akto-traffic-collector service to your docker-compose file. Your APIs from this traffic will show up in Akto dashboard. ## Adding Akto traffic processor 1. Set up and configure Akto Traffic Processor and save the mini-runtime service URL. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). Alternatively, if you're on on-premise deployment, save the runtime service URL. ## Adding Akto docker service 1. Create a file `docker-akto-collector.env` with the following content. 1. Replace `` with the mini-runtime/runtime service URL saved earlier. ```bash AKTO_TRAFFIC_BATCH_TIME_SECS=10 AKTO_TRAFFIC_BATCH_SIZE=100 AKTO_INFRA_MIRRORING_MODE=gcp AKTO_KAFKA_BROKER_MAL=:9092 AKTO_MONGO_CONN=mongodb://0.0.0.0:27017 ``` 2. Add the following service to your docker-compose file. Adjust the mem\_limit accordingly. ```yaml akto-api-security-traffic-collector: image: aktosecurity/mirror-api-logging:k8s_agent env_file: ./docker-akto-collector.env mem_limit: 512m restart: always network_mode: host ``` ## Run with a single command You can run the traffic collector with one `docker run` command. Replace `` with the mini-runtime/runtime service URL. ```bash docker run -d \ --name akto-api-security-traffic-collector \ --restart always \ --network host \ --cpus="0.5" \ --memory="512m" \ -e AKTO_TRAFFIC_BATCH_TIME_SECS=10 \ -e AKTO_TRAFFIC_BATCH_SIZE=100 \ -e AKTO_INFRA_MIRRORING_MODE=gcp \ -e AKTO_KAFKA_BROKER_MAL=":9092" \ -e AKTO_MONGO_CONN=mongodb://0.0.0.0:27017 \ public.ecr.aws/aktosecurity/mirror-api-logging:k8s_agent ``` ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto on TLS service Akto can automatically detect and analyze your API traffic—even if it's encrypted using TLS. This is achieved using **Akto Traffic Collector**, which leverages **eBPF** to passively observe kernel-level network activity. You can deploy this collector on **any Linux-based system** (VM, bare metal, or cloud instance) to forward traffic insights to Akto. Here's how: #### Step 1: Set Up Akto Traffic Processor (Mini-Runtime) First, set up and configure the **Akto Traffic Processor (Mini-Runtime)**. * You’ll get a **runtime service URL** or **Kafka IP** once setup is complete. * If you're using **on-prem Akto**, this will be your internal runtime URL. 📘 [Follow this setup guide](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas) for instructions. #### Step 2: Deploy Traffic Collector (Supports TLS via eBPF) This Docker container uses **eBPF** to mirror all API traffic at the kernel level—including **TLS-encrypted** traffic—without needing to decrypt it manually or modify applications. **⚠ Prerequisites:** * **Linux VM** or system with **kernel headers installed** (required for eBPF) * Docker daemon installed and running * Access to your Akto runtime (Kafka IP) #### Run the Traffic Collector The kafka\_ip here is the mini-runtime/runtime service URL we saved in the previous step. ```bash docker run -d \ --name akto-api-security-traffic-collector \ --restart always \ --network host \ --privileged \ --pid=host \ --cap-add SYS_PTRACE \ --cap-add SYS_ADMIN \ --cpus="0.5" \ --memory="512m" \ -v /lib/modules:/lib/modules \ -v /sys/kernel:/sys/kernel \ -v /usr/src:/usr/src \ -v /:/host \ -e AKTO_TRAFFIC_BATCH_TIME_SECS=10 \ -e AKTO_TRAFFIC_BATCH_SIZE=100 \ -e AKTO_KAFKA_BROKER_MAL=":9092" \ -e PROBE_ALL_PID=true \ public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf ``` In case you face an issue with the spaces in the command above ```bash docker run -d --name akto-api-security-traffic-collector --restart always --network host --pid=host --privileged --cap-add SYS_PTRACE --cap-add SYS_ADMIN --cpus="0.5" --memory="512m" -v /lib/modules:/lib/modules -v /sys/kernel:/sys/kernel -v /usr/src:/usr/src -v /:/host -e AKTO_TRAFFIC_BATCH_TIME_SECS=10 -e AKTO_TRAFFIC_BATCH_SIZE=100 -e AKTO_KAFKA_BROKER_MAL= -e PROBE_ALL_PID=true public.ecr.aws/aktosecurity/mirror-api-logging:k8s_ebpf ``` #### What’s Happening Behind the Scenes? * **eBPF hooks into your Linux kernel** to capture real-time traffic—even if it’s encrypted (TLS). * No code changes, no traffic proxying, no SSL termination. * The collector forwards API traces to Akto for real-time inventory and security analysis. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto on TLS service (bare Linux) Akto can automatically detect and analyze your API traffic—even if it's encrypted using TLS. This is achieved using **Akto Traffic Collector**, which leverages **eBPF** to passively observe kernel-level network activity. You can deploy this collector on **any Linux-based system** (VM, bare metal, or cloud instance) **without Docker** by installing the **dockerless** eBPF core bundle (Go binary + BPF object + shell wrappers), distributed as a versioned **`.tar.gz`**. Here's how: #### Step 1: Set Up Akto Traffic Processor (Mini-Runtime) First, set up and configure the **Akto Traffic Processor (Mini-Runtime)**. * You’ll get a **runtime service URL** or **Kafka IP** once setup is complete. * If you're using **on-prem Akto**, this will be your internal runtime URL. 📘 [Follow this setup guide](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas) for instructions. #### Step 2: Deploy Traffic Collector (Supports TLS via eBPF, tarball) This path uses the **bare Linux** bundle instead of a container. It mirrors API traffic at the kernel level—including **TLS-encrypted** traffic—without decrypting traffic in userspace or changing your applications. **⚠ Prerequisites:** * **Linux** on the target host (amd64 or arm64 matching the tarball you download). * **Kernel / BPF**: CO-RE expects host BTF (typically `/sys/kernel/btf/vmlinux`) and sufficient privileges to load BPF (often root or the same capability set as your Kubernetes DaemonSet). * **Network**: reachability to the Kafka broker you configure in `.env` (use the **Kafka IP** or runtime address from Step 1). Typical archive names: `akto-mirroring-module--.tar.gz` *** ## Install ### 1. Download the archive Use the HTTPS download URL Akto provides. Choose the build whose **arch** matches this machine (`amd64` vs `arm64`). ```bash wget -O akto-mirroring-module--.tar.gz "" ``` (`curl -fL "" -o akto-mirroring-module--.tar.gz` works the same way.) ### 2. Unpack (default layout: `/ebpf`) As **root** (paths in the archive are rooted at `ebpf/`): ```bash sudo tar -xzf akto-mirroring-module--.tar.gz -C / ``` This creates **`/ebpf/`** including: | Path | Role | | ---------------------------------- | ------------------------------------------------------- | | `ebpf/ebpf-logging` | Main Go binary | | `ebpf/kernel/module.bpf.o` | Compiled BPF object | | `ebpf/ebpf-run.sh` | Supervisor loop | | `ebpf/run-ebpf-core-host.sh` | Host entrypoint (sudo wrapper; **detached by default**) | | `ebpf/uninstall-ebpf-core-host.sh` | Stops processes; leaves `${EBPF_ROOT}` on disk | | `ebpf/.env` | Default environment (edit before production) | If you install under a **different** directory, set **`EBPF_ROOT`** consistently (see below) and keep **`ebpf-run.sh`** and **`.env`** together under that directory. ### 3. Configure Edit **`/ebpf/.env`** (or **`${EBPF_ROOT}/.env`**). At minimum set **`AKTO_KAFKA_BROKER_MAL`** to your broker from Step 1 (replace the `` placeholder in the shipped template). Typical bare-metal defaults in that file: * **`EBPF_ROOT=/ebpf`** — bundle root. * **`HOST_MAPPING=/`** — host path prefix (use **`/host`** when running inside Docker with `-v /:/host`). * **`ENABLE_LOGS=false`** / **`LOG_FILE=/ebpf/dump.log`** — shipped defaults; if you change **`EBPF_ROOT`**, set **`LOG_FILE`** under that directory (for example **`/opt/akto/ebpf/dump.log`**). ### 4. Run (detached by default) `run-ebpf-core-host.sh` starts the supervisor under **`nohup`** and returns immediately. It writes **`${EBPF_ROOT}/ebpf-core-run.pid`**. **`nohup.out`** is not used. With **`ENABLE_LOGS=false`**, **`ebpf-run.sh`** attaches non-TTY stdout/stderr to **`LOG_FILE`** (see **`.env`** / **`MAX_LOG_SIZE`** for rotation). ```bash sudo /ebpf/run-ebpf-core-host.sh ``` Follow logs: * **`ebpf-run.sh`** shell output (memory lines, restarts) and collector when **`ENABLE_LOGS=false`** (bundle default): `tail -f /ebpf/dump.log` or override **`LOG_FILE`** in **`.env`** Attach to the supervisor in the foreground (blocks this shell), for debugging: ```bash sudo /ebpf/run-ebpf-core-host.sh -f # or: sudo AKTO_FOREGROUND=true /ebpf/run-ebpf-core-host.sh ``` Or with a non-default install root: ```bash sudo EBPF_ROOT=/opt/akto/ebpf /opt/akto/ebpf/run-ebpf-core-host.sh ``` Ensure **`EBPF_ROOT`** in the environment matches **`EBPF_ROOT`** in **`.env`** when you use a custom path. ### 5. Uninstall Stops **`ebpf-run.sh`** / **`ebpf-logging`** for this install (using the pidfile when present, then matching processes). It does **not** remove **`EBPF_ROOT`**. ```bash sudo /ebpf/uninstall-ebpf-core-host.sh -y ``` Custom root: ```bash sudo EBPF_ROOT=/opt/akto/ebpf /opt/akto/ebpf/uninstall-ebpf-core-host.sh -y ``` Omit **`-y`** for an interactive confirmation (requires a TTY). #### What’s Happening Behind the Scenes? * **eBPF hooks into your Linux kernel** to capture real-time traffic—even if it’s encrypted (TLS). * No code changes, no traffic proxying, no SSL termination. * The collector forwards API traces to Akto for real-time inventory and security analysis. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with TCP Agent ## Introduction You can use Akto traffic collectors to collect and send traffic to Akto. Your APIs from this traffic will show up in Akto dashboard. ## Adding Akto traffic processor 1. Set up and configure Akto Traffic Processor and save the mini-runtime service URL. The steps are mentioned [here](https://docs.akto.io/getting-started/traffic-processor/hybrid-saas). Alternatively, if you're on on-premise deployment, save the runtime service URL. ## Adding Akto traffic collector container 1. Start a docker service `aktosecurity/mirror-api-logging:k8s_agent` to any instance you want to collect traffic 2. Set the following env variables. 1. Replace `` with the mini-runtime/runtime service URL saved earlier. ``` export AKTO_TRAFFIC_BATCH_TIME_SECS=10 export AKTO_TRAFFIC_BATCH_SIZE=100 export AKTO_INFRA_MIRRORING_MODE=gcp export AKTO_KAFKA_BROKER_MAL=:9092 export AKTO_MONGO_CONN=mongodb://0.0.0.0:27017 ``` 3. Launch docker in your server instance. # Connect Akto with MITM Proxy This mitmproxy addon script can be used to populate the Akto inventory. `mitmproxy` An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers. ### How it works? `mitmdump` is essentially the command-line version of mitmproxy, functioning much like tcpdump but for HTTP traffic. By utilizing this add-on script with the `-s` option, you can effectively save the API data collected in mitmdump to Akto. The script initializes a JSON object and starts populating it with HAR entries. When the JSON object reaches a size exceeding 20MB, it then proceeds to transmit the HAR JSON to Akto. ### Usage #### Standalone mitmproxy ```bash pip install mitmproxy requests export AKTO_BASE_URL="https://app.akto.io" export AKTO_API_KEY="YOUR_API_KEY" mitmdump -s ./akto.py --set akto_collection=YOUR_COLLECTION_NAME ``` #### Dockerized mitmproxy ```bash docker build -t mitm . docker run --rm -it \ -v $(pwd):/opt/mitm \ -p 8080:8080 \ -e AKTO_BASE_URL="https://app.akto.io" \ -e AKTO_API_KEY="YOUR_API_KEY" \ mitm mitmdump -s /opt/mitm/akto.py \ --set akto_collection=YOUR_COLLECTION_NAME ``` **Note**: Upon completion of the execution, ensure the mitmdump is exited (or the mitmdump container is stopped) to transmit the remaining data to Akto. # Manual # Connect Akto with Burp suite Learn how to send API traffic data from Burp suite to Akto from your environment. ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). If you don't have access to staging or production environment, you can create API inventory using Burp's traffic. {% hint style="info" %} Note that traffic from Burp Suite won't be automated like the native cloud connectors. {% endhint %} ## Pre-requisites for Akto Burp connection 1. Make sure you have Burp Suite Community edition or professional installed on your system. 2. You should have an active Akto account which is accessible from your machine. ## Configuring Burp extension in Akto Dashboard In the demonstration below, we have first bridged the connection between our Akto account and the Burp Suite account before we can start populating the API traffic in our API inventory. This integration begins by downloading the executable **`“Jar file”`** provided in the Akto account. Later on, this file is uploaded to the Burp Suite account to initiate the installation of the Akto extension. Once the extension was successfully installed in the Burp Suite account, we navigated back to Akto to copy the **`AKTO ID`** & **`AKTO TOKEN`** and paste the values in the relevant fields provided under the Akto extension tab in Burp Suite. {% embed url="" %} {% embed url="" %} Akto Burp connection Demo {% endembed %} ### What's next? Head to [API Discovery](/api-inventory/concepts/api-collection) to learn more. Once you start seeing inventory, you can run API Security tests on your APIs. See [Akto's test library](https://www.akto.io/test-library) to select tests you want to run on your APIs. ## Frequently Asked Questions (FAQs) #### 1. How can I send data related to only a particular domain - example.com to Akto via Burp? Step 1: In Burp Suite, open `Target` tab, click on `Scope settings`
Scope settings in burp

Scope settings in burp

Step 2: Inside the `Scope settings` popup, click on `Add` button inside the `Target scope` section and add the prefix of the url i.e. .
Add target scope

Add target scope

Add prefix

Add prefix

Add scope

Add scope

Step 3: Now scroll down to `Out-of-scope request handling` section and select the `Drop all out of scope requests` checkbox. Note: this option will not allow the proxy browser to access any other urls and hence data related to no other urls will be sent to Akto.
Drop all out of scope requests

Drop all out of scope requests

#### 2. What should I do if my API key has expired or is invalid? If your API key has expired or is invalid, you will see a dialog box with the error message "`Invalid API key`" To resolve this issue: Step 1: Open the Akto dashboard. Step 2: Navigate to `Settings > Integrations > Burp`. Step 3: Generate a new token and copy it. Step 4: Paste the new token into the "Options" tab of Burp under AKTO\_TOKEN. #### 3. Does the Akto Burp plugin processes all the network calls passing through the proxy? Akto processes only API traffic. Network calls like getting media files are excluded. #### 4. How to pause sending data to Akto? In Burp Suite, go to `Akto tab> Options`. Disable the setting `Send data to Akto automatically`. #### 5. I want to re-export the same data in a different collection. How can I do this in Burp using the Akto plugin? To re-export the same data into a different collection using the Akto Burp extension, follow these steps: Step 1: Open Burp Suite and navigate to the Akto tab. Step 2: In the Akto tab in Burp Suite, locate the "Options" tab. Step 3: Inside the "Options" tab, you can change the collection name to your desired new name. Step 4: Once you've updated the collection name, the changes are automatically saved. Step 5: Re-export the data using the updated collection name, and it will be saved as a separate collection with the new name, allowing you to organize and manage your data effectively in Burp. #### 6. Can I import ZAP traffic into Akto? Yes, you can import ZAP (Zed Attack Proxy) traffic into Akto using the Akto plugin. Here's how: Step 1: Open the `Akto tab` in your Burp Suite in your chosen environment. Step 2: Navigate to the `Options tab` within the Akto tab in Burp Suite. Step 3: In the `Options` tab, you'll find a feature that allows you to import ZAP traffic. Step 4: Follow the provided instructions to import ZAP traffic data into Akto. By utilizing this feature in the Akto plugin, you can seamlessly import ZAP traffic alongside other data sources, enabling comprehensive monitoring and analysis within the Akto platform. ## Troubleshooting Guide If you encounter connectivity issues with the Akto server, follow these steps: **1. If you see a dialog box with the error message "Connection to localhost failed: Connection refused," it means that the Akto server is not reachable from your Burp instance.** To check and ensure reachability to the Akto server, follow these steps: Step 1: Open a Web Browser: Launch a web browser on the same machine where Burp is installed. Step 2: Enter Akto Server URL: In your web browser's address bar, enter the same URL or IP address that you previously configured in the "AKTO\_IP" setting within the Burp plugin. This URL corresponds to the location where Akto's services are hosted. Attempt to Access Akto: Press Enter or click "Go" to navigate to the Akto server's URL. Step 3: Observe Response: Pay attention to the response from the Akto server. If the server is reachable and responsive, you should see a page or message indicating successful access. If you encounter any errors or the page doesn't load, it suggests a connectivity issue. **2. I can't see all my APIs in the Burp collection. What should I check?** If you cannot see data in the Burp collection, ensure the following: The traffic in your Burp API Collection has a 2xx status code because Akto ignores non-2xx API traffic data. Check the response codes for the requests you are monitoring. **3. Why are rows highlighted in black within the Akto Burp plugin's table view, and how can I resolve this issue?** If you notice rows being highlighted in black within the Akto Burp plugin's table view, it signifies an issue with data presentation. This issue is commonly encountered when there is a conflict with another plugin called LoggerPlusPlus. To resolve this issue, follow these steps: Step 1: Remove LoggerPlusPlus Plugin: The black highlighting issue is often caused by conflicts with the LoggerPlusPlus plugin. To resolve this, you should remove the LoggerPlusPlus plugin from your Burp installation for Akto extension to work. Step 2: Refresh the Table: After removing the LoggerPlusPlus plugin, refresh the table view within the Akto Burp plugin. You may need to close and reopen the Akto Burp plugin or take any necessary steps specified in the plugin's interface to update the view. **4. Akto extension unable to send data after I reinstalled it in burp for a different akto account** 1. Load the Akto extension in burp suite and open `Akto` tab, click on `Options` and then click on `Reset All Settings`. 2. Now click on `Extensions` and reload the akto extension by unchecking and then checking the checkbox. Note: This should load the new settings for the akto extension. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with Postman Learn how to send API traffic data from Postman to Akto. ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). If you don't have access to staging or production environment, you can create API inventory using Postman collection. {% hint style="info" %} Note that traffic from Postman won't be automated like the native cloud connectors. {% endhint %} ## What is Akto postman connector? Akto gives you ability to add API data through Postman integration. If you have a Postman API collection, follow the steps below to add API data to Akto: ## Pre-requisites Before integrating Akto with Postman, ensure the following setup requirements are met. #### 1. You Have an Active Akto Account You must have an active Akto account. If you do not have one, [sign up on the Akto platform.](https://app.akto.io) #### 2. You Have Access to Postman You must have access to Postman in one of the following ways: * A Postman account (API key access required to fetch collections). * Postman Desktop App (export the collection file and upload it to Akto). #### 3. Your API URLs Are Reachable If your Postman collection does not contain saved response examples: * Akto will replay the APIs to fetch responses. * You must ensure the URLs in your collection are reachable from your machine or environment. If endpoints are not reachable, API replay will fail. #### 4. Your Collection Is Prepared Before syncing or uploading: * You have organised your Postman collections. * You have included the APIs you want Akto to discover. * Each request contains complete details (headers, body, query parameters). #### 5.You Whitelist Akto IPs You must ensure Akto’s IP addresses are whitelisted in: * Your WAF (Web Application Firewall) rules * Your rate limiting rules * Any IP-based access control lists ## Collection Requirements To ensure smooth import and accurate API discovery, your collection must meet the following requirements: ### 1. If You Add API Successful Examples (Recommended) If you add an **API Successful Example** for each API then Akto imports APIs directly using the request and response pairs. An API Successful Example must include: * The complete request * A successful response (e.g., 200, 201) * Request headers * Request body (if applicable)
How to Add a Successful Example Here are the following steps on how you can a successful response example : **Steps** 1. Open the request in **Postman**. 2. Click **Send** to execute the request. 3. In the response panel, click **Save Response**. 4. Select **Save as Example**. 5. Save the example (ensure status code and response body are correct). Repeat this for each API where you want to provide a successful response example. For detailed instructions, refer to the [official Postman documentation](https://learning.postman.com/docs/design-apis/mock-apis/tutorials/mock-with-examples#save-a-response-as-an-example).
### 2. If You Do NOT Add API Successful Examples (Replay Mode) If API Successful Examples are not present: * Akto will replay the APIs defined in your Postman collection. * Akto captures live request-response pairs. * These captured pairs populate the API Inventory. In this case, the following are required for replay to succeed: {% tabs %} {% tab title="Authorization (For Authenticated APIs)" %} * The `Authorization` header must be present. * The token must be valid and active. * The format must follow standard conventions (e.g., Bearer token) {% endtab %} {% tab title="Host Header" %} * The `Host` header must be present in each request. * This ensures proper service identification and routing. {% endtab %} {% endtabs %} {% hint style="warning" %} #### Common Import Errors You may see the following errors on the Akto dashboard: * **Unresolved variables** * **No response found** * **Unknown auth mechanism** To prevent these: * Define all variables in the collection file. * Add at least one successful response example per API. * Ensure the Host header is present in each request. * Ensure Authorisation headers are correctly configured for authenticated APIs. {% endhint %} ### Variables Definition References If your requests use variables (e.g., `{{baseUrl}}`, `{{authToken}}`): * All variables must be defined in the collection. * Variables must resolve successfully during import. Refer to [#variables-in-postman-collection-file](#variables-in-postman-collection-file "mention") for reference. {% hint style="success" %} #### Recommendation To avoid replay dependency and configuration complexity: * Add an API Successful Example for each API. * Ensure variables are properly defined. If API Successful Examples are present, replay-related configuration is not required. {% endhint %} ## Integrating Postman In the demonstration below, we have first bridged the connection between our Akto account and Postman account before we can start populating the API traffic in our API inventory. This integration involves entering the **`Postman API key`** in the relevant field while also selecting the **`Postman workspace`** we wish to import. {% embed url="" %} After connecting your Postman Account to Akto, you will be provided with the following two options to import the API Traffic data from Postman: * Using Postman API Key * Using Postman Collection File ### 1. Using Postman API Key In the demonstration below, we have generated our **`Postman API key`** and pasted the value in the configuration setup to fetch and select the Postman workspace (containing API traffic) to import to Akto. {% embed url="" %} Import using Postman API key {% endembed %} ### 2. Using Postman Collection File In the demonstration below, we have imported the API traffic data to our Akto account from one of our workspaces in Postman. By simply exporting the API collection from our Postman workspace, we have uploaded the same **`JSON file`** to Akto and populated the API traffic in the inventory. {% embed url="" %} Import Postman collection file {% endembed %} ## Variables in Postman Collection File Akto supports Postman **collection-level variables** in your exported collection JSON file. Variables help you parameterise parts of your API requests (such as URLs, headers, auth values, and request bodies) using the `{{variableName}}` syntax. Akto will replace these variables with the values defined in the collection before resolving requests during import or replay. {% hint style="success" %} #### Why Proper Variable Definition Matters If any variable used in the collection is not defined: * Akto may show **unresolved variables** errors on the dashboard. * API requests that depend on those variables may break or fail during replay. * Replay may substitute undefined variables as blank, leading to incorrect URLs or headers. {% endhint %} #### How Variables Work * Variables should be defined in the `variable` array at the root of the Postman collection JSON. * Each variable must have a `key` and a `value`. * Variables can be used in URLs, headers, body data, and authentication fields. Example of a collection variables block: ```json "variable": [ { "key": "baseUrl", "value": "https://api.example.com" }, { "key": "apiKey", "value": "my-secret-key" } ] ``` You can then use these variables in your API request definitions like: ```json {{baseUrl}}/api/v1/users ``` {% hint style="info" %} #### Note Before exporting your collection for Akto: * Ensure all variable references (`{{…}}`) in your collection are defined in the `variable` section. * If you are using environment variables in Postman, copy those values into the collection’s variable array before export. {% endhint %} When Akto imports your collection, it will substitute these values automatically. For more details on how variables work in Postman and how to define them across scopes, see the [official Postman documentation](https://learning.postman.com/docs/sending-requests/variables/variables). ## What's next? Once you start seeing inventory, you can run API Security tests on your APIs. See [Akto's test library](https://www.akto.io/test-library) to select tests you want to run on your APIs. ## Frequently Asked Questions (FAQs) **1. How can I find my Postman API key for integration with Akto?** To find your Postman API key: Open Postman. Click on your Profile in the top-right corner. From the drop-down menu, select Settings and then API Keys. Generate a new API key or copy an existing one. **2. What security measures are in place to protect my Postman API key and collections when using the Akto integration?** Akto takes data security seriously. Your Postman API key is securely stored, and Akto uses encryption and other security practices to protect your data during the integration process. It's important to keep your API key confidential and not share it with unauthorized parties. **3. What is the benefit of syncing Postman workspaces with Akto?** Syncing Postman workspaces with Akto allows you to leverage Akto's features for API testing, monitoring, and analytics on your Postman collections. It provides a centralized platform for managing and analyzing your API-related activities. **4. Are there any limitations on the size of Postman collections that can be uploaded to Akto?** While there may not be a specific file size limitation for uploading Postman collections to Akto, it's important to consider the practicality and performance of working with very large collections. Extremely large collections may take longer to upload and process, so it's advisable to break them into smaller, manageable parts if necessary. **5. What happens if I tick the "Allow Akto to replay API requests if responses are not found" checkbox in Akto?** If this checkbox is ticked, Akto will attempt to replay APIs to generate responses when they are missing in the Postman collection. However, if the APIs are inaccessible or return non-2xx response codes, they may fail to be imported to Akto. **6. Is there a difference in using the Akto integration with the Postman Desktop App (installed locally) compared to the Postman SaaS App?** Yes, there is a difference in how the two versions of Postman integrate with Akto: Postman Desktop (Installed Locally): Users of the Postman desktop app, installed locally on their machines, have the option to upload collections manually to Akto. They export their Postman collections as files and then manually upload these files to Akto. Desktop users do not have access to API keys for integration. Postman SaaS (Online): Users of the Postman SaaS version have more versatile integration options. They can choose to use API keys for seamless integration. This involves generating an API key from their Postman SaaS account and providing it during the Akto integration setup. Alternatively, they can manually download the Postman collection and upload it to Akto. ## Troubleshooting Guide **1. After following the steps, I see new collections in Akto, but they have fewer endpoints than the original Postman file. What could be the issue?** Akto processes APIs within the Postman collection based on whether they have saved responses or return 2xx status codes. Here's a detailed explanation: Saved Responses: Akto primarily looks for saved responses within your Postman collection. To ensure comprehensive coverage, it's a best practice to hit all APIs from within Postman itself and save the responses. When Akto detects saved responses, it includes these in the Akto collection. Handling Missing Responses: If Akto does not find saved responses for certain APIs, it attempts to send requests to those APIs one-by-one (substituting variables if any). However, it's important to note that only APIs returning a 2xx status code (indicating a successful response) during this process get processed and included in the Akto collection. In summary, Akto relies on saved responses and successful API responses (2xx status codes) to populate the Akto collection. Ensuring that all APIs have saved responses in Postman is recommended for complete integration with Akto. **2. I enabled the "Allow replay" checkbox, but I still don't see any APIs in Akto. What could be the issue?** To resolve this issue, please consider the following steps: Ensure that the server is accessible from your Akto instance. If the server is not reachable, Akto won't be able to replay the API requests and generate responses. Check your network settings and firewall configurations if needed. Verify that the Postman collection includes valid authentication tokens or credentials if required. A successful API request depends on having the appropriate authentication in place. If the API requests in the collection lack valid credentials, they may not succeed, even with the "Allow replay" option enabled. **3. What happens if the upload of my Postman collection to Akto fails?** If the upload of your Postman collection to Akto fails: 1. Ensure that the collection file is in the correct format (Collection v2.1). 2. The file isn't bigger than 25mb ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `support@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Connect Akto with OpenAPI Learn how to send API traffic data from OpenAPI spec to Akto. ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for AP misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). If you don't have access to staging or production environment, you can create API inventory using OpenAPI spec. {% hint style="info" %} Note that traffic from OpenAPI spec won't be automated like the native cloud connectors. {% endhint %} ### Pre-requisites for Akto OpenAPI connection * You must have an `active Akto account`. If you don't have one, sign up for an account on the Akto platform. * [Cloud Signup](https://app.akto.io/) * Prepare the OpenAPI specification you wish to upload to Akto. Make sure these collections are organized and contain the API requests you want to work with. You can also add your authentication mechanism in the specification file itself, to unlock advanced capabilities of the AKTO testing module. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Add API traffic to Akto using HAR file upload Learn how to uplaod API traffic data from HAR file to Akto ## Introduction [Akto](https://www.akto.io/) needs your staging, production or other environment's traffic to Discover APIs and analyze for API misconfiguration. It does so by connecting to one of your [traffic sources](/traffic-connector/traffic-data-sources). If you don't have access to staging or production environment, you can create API inventory using HAR file upload. {% hint style="info" %} Note that traffic from HAR File upload won't be automated like the native cloud connectors. {% endhint %} #### What is HAR file? The HTTP Archive format, or HAR, is a `JSON-formatted archive file format` for logging of a web browser's interaction with a site. The common extension for these files is `.har`. You can use this method if you quickly want to try out Akto. Akto can process HAR (Http Archive) files and populate inventory from them. ## Pre-requisites to add HAR file data to Akto * You should have an active [Akto](https://app.akto.io/) account. * Make sure you have HAR files generated from Chrome or Firefox available for upload. The maximum file size for upload is 25 MB. ## Steps to capture traffic in a HAR File Launch your Chrome browser and navigate to the web page for which you want to capture the traffic. For demonstration purposes, we will capture the traffic from {% @arcade/embed url="" flowId="0rereawiRT0wuVKtM9wS" %} ## Steps to upload HAR file in Akto dashboard Add the generated HAR file to your API collection by following the steps demonstrated below. {% @arcade/embed url="" flowId="tErOE27G2Zw8UI8DLqlD" %} ### What's next? Head to [API Discovery](/api-inventory/concepts/api-collection) to learn more. Once you start seeing inventory, you can run API Security tests on your APIs. See [Akto's test library](https://www.akto.io/test-library) to select tests you want to run on your APIs. ## Frequently Asked Questions (FAQs) **1. What is the limit on the size of HAR file upload?** The maximum size you can upload to Akto is 25 mb. **2. What is a HAR file, and how can I generate one in Chrome or Firefox?** HAR stands for HTTP Archive, and it is a format used to capture and store network traffic data during a web browser session. To generate a HAR file in Chrome or Firefox: *Steps for Chrome:* Step 1: Open Chrome Step 2: Right-click on the page and select "Inspect" to open Developer Tools. Step 3: Go to the "Network" tab. Perform the actions or interactions you want to capture (e.g., load a webpage). Step 4: Right-click on the network activity list and choose "Save as HAR with Content." *Steps for Firefox:* Step 1: Open Firefox. Step 2: Click on the `menu` icon (three horizontal lines) and select `Web Developer > Network` Step 3: Perform the actions you want to capture. Step 4: Click the `Export` button to save the captured data as a HAR file. ## Troubleshooting Guide **I uploaded 100 APIs, but I can only see 85 of them in the dashboard. Where are the missing APIs?** Akto processes and displays only APIs that have received a 2xx series status code in their HTTP responses. If an API request did not receive a 2xx status code (e.g., 3xx, 4xx, or 5xx), it may not appear in the dashboard. ## Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # API Import: WSDL in Akto You can import SOAP APIs into Akto by uploading a **WSDL (Web Services Description Language)** file. This allows Akto to automatically generate an API inventory for your SOAP APIs and start testing them.
*** ### How to Import To import your WSDL: 1. Go to **Quick Start** in the Akto dashboard. 2. Click **Connect** under **Manual >** **SOAP API**. 3. Follow the steps to upload your WSDL file using Postman. 👉 For detailed Postman integration steps, visit the guide: [Integrating Postman with Akto](/traffic-connector/manual/postman#integrating-postman) {% hint style="info" %} ✅ Enable “**Allow Akto to replay API requests if responses are not found**” to let Akto automatically retry missing responses and improve inventory accuracy. {% endhint %} Once the WSDL is uploaded, Akto will automatically populate your API inventory and you can start security testing. # Third Party Software # Connect Akto with Imperva ### Imperva Schema Import #### Overview * Import API definitions discovered by Imperva into Akto. * Creates or reuses an Akto API collection based on the hostname present in the Imperva export. * Runs asynchronously; once accepted, imported endpoints appear under API Collections. #### Key Features * Import from Imperva export JSON (single file). * Automatically creates a new collection named after the hostname if it doesn’t exist; otherwise reuses it. * Ingests endpoints with associated request data (method, path, headers, cookies, query params) from the file. #### Steps (in the Dashboard) 1. Go to Quick Start in the Akto Dashboard. 2. Open the Imperva import card under Manual Section OR Search for Imperva import. 3. Click File and choose your Imperva export json file. 4. Confirm the selected filename appears. 5. Click Upload. #### After Import * Navigate to Custom tab under API Discovery page. * Look for a collection named after the hostname present in the Imperva file. * Open the collection to see discovered endpoints. ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact `help@akto.io` for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Configure TLS on kafka We can configure kafka which is deployed as part of the hybrid runtime setup to use TLS for all producers. Steps: 1. Create `openssl-san.cnf` file with the content below. This file configures the SAN for the certificates we will create in the next step. ```bash [ req ] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [ req_distinguished_name ] CN = kafka-broker [ v3_req ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [ alt_names ] DNS.1 = akto-mini-runtime-mini-runtime.default.svc.cluster.local ``` 2. Create certificates stores and certificate authority. The script below will create `ca-cert.pem`, `server.keystore.jks` and `server.truststore.jks`. ```bash #!/bin/bash # Create the CA key openssl genrsa -out ca-key.pem 4096 # Create the CA cert openssl req -x509 -new -key ca-key.pem -out ca-cert.pem -days 365 \ -subj "/CN=MyKafkaCA" keytool -genkeypair -alias kafka-server \ -keyalg RSA -keysize 2048 \ -keystore server.keystore.jks \ -storetype PKCS12 \ -dname "CN=kafka-broker" \ -validity 365 \ -storepass password -keypass password keytool -certreq -alias kafka-server \ -keystore server.keystore.jks \ -file kafka-server.csr \ -storepass password openssl x509 -req \ -in kafka-server.csr \ -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \ -out kafka-server-signed.crt \ -days 365 \ -extensions v3_req \ -extfile openssl-san.cnf # Import CA keytool -keystore server.keystore.jks \ -alias CARoot \ -import -file ca-cert.pem \ -storepass password -noprompt # Import signed cert keytool -keystore server.keystore.jks \ -alias kafka-server \ -import -file kafka-server-signed.crt \ -storepass password keytool -keystore server.truststore.jks \ -alias CARoot \ -import -file ca-cert.pem \ -storepass password -noprompt ``` 3. Crete secret in kubernetes cluster to store these certificates. ```bash kubectl create secret generic kafka-certs \ --from-file=server.keystore.jks \ --from-file=server.truststore.jks \ --from-file=ca-cert.pem ``` 4. Install the helm chart for [hybrid-saas](/getting-started/quick-start-with-akto-cloud/hybrid-saas#helm-chart) and add the following attribute at the end of the helm install command. This will configure kafka to use TLS on port `9093`. ```bash --set mini_runtime.kafka1.useTls=true ``` 4. Configure producers to use TLS. 1. Traffic connectors which are generally deployed as daemonsets need to be configured to use TLS to send data to the kafka broker. Here is the updated configuration for the [kubernetes connector](/traffic-connector/kubernetes/kubernetes#setting-up-akto-daemonset-pod-on-your-k8s-cluster). Here, we've mounted the `ca-cert.pem` file on the file system for the daemonset. ```bash apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: mirror-api-logging image: aktosecurity/mirror-api-logging:k8s_agent env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_INFRA_MIRRORING_MODE value: "gcp" - name: AKTO_KAFKA_BROKER_MAL value: ":9093" - name: AKTO_MONGO_CONN value: "mongodb://0.0.0.0:27017" # additional configuration - name: USE_TLS value: "true" - name: TLS_CA_CERT_PATH value: "/app/certs/ca-cert.pem" volumeMounts: - name: kafka-certs mountPath: /app/certs volumes: - name: kafka-certs secret: secretName: kafka-certs ``` 2. Similar configuration can also be added to the [eBPF](/traffic-connector/ebpf/ebpf) traffic connector. ### Note: 1. You can disable hostname verification as well by adding `INSECURE_SKIP_VERIFY` environment variable in the traffic connector and setting its value as `true`. 2. You might need to change the value of `DNS.1` based on your deployment in step 4. In that case, recreate the certificates after deploying the helm chart and use them. 3. To customize the helm chart you may take reference from [helm-charts](https://github.com/akto-api-security/helm-charts/tree/master/charts/mini-runtime). ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Configure SASL Authentication on kafka We can configure kafka which is deployed as part of the hybrid runtime setup to use SASL as authentication for all producers and consumers connecting to kafka. Steps: 1. Install the helm chart for [hybrid-saas](/getting-started/quick-start-with-akto-cloud/hybrid-saas#helm-chart) and add the following attributes at the end of the helm install command. This will configure kafka to use SASL authentication: ```bash --set mini_runtime.kafka1.useSasl=true \ --set mini_runtime.kafka1.env.saslUsername= \ --set mini_runtime.kafka1.env.saslPassword=\ --set mini_runtime.zoo1.env.saslPassword= ``` 2. Configure producers to use SASL authentication. 1. Traffic connectors which are generally deployed as daemonsets need to be configured to use SASL authentication to send data to the kafka broker. Here is the updated configuration for the [kubernetes connector](/traffic-connector/kubernetes/kubernetes#setting-up-akto-daemonset-pod-on-your-k8s-cluster) with SASL authentication: ```bash apiVersion: apps/v1 kind: DaemonSet metadata: name: akto-k8s namespace: {NAMESPACE} labels: app: akto-collector spec: selector: matchLabels: app: akto-collector template: metadata: labels: app: akto-collector spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: mirror-api-logging image: aktosecurity/mirror-api-logging:k8s_agent env: - name: AKTO_TRAFFIC_BATCH_TIME_SECS value: "10" - name: AKTO_TRAFFIC_BATCH_SIZE value: "100" - name: AKTO_INFRA_MIRRORING_MODE value: "gcp" - name: AKTO_KAFKA_BROKER_MAL value: ":9092" - name: AKTO_MONGO_CONN value: "mongodb://0.0.0.0:27017" # SASL authentication configuration - name: IS_AUTH_IMPLEMENTED value: "true" - name: KAFKA_USERNAME value: "" - name: KAFKA_PASSWORD value: "" ``` 2. For Docker-based traffic connectors, add the following environment variables: ```bash # SASL authentication environment variables for Docker -e IS_AUTH_IMPLEMENTED=true \ -e KAFKA_USERNAME= \ -e KAFKA_PASSWORD= ``` 3. Similar configuration can also be added to the [eBPF](/traffic-connector/ebpf/ebpf) traffic connector. 4. For Docker-based traffic collectors, add the following: ```bash # SASL authentication environment variables for Docker -e KAFKA_AUTH_ENABLED=true \ -e KAFKA_USERNAME= \ -e KAFKA_PASSWORD= ``` ### Note: 1. For SASL authentication, ensure that your Kafka broker is configured to use SASL/PLAIN authentication mechanism. 2. Replace `` and `` with your actual Kafka credentials in both the traffic connector configuration and Helm chart parameters. 3. If you want to configure both TLS and SASL plain authentication to kafka, configure the env variables from above and follow the [KAFKA-TLS](/traffic-connector/kafka-tls-in-kubernetes) documentation 4. To customize the helm chart you may take reference from [helm-charts](https://github.com/akto-api-security/helm-charts/tree/master/charts/mini-runtime). ### Get Support for your Akto setup There are multiple ways to request support from Akto. We are 24X7 available on the following: 1. In-app `intercom` support. Message us with your query on intercom in Akto dashboard and someone will reply. 2. Join our [discord channel](https://www.akto.io/community) for community support. 3. Contact for email support. 4. Contact us [here](https://www.akto.io/contact-us). # Configure external kafka You can configure the mini\_runtime deployment to connect to an external Kafka broker instead of deploying a built-in Kafka instance. This is useful when you want to use a managed Kafka service or share a Kafka cluster across multiple deployments. ## Features * Support for external Kafka brokers (single or multiple brokers) * SASL/PLAIN authentication support ## Prerequisites Before configuring an external Kafka broker, ensure: 1. Your Kafka broker is accessible from your Kubernetes cluster 2. Required Kafka topics are created 3. If using SASL authentication, you have valid credentials 4. Network connectivity is established between Kubernetes pods and Kafka broker ## Configuration Steps ### Step 1: Set Up Your Kafka Cluster You can use a managed Kafka service from cloud providers or set up your own Kafka cluster. Below are links to official documentation for creating Kafka clusters on major cloud platforms: #### Cloud-Managed Kafka Services **Amazon Web Services (AWS):** * **Amazon MSK (Managed Streaming for Apache Kafka)** * [Getting Started with Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/getting-started.html) **Google Cloud Platform (GCP):** * **Apache Kafka** * [Apache Kafka on GCP](https://cloud.google.com/products/managed-service-for-apache-kafka?hl=en) **Microsoft Azure:** * **Azure Event Hubs for Apache Kafka** * [Event Hubs for Kafka Overview](https://learn.microsoft.com/en-us/azure/event-hubs/azure-event-hubs-kafka-overview) #### Create Required Kafka Topics Regardless of which platform you choose, ensure the following topics are created: **Required Topics:** * `akto.api.logs` (recommended: 3 partitions, replication factor 3 for production) * `akto.api.producer.logs` (recommended: 3 partitions, replication factor 3 for production) **Note:** Many managed Kafka services support automatic topic creation. If enabled, topics will be created automatically when the application first connects. ### Step 2: Determine Kafka Broker Address Obtain the broker address (hostname:port or IP:port) that is accessible from your Kubernetes cluster. Ensure the address is routable from within your cluster and not using `localhost`, `127.0.0.1`, or `host.docker.internal`. ### Step 3: Install Mini Runtime with External Kafka #### For Kafka Without Authentication: Create a values file (`custom-kafka-values.yaml`): ```yaml mini_runtime: useExternalKafka: true externalKafka: brokerUrl: ":9093" # External listener address username: "" # Empty for no authentication password: "" # Empty for no authentication ``` Install or upgrade the Helm chart: ```bash helm install akto-runtime ./charts/mini-runtime \ -f custom-kafka-values.yaml \ -n akto \ --create-namespace \ --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorToken="" ``` #### For Kafka With SASL Authentication: Create a values file (`custom-kafka-sasl-values.yaml`): ```yaml mini_runtime: useExternalKafka: true externalKafka: brokerUrl: ":9093" # External SASL listener address username: "" # Your Kafka SASL username password: "" # Your Kafka SASL password ``` Install or upgrade the Helm chart: ```bash helm install akto-runtime ./charts/mini-runtime \ -f custom-kafka-sasl-values.yaml \ -n akto \ --create-namespace \ --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorToken="" ``` #### Using Command-Line Parameters: You can also configure external Kafka directly via command-line parameters: ```bash # Without authentication helm install akto-runtime ./charts/mini-runtime \ --set mini_runtime.useExternalKafka=true \ --set mini_runtime.externalKafka.brokerUrl=":9093" \ --set mini_runtime.externalKafka.username="" \ --set mini_runtime.externalKafka.password="" \ --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorToken="" \ -n akto \ --create-namespace # With SASL authentication helm install akto-runtime ./charts/mini-runtime \ --set mini_runtime.useExternalKafka=true \ --set mini_runtime.externalKafka.brokerUrl=":9093" \ --set mini_runtime.externalKafka.username="" \ --set mini_runtime.externalKafka.password="" \ --set mini_runtime.aktoApiSecurityRuntime.env.databaseAbstractorToken="" \ -n akto \ --create-namespace ``` ### Step 4: Verify Connection Check that the mini\_runtime pods are connecting to Kafka successfully: ```bash # Get the pod name kubectl get pods -n akto # Check logs for successful Kafka connection kubectl logs -n akto | grep -i "kafka\|consumer" # You should see messages like: # "Successfully synced group in generation" # "Discovered group coordinator" # "Adding newly assigned partitions" ``` ## Troubleshooting ### Connection Refused Errors If you see errors like "Connection to node -1 could not be established": 1. **Verify Kafka is running:** ```bash docker ps | grep kafka docker logs ``` 2. **Test network connectivity:** ```bash # From inside a Kubernetes pod kubectl run test-connectivity --rm -it --image=busybox -- sh # Inside the pod: telnet 9093 ``` 3. **Check advertised listeners match your configuration:** ```bash docker logs | grep "advertised.listeners" ``` ### Authentication Failures If you see "Failed authentication" errors in Kafka logs: 1. **Verify credentials are correct** in your values file 2. **Check JAAS configuration** matches the username/password 3. **Ensure SASL mechanism is PLAIN:** ```bash kubectl get deployment -n akto -o yaml | grep SASL ``` ### DNS Resolution Issues If you see "UnknownHostException" errors: 1. Use IP addresses instead of hostnames 2. Test DNS resolution from within the cluster: ```bash kubectl run test-dns --rm -it --image=busybox -- nslookup ``` ### Pods Not Starting Check the deployment environment variables: ```bash kubectl get deployment -n akto -o jsonpath='{.spec.template.spec.containers[0].env}' | jq '.' ``` Verify these variables are set correctly: * `AKTO_KAFKA_BROKER_URL` * `KAFKA_AUTH_ENABLED` (should be "true" for SASL, absent for PLAINTEXT) * `KAFKA_USERNAME` and `KAFKA_PASSWORD` (for SASL) ## Environment Variables Set by Configuration When you enable external Kafka, the following environment variables are automatically configured: ### Without Authentication (PLAINTEXT): * `AKTO_KAFKA_BROKER_URL`: Your broker URL * `AKTO_KAFKA_BROKER_MAL`: Your broker URL * `KAFKA_AUTH_ENABLED`: Not set (defaults to false) ### With SASL Authentication: * `AKTO_KAFKA_BROKER_URL`: Your broker URL * `AKTO_KAFKA_BROKER_MAL`: Your broker URL * `KAFKA_AUTH_ENABLED`: "true" * `AKTO_KAFKA_SASL_MECHANISM`: "PLAIN" * `KAFKA_USERNAME`: Your username * `KAFKA_PASSWORD`: Your password # Concepts # Overview A quick overview of Akto's API security posture Akto's API security posture gives you a comprehensive view of all crucial information such as identified issues, data exposure risks and test coverage, giving you clear visibility into the security of your APIs and enabling proactive management of vulnerabilities.
### Key Capabilities #### 1. API Risk Scoring * Every API is **scored based on its risk level**, making it easy to prioritize remediation. * Helps security teams focus on the APIs that pose the greatest potential business and compliance risk. #### 2. Compliance Alignment with API Security * Maps APIs against **regulatory frameworks** such as GDPR, HIPAA, and PCI DSS. * Highlights compliance gaps and provides visibility into what needs fixing. * Enables **automated compliance checks** so that you can continuously validate security posture. #### 3. Misconfiguration Detection * Detects common API misconfigurations including: * Missing authentication * Weak authorization * CORS issues * Flags misconfigured APIs before attackers can exploit them. #### 4. Sensitive Data Detection * Identifies APIs that **expose or transmit sensitive data types** like PII, PHI, or financial data. * Helps ensure sensitive data is **properly secured and masked** where necessary. #### 5. Unauthenticated & Publicly Exposed APIs * Flags APIs that are accessible **without authentication controls**. * Identifies APIs that are **publicly exposed to the internet**, reducing attack surface. # Analysis The **Analysis tab** in Akto’s API Security Posture provides a prioritized list of security issues across your API ecosystem. It converts raw scan data into actionable insights by highlighting risks, affected endpoints, and recommended remediation steps. Instead of overwhelming teams with hundreds of alerts, **Analysis organizes issues into prioritized action items (P0, P1, P2)**, helping security and development teams focus on what matters most.
*** ### 🔎 Key Concepts 1. **Action Items** * Each issue is grouped into an **action item** (e.g., “APIs returning sensitive data” or “Missing authentication methods”). * Action items are designed to be **team-focused** so Dev, QA, and Security teams know exactly what to fix. 2. **Priority Levels (P0, P1, P2)** * **P0:** Immediate attention required, high business risk. * **P1:** High-severity issues with significant impact. * **P2:** Medium or low severity issues, often best handled in bulk remediation. 3. **Details per Action Item** * **Description** – Explains the issue and how many APIs are impacted. * **Team** – Suggests which team should handle remediation. * **Efforts** – Estimated effort (Low/Medium/High). * **Why It Matters** – Explains the risk (e.g., “Violates GDPR compliance” or “Exposes sensitive data”). 4. **Drill-Down View** * Clicking an action item reveals **specific endpoints** affected, with details such as: * Endpoint & method (GET, POST, etc.) * Sensitive parameters detected * Risk score * Type of issue (Sensitive Data, Auth, etc.) * Hostname *** ### ✅ Benefits * **Prioritization:** Focus on the highest-risk issues first. * **Collaboration:** Clearly assign issues to Dev, QA, or Security teams. * **Compliance Alignment:** Map risks to regulatory concerns like GDPR, PCI-DSS, HIPAA. * **Efficiency:** Reduce noise by grouping related issues instead of surfacing duplicates. # Concepts # API Endpoints View all API endpoints across all of your services in Akto. ## What is an API Endpoint? API endpoints are specific URLs or addresses within an API that serve as access points for different functionalities or resources. They define where and how data or actions can be requested or performed within the API, typically using HTTP methods like GET, POST, PUT, or DELETE. ## View an Endpoint Akto automatically updates your API inventory whenever new APIs are detected and allows you to view the endpoints. By viewing endpoints, you get a detailed overview of the API's capabilities. This includes details of **`header & response`** data and **`payloads`**, which shows how data is structured when interacting with the API. You can also identify any sensitive parameters that the endpoint has, such as passwords or personal identification numbers, ensuring that they are handled securely. In the demonstration below, we are viewing the details of the **`api/quantity/`** endpoint within the **“New Burp”** collection. Go to the **API Discovery > API Collection.** Select the **"New Burp"** collection, and click on **`api/quantity/`** Endpoint to view its details. {% embed url="" %} View an Endpoint {% endembed %} In the above demonstration, we observed that there are 14 request headers and 9 response headers which gives us a deep understanding of the interaction between the client and the server. By viewing the sample values of these headers, we see how data changes during API calls. You can also copy your API endpoint data for troubleshooting, debugging, version control, etc. For more information, refer to this [link](https://docs.akto.io/api-inventory/how-to/copy-api-endpoints-data). ### Tech Stack Detection with Akto-AI Akto automatically identifies the **underlying technologies** used by your APIs through intelligent traffic analysis powered by **Akto-AI**. For each endpoint, Akto displays detected stacks such as **AWS**, **Azure**, **MongoDB**, **Stripe**, and more—based on observed request headers, payload patterns, and infrastructure clues. This gives teams better visibility into their API environment and helps prioritize tests or security policies based on tech stack relevance.
# Meta Properties of API Endpoint View meta properties of an API endpoint in Akto. ## Auth Type Akto is designed to automatically detect standard authentication methods like JWT and Bearer authorization headers. This helps in identifying and addressing potential security threats. However, not all APIs follow standard practices. Hence, Akto also supports custom authentication methods. [Read more here](/api-inventory/concepts/auth-types). For example, if your API uses a non-standard authentication method, such as sending the auth token under a non-standard header, Akto provides the flexibility to set this up as a custom auth type. This means you can customize Akto to suit the unique requirements of your API. Even if your authentication method doesn't align with standard practices, Akto can still analyze and secure it properly. ## Access Type Akto provides visibility into your APIs, regardless of whether they're accessed from a public network or internally via microservices. This feature enables you to monitor and ensure that internal APIs aren't exposed to the public network, thus enhancing your security measures. [Read more here](/api-inventory/concepts/access-type). #### Real time updates For any new API, along with the path and schema, Akto will update meta properties such Auth type, Access Type and Sensitive Data exchanged by that API in real time. These properties are updated in real time for each API call processed by Akto. These meta properties (along with sensitive data exposure) are updated in real time with each API call. For example, say, an API initially was initially marked as "Private". When Akto sees even 1 call for that API coming from Public domain, Akto will mark the Access Type as "Public".\ Similarly if Akto converts an Auth type from "authenticated" to "unauthenticated" when Akto processes a successful call for that API without any auth type. Akto will keep adding more auth types in real time as it processes calls for that same API. --- [Next Page](/llms-full.txt/1)