Skip to content
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

Closed
5 tasks done
jen-huang opened this issue Nov 28, 2024 · 6 comments · Fixed by #206074
Closed
5 tasks done

[Fleet] Restrict input types allowed for agentless integrations #202091

jen-huang opened this issue Nov 28, 2024 · 6 comments · Fixed by #206074
Assignees
Labels
QA:Needs Validation Issue needs to be validated by QA Team:Fleet Team label for Observability Data Collection Fleet team v8.18.0

Comments

@jen-huang
Copy link
Contributor

jen-huang commented Nov 28, 2024

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.

  • Create a blocklist constant for disallowed agentless input types: tcp, udp, winlog, http_endpoint, filestream
  • In the policy editor, when Setup technology is set to Agentless:
    • Hide the rendering of configuration for inputs that have type matching the blocklist
    • Ensure that these inputs are set to enabled: false
  • At the API level, throw an error if attempting to enable a disallowed input type
@jen-huang jen-huang added the Team:Fleet Team label for Observability Data Collection Fleet team label Nov 28, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@qcorporation
Copy link

@jen-huang, for your consideration, would it be better to have a definition within the policy_template as we do for agentless with deployment_modes for allowable inputs and outputs?
Should we allow our integration developers to control an integration deployment method instead of hard coding the allowable inputs and outputs for all integrations in different contexts?

@kpollich kpollich changed the title [UII] Restrict input types allowed for agentless integrations [Fleet] Restrict input types allowed for agentless integrations Dec 3, 2024
@kpollich kpollich added QA:Needs Validation Issue needs to be validated by QA v8.18.0 labels Dec 4, 2024
@jen-huang
Copy link
Contributor Author

@jen-huang, for your consideration, would it be better to have a definition within the policy_template as we do for agentless with deployment_modes for allowable inputs and outputs?
Should we allow our integration developers to control an integration deployment method instead of hard coding the allowable inputs and outputs for all integrations in different contexts?

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?

@cmacknz
Copy link
Member

cmacknz commented Jan 16, 2025

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".

@jlind23
Copy link
Contributor

jlind23 commented Jan 17, 2025

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.

@cmacknz
Copy link
Member

cmacknz commented Jan 17, 2025

I did not know we had something along those lines already. TIL.

viduni94 pushed a commit to viduni94/kibana that referenced this issue Jan 23, 2025
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QA:Needs Validation Issue needs to be validated by QA Team:Fleet Team label for Observability Data Collection Fleet team v8.18.0
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants