I have
The application running in AWS EKS. The application frontend is exposed to the world over nginx ingress controller.
I need to
Enable AWS WAF and AWS Shield protection from Application and Network attacks with AWS WAF and AWS Shield.
Why do I need this?
AWS WAF helps to prevent malicious attacks such as SQL injection attacks and cross-site scripting, aligning with OWASP top 10 list. Complete list of features is available here.
AWS Shield is primarily used to protect from distributed denial of service (DDoS) attacks. It automatically detects threats to the environment
I know that
Nginx ingress controller creates Network Load Balancer for it's service.
Also I know the OSI model and the Application is level 7 while NLB is level 4. Such integrations are incompatible.
AWS WAF
doesn't work for Network Load Balancers
.
AWS WAF
is applicable only to the following resources
- Amazon CloudFront distribution
- Amazon API Gateway REST API
- Application Load Balancer
- AWS AppSync GraphQL API
- Amazon Cognito user pool
- AWS App Runner service
- AWS Verified Access instance
AWS Shield
.. comes with 2 subscription models Standard
and Advanced
.
AWS Shield Advanced provides expanded DDoS attack protection for
- Amazon EC2 instances
- Elastic Load Balancing load balancers
- CloudFront distributions
- Route 53 hosted zones
- AWS Global Accelerator standard accelerators.
AWS Shield Advanced incurs additional charges. The pricing breakdown can be found here. To be short: it costs ~$3k/month
with a yearly subscription so you need to pay $36k
to enable it for your AWS organization.
AWS Shield Standard is automatically included at no extra cost beyond AWS managed services. This means that you have no control over the configuration of Shield standard. It is used by AWS to protect the managed services like AWS Cloudfront distributions, route53 resolvers and global accelerator.
AWS CloudFront is the answer
Taking a look at the statements above we can use AWS Cloudfront to take advantage of built-in AWS Shield basic and enable filtering with AWS WAF Rules. The only trick is to disable caching where it is not needed. Really often caching can affect your workload experience.
Additionally you will need to ensure your NGINX Ingress Controller on EKS handles only traffic routed through CloudFront.
To achieve this you can Configure CloudFront to add a custom header (e.g., X-CloudFront-Secret
) to all requests and next update your NGINX Ingress configuration to validate this custom header.
Use the following annotation in the Ingress resource to set up a whitelist of allowed headers.
Example:
nginx.ingress.kubernetes.io/server-snippet: |
if ($http_x_cloudfront_secret != "YourSecretValue") {
return 403;
}
It has to be applied to every Ingress
resource in your workloads.
Alternatively you can apply the custom header validation globally at the controller level by modifying the NGINX configuration through a ConfigMap
or custom template.
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-configuration
namespace: ingress-nginx
data:
http-snippet: |
map $http_x_cloudfront_secret $valid_secret {
default 0;
"YourSecretValue" 1;
}
server {
if ($valid_secret = 0) {
return 403;
}
}
Bonus part
You can not be 100% confident that managed services will save you from all the problems. This is why I recommend to create the custom WAF ACL with the list of IPs that should be blocked from accessing your website.
In this case you will have a quick path to block IP address or IP CIDR if you see the suspicious activity coming form those to remain safe while you are sorting out what is missing in your security configuration.
Top comments (0)