Open maxcold opened 10 months ago
eyalkraft
commented
9 months ago While this is indeed something we have to do, Since this token isn't the one used (we use the static enrollment token), and what it allows is only for the user to start their own agent enrolled to this same policy, We can revisit the priority of this task.
cc @tehilashn
seanrathier
commented
4 months ago I wonder if this ticket is still needed now. When we create agentless agents we are not executing the request from the client-side UI. We are instead calling the Agentless API in the Kibana Fleet server, and we are requesting the enrollment token in the backend.
@Omolola-Akinleye @maxcold, is this story still needed?
maxcold
commented
4 months ago @seanrathier the problem is that in the current Serververless implementation, the enrollment token for the Agentless Agent Policy is available in the response (not in the UI). You wrote When we create agentless agents we are not executing the request from the client-side UI. but we don't request it from the client side in the current agentless solution either. The question of whether this issue is still needed or not can be answered when we have the main flow covered. Then we can check if there is some enrollment token available for the managed agentless agent policy we create in the API response
User story As a Cloud Security stakeholder, I don't want agentless enrolment tokens to be available to users to avoid any security risk
Motivation
After making "Agentless" agent policy managed, the enrollment token is hidden from the Fleet UI, but still visible in the response (eg. in browser dev tools). We need to make sure the token we use for agentless infra is not visible for end users We also need to understand better, in which case the token is available. Eg., the token for Elastic Cloud agent policy (managed policy on ESS) is not available in response
Definition of done
Out of scope
Related tasks/epics
Team tag
@elastic/kibana-cloud-security-posture