Firewalling a Service Mesh with WebAssembly.pdf

MEETUP
Firewalling a Service Mesh with WebAssembly: Pick low hanging Fruits
for secure and performant self-servicing
SDA DevOps Team | 29.11.2023

SDA SE
SDA SE
• What we have now
• The Plan: 3 Layered Firewall
• Layer 1: IP-Based Rate-Limiting
• Layer 2: DevOps managed loose Istio Firewall
• Layer 3: Developer managed fine-grained Istio Firewall
• Closing words and questions
AGENDA
Thanks for attending
30.11.23 Firewalling a Service Mesh with WebAssembly 2

SDA SE
SDA SE
CLUSTER CONFIGURATION
11/30/23 3
Tools Cluster
Here we find all the tools we need to develop software based on industry best practices.
Includes the following tools, among others: Applications Cluster (Testing)
Software will be deployed over GitOps, by using ArgoCD
from the Tools Cluster
Applications Cluster (Integration)
from the Tools Cluster, after passing all tests in the application
Cluster (Testing)
Applications Cluster (Prod)
from the Tools Cluster, after passing all tests in the application
Cluster (Staging)
Log
Cluster Analysis Platt-
form
Security
Monitor
Cluster
Image
Scanner
Requirements/
Supporting Tools
We believe in IaC (Infrastructure as Code), these tools help us
deploy our Code/Infrastructure
Tools & Application Cluster (4 separated kubernetes cluster)
Cluster
Monitor
Log
DBs
Cluster
Monitor
Log
DBs
Cluster
Monitor
Log
DBs
Firewalling a Service Mesh with WebAssembly
What we have now

SDA SE
SDA SE
11/30/23 4
What we have now
Key Points to take away
• Many Clusters
• Like to pull Cloud-Features into k8s
• Plattform Tools
• Business-Logic Software
• DevOps doesn’t know upfront what will be deployed
• Terraform everything

SDA SE
SDA SE
Private Clusters Networking
30.11.23 5
What we have now
AWS Cloud
AWS account
VPC - 10.x.x.x/18
Private – tools-meetup-a - 10.x.x.x/22
Private – tools-meetup-b - 10.x.x.x/22
Private – tools-meetup-c - 10.x.x.x/22
Public – tools-meetup-a - 10.x.x.x/24
Public – tools-meetup-b - 10.x.x.x/24
Public – tools-meetup-c - 10.x.x.x/24
Private – dev-meetup-a - 10.x.x.x/22
Private – dev-meetup-b - 10.x.x.x/22
Private – dev-meetup-c - 10.x.x.x/22
Public – dev-meetup-a - 10.x.x.x/24
Public – dev-meetup-b - 10.x.x.x/24
Public – dev-meetup-c - 10.x.x.x/24

SDA SE
SDA SE
What we have now

SDA SE
SDA SE
What we have now
External-DNS needs
svc.Status.LoadBalancer.Ingress
for Route53 record content

SDA SE
SDA SE
11/30/23 8
What we have now
Key Points to take away
• Using Istio Service-Mesh
• Currently no Firewall
• Always Public/Private capabilities
• Manage Infrastructure from inside k8s
• External-DNS needs service status

SDA SE
SDA SE
3 LAYERS OF FIREWALL
The Plan
1. Point of first contact
• Implement Rate-Limit to keep malicious traffic out of the cluster
• Swap NLB for ALB
• Attach AWS WAF Rules to said ALB
2. Last DevOps managed point of contact
• Implement Software Firewall at Ingress-Gateways
• Use loose ruling to fit common use-cases
• Implement lower coverage of OWASP CRS
3. Deployment specific point of contact
• Implement Software Firewall as part of Deployment
• Implement, at best, all of OWASP CRS

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
• Guard from large number of requests from recent IPs
• Required for both Public/Private – so no CDN
• Istio is distributed, counting requests is hard
• AWS WAF is cheap, request agnostic

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
From this:

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
To this:

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
But:
• AWS LoadBalancer Controller only creates ALB for Ingress type resources
• AWS LoadBalancer Controller doesn’t create Service Status for ALBs
• Can’t manually set Service Status using Terraform

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
So:
• Create ALB using Terraform
• Allocate public EIP and cut private subnet IP from subnets
• Set IPs to externalIPs field of service

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
But:
• ALBs don’t support choosing Ips
• Only NLBs support attaching EIPs and private IPs

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
So:

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
But:
• External-DNS VirtualService does only read service status
and not externalIPs

