This article intends to provide a brief overview of permissions in Cribl.Cloud. The full doc covering permissions can be found here.
Key Guiding Rules
For Cribl.Cloud, there are two key rules to help with thinking about permissions:
1. Permissions are purely additive. If there are multiple reasons someone should have a certain level of permissions for something, they get the most permissive.
Additionally, there isn’t a way you can use negative permissions or exclusions such as “Give read access to all, except member of team A”.
2. Permissions are inherited. Permissions from Organizations go to Workspaces which go to products and so on.
The third bonus rule/tip is something that takes some thinking about:
3. Read-Only is not the lowest level of permissions, User is the lowest. User level of permissions means that a member is an “Addressable entity” that can be granted complimentary permissions on top.
For example, if a member is granted Stream User permissions, they’d then have to have individual worker groups shared with them to be able to see them in the UI.
With those key rules in mind, the best advice for permissions is to start small with the fewest layers of permissions and add extra ones as required via team memberships.
Diagram for Cribl.Cloud Permissions
Explanation and Notes
The highest level grouping is that of an Organization. Organizations are attached to AWS regions and each organization has a unique random ID (Org-ID).
Organizations each ‘contain’ the Cribl product suite. Behind the scenes, these map to a specific AWS account. Within an organization, people (members) can be granted User, Admin or Owner permissions.
Organizational Admins and Organizational owners can make significant changes to an organization. For example, enabling/modifying SSO/changing workspaces, so these permission levels should be used rarely and access carefully controlled.
The next layer down is a Workspace. Each workspace offers a multi-tenancy capability with higher isolation. This makes it a good fit for different business units, subsidiaries or customers in a managed service. At a Workspace layer, people can be granted member, Admin or Owner permissions.
Again, Workspace Owners have a high level of permissions. This permission level should be carefully used and access controlled.
Within workspaces, members can be granted Product level permissions. These can be User, Read only, Editor and Admin.
Note that ‘User’ doesn’t give access to any Cribl Stream worker groups, these would have to be added additionally.
Finally, within each product, there are Resource level sharing options. These include Stream Projects or Search Resources. You can be very fine grained if you’d like!
Conclusion
This overview should give you a good introduction to Cribl.Cloud permissions. Please take a look at the docs if you’d like to learn more about this topic or reach out with any questions.