3. Is there any way to enable endpoints to "consent" to new policies or queries? Since osquery is very powerful (reading process_envs, reading files from disk, sending curl requests, etc.), the Fleet server has near infinite control over the nodes. One way to mitigate the risk (either of attackers gaining control of the Fleet server or a malicious admin) would be to require consent to queries or new policies. For example by not using the configuration push of osquery, but saving the new osquery configuration in a git repo and letting users inspect the changes before they do a git pull to apply them. Would this be a workflow you could imagine to support?

This is an interesting idea! This wouldn't be possible for live queries, but you could certainly set things up so that there's some oversight on an organizational level to changes to the Fleet configuration by using a configuration file and requiring review before pushing changes, depending on your deployment pipeline. My biggest concern about allowing that level of discretion at the user level is that it would greatly hinder your ability to gather data in the event of a security incident, and make the information Fleet gathers less reliable. A host could be failing a critical policy, but not flagged because the user hasn't applied the change.

Hi Jen. This is something we can bring to our product team. In addition to what you suggest, we also have the concept of roles in fleet which can be used to mitigate the risk by limiting the abilities of possible malicious users in fleet https://fleetdm.com/docs/using-fleet/permissions. With the fleet premium tier, malicious users can be limited even further to only a specific team context. It is not as bullet proof as your suggestion but does provide a level of access base controls you can use to greatly limit a malicious users abilities.

Hi, thanks for your input! While I agree that roles or similar might help a bit, my threat model is more "what if an attacker gains control of the Fleet application or the server below it". Then they could use the access to endpoints for lateral movement (gaining secrets through "process_env" table etc.). I agree that my proposal would disable the live queries, but actually, this is the point of the proposal ^^ Maybe my usecase is less for incident response, but only for prevention. However I dont think that the proposal would stop policies if users dont update (dont consent), because the server could see that the endpoint is on an old version and flag this for everyone (and the user) to see. You wont see whats wrong, but you could see that it is an old version

Hey Jan, I hear your concern here. Fleet generally takes the position of providing control for admins, and transparency for end users. This already exists to some extent with Fleet Desktop, and we want to further improve that experience to let end users see what queries are running. Note that this would not be end users controlling which queries can run -- admins will maintain that control. For the security concern, there are a couple of mitigations: 1) Utilize the roles (Observer, Maintainer, Admin) to control what each user account can do (Fleet Premium has the Teams feature that allows applying different roles across different groups of hosts). 2) Monitor the activity log. This is available in the Fleet UI and stderr of the server. In Fleet Premium this can also be logged to any of Fleet's supported log destinations. Does this help? We are always open to suggestions from community users and we are able to provide extra prioritization to requests from customers.