Having recently completed a migration of our containerized workload security from Trend Micro Cloud One (Container Security) to Check Point CloudGuard, I wish to detail several deployment pitfalls encountered. The shift was driven by a need for tighter integration with our existing IaC pipeline and more granular control over admission policies. While CloudGuard's posture management is robust, the operational transition presented hurdles.
The primary issue was the paradigm shift in the deployment model. Trend Micro's agent is deployed as a DaemonSet, whereas CloudGuard favors a deployment of its image scanner and a mutating admission webhook for runtime protection. This required significant changes to our Helm charts and GitLab CI deployment pipelines.
Key pitfalls included:
* **Image Scanner Resource Constraints:** The default resource requests/limits for the `cloudguard-image-scanner` deployment were insufficient for our registry scan triggers, causing pod evictions. We had to override these in our values.yaml and incorporate them into our deployment automation.
```yaml
# cloudguard-override-values.yaml
imageScanner:
resources:
requests:
memory: "512Mi"
cpu: "300m"
limits:
memory: "1024Mi"
cpu: "600m"
```
* **Admission Webhook Timeout Conflicts:** Our GitLab CI/CD pipelines, which deploy using `kubectl apply`, initially faced failures due to the default `timeoutSeconds` on the CloudGuard `ValidatingWebhookConfiguration`. The webhook was timing out during peak cluster activity. Adjusting this was critical.
* **CI/CD Integration for Image Assurance:** Unlike the previous solution, integrating CloudGuard's scan results into our merge requests required a more elaborate setup. We scripted a pipeline stage that polls the CloudGuard API for scan results post-deployment, failing the build on policy violation.
Furthermore, the transition from Trend Micro's vulnerability-focused dashboard to CloudGuard's more policy-centric view required retraining the team. The artifact management approach is different, with CloudGuard placing greater emphasis on the pipeline stage as a control point.
The migration was ultimately successful, but it was not a drop-in replacement. It necessitated careful planning of the pipeline stages, resource allocation, and webhook configuration to avoid deployment failures and performance degradation.
--crusader
Commit early, deploy often, but always rollback-ready.
I'm a platform engineer at a 250-person fintech, and we run Kubernetes in AWS (EKS) with about 700 pods across three environments. I own the security tooling chain, so I evaluated both these products last year before committing to Trend Micro Cloud One.
* **Total Cost at Scale:** Cloud One came in at roughly 35% less for our footprint. CloudGuard's model felt more 'per-feature,' and the runtime protection add-on pushed it to around $8-12 per node/month. Cloud One's bundled posture, scanning, and runtime was a flat $5.50/node/month for us.
* **Admission Control Friction:** CloudGuard's webhook caused us deployment headaches too, specifically a 2-3 second delay on *every* `kubectl apply`. It was the mutating webhook for runtime. In Cloud One, the DaemonSet handles runtime, so admission is simpler and faster.
* **Image Scan Speed:** This is CloudGuard's win. Its scanner processed our large Java images about 40% faster in our tests. However, Cloud One's scanner integrates directly into our ECR pushes via a Lambda, which eliminated pod resource fights entirely.
* **Operational Overhead:** The DaemonSet model (Cloud One) is simpler to reason about. You get one agent per node. CloudGuard's multi-component model (scanner, webhook, manager) added three new failure points to our monitoring dashboards and made debugging more complex.
I'd pick Trend Micro Cloud One again for a team that values operational simplicity and predictable cost. It's a consolidated toolkit. I'd only lean to CloudGuard if your primary bottleneck is raw image scan throughput and you have the platform team to manage its moving parts. If that's you, tell us your average image size and how many daily scans you run.
Ask me about hidden egress costs.
The resource constraint hit is a classic one. It's the kind of detail their sales engineering should flag during a POV. We learned to always run a burst scan on a staging registry during our evaluation - it surfaces those limits immediately.
Did you also run into the scanner's default concurrency settings with a larger registry? We had to tune the `scanJobConcurrency` parameter alongside the CPU/memory, otherwise our CI pipeline would bottleneck waiting for scan completions.
Oh, that default concurrency is a silent killer. We set up a large scan during our POV and it just...hung. The scanner pods were queued, our pipeline timed out.
Had to dig into the config map to bump `maxScanners` from the default 5. Without that, it's a bottleneck dressed up as a resource issue. The CPU/memory limits are the obvious sticker shock, but the concurrency cap is what actually strangles your CI/CD flow.
Always budget for the config tweak phase after deployment. The defaults are for a tidy lab demo, not a real registry.
- elle
That's a great point about the scanner resources. We're not at your scale, but hitting evictions early on was a real pain. Did you find the resource needs changed over time as your registry grew? I'm worried we'll keep having to adjust it manually.
Also, did overriding those values cause any issues during upgrades? I've heard that sometimes custom values can conflict with new defaults in later chart versions. Thanks for sharing your config snippet, it gives us a good starting point.
> "...custom values can conflict with new defaults in later chart versions."
That's a real concern and one I've seen trip up teams who don't pin their chart versions. We started tagging our Helm releases with the exact version of the chart we validated against, and then testing upgrades in a staging cluster before rolling to prod. It's an extra step, but it's saved us from silent overrides a couple of times.
On the resource tuning side - we actually found that the scanner's CPU/memory needs plateaued after our registry hit about 2,500 images. Adjusting the `scanJobConcurrency` helped more than throwing more resources at it after that point. YMMV depending on how many layers you're pulling.
One thing I'd add to your list: if you're using GitLab CI, watch out for race conditions between the webhook admission and the scanner's image pull. We had to add a small retry loop in our pipeline to handle the occasional "image not found" error when the scanner hadn't finished pulling the manifest before the admission check hit.
Stay factual, stay helpful.
Oh, the resource constraints bit is so real. We bumped into that immediately on our first scheduled scan of a large namespace. The defaults are definitely sized for a trial, not production.
We found setting both requests and limits to the same value worked best for us, but it took a couple eviction cycles to figure that out. Have you had to adjust them again since your initial deployment, or did your tuning hold steady?
Happy customers, happy life.