> _Article by Jiju Jacob, Director of Engineering at Revenera_
[_This is an update of Mr. Jacobs 05/23 post in his _[_Medium blog_]()_. He is a Director of Engineering at Revenera. _[_Revenera_]()_, born as InstallShield and now a Flexera company, helps software and technology companies use open source solutions more effectively, and provides software development, consulting, training and revenue recovery services. We are grateful to Jiju for updating his post for our blog and sharing it with our audience. You can connect with him via _[_LinkedIn_]()_._]
We have already moved into a world of APIs that provide monetizable functions for our customers. This necessitates us to front our APIs with an API Gateway that provides cross cutting functionalities such as logging, access control, routing, monitoring, etc. But what about protecting them against the real dangers out there? Protecting against API-specific threats requires a solution that is specifically built to protect APIs.
In this post, we will integrate a Wallarm solution into our API Gateway. We have selected the Wallarm [API Security platform](), which provides protection for both APIs and legacy web apps. And we are integrating this into a pre-existing [API Gateway]() laid out with Kong on our Kubernetes Cluster.
Though it is much easier to integrate a WAF like AWS WAF into the load balancer itself, Wallarm has a lot of benefits over it. Its built to support all API protocols (like [REST](), [GraphQL](), [gRPC](), etc.), it requires near-zero tuning and configuration, and can work across multiple cloud and K8s environments. This is what appealed to me to pick Wallarm in lieu of AWS WAF . With most security solutions (such as old-fashioned WAFs), we will need to add rules ourselves for protecting against newer attacks, whereas the Wallarm signature-less detection engine detects and protects against new attacks without you having to write new rules. Isnt that great?
## What are we building today?
They say words are clueless about what diagrams have to say!
Wallarm API Security Platform Scheme
The Wallarm API Security platform sits between the ALB (Application Load Balancer) and the API Gateway (Kong on Kubernetes). The Wallarm API Security platform is deployed as an ECS Cluster (AWS Fargate). The ALB does the SSL termination. The Wallarm ECS nodes are capable of either blocking or just monitoring and reporting all kinds of attacks that are directed towards your infrastructure.
We will automate our infrastructure building using Terraform. And I am just going to put up the most important parts of the code here, not everything.
**Building out**
Wallarm allows a free trial [here]() and you can use that to create an account. Using this account, we can configure our ECS cluster and we can also visualize the attacks on our infrastructure.
Older versions of Wallarm needed a username and password to be configured on the scanning nodes, but the newer version needs a token instead. We can easily retrieve this token from the Wallarm UI. After signup and sign-in, create a new node in the UI as shown.
On creation of a new node, a token will be generated, this will need to be saved securely.
In the gist below, we are creating secrets in AWS Secrets manager having WALLARM_API_TOKEN and this is passed to the terraform as the environment variable WAF_NODE_API_TOKEN. The value of this environment variable is the token that we just generated.
resource “aws_secretsmanager_secret” “waf_deploy_secretx” {
name = format(“waf_deploy_secret_%s”, var.ENV)
recovery_window_in_days = 0
}
resource “aws_secretsmanager_secret_version” “waf_deploy_secret_version” {
secret_id = aws_secretsmanager_secret.waf_deploy_secretx.id
secret_string = ) appeared first on [Wallarm]().Read More
References
Back to Main
