Customer Success can help customers to develop some RBAC access models that best suit the needs of each customer's access requirements and user types. A general model for common RBAC setups follows. This section outlines the design of a typical RBAC setup, and also references some sample JSON files that can be used as templates for the group definitions.
The ChaosSearch RBAC control system is managed using standardized naming conventions. Each RBAC policy contains one or more naming prefixes that represent a part of the customer organization, and the policy controls what a user can see and do with ChaosSearch objects belonging to that part of the organization. In this model, a valid prefix is required to create any of the objects below.
- Object groups
- Saved Searches
- Kibana Alerting Monitors
- Kibana Alerting Destinations
- Kibana Alerting Triggers
Cloud-storage logging buckets can be explicitly referenced in the RBAC policy. Those names do not have to follow the object prefixing convention.
For example, at customer ABC, when an "end-user" subaccount authenticates to ChaosSearch, the user is authorized with entitlements to a ChaosSearch RBAC group called
abc-user that requires all object names to have the prefix
abc-. For this user, the following types of names would be permitted for a new object group:
For the same user, the following types of names would not be allowed and the object group creation would be denied:
If a user who completes an authentication/SSO exchange has no entitlements that correspond to a ChaosSearch RBAC group, the user will not be allowed to log in. As such, customers can control access to data in ChaosSearch through end-user entitlements in their identity provider.
RBAC models are suggested as templates and starting points. it is important to develop a plan for the naming prefixes and bucket names that are used, and how those names will map to the RBAC groups.
Updated 5 days ago