Cloud Armor with Google Cloud GKE

This blog post was co-authored by Sakshi Bhutani(Medium)
MicroServices and the Expanded Attack Surface
MicroServices architectures break down applications into smaller, independently deployable services. Each service communicates with others through APIs (Application Programming Interfaces). While this creates flexibility and scalability, it massively increases the number of potential attack points. Each API endpoint is a possible gateway for hackers to exploit when exposed to the internet.
The Risks of API Vulnerabilities
- Data Breaches: Poorly secured APIs can allow unauthorized access to sensitive data like customer information, financial records, or intellectual property. This can have devastating reputational and financial consequences.
- Denial of Service (DoS) Attacks: Attackers can flood APIs with requests, overwhelming them and making your services unavailable to legitimate users.
- Injection Attacks: Hackers can manipulate API inputs to inject malicious code, potentially taking control of systems.
- Exploitation of Business Logic Flaws: APIs can have flaws in the way they process and validate data. Attackers who find these flaws might be able to perform actions they shouldn’t be authorized to do.
Best Practices for API Security in Microservices
- Authentication and Authorization: Implement robust authentication (verifying user identity) and authorization (controlling access rights) mechanisms like OAuth2 or OpenID Connect.
- Input Validation and Sanitization: Rigorously validate all data coming into your APIs to prevent injection attacks.
- Rate Limiting: Protect against DoS attacks by limiting the number of requests an individual user or IP address can make.
- Encryption: Use TLS/SSL to encrypt communication between services and clients, ensuring that data can’t be intercepted in transit.
- Monitoring and Logging: Track API usage patterns to detect anomalies or malicious activity — this is key for proactive response in case of a potential breach.
Cloud Armor is a Google Cloud service that acts as a shield for your web applications and services. It offers defense against Distributed Denial of Service (DDoS) attacks, which aim to overwhelm your systems with malicious traffic. Beyond DDoS protection, Cloud Armor provides a Web Application Firewall (WAF) that includes preconfigured rules designed to mitigate common web application vulnerabilities, such as those outlined in the OWASP Top 10 (e.g., SQL injection, cross-site scripting).
Key Benefits of Cloud Armor
- Always-On Protection: Cloud Armor safeguards your applications against network and protocol-based DDoS attacks without requiring manual intervention.
- Web Application Security: Cloud Armor’s WAF capabilities help defend against web exploits that could compromise your applications or steal sensitive data.
- Google-Scale Defense: Cloud Armor leverages the same infrastructure Google uses to protect its own services like Search and YouTube, providing you with robust defense capabilities.
- Managed Option: The Cloud Armor Managed Protection Plus tier offers curated rule sets, expert support, and predictable monthly pricing.
Let’s look at how we can use Cloud Armor with GKE to secure our APIs:
- Login to the GCP Console and open the Cloud Shell.
- Let’s create the cluster. Please replace the VPC Name, Subnet Name and region name approriately.
gcloud container clusters create gateway-test --gateway-api=standard --enable-l4-ilb-subsetting --zone asia-south1-a --node-locations asia-south1-a --num-nodes=2 --spot --network=cloud-demos-gcp-vpc --subnetwork=cloud-demos-gcp-vpc-subnet
- Let’s open the firewall for port 80 and we will be exposing the service for the same.
gcloud compute firewall-rules create cloud-demos-gcp-80 --allow=tcp:80 --description="Allow incoming traffic on TCP port 80" --direction=INGRESS --network=cloud-demos-gcp-vpc --source-ranges="0.0.0.0/0"
- Run the below command to get the cluster credentials
gcloud container clusters get-credentials gateway-test --zone asia-south1-a --project cloud-demos-gcp
- You can clone the github repository
git clone https://github.com/jainsourabh2/googlecloudplatform.git
cd googlecloudplatform/gke/cloud-armor-gke
- Create the namespace
kubectl apply -f manifests/namespace.yaml
- Deploy the pods and services.
kubectl apply -f manifests/bookstore.yaml
- Create the Healthcheck Backend Config.
kubectl apply -f manifests/backendconfig-default-backend.yaml
- Deploy the Gateway
kubectl apply -f manifests/gateway-external.yaml
- Deploy the Routes
kubectl apply -f manifests/route-external-bookstore-en.yaml
- Create the Security Policy and Rule. The below policy rule just blocks all requests coming to the API call.
gcloud compute security-policies create block-all-http-requests --description="Block all HTTP requests"
gcloud compute security-policies rules create 1000 --action=deny-403 --security-policy=block-all-http-requests --description="block all http requests" --src-ip-ranges=0.0.0.0/0
- Now let’s associate the above created security policy to the backend service for the deployed GKE service.
kubectl apply -f manifests/backend-security-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: <<name of this backend policy(any name you can give)>>
namespace: <<namespace>>
spec:
default:
securityPolicy: <<security policy name>>
targetRef:
group: ""
kind: Service
name: <<service name>>
As you can see above , we have linked the security policy name and the the service name.
- Fetch the external IP name using the below command. This command will help you get the IP address of the load balancer.
kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}" -n bookstore-en
You can now run the below command to validate that you are getting the desired output.
curl -X GET http://<<IP address from the above step>>/en
You should get the below output indicating that the Cloud Armor policy has been applied on the service. As we have applied the Cloud Armor policy to block all the requests , we are forbidden to access the API endpoint.
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden
You can view the Cloud Armor logs to confirm the hits are coming and are blocked by the Cloud Armor Security Policy.
gcloud logging read 'SEARCH("block-all-http-requests") AND resource.type="http_load_balancer"'
NOTE : If you are not able to see the logs, ensure that the logs are enabled for the backend service associated to the load balancer and sampling rate is set to 1.
Please do reach out if any queries and Happy GCPing!