Commit graph

5 commits

Author SHA1 Message Date
Brijesh Khunt
3fcdc062fa
XSOAR Connector (#212049)
## Summary

XSOAR action connector, enabling users to send alerts generated by the
rule detection engine to Palo Alto XSOAR for automation and remediation.

### **create connector**

![xsoar-connector](https://github.com/user-attachments/assets/14d9791b-0242-42b5-b9e4-975d7f6826cc)

### **test connector**
1. **test page**

![xsoar-params-test](https://github.com/user-attachments/assets/2bdd3b79-7f5f-4d52-836b-f458c390e55c)

2. **select playbook**

![xsoar-select-playbook](https://github.com/user-attachments/assets/23787b24-31b0-4f56-b451-0e8b42c79797)

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [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
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] 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)

### For maintainers

- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Sergi Massaneda <sergi.massaneda@elastic.co>
Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
2025-06-20 14:50:07 +02:00
Marta Bondyra
65bdf1ff8e
Optimize existing image assets with lossless compression (#223998)
## Summary

This PR applies **lossless compression** to all SVG and JPG/PNG assets
across Kibana using:

- [`svgo`](https://github.com/svg/svgo) — for optimizing SVGs  
- [`image-optimize`](https://www.npmjs.com/package/image-optimize) — for
JPG/PNG compression

‼️**Please scroll to ''Unknown metric groups" accordion to see what's
the gain for your code.**
<img width="542" alt="Screenshot 2025-06-18 at 13 24 20"
src="https://github.com/user-attachments/assets/191afb28-44fc-4551-9026-756a8385c66a"
/>

The goal is to reduce asset size and improve load performance without
compromising visual quality.

This PR achieves a **23 MB** reduction in asset size across all images
bundled in Kibana’s running code—meaning these compressed images
directly impact what ships in Kibana.
Some assets get bundled into chunks due to our bundling strategy but
might not actually be requested at runtime.

Additionally, I ran the same optimization script on the docs assets as a
harmless extra step, but those savings aren’t included in the 23 MB
total.

---

## Why

While working on Emotion rewrites, I noticed some SVGs seemed
unnecessarily heavy. That led to a broader investigation into our image
assets, and it turns out we’re not consistently optimizing them during
development or build.


---

## Notes

- Visual fidelity of optimized assets has been manually verified — no
visible differences
- The optimization is **lossless**, meaning no quality degradation
- Some assets (like large background images) could benefit further from
**lossy compression**

---

## Follow-ups / Ideas

1. **Automate compression in the dev/build pipeline**
   - e.g. add `svgo` as a pre-commit or CI step for SVGs
2. **Improve CI reporting**  
- Currently, bundle size diffs for images are hidden under "Unknown
metric groups" in the GitHub CI comment. We may want to make these more
visible.
   - 
3. **Audit large assets manually** — apply lossy compression where
appropriate
4. **Avoid redundant image loading**  
- e.g. background images on the login page are loaded again on the space
selector page since they’re bundled twice. I’m working on a separate PR
to address that.

## Snippets I used to apply the compression

```
# Find SVG files
find . -type f -iname "*.svg" \
  -not -path "*/node_modules/*" \
  -not -path "*/functional/*" > svg-files.txt

# Compress SVGs
while IFS= read -r file; do
  svgo "$file"
done < svg-files.txt
```

This snippet has been used for png and jpg, but the example below is for
png:
```
# Find PNG files
find . -type f -iname "*.png \
  -not -path "*/node_modules/*" \
  -not -path "*/functional/*" > png-files.txt

# Compress PNGs
while IFS= read -r file; do
  image-optimize -f jpg "$file"
done < png-files.txt
```
2025-06-19 16:44:13 +02:00
Lisa Cawley
f3115c6746
[DOCS] Update CrowdStrike and SentinelOne connectors (#219887) 2025-05-08 11:34:40 -07:00
Lisa Cawley
154ed1ef6f
[DOCS] Microsoft Defender for Endpoint connector (#219999) 2025-05-08 11:34:12 -07:00
Colleen McGinnis
5e5aff3b5b
[docs] Miscellaneous docs clean up (#215260)
Miscellaneous docs clean up including: 

* [x] Removing unused substitutions
* [x] Moving images per https://github.com/elastic/docs-builder/pull/774
* [x] ~~Clean up redirecting links~~
* [x] ~~Clean up asciidoc-style links~~
2025-03-25 12:57:00 +00:00