A user would become a "Global user" if they have chronicle.globalDataAccessScopes.permit permission, so ensure you don't have this in your custom role.
A user would become a "Global user" if they have chronicle.globalDataAccessScopes.permit permission, so ensure you don't have this in your custom role.
Thanks for the reply, Chris.
As I dig deeper into this, my concern is that even if a user is not a "Global user", data RBAC can still easily be violated. Certain features that can do so are documented here (such as Looker dashboards, etc). But I'm also finding that there are other undocumented potential impacts and edge cases. For example, if enabling permissions required for parser UI management, the sample log provided when creating a custom parser doesn't abide by data RBAC scopes.
Are there plans to address some of these issues and/or eventually release a pre-defined Chronicle API Restricted Data Access Editor/Admin role?
Not an authoritative answer for the Product Team, but I think if something isn't on that link you mentioned then I would consider it may not be tested to be safe for Data RBAC, and like the example you've found it would then need raising up back to us for evaluation (I've mentioned the above item to Eng colleagues), but there is roadmap work to expand the coverage of feature for Data RBAC.
I don't know about a pre-defined roles either am afraid. I have thought for now it may be more effective to have some community Terraform IAM roles which could solve for this.
Not an authoritative answer for the Product Team, but I think if something isn't on that link you mentioned then I would consider it may not be tested to be safe for Data RBAC, and like the example you've found it would then need raising up back to us for evaluation (I've mentioned the above item to Eng colleagues), but there is roadmap work to expand the coverage of feature for Data RBAC.
I don't know about a pre-defined roles either am afraid. I have thought for now it may be more effective to have some community Terraform IAM roles which could solve for this.
Gotcha, thank you again for the responses and super useful blog posts. I'll continue just being careful when adding permissions for the time being.
Thanks for the reply, Chris.
As I dig deeper into this, my concern is that even if a user is not a "Global user", data RBAC can still easily be violated. Certain features that can do so are documented here (such as Looker dashboards, etc). But I'm also finding that there are other undocumented potential impacts and edge cases. For example, if enabling permissions required for parser UI management, the sample log provided when creating a custom parser doesn't abide by data RBAC scopes.
Are there plans to address some of these issues and/or eventually release a pre-defined Chronicle API Restricted Data Access Editor/Admin role?
I think you're mixing worlds though.
Feature RBAC could restrict viewing that isn't allowed through data RBAC (ie. dashboard data) We'd need some specifics to get those scenarios nailed down.
