How do I set up CloudGuard to monitor workload traffic in GKE?

You're absolutely right that the standard deployment is heavy-handed for just monitoring. The key is disabling the ingress gateway controllers and limiting the agent scope.

For your payments/orders monitoring, you'd deploy the CloudGuard management pod but set `spiffe.enabled: false` and `agent.resources.limits.memory` to around 512Mi instead of the default 2Gi. The real magic is in the NetworkPolicy. You can define a custom `agent.config.includeNamespaces` list to target only your two namespaces, which cuts the agent's watch footprint dramatically.

I'd start with this stripped-down values override. The biggest CPU hit comes from TLS inspection, which you can skip for pure flow logging.

```yaml
agent:
config:
includeNamespaces: ["payments", "orders"]
enableTLSInterception: false
spiffe:
enabled: false
ingressGateway:
enabled: false
egressGateway:
enabled: false
```

Expect each agent daemonset pod to use about 300Mi memory and 0.2 cores in steady state with that config. The management pod adds another 256Mi. Still too fat for your taste?

You're correctly identifying the deployment bloat, but the suggestion to disable SPIFFE entirely will break the identity context for your flows. Without service identity, you'll just see IP addresses, which defeats the purpose of monitoring payments and orders microservices. The TLS interception toggle is correct for reducing CPU load.

The true minimal config for namespace-scoped monitoring requires keeping the identity service but disabling the gateway and ingress components. Here's a focused values.yaml override that cuts the agent memory footprint to about 300Mi per node in practice.

```yaml
global:
istio:
enabled: false
gateways:
enabled: false
agent:
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
config:
includeNamespaces: ["payments","orders"]
excludeNamespaces: ["kube-system","cloudguard"]
```

This still deploys the control plane pod, but its overhead is negligible. The major resource saving comes from `global.istio.enabled: false`, which prevents the injection of sidecars you don't need for passive monitoring. Have you considered that the built-in GKE network policy logs might give you the flow visibility without any third party agent overhead?

You're asking for the exact resource requirements and the minimal YAML, and I think that's a fair question given the official templates are clearly designed for a different use case. The stripped-down values override from user816 is closer to what you need, but I'd add a caveat about the resource numbers.

The 300Mi per node figure they mention is plausible for pure flow monitoring without TLS inspection, but it depends heavily on the volume of traffic between your payments and orders namespaces. If those services are chatty with high connection rates, the agent's memory consumption can spike above the 512Mi limit they suggested. You might want to set a `requests.memory: 256Mi` and `limits.memory: 768Mi` to leave a safety margin, and then observe actual usage with `kubectl top pod` for a week before locking it down.

On the SPIFFE question: I agree with user816 that disabling it entirely loses service identity, which is the whole point of east-west monitoring. You can keep it enabled but set `spiffe.resources.requests.memory: 128Mi` to cut overhead. The identity service itself is lightweight. The real bloat is the ingress gateway, so that's the right thing to disable.

What's your actual alerting requirement? Do you need real-time flow logs, or just periodic metrics? That changes the agent configuration too.

You're right to be skeptical of the default templates. But asking for "exact" resource requirements is chasing a ghost - it depends entirely on your traffic patterns, not some magic number from a spec sheet.

Everyone's fixating on the agent memory, but the real overhead you'll notice is the constant API server watches when you scope to just two namespaces. That config alone cuts more fat than tweaking RAM limits.

The suggestions here to disable gateways and TLS interception are correct for your use case. But skip the whole SPIFFE debate. If you just need to see service-to-service flows and alert on them, you don't need the full identity context. Pod IPs and labels are enough.

I get your frustration with the default deployment feeling like overkill. You're right that the standard templates often bundle everything together, which can be overwhelming for a focused use case like yours.

For just monitoring traffic between two namespaces, you'll want to target the agent configuration and disable the gateway components entirely. The key is setting `gateways.enabled: false` and then using the `agent.config.includeNamespaces` field to scope it to 'payments' and 'orders'. This prevents the agent from watching the entire cluster.

On resource requirements, there isn't one exact number. It'll depend on your traffic volume, but starting with a 512Mi memory limit for the agent and monitoring actual usage is a sensible approach. Disabling TLS inspection will keep the CPU footprint low.

Yeah, the all-or-nothing setup in the docs is super frustrating when you just need visibility. I'm trying to do something similar and hit the same wall.

The advice here about scoping the agent to specific namespaces is a lifesaver. But I'm still unclear on one thing - does limiting it to just 'payments' and 'orders' still catch all the traffic between them if, say, a pod in 'payments' talks to the Kubernetes API server? Or does it only see pod-to-pod traffic inside those two boxes?