Hi All,
I have a question regarding Bigfix Fixlet/Task, that Can we restrict few fixlets of console that these can be deployed by using a password only.
No, we don’t have an option for that. You could copy the Fixlets into a new site and restrict operators’ access, or you could Globally Hide them so they are only visible to Master Operators though.
2 Likes
If it is custom content, you could try to add something that would prevent someone from running it without providing a correct password, but they would be able to figure out what the password was if they looked in the right spot.
Both of the options mentioned by @JasonWalker are better.
What is the use case?
1 Like
@JasonWalker@jgstew Thanks for your responses on this topic. New site option for this type of fixlets suited us so we used the same in our environment.
2 Likes
As much as its probably the only viable option, the one downside of creating copies is it increases the amount of admin overhead at maintaining the content, and could also add to the process cycles as the same fixlet may be being processed as many times as its been copied (computer site subscription depending of course). It would be great if there was a feature that could either give fixlet access as the fixlet level, or maybe just link existing fixlets to another site, similar concept to file system symbolic links, and that would then let those linked copied to be access but still change as the parent fixlet changes.
I see this an area we’ll be encountering more as we start to look at allowing groups that do not have Bigfix knowledge, access to the platform via WebUI and having to create multiple copies in site that restrict who can deploy what and to where. Maybe having a “public” site for shared content is an option for some deployment but that also risks the potential of exposing too much custom content to everyone.
One(?) challenge with the BigFix console is that it was not designed for use in a business process, with separation of duties, delegation of responsibilities, and approvals. This is why I like using API calls to actually take action, after all the approvals are made in a proper ITSM tool. Maybe the WebUI will provide a better platform for this, down the road.
1 Like
Maybe Bigfix 11 and the WebUI SDK (mentioned on the Bigfix Days EMEA today)
Hmm - interesting. I will be looking into that.
I kind of feel like it does handle that by assigning different operators access to different sites and computers. That is how I always used it as a customer. We would create a custom site for every group and those operators would only have write access to that site, and only their computers would subscribe to that site.
There is an optional 4 eyes approval flow in the console, but it is very clunky and requires actual physical input from the same device. It really only makes sense for break glass local admin accounts or very limited use cases.
This could be a path forward. Though the ability to create custom dashboards in the console exists today and is in some ways easier to do than the WebUI SDK, but the WebUI SDK is more capable.