-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secrets do not work in server event artifacts #3885
Comments
The reason this does not work is because the server monitoring runner is running as an internal server user called VelociraptorServer. The reason it works for regular server artifacts is because for individual server artifacts, the runner assumes the identity of the user that launched the collection: So the collection is running under the identity of the user admin so the VQL has access to all secrets given to admin. For event artifacts they run constantly and we dont retain the identity of the user which initially added the collection. Therefore the monitoring query is always running with server level access (you can verify this using the whoami() VQL funcion). Therefore it is not possible to access secrets that way. Should we run the event artifacts under the identity of the user that added them? maybe so but this makes it a bit blurry because event artifacts are meant to be running all the time and it may not make sense to relate them to specific users. As for permissions and ACL it does not matter because the internal service is running as admin level so all ACLs will pass but secrets are a bit special because they are given to a user (its not an ACL as such). One possibility is to allow internal server runners to access all secrets automatically - another is to deliberately give them the secret (then it is a choice). For that to work we should add VelociraptorServer as a special username in the secrets dialog |
Thanks for the explanation. I understand the choices made.
This sounds like a good solution. |
I have a server artifact that uses a HTTP secret. This works just fine. However, calling this artifact from a server event artifact consistently results in the error "http_client: Permission Denied accessing secret […]". It appears that the secret somehow isn't accessible in server event artifacts.
This is not an issue with secrets in artifacts being called by other artifacts, sine calling the server artifact from another (non-event) server artifact also works fine.
The text was updated successfully, but these errors were encountered: