-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Fleet] Restrict input types allowed for agentless integrations #202091
Comments
Pinging @elastic/fleet (Team:Fleet) |
@jen-huang, for your consideration, would it be better to have a definition within the |
The main reason for hard coding allowed inputs and outputs for agentless integrations is to mitigate undue burden for integration developers, but I am curious if you have an example of an agentless integration which might not want to follow the proposed blocklist? |
I wonder if as a follow up we should think about tagging the capabilities or categories of integrations directly in the package spec, so that one day this implementation is "prevent integrations that declare they need egress capability" instead of "prevent a hard coded list of integrations directly in Kibana". |
There is already a capabilities field that we could most probably piggy back on - elastic/package-spec#809 but maybe this is already what you are referring to. |
I did not know we had something along those lines already. TIL. |
…ns (elastic#206074) Closes elastic#202091 ## Summary Disallow some egress-specific inputs for agentless integrations. - In the policy editor, when Setup technology dropdown is set to Agentless, hide the rendering of configuration for inputs that have type matching the blocklist and ensure that these inputs are set to `enabled: false` - `tcp, udp, winlog, http_endpoint, filestream` should be disabled when `supports_agentless: true` - At the API level, throw an error if attempting to enable a disallowed input type ### Testing Simulate agentless env with following setup in `kibana.dev.yml`: ``` xpack.cloud.id: 'anything-to-pass-cloud-validation-checks' xpack.fleet.agentless.enabled: true xpack.fleet.agentless.api.url: 'https://localhost:8443' xpack.fleet.agentless.api.tls.certificate: './config/certs/ess-client.crt' xpack.fleet.agentless.api.tls.key: './config/certs/ess-client.key' xpack.fleet.agentless.api.tls.ca: './config/certs/ca.crt' ``` -Apply [this patch](https://gist.github.com/jen-huang/dfc3e02ceb63976ad54bd1f50c524cb4) to prevent attempt to create agentless pod (the agentless policy creation fails without the patch) - Install the following test integration, that has a bunch of different inputs to simulate this specific case and is enabled for agentless (it shows the setup technology as well) [agentless_package_links-0.0.2.zip](https://github.com/user-attachments/files/18425895/agentless_package_links-0.0.2.zip) ``` curl -XPOST -H 'content-type: application/zip' -H 'kbn-xsrf: true' http://localhost:5601/YOUR_PATH/api/fleet/epm/packages -u elastic:changeme --data-binary @agentless_package_links-0.0.2.zip ``` - Navigate to the integrations page, find the above integration and test that switching between agent-based/agentless the enabled inputs change as follows: <img width="1288" alt="Screenshot 2025-01-15 at 15 30 28" src="https://github.com/user-attachments/assets/6abd45d7-1bd8-465a-af29-4c34940b32e3" /> <img width="1072" alt="Screenshot 2025-01-15 at 15 31 18" src="https://github.com/user-attachments/assets/6957562f-08a6-403a-8725-1a654e443537" /> - Verify that the preview flyout has the correct inputs based on the selected deployment mode <img width="863" alt="Screenshot 2025-01-15 at 15 32 19" src="https://github.com/user-attachments/assets/ceca1f5d-249c-4ee1-9295-6f01ae21fdb4" /> <img width="862" alt="Screenshot 2025-01-15 at 15 33 33" src="https://github.com/user-attachments/assets/f43562d7-633e-4f0a-bfc1-19e89aef7659" /> - Verify that the api throws an error when attempting to enable any of the disallowed types <img width="1774" alt="Screenshot 2025-01-15 at 15 36 03" src="https://github.com/user-attachments/assets/2b4d24a3-5adc-4ab2-bbad-83b44d348763" /> ### Checklist - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: Elastic Machine <[email protected]>
When integrations are hosted and managed using the agentless deployment_mode (
supports_agentless: false
on the integration policy object), some special security handling is invoked. From a security perspective, we treat the deployment as if it could run arbitrary malicious code and be controlled by the user. Its network is isolated, ingress is disallowed and only specific egress is allowed.This means that many inputs won't be user-useable. These inputs include tcp, udp, winlog, http endpoint, and filestream. We need to disable and hide these inputs from being configured in agentless mode.
tcp
,udp
,winlog
,http_endpoint
,filestream
Setup technology
is set toAgentless
:type
matching the blocklistenabled: false
The text was updated successfully, but these errors were encountered: