Been running CloudGuard on our GKE clusters for a year. It’s… fine. Does the job, but feels like wearing a suit of armor to run a marathon. Heavy.
The posture management and CSPM bits are solid. It finds the stupid misconfigs we all make. The Helm chart for the DaemonSet is a mess of values though. Deploying it via ArgoCD was an exercise in frustration. Their CRDs for network policies are okay, but you end up writing more `kubectl` patches than you’d like.
```yaml
# Example of the kind of override you'll need
agent:
configuration:
profile: "gke_standard"
resources:
requests:
memory: "512Mi" # They suggest less, don't.
```
The canary deployment model for their protected services? Clunky. Had to build our own GitOps pipeline around it because their workflow didn’t mesh with our Argo rollouts. The chaos monkey in me killed a few pods to test the auto-remediation. It works, but slowly. You feel the tax.
Pricing is what you’d expect. Not cheap. You’re paying for the Check Point name and a unified pane of glass. If you’re already deep in their ecosystem, it’s a no-brainer. If you’re a cloud-native shop building on Istio and a mature CI/CD pipeline, you’ll feel the friction.
Biggest win: the compliance reporting made the auditors happy.
Biggest loss: the agent overhead per node.
Yep, that tracks with our experience, especially the "suit of armor" feeling. It's a security suite first, and a cloud-native citizen second.
You're spot on about the memory requests. Their default profile is wildly optimistic for any real cluster with even moderate traffic. We saw constant OOM kills until we bumped it up similar to your example.
The real friction for us came with the GitOps integration. Their model assumes you're managing policy through *their* console, not as code in your repo. We ended up templating their CRDs with Kustomize and using a post-sync hook in Argo to inject some of their required labels, which feels hacky. I wish they'd embrace a more declarative, git-centric workflow.
And you mentioned the auto-remediation being slow - that's often the trade-off with these all-in-one tools. It's checking in with a central brain before taking action, which adds latency. For some things, a simple, fast NetworkPolicy applied locally is more effective, even if it's less "intelligent."
Prod is the only environment that matters.
That "suit of armor" comparison is perfect. I'm exploring this for a migration project and the weight is my main concern.
Your point about the Helm chart being a mess of values worries me. Did you find any specific pitfalls beyond the memory requests? Like, are the nodeSelector or tolerations settings manageable, or is that another patch-fest?
Also, when you say the auto-remediation is slow, are we talking minutes or tens of minutes? That could be a real problem for our SLOs.
learning every day
Your memory override is on point. We ran into the same OOM kills until we set hard limits, not just requests.
Their CRD-based policies have a similar issue. The abstraction leaks, and you're forced into patching for simple things like label selectors. For the canary model, our auto-remediation latency averaged around 8 minutes. That's too slow for any real-time SLO.
Data is not optional.