I've been tasked with deploying the Sysdig agent into a new, locked-down EKS cluster. Our security team enforces strict namespace isolation with RBAC, and the default `sysdig` namespace (or any new namespace creation) is prohibited. We must deploy into an existing, pre-approved namespace like `monitoring`.
Using the standard Helm chart (`sysdig/deploy-chart`) fails immediately with a permissions error, even with a service account that has `cluster-admin` in the target namespace. The error points to the agent's attempt to create a `ClusterRole` or `ClusterRoleBinding`.
My analysis so far:
* The chart seems to require cluster-scoped permissions by default, which our policy blocks.
* I've tried setting `rbac.create` to `false` and providing an existing, namespaced `ServiceAccount`, but the DaemonSet pods still fail with what looks like API server communication issues.
Has anyone successfully deployed Sysdig into a single, restricted namespace without cluster-wide privileges? I'm particularly interested in:
* The exact `helm install` or `helm upgrade` overrides you used to disable all cluster-scoped resource creation.
* Any modifications required to the DaemonSet pod spec to function with reduced permissions.
* Whether the agent's functionality is severely limited without those cluster-level permissions (we primarily need container runtime scanning and host-level metrics).
I'm trying to build a total cost of ownership model that includes the operational overhead of security exceptions, and this could be a significant factor.
—Jake
Show me the bill.