## Summary
Close https://github.com/elastic/kibana/issues/183686
Adds a new sorting option "Recently viewed". Recently viewed dashboards
will be shown at the top of the list. The remaining dashboards are
sorted by last updated at.
- This is a default option unless another option was explicitly selected
before (and saved in local storage)
- If there are no recently viewed dashboards, then this sorting option
is hidden, and "last updated at" is default like before
- This option is only added to the dashboard listing
Implementation:
- Recently viewed dashboard are stored in local storage as a queue with
20 items max
- I reused the existing RecentlyAccessedService we've been using for
sidenav's recently viewed section. For this, I moved it to a separate
package. The service already handles a lot of edge cases like spaces,
key hashing, and deduping.
- The sorting part in EUITable is a bit hacky. It doesn't support custom
internal sorting (like we do with title and lastUpdatedAt), so I had to
sort the list myself and then tell EUITable not to do any sorting in
case "Recently viewed" option is selected. [slack
discussion](https://elastic.slack.com/archives/C7QC1JV6F/p1720008717120589)
<img width="1265" alt="Screenshot 2024-07-05 at 10 59 25"
src="9cc46fd2-4270-494f-9272-302007a7efc0">
## Summary
*(Yeah, the title is pretty bad I apologize, I couldn't find something
sexy. OTOH, "sexy" and "logging" are usually antonyms, like "sport car"
and "fiat panda", or "server language" and "javascript")*
### 1. Provide a more developer-friendly alternative to
`Logger.isLevelEnabled`.
**With `isLevelEnabled`**
```ts
if(logger.isLevelEnabled('info')) {
const message = someExpensiveMessageProbablyBasedOnJsonStringifyOrSomething();
logger.info(message);
}
```
**With this PR:**
```ts
logger.info(() => someExpensiveMessageProbablyBasedOnJsonStringifyOrSomething());
```
### 2. Adapt calls to `log.debug` (arguably) costly to use this syntax
Aka any call relying on `JSON.stringify` or function calls.
I used the new syntax for those, except when the tests were too
complicated to fix or when the code did not allow it (e.g. untyped let
variables infered from return from assignations don't play well with
closures)
## Summary
fix https://github.com/elastic/kibana/issues/187570
The problem was that when the system/browser was in dark mode, the
default text color became white, but the background was forced to a
specific bright color, so the text became unreadable. A quick fix is to
also force the text color (I used EUI text colors)
<img width="858" alt="Screenshot 2024-07-05 at 12 44 11"
src="9ccefc04-60f6-46e3-a649-4e47cad043ac">
## Summary
Part of https://github.com/elastic/kibana/issues/186530.
This PR sets the basis for allowing namespaced usage counters.
It relocates `usage-counters` SO type from `.kibana` to a dedicated
`.kibana_usage_counters`.
Furthermore, the original SO type is removed, and replaced by 2 separate
types:
* `server-counters`
* `ui-counters`
Note that these 2 steps are necessary if we want to leverage
`namespaces` property of the saved objects.
We can't currently update the `namespaceType: 'agnostic'` without
causing a migration.
Thus, these two types will be defined as `namespaceType: single`.
Up until now, UI counters were stored under a special `domainId:
uiCounter`.
This forced a workaround that consisted in storing `appName:eventName`
in the `counterName` property of the SO.
Having a dedicated SO type for them allows to store `appName` as
`domainId`, avoiding the need for a
[workaround](https://github.com/elastic/kibana/blob/main/src/plugins/usage_collection/common/ui_counters.ts).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Needed for https://github.com/elastic/kibana/pull/187306 and [probably
more to come](https://github.com/elastic/kibana/issues/186574).
Expose authenticated user mock and type from core-security server &
browser mocks.
Exposing the mock from Core avoids dependencies on the Security Plugin
remaining just for mocks.
It also helps avoid creating duplicates specifically for tests.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Updates
### Latest updates
- Expose whether KB is configured to run in FIPS mode from Core ->
Security
<img width="653" alt="Screenshot 2024-06-20 at 9 55 17 PM"
src="56a9f50f-0a05-41ca-9292-ed225b3d8062">
Consolidating all FIPS PRs into this PR
*Previous PRs were Approved
### Changes
- Config option is now experimental:
`xpack.security.experimental.fipsMode.enabled`
- Documentation has been revised
- Listed as an experimental feature
- Added keystore references for adding a password
## Summary
Closes#169738Closes#169739Closes#169740Closes#185948
FIPS is a platinum license feature.
KIbana instances must have a platinum or better license to start up in
FIPS mode, a lesser license will result in Kibana failing to start up
If the license is degraded, Kibana will still run, but an error will be
logged letting the user know that Kibana will not be able to restart.
## Config changes
This PR required the changes that were approved from [a previous
PR](https://github.com/elastic/kibana/pull/174558), since that PR
couldn't be merged into main, I merged it here.
## Testing
### Locally
In your `kibana.dev.yml` add:
`xpack.security.experimental.fipsMode.enabled: true`
To allow Kibana to start without actually providing a compliant OpenSSL
provider, in `x-pack/plugins/security/server/config.ts` change L328 from
`if (isFipsEnabled !== isNodeRunningWithFipsEnabled)` to `if (false)`
You are now configured to run in FIPS-spoof mode!
Run: `yarn es snapshot` and `yarn start` > You should see Kibana fail to
start with an error about using a basic license.
Run: `yarn es snapshot --license trial` and `yarn start` > Kibana should
start.
Login as `elastic` and navigate to Stack Management > License Management
Switch your license to `basic` and accept.
In your logs, you will see an error letting users know that you no
longer have an appropriate license and Kibana will not restart.
### For FIPS enthusiasts
Start an ES instance in a method of your choosing, but not using `yarn
es snapshot`. I like to use an 8.15.0-snapshot from the `.es/cache`
directory by running `tar -xzvf
elasticsearch-8.15.0-SNAPSHOT-darwin-aarch64.tar.gz ` and cd into the
new directory's `bin` folder to run `./elasticsearch`
Ensure you have Docker running locally.
From any command line, run: `docker run --rm -it -e
XPACK_SECURITY_FIPSMODE_ENABLED='true' -p 5601:5601/tcp
docker.elastic.co/kibana-ci/kibana-ubi-fips:8.15.0-SNAPSHOT-bc3150316ed317c08d57c6bd785ba39586072e1d`
This will start Kibana into Interactive Setup mode, copy and paste the
token from the ES startup logs.
Kibana should fail to start and you should see Kibana fail to start with
an error about using a basic license.
Repeat the above process except before you paste the token from ES, do
the following to enable a trial license on your ES instance:
In a new terminal window, navigate to your the top level of your
elasticsearch folder and run
`curl -X POST --cacert config/certs/http_ca.crt -u
elastic:YOUR_PASSWORD_HERE
"https://localhost:9200/_license/start_trial?acknowledge=true&pretty"`
You should receive a successful response.
Now paste the token from the ES startup logs into the Kibana Interactive
Setup window and Kibana should start.
Login as `elastic` and navigate to Stack Management > License Management
Switch your license to `basic` and accept.
In your logs, you will see an error letting users know that you no
longer have an appropriate license and Kibana will not restart.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
## Summary
Reopening https://github.com/elastic/kibana/pull/186326 with my account,
non-internal PRs are just terrible to work with
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
## Summary
Addresses https://github.com/elastic/kibana/issues/177831.
The PR introduces specific steps to check that
`cluster.routing.allocation.enable` has a suitable value for _reindex
migrations_.
Up until now, this check was done systematically after the `INIT` step.
Now, a couple new dedicated steps have been introduced, which allow
verifying this setting on _reindex migrations_ only (highlighted in
orange):
## Summary
Fix https://github.com/elastic/kibana/issues/185042
- Add a new `elasticsearch.maxResponseSize` config option
- Set this value to `100mb` on our serverless configuration file
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Addresses https://github.com/elastic/kibana/issues/185918
The idea is to simply check whether the index that a migrator is trying
to `write_block` (aka the source of the reindex operation) matches the
target index name. In this case:
* We assume that other migrators are half way through, ahead of us.
* We abort operation and trust other instances' migrators to finish the
job.
* Subsequent restart, when migration has finished, should basically be a
no-op.
## Summary
Fix https://github.com/elastic/kibana/issues/179458
Add a third method to `IScopedClusterClient`, `asSecondaryAuth` which
allow performing requests on behalf of the kibana system users with the
current user as secondary authentication (via the
`es-secondary-authorization` header)
## Summary
Close https://github.com/elastic/kibana/issues/184719
Adds the ability to capture OAS for `serverless` build flavor in
addition to `traditional`. By default the CLI will run for both, but
this can be controlled by passing in one of two new flags:
`--no-serverless` or `--no-traditional`.
See `oas_docs/bundle.serverless.json` for output.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Per [the OAS docs](https://swagger.io/specification/), they have an info
object with a `summary` and `description` field. This PR refactors the
existing router `description` field to to OAS `summary` (that is how it
has been used) and introduces a "new" `description` field that will be
used for the longer form descriptions.
## Resources
* https://swagger.io/specification/
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
## Summary
We recently "discovered" that ES calls performed from the SOR were not
having the default retry mechanism used by the ES client.
This is caused by the way we construct the ES client wrapper used for
the SOR, that forces the `maxRetries` option to `0`
8911bfabb0/packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository_es_client.ts (L38-L40)
I initially tried to fully get rid of `retryCallCluster` in
https://github.com/elastic/kibana/pull/184658, as we assumed that
re-enabling the retry mechanism would be sufficient, but this was
causing flakiness in test suites (uncaught rejections in plugins not
properly stopping after ES and Kibana are shut down, with
`NoLivingConnectionsError` errors...)
So instead, I just re-enabled the ES client native mechanism by removing
the `maxRetries` override.
## Summary
Part of https://github.com/elastic/kibana/issues/7104
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
*Note: by default, enabling `http2` requires a valid `h2c`
configuration, meaning that it can only run over HTTPS with TLS1.2+*
```yaml
## kibana.yaml
server.protocol: http2
server.ssl.enabled: true
server.ssl.key: path/to/key
server.ssl.certificate: path/my/cerf
```
## What is this PR doing
### Add HTTP2 support for the Kibana server
#### - Plug http2 to the Kibana server
Even if HAPI was never officially updated to really support HTTP2,
node's `http`/`https`/`http2` modules are compatible enough to be able
to just instantiate an http2 server/listener and provide it to HAPI "as
a plain https listener". There were some tweaks to do (mostly silencing
a few warnings that HAPI was causing by sending http2-illegal headers
such as `Connection`), but overall, it went smoothly.
#### - Add config validation
By default, Kibana will require a valid `h2c` configuration to accept
enabling `http2`. It means that TLS must be enabled and that TLS1.2+
should at least be in the list of supported SSL protocols
(`server.ssl.supportedProtocols`). Note that default value of this
setting includes TLS1.2 and 1.3.
#### - Add escape hatch to run `h2` without `h2c`
In some situations, it may be required to enable http2 without a valid
`h2c` configuration. Kibana supports it, by setting
`server.http2.allowUnsecure` to `true`.
(*Note, however, that if http2 is enabled without TLS, ALPN protocol
negotiation won't work, meaning that most http2 agents/clients will fail
connecting unless they're explictly configured to use http2.*)
### Add documentation about this new feature
#### - Update the user-facing doc about this new `server.protocol`
setting
Update the user-facing Kibana settings documentation to include this
`http.protocol` setting (and refer to `server.http2.allowUnsecure`)
**Note: this setting, and this feature, are considered as experimental**
### Adapt our dev tooling to support running Kibana with http2 enabled
#### - Add a `--http2` flag to the dev CLI
Enabling this flag will add the proper configuration settings to run
Kibana with `http2` enabled in an (almost) valid `h2c` configutation.
*Note: when using this flag, even if listening on the same port, the
Kibana server will be accessible over https, meaning that you need to
use https in your browser to access it. Aka `http://localhost:5601`
won't work, you need to use `https://localhost:5601`. Also, we're using
the self-signed dev certificates, meaning that you must go though the
scary warning of your browser*
#### - Implement an http2-compatible base-path proxy
The current base path proxy is based on `hapi` and `hapi/h2o2`. I tried
for a bunch hours trying to hack around to make it work with http2
proxying, but ultimately gave up and implemented a new version from
scratch.
Note that with some additional efforts, this new http2 basepath proxy
could probably fully replace the existing one and be used for both http1
and http2 traffic, but it's an optimization / refactoring that did not
feel required for this PR.
### Adapt the FTR to run suites against http2
#### - Add support to run FTR test suite against an h2c-enabled Kibana
Note that with ALPN, clients using http1 should be (and are) able to
communicate with http2 Kibana, given h2c/alpn allows protocol
negitiation. So adapting our FTR tooling was not really about making it
work with http2 (which worked out of the box), but making it work with
**the self signed certifcates we use for https on dev mode**
Note that I'm not a big fan of what I had to do, however, realistically
this was the only possible approach if we want to run arbitrary test
suites with TLS/HTTP2 enabled without massively changing our FTR setup.
Operations and QA, feel free to chime in there, as this is your
territory.
#### - Change some FTR test suites to run against an HTTP2-enabled
server
I added a quick `configureHTTP2` helper function to take any "final" FTR
suite config and mutate it to enable `http2`. I then enabled it on a few
suites locally, to make sure the suites were passing correctly.
I kept two suites running with http2 enabled:
- the `console` oss functional tests
- the `home` oss functional tests
We could possibly enable it for more, but we need to figure out what
kind of strategy we want on that matter (see below)
## What is this pull request NOT doing
#### - Making sure everything works when HTTP2 is enabled
I navigated the applications quite a bit, and did not see anything
broken, however I obviously wasn't able to do a full coverage. Also, the
self-signed certificate was a huge pain to detect issues really caused
by http2 compared to issues because the local setup isn't valid `h2c`.
In theory though (famous last words) anything not doing http/1.1
specific hacks such as bfetch should work fine with http2, given that
even if using non-http2 clients, ALPN should just allow to fallback to
http/1.x (this part was tested)
#### - Enabling HTTP2 by default
PR isn't doing it for obvious reasons.
#### - Enabling HTTP2 for all FTR suites
First of all, it's not that easy, because it requires adapting various
parts of the config (and even some var env...), and we don't have any
proper way to override config "at the end". For instance, if you add the
http2 config on a top level config (e.g. the oss functional one that is
reuse by the whole world - learned the hard way), it won't work because
higher-level configs redefined (and override) the `browser` part of the
config, loosing the settings added to run the browser in insecure mode.
Secondly, I'm not sure we really need to run that many suites with http2
enabled. I learned working on that PR that we only have like one suite
where https is enabled for the Kibana server, and I feel like it could
be fine to have the same for http2. In theory it's just a protocol
change, unless parts of our apps (e.g. bfetch) are doing things that are
specific to http/1.1, switching to http2 should be an implementation
detail.
But I'd love to get @elastic/kibana-operations and @elastic/appex-qa
opinion on that one, given they have more expertise than I do on that
area.
- Running performances tests
We should absolutely run perf testing between http/1.1 over https and
http/2, to make sure that it goes into the right directly (at least in
term of user perceived speed), but I did not do it in the scope of this
PR (and @dmlemeshko is on PTO so... 😅)
## Release Note
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
Note: by default, enabling `http2` requires a valid `h2c` configuration,
meaning that it can only run over HTTPS with TLS1.2+
Please refer to the Kibana config documentation for more details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Upgrading intl packages from v2 to v6
### Packages upgrade:
- [x] Add @formatJS packages
- [x] `react-intl` Upgraded
- [x] `intl-messageformat` Upgraded
- [x] `intl-format-cache` removed
- [x] `intl-relativeformat` removed
- [x] `intl-messageformat-parser` removed
### Todo list:
- [x] Refactor HTML tags
- [x] Refactor Upgrade tags
- [x] Refactor `kbn-i18n`
- [x] Refactor `kbn-i18n-react`
- [x] Refactor `FormattedRelative` to `FormattedRelativeTime`
- [x] Refactor polyfills
- [x] Refactor IntlShape types
- [x] Rewrite Providers
- [x] Rewrite tests using i18n
- [x] Removed current pseudolocale implementation (tracker:
https://github.com/elastic/kibana/issues/180244)
- [x] Fix jest tests using rendered `Provider`
- [x] Remove no longer valid i18n packages documentation (tracker:
https://github.com/elastic/kibana/issues/180259)
Closes https://github.com/elastic/kibana/issues/178968
Closes https://github.com/elastic/kibana/issues/38642
## Notes to code reviewers
For team other than the core team, please review your plugins code
changes by filtering files by codeowners.
### Test Snapshot updates
Most of the changes are refactors of renamed functions and changed ICU
syntax.
The main updates are snapshot changes where `FormattedMessage` is now
memoized so snapshots capturing the html tree needed to be updated to
use `<Memo(MemoizedFormattedMessage)` instead of `<FormattedMessage`
### ICU now supports HTML tags:
before:
```
<FormattedMessage
defaultMessage="To buy a shoe, { link } and { cta }"
values={{
link: (
<a class="external_link" target="_blank" href="https://www.shoe.com/">
visit our website
</a>
),
cta: <strong class="important">eat a shoe</strong>,
}}
/>
```
after:
```
<FormattedMessage
defaultMessage="To buy a shoe, <a>visit our website</a> and <cta>eat a shoe</cta>"
values={{
a: msg => (
<a class="external_link" target="_blank" href="https://www.shoe.com/">
{msg}
</a>
),
cta: msg => <strong class="important">{msg}</strong>,
}}
/>
```
### Escape character to prevent ICU parsing changed from double slashes
to single quotes:
before: `\\{escaped\\}`
after: `'{escaped}'`
### No need for Intl Shape
the new packages under formatJS are written in typescript and come with
types support out of the box so no need to set types when using i18n.
Renamed `InjectedIntlProps` with `WrappedComponentProps`.
Removed `prop-types` and `intlShape` in favor of `IntlShape`.
### FormattedRelative has been renamed to FormattedRelativeTime and its
API has changed significantly. See
[FormattedRelativeTime](https://formatjs.io/docs/react-intl/upgrade-guide-3x#formattedrelativetime)
for more details.
### All tags specified must have corresponding values and will throw
error if it's missing
All tags are now parsed and expected to be formatted properly (all
opened tags must be closed).
To skip this check you can use the `ignoreTag: true` property
```
i18n.translate('xpack.apm.agentConfig.captureJmxMetrics.description', {
defaultMessage: 'This is not an HTML tag <JMX object name pattern>' +
ignoreTag: true,
}),
```
**When do I use ignore tags?**
If your message has HTML tags, it is preferred not to ignore the Tag to
have some string verification that the html tags you are adding are
properly formatted and closed.
If it the text between brackets is not an HTML tag and it is just a
fomat preference then using `ignoreTag` makes sense.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Close https://github.com/elastic/kibana/issues/184575
## How to test
1. Add `server.cdn.url: null` to kibana.dev.yml
2. Start ES + Kibana
3. Open Kibana, should work as usual by loading assets from Kibana
server
## Summary
When we implemented the browser-side analytics service, browser-side
logger wasn't a thing yet, so we had to implement a custom one. This PR
addresses that, by now properly using core's logger.
Direct upside is that those messages:
1c1e20afdb/packages/analytics/client/src/analytics_client/analytics_client.ts (L136-L138)
using the `debug` level will now be silent by default, unless the
developer explicitly sets `logging.browser.root.level` to `INFO` or
superior.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Close https://github.com/elastic/kibana/issues/181992
## Summary
First iteration of a CLI to capture an OAS snapshot.
## How to test
Run `node ./scripts/capture_oas_snapshot.js --update --include-path
/api/status` and see result in `oas_docs/bundle.json`.
If you have the [bump CLI](https://www.npmjs.com/package/bump-cli)
installed you can preview the hosted output with `bump preview
./oas_docs/bundle.json`
## Notes
* Added ability to filter by `version`, `access` (public/internal) and
excluding paths explicitly to the OAS generation lib
* Follows the same general pattern as our other "capture" CLIs like
`packages/kbn-check-mappings-update-cli`
* Result includes only `/api/status` for now, waiting for other paths to
add missing parts
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Close https://github.com/elastic/kibana/issues/182910
Add the ability to declare recursive schemas. Updates
`@kbn/config-schema` to support recursive types. This design follows the
underlying pattern provided by Joi:
https://joi.dev/api/?v=17.13.0#linkref:
```ts
const id = 'recursive';
const recursiveSchema: Type<RecursiveType> = schema.object(
{
name: schema.string(),
self: schema.lazy<RecursiveType>(id),
},
{ meta: { id } }
);
```
Since using the `.link` API we are also using `.id` which enables us to
leverage this mechanism OOTB with `joi-to-json` for OAS generation (thus
we could delete a lot of code there).
I chose to avoid using `id` originally because I thought it would be
simpler if we control more of the conversion in config-schema's case but
for recursive schemas and references I think this is a favourable trade
off. Open to other ideas!
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes needed for getting CI to pass when EUI throws an error if
attempting to render a component without the EuiProvider in the render
tree.
## Detailed description
In https://github.com/elastic/kibana/pull/180819, I will deliver a
change that will cause EUI components to throw an error if the
EuiProvider context is missing. This PR comes in as part of the final
work to get all functional tests passing in an environment where EUI
will throw the error. The tied to the ["Fix 'dark mode' inconsistencies
in Kibana" Epic](https://github.com/elastic/kibana-team/issues/805) has
so far been in preparation for this.
**Reviewers: Please interact with critical paths through the UI
components touched in this PR, ESPECIALLY in terms of testing dark mode
and i18n.**
<img width="1107" alt="image"
src="c0d2ce08-ac35-45a7-8192-0b2256fceb0e">
### Checklist
Delete any items that are not applicable to this PR.
- [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
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/7104
Adapted from https://github.com/elastic/kibana/pull/183465
For `http2` support, we will have to change the way we configure the
HAPI server to manually provide the listener instead of passing down the
options for HAPI to create it.
This PR prepares that work, by creating the `http` or `https` (`tls`)
listener and passing it when creating the HAPI server instead of just
passing the `tls` options.
**Note:** no integration tests were added, because we already have the
right coverage for both tls and non-tls mode, so any change of behavior
introduced by the PR should be detectable by them.
## Summary
Closes https://github.com/elastic/ingest-dev/issues/3252
## Add integration
Added warning to Add integration when the integration requires root
privilege and the selected existing agent policy has unprivileged agents
enrolled.
To verify:
- enroll an agent with docker (it has unprivileged: true)
- try to add an integration that requires root e.g. auditd_manager
- verify that when trying to save the integration, the warning callout
is part of the confirm deploy modal
<img width="807" alt="image"
src="420da729-a4f4-4861-9767-001699629397">
## Add agent flyout
Added warning to Add agent flyout when an unprivileged agent is detected
in combination with an agent policy that has integrations requiring root
To verify:
- add an integration to an agent policy that requires root e.g.
auditd_manager
- open Add agent flyout, verify that the warning callout is visible
<img width="1273" alt="image"
src="e4ae1d73-358b-4d3c-9ca0-27e88bc734a6">
### Open question:
- Do we want to show the warning on `Add agent flyout` only for newly
enrolled agents (in the last 10 mins like we query enrolled agents), or
any unprivileged agents that are enrolled to this policy?
- Decision: No longer applicable as we decided to not show a count here
### Checklist
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
