Now that you know about the new RBAC feature available in Log Insight 2.5, I would like to walk you through an example on how to configure RBAC with real data.
Before You Begin
First, you need to decide how you want to restrict access to data. Data restriction can be done using any static field within Log Insight. This means you can leverage information such as the hostname and/or appname, or you could use any tags you have added to an event when leveraging the ingestion API. In this example, I will use ESXi data and will assume that I have ESXi hosts logging directly to the LI instance on which I wish to configure RBAC. For me, the business requirement is that I wish to have certain users restricted to only ESXi data.
Data Sets
The primary configuration step is creating data sets that meet the business requirements. If I am looking for the easiest and most precise way to configure a data set to return only ESXi data, I could use the hostname field.
Important: The source field could also be used given that all ESXi hosts are logging directly to LI. If ESXi hosts were going through a forwarder and to an external load balancer that sends traffic to LI then the source field may not be usable as it may not return just ESXi hosts. For more information, see this post.
In many environments, it is easy to determine which hosts are ESXi by the naming standard used for the hostname. Given this information, a hostname filter can be constructed:
While the above example will meet the business requirements, a problem may arise where the hostname filter may not match new ESXi hosts that are brought online. For example, let’s say my hosts were prefixed with datacenter information like us1-esx* and eu1-esx*. If eu2-esx* comes online next year, I will need to update my data set or the new hosts will not be properly shown to users. This adds management overheard.
Another way to tackle data sets is by using information that is specific to events, but not specific to environments. For example, if you look at the “All vSphere events” widget in the General – Overview dashboard of the vSphere content pack, it should be returning results that do not rely on the hostname as content packs are meant to be as generic as possible.
If you select the magnifying glass to run the query in Interactive Analytics, you can see the filters used to return the results:
As you can see, the filters rely on the appname field to return applicable results. This approach could also be used when defining data sets:
Now ESXi events will be returned properly even as the environment grows. It is important to note that using information within the event is not without limitations as well. For one, if you upgrade or run different versions of a piece of software the logging may change or be added to. The result is that information may need to be added or changed from the defined data set. Second, and perhaps more importantly, it is possible that while some information contained within events are unique others are shared by other systems. For example, if you look at the appnames returned by an ESXi host, you will see it is more than the appnames defined in the vSphere content pack:
The reason for the delta is because the additional appnames (e.g. syslog, crond) are not specific to vSphere and will return results for other systems like Linux operating systems. This means that some information may be missing from data sets when taking this approach.
Roles
Once you have defined the data sets you care about you then need to associate them with roles. My advice is to not change the default roles and instead define new roles when you have data sets you wish to associate. In general, a user role for each data set is recommended at the minimum.
In some environments, a second role for just dashboard access is also required. Once the new roles have been created, the can be associated with the proper users and/or groups.
Summary
When configuring RBAC be sure to:
- Understand the business requirements you are trying to solve
- Carefully consider whether to construct data sets based on environmental information (e.g. hostname) that might change or event information (e.g. appname), which may be incomplete
- Consider creating new roles instead of editing existing roles when assigning new data sets
- Be sure to test roles to ensure they return the results desired. With a single data set per role this is easy, but with multiple data sets per role/user/group this can become challenging.
© 2015, Steve Flanders. All rights reserved.
