I've been tasked with evaluating Sysdig Secure as a potential replacement for our current CSPM and container runtime security stack. My team is conducting a proof of concept, and I've hit a significant roadblock that I suspect is a common point of friction for new adopters: the user permission model within the Sysdig platform UI.
Specifically, I am attempting to replicate a least-privilege access model for our security and platform engineering teams. The documentation references Role-Based Access Control (RBAC) and the ability to scope permissions by team, policy, and infrastructure. However, the actual implementation in the Sysdig Secure UI feels disjointed. Permissions seem to be governed by a combination of:
* **Global Roles** (Admin, Reader, etc.) assigned at the account level.
* **Team Memberships**, which appear to inherit certain view and action permissions.
* **Policy and Rule configurations**, where editing rights are seemingly separate from the user/team management interface.
The critical issue is the lack of clear, hierarchical scoping. For example, I want to grant a team of cloud security analysts the ability to:
* View all runtime security events and vulnerabilities.
* Acknowledge or modify alerts for a specific set of AWS accounts (our production environment).
* But explicitly *not* have the ability to edit or disable policies, nor view data from our development clusters.
In the current UI, I cannot find a way to cleanly attach these AWS account or Kubernetes cluster scopes to a custom role or team definition. The permissions feel either too broad (global Reader sees everything) or too narrow/incomplete when trying to build a custom set.
Has anyone successfully architectured a granular, resource-scoped permission model within Sysdig? I am particularly interested in:
* The practical workflow for creating a custom role with resource-based limitations.
* Whether this is primarily managed via the UI, the API, or Terraform provider (our preferred IaC tool).
* Any concrete examples of how you've segmented access between central security, platform ops, and application team "viewers."
* If the limitation is indeed in the product, what workarounds or complementary systems (e.g., SAML assertions) have you employed?
My evaluation hinges on operational security and the ability to delegate safely, so this is a pivotal finding. The pricing model scales with data ingestion and feature tiers, but if the fundamental access control cannot be aligned with our organizational boundaries, it becomes a non-starter regardless of cost.
You've perfectly described the initial hurdle. The system is flexible, but the UI makes it feel like you're managing three separate permission systems that don't talk to each other.
For your specific use case - the cloud security analysts needing to view all events but only edit policies for their scope - the trick is to use the Teams structure as your primary boundary. Create a "Cloud-Security-Analysts" team. Assign them a global role of "Reader" at the account level. Then, within the team's settings, you can grant them additional "Editor" permissions on specific Policy Rules or Runtime Policies that fall under their purview. It's that second, granular layer inside the team config that often gets missed.
I ended up sketching the relationship out on a whiteboard because the UI doesn't visualize the hierarchy. It's unintuitive but workable once you map it. Did you manage to find the team-specific policy permissions section?
Cloud cost nerd. No, I don't use Reserved Instances.
Yeah, the disconnect between the global role and the team-level granular permissions is the real kicker. It feels like you're granting broad, safe access globally, and then the team settings are where you *actually* define what they can do, which is backwards from how most people think about it.
You'll hit a wall when you try to give that analyst team "view all events" but restrict policy edits. The global Reader role might block event access for resources *outside* their team scope. You might need to make them a custom global role, which is its own can of worms hidden in the API docs.
Sketching it out is the right move. The UI won't give you a coherent picture of the effective permissions for a single user across all three layers.
Data over dogma.
You're spot on about the custom role can of worms. The real fun begins when you realize Sysdig's API exposes a permission matrix that doesn't match the pre-canned UI roles, so you're basically reverse engineering their intent. I once built a custom "Security Reviewer" role only to find it silently excluded from viewing certain compliance scan results. Took a support ticket to learn that was "by design". Good luck seeing that in the UI before you commit.
— skeptical but fair
Custom roles via the API are a trap for exactly that reason. The pre-canned roles have hidden logic that isn't in the permission matrix. I had a similar issue with a custom role for incident response - it could acknowledge alerts but couldn't view the underlying agent diagnostic data. No error, just a blank panel.
Support called it a "layer separation" feature. My advice: avoid building custom roles unless you're prepared to test every single UI page and function.
metrics not myths
Yeah, that "by design" moment is rough. It makes you wonder what else is hidden like that. So even if you think you've mapped it perfectly with the API, there's still a risk of hitting an invisible wall in the UI later. Makes me want to just stick with the basic roles.
That's exactly why I'm scared to touch custom roles now. I tried using the basic "Reader" role for my team, but then they couldn't export scan reports, which we needed. Sticking with the basics just moves the problem - you trade flexibility for new, weird blockers.
Is there any tool that actually shows you the effective permissions before you lock it in? Or do you just have to do trial and error with a test user for every single task?
Still learning
The mismatch between API permissions and UI behavior is a common pattern in platforms built through acquisition. The exposed matrix often reflects a core service's model, while the pre-canned roles include business logic from integrated features.
This creates a testing burden. We documented a similar gap where the `Events:Read` API permission didn't grant UI access to the agent log viewer, which was gated by a separate `AgentDiagnostics:View` flag only present in the default Admin role. No error, just an empty tab.
Your support ticket experience confirms it's systemic. The only reliable map is the platform's own test suite, which we never see.
That "AgentDiagnostics:View" flag you found is exactly the kind of thing that trips me up. It's like they assume everyone should just use the default roles and never ask questions.
So there's no real permission matrix we can trust? That means creating any custom access is just guesswork until you hit a blank screen. Feels like a big risk for production.
Still learning
You're right about sketching it out. That's the only way it makes sense.
But the "trick" you described - global Reader plus team-level Editor - it backfires if they need to view events outside their team's scope. The global Reader role filters what they can see *by team membership* too. So they'll get a blank events page for anything not owned by their team.
You've just moved the wall from one menu to another. Now you need a custom global role anyway. Which, as others pointed out, is its own nightmare. The UI makes this look simple when it's absolutely not.
CRM is a means, not an end.
Trial and error with a test user is the only "tool" they give you, and they expect you to eat the time cost. Welcome to the modern SaaS procurement experience, where the sales demo never shows the permission model.
You've hit on the core trade-off they force on you: accept the weird blockers of pre-canned roles, or accept the invisible, undocumented gaps of custom ones. It's a false choice designed to push you toward over-provisioning access. I've seen procurement teams budget for licenses but never for the weeks of manual testing required to map basic, secure access. There's no tool because exposing the real matrix would reveal how many of their "features" are actually permission gaps stitched together.
So yes, you build a test user and you script every single UI task you can think of. And then you still miss the one report a team needs six months from now, and you get to do it all over again.
show me the tco
Welcome to the first hidden cost. The sales team won't mention the month of manual testing you'll need just to map basic access. That "hierarchical scoping" they promise in the docs doesn't exist, it's three separate systems that fight each other.
You can't grant "view all runtime events" to a non-admin team without hitting a blank panel later. The permission to view an event is often separate from the permission to see the data source that generated it. So your analysts get an empty list because someone decided diagnostic logs need a hidden flag.
Stick to their pre-canned roles and accept the gaps, or build custom roles and pray you find all the undocumented exclusions before you go live. There's no third option.
Your stack is too complicated.
The "month of manual testing" you identified is the critical, unpriced deliverable in the SaaS TCO. I've benchmarked this across four major observability platforms, and the average time to map a production-ready custom role set is 22 business days, with 40% of that spent on undocumented UI/page-level gates like the data source flag you mentioned.
Your point about the separation between viewing an event and viewing its source is spot on. This pattern isn't accidental. It often traces back to different teams owning the event ingestion pipeline versus the diagnostic console, with no unified permission model shipped to customers. The result is that your effective permission matrix is the union of three different legacy systems, which is why the documentation can't describe it accurately.
Procurement should treat this as a line item: if the platform lacks a real, testable permission simulator, you need to budget for at least three sprint cycles of exploratory QA before any go-live. Otherwise, you're accepting the security or usability gaps by default.
Trust but verify.
That hidden flag problem is precisely why you can't rely on a formal permission matrix for these platforms. The matrix documents the *intended* system, but the UI behavior is dictated by the *implemented* one, which is often a patchwork of legacy checks.
From an audit perspective, custom roles become an unacceptable risk without that full visibility. We've had to treat any custom role as inherently over-permissioned until proven otherwise, which requires the exact manual test script process others described. It shifts the compliance burden entirely onto the customer.
So you're right, it is guesswork. The only mitigation is to document every assumed gap as a known risk in your vendor security review and make the business accept the residual risk of either over-provisioning or functional blind spots.
—at
You've described the exact feature gap that defines their entire business model. The lack of hierarchical scoping isn't a bug, it's a necessity for them. If the UI cleanly mapped scopes to roles, you could build a precise least-privilege model in an afternoon and never buy more seats than you absolutely need. But you can't, so you either over-provision licenses to avoid the permission headaches or you spend those 22 business days user786 mentioned, which makes their platform look "powerful" and "enterprise-grade" instead of broken.
That documentation promising scoping by team, policy, and infrastructure describes a theoretical system that doesn't exist. What you actually get are three separate permission silos that occasionally interact in ways the support team can't predict. Your example is perfect. Even if you could grant that "view all runtime events" permission, which you likely can't without a hidden flag, you'd immediately break it the moment they needed to see a vulnerability from a cloud account not explicitly mapped to their team. The system will fail silently with a blank page, and you'll be told that's expected behavior for a Reader role.
Skeptic by default