SDA SE
SDA SE
IP-BASED RATE LIMIT
Layer 1
So:
• We need to add this via Open-Source PR
• Layer 1 plan has failed so far

SDA SE
SDA SE
DEVOPS MANAGED SERVICE-MESH FIREWALL
Service-Mesh
Layer 2
• dedicated infrastructure layer
• communication between microservices
• manage and control the interactions
• We use Istio – biggest player

SDA SE
SDA SE
Coraza WAF
Layer 2
• Web Application Firewall (WAF)
• 100% compatible with OWASP CRS v4
• written in Go - is a library at its core
• replace ModSecurity Engine
• Itself an Engine – useless without rules

SDA SE
SDA SE
OWASP CRS
Layer 2
• Generic attack detection rules, like OWASP Top Ten
• Can be loaded into compatible WAFs
• Customizable – using paranoia levels, exclusions etc.

SDA SE
SDA SE
ModSecurity policy
Layer 2
SecRule REQUEST_URI "@streq /admin" "id:101,phase:1,t:lowercase,deny"
• SecRule = Keyword
• REQUEST_URI = Variable e.g “/admin”
• “@streq /admin” = compare variable to string
• Id = id of the rule – they need to be unique
• phase:1 = request headers and body processing
• deny = action

SDA SE
SDA SE
Coraza Proxy WASM
Layer 2
• WAF WASM filter
• Implementing the proxy-wasm Application Binary Interface specification
• Event-driven streaming APIs
• In binary format and run in a sandbox (module)
• WASM modules gain adoption in container ecosystems like containerd and docker registries
• Can be loaded into Istio-Proxy (envoy)

SDA SE
SDA SE
Istio Ingress-Gateway WAF
Layer 2

SDA SE
SDA SE
Istio Ingress-Gateway WAF
Layer 2
• WAF implemented at Gateway level
• ALL services of whole Gateway now secured by the rules
• Activating full OWASP CRS at this level is nearly impossible in our case

SDA SE
SDA SE
DEVELOPER MANAGER FINE-GRAINED ISTIO FIREWALL
Service specific WAF
Layer 3
• As close as possible to service
• No host matching
• Each pod can get own WAF and own paranoia levels
• As close as possible to full OWASP CRS coverage
• Can even be used for service-to-service
• WAF can be tested in Pull-Requests

SDA SE
SDA SE
Layer 3

SDA SE
SDA SE
Take aways
Layer 3
• Layer 1 for generic rate-limiting
• Private endpoints can’t have CDN
• Possible in Istio but have to manage Redis Cluster
• Cloud Solutions scale great and are not too expensive
• Layer 2 for generic DevOps managed WAF
• Enforced least amount of OWASP CRS coverage
• Great if deployed services are unknown
• Enforcing great coverage in Layer 3 is hard
• Layer 3 for close at service WAF
• Very specific maximum OWASP CRS coverage
• Requires a lot of testing
• Is part of deployment and can be tested in PRs

SDA SE
SDA SE
Closing words
Layer 3

SDA SE
SDA SE
Contact us at devops@sda-se.com for further questions or specific code snippet
FINISHED
ANY QUESTIONS?
30.11.23 Titel der Präsentation 31

Firewalling a Service Mesh with WebAssembly.pdf

Recommended

Recommended

More Related Content

Similar to Firewalling a Service Mesh with WebAssembly.pdf

Similar to Firewalling a Service Mesh with WebAssembly.pdf (20)

Recently uploaded

Recently uploaded (14)

Firewalling a Service Mesh with WebAssembly.pdf