## Summary
disables features under Application for serverless-essentials.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces a new Search Home page.
Currently, the homepage experience differs across Classic nav, Solution
nav, and Serverless. Our goal is to unify these into a consistent,
foundational experience that we can iterate on to create a more
personalized and customizable homepage for Elasticsearch users.
The new page includes:
- An option to connect to Elasticsearch
- File upload and sample dataset ingestion
- Entry points to explore Elastic’s AI Search capabilities
- Quick access to Observability and Security solutions
- Links to Search Labs, Python notebooks, and Elasticsearch
documentation
https://github.com/user-attachments/assets/7b1b5330-59b4-43b7-aa5b-000fcd2654e2
### 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
- [ ] 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)
- [ ] 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)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: Rodney Norris <rodney@tattdcodemonkey.com>
# Overview
This pull request enables the Security Entity Analytics Privileged user
monitoring feature. This feature has many accompanying PRs, that have
until now been kept behind an experimental feature flag. The feature is
currently slated to ship as a Technical Preview.
Instead of removing the feature flag, we will be allowing for a
"disabled" version of the experimental flag, which allows this feature
to remain disabled in Serverless, until fully tested during the 9.1
release cycle. Disabling in Serverless is accomplished via setting the
configuration to disabled in the `config/serverless.security.yml` file.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## 📓 Summary
Given the setting introduced in [#221286 [ML] AIOps: Adds ability to
disable AIOps features in
Kibana](https://github.com/elastic/kibana/pull/221286), this adds the
expected configuration value to disable all the AIOPS features for
`logs_essentials` projects.
## Summary
- Adds configuration for the product intercept in `oblt`, `es` and
`security` serverless offerings, alongsides stateful offering too. The
configuration provided sets the intercept to display every 90days, this
is configurable through the config `xpack.product_intercept.interval`.
The intercept can also be turned off through the config
`xpack.product_intercept.enabled`
- Also tweaks prompter timer implementation to accommodate inherent
[issue with long timer
delays](https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout#maximum_delay_value)
in the browser
- Adjusts the signature of the `registerIntercept` method, such that a
deferred value to be evaluated when the intercept is to be displayed is
passed. This unlocks the ability to have consumers provide dynamically
imported modules that provide the config for the intercept, see
0e07892217
for an example.
### How to test
- Add the following config to your `kibana.dev.yml` file;
```yml
xpack.product_intercept.enabled: true
# we set the interval to 30s so the wait long period to display the
intercept is bearable
xpack.product_intercept.interval: '30s'
```
- Start kibana in stateful, and serverless mode, in either scenario you
should be presented the product intercept, with the intercept
specifically stating the current product the user is interacting with.
See below for an example of observability solution;
https://github.com/user-attachments/assets/6ca6baf2-58d3-4002-ac94-ec6e9a0902ae
<!--
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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
- [ ] [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
- [ ] 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)
- [ ] 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.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
> [!TIP]
> looks huge, but
> - 5,402 lines snapshot tests
> - 714 lines yaml files
## Summary
This PR adds a new feature version `siemV3` with the required role
migrations, in order to enable the new privilege
`global_artifact_management_all` for users where needed.
### What's in the PR?
- Required changes around security role migration from `siemV2` to
`siemV3`
- Improvements by parameterizing `siemV3` in lots of places, to ease
future role migrations by decreasing the occurrences that have to be
changed.
- A new function called `baseFeatureConfigModifier()` in
`ProductFeaturesConfig`: now product features have the ability to modify
the base Kibana feature. de05a3b167
- Product feature `endpointArtifactManagement` is split to
ESS/Serverless counterparts, and adds role migrations to the base Kibana
config using `baseFeatureConfigModifier()`
(1c31f56b43). This solves 2 problems:
- Different migrations are needed for ESS and Serverless.
- The product feature `endpointArtifactManagement`, and hence the
privilege `global_artifact_management_all` is not available on all
serverless tiers (see [these
fails](https://buildkite.com/elastic/kibana-pull-request/builds/310534/summary/annotations?jid=019788c8-d03e-44e7-867f-ff1557f9e894#019788c8-d03e-44e7-867f-ff1557f9e894/256-4872)),
therefore the migration needed to be separated from the base Kibana
feature config.
- (note: these changes were safeguarded by the role migration tests and
snapshot tests)
- Security / **Global Artifact Management** [space awareness]:
- moves the sub-privilege out of feature flag, in order to be able to
target it for role migrations
- adds a 'Coming soon' test to the privilege
- `endpointManagementSpaceAwarenessEnabled:false`
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/fdfd5fc7-7f7d-4210-96c9-09e2357530c0"
/>
- `endpointManagementSpaceAwarenessEnabled:true`
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/f8361a4c-da6e-416c-b728-5788eb1a053e"
/>
- role migration is added: in short, any artifact ALL privilege causes
the new Global Artifact Management ALL privilege to be added
(https://github.com/elastic/security-team/issues/11717)
- predefined roles are updated locally
(note: in elasticsearch-controller, it'll be updated after this PR is
merged and deployed,
https://github.com/elastic/elasticsearch-controller/pull/1010)
- tests!
- testing the migration itself: b8d90d085f
and 309abb30a8
- snapshot test with deprecated features:
https://github.com/elastic/kibana/pull/219566/files#diff-ed11536475a7a6f0a835cbc950c3b7405093058ad42bab30cf06f41ed21561a3
- some functional tests enabled for deprecated features:
4b4f49ea3d
## Global Artifact Management role migrations
```mermaid
flowchart LR
subgraph siemV2[siem/siemV2]
none1[none]
end
subgraph siemV3
none2[none]
end
none1 --> none2
```
```mermaid
flowchart LR
subgraph siemV2[siem/siemV2]
read1[read]
end
subgraph siemV3
read2[read]
end
read1 --> read2
```
```mermaid
flowchart LR
classDef serverless stroke:blue,stroke-dasharray: 5 5
subgraph siemV2[siem/siemV2]
subgraph minread1[minimal_read]
minread1_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall1_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
eer1["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea1["`endpoint_exceptions_all
(only serverless)`"]:::serverless
end
end
subgraph siemV3
subgraph minread2[minimal_read]
minread2_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall2_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
eer2["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea2["`endpoint_exceptions_all
(only serverless)`"]:::serverless
g2[global_artifact_management_all]
end
end
minread1 --> minread2
minread1_subs -->|each to his own| minread2_subs
minall1_subs -->|global for any of these| g2
minall1_subs -->|each to his own| minall2_subs
eer1 -->|only serverless| eer2
eea1 -->|only serverless| eea2
eea1 -->|only serverless| g2
linkStyle 4,5,6 stroke:#00f,color:blue
```
notes for above:
- `global_artifact_management_all` have to be added for **any** artifact
write privilege (trusted apps, event filters, blocklists, host isolation
exceptions)
- on serverless, there is a separate endpoint exceptions privilege, it
counts as an artifact
```mermaid
flowchart LR
subgraph siemV2[siem/siemV2]
all1[all]
end
subgraph siemV3
subgraph minall2[minimal_all]
g1[global_artifact_management_all]
end
end
all1 -->|keep access to the included Endpoint Exceptions ALL| g1
all1 -->|enable sub-feature toggle| minall2
```
notes for above:
both on serverless and ESS, Endpoint Exceptions are included in ALL,
hence the migration
> [!note]
> `siem` sub-privileges are not included in READ/ALL parent privileges.
The user needs to enable them one-by-one after enabling the sub-feature
privileges toggle. So Endpoint Exception here is an exception. In any
sense of the word.
```mermaid
flowchart LR
classDef serverless stroke:blue,stroke-dasharray: 5 5
subgraph siemV2[siem/siemV2]
subgraph minall1[minimal_all]
minread1_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall1_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
eer1["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea1["`endpoint_exceptions_all
(only serverless)`"]:::serverless
end
end
subgraph siemV3
subgraph minall2[minimal_all]
minread2_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall2_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
g2[global_artifact_management_all]
eer2["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea2["`endpoint_exceptions_all
(only serverless)`"]:::serverless
end
end
minall1 -->|only on ESS to keep access to the included Endpoint Exceptions ALL| g2
minall1 --> minall2
minread1_subs -->|each to his own| minread2_subs
minall1_subs -->|global for any of these| g2
minall1_subs -->|each to his own| minall2_subs
eer1 -->|only serverless| eer2
eea1 -->|only serverless| eea2
eea1 -->|only serverless| g2
linkStyle 5,6,7 stroke:#00f,color:#00f
linkStyle 0 stroke:#0a0,color:#0a0
```
notes for above:
when sub-feature privileges are enabled,
- on ESS endpoint exceptions are still automatically included, that's
why we need to add global access
- on serverless, endpoint exceptions are controlled by the sub-feature
privilege (just like all other artifact privileges, see the note above)
## Background
- Previous role migration PR:
https://github.com/elastic/kibana/pull/201780
- Role migration description:
https://github.com/elastic/kibana/pull/186800
### 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
- [ ] 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)
## Summary
Closes https://github.com/elastic/observability-dev/issues/4539
Fixes https://github.com/elastic/kibana/issues/221035
Enables custom roles for Observability projects in serverless.
The following is a summary of the changes:
## Feature renaming
1. Renamed `Uptime and Synthetics` to `Synthetics`
2. Renamed `APM and User Experience` to `Applications`
3. Renamed `Metrics` to `Infrastructure`
## Category reassignment
1. Changed `Dashboard` category from `Analytics` to `Observability`
2. Changed `Discover` category from `Analytics` to `Observability`
3. Changed `ML` category from `Analytics` to `Observability`
## Feature hiding
1. Hides the `Stack Alerts` feature.
2. Provides backwards compatibility for alerts created via Stack Alerts.
This enables our users to import rules created within Stack Alerts and
expect to see them in the Observability rules table.
## Navigation updates
1. Adds a `Custom Roles` link under the `Access` section in the
management navigation
2. Adds a `Manage Organization Members` link under the `Access` section
in the management navigation
3. Removes the `Users and Roles` link from the navigation footer (in
favor of the `Manage Organization Members link)
## Bug fixes
1. Fixes a bug where the `Alerts` link was not shown for Synthetics only
user (in stateful and serverless)
2. Fixes a bug where the `Alerts` link was not shown for Logs only user
(in stateful and serverless)
## Alert Override Removal
In the alerting framework, each rule is assigned a `consumer` value.
This `consumer` value changes depending on where the rule is created in
Kibana. However, in serverless we introduced an override that caused the
`consumer` value to be `Observability` in nearly every case. This logic
branched from stateful causing complexity and a large mental burden for
our engineers. Ultimately, this override became the source of bugs,
uncertainty, and unintended user experiences. Because of this, we've
removed this overrides.
If we kept this override, it would have the unfortunate side effect of
making all rules created in serverless visible from all custom roles (an
APM only user would have been can see Synthetics rules, and vice
versus). To make things more unpredictable, when users import their
rules from stateful the behavior would be different (access would be
properly mapped to the specific feature).
To address these specific user experience issues, and remove the source
of complexity, branching logic, and bugs, we removed this override logic
and restored the rule access behavior to match with stateful.
We did this while introducing backwards compatibility logic, ensuring
rules created in earlier versions of an oblt stateful cluster continue
to work and are accessible by a user with the right role access.
# Testing
1. Run local ES
```
yarn es serverless --projectType=oblt -E xpack.security.authc.native_roles.enabled=true
```
2. Run local Kibana
```
yarn start --serverless=oblt --xpack.security.roleManagementEnabled=true --xpack.cloud.users_and_roles_url="https://test_users_and_roles_url"
```
3. Login to Kibana with the admin role. Navigate to the Custom Roles
page via the management navigation.
4. Create a custom role
5. Log out of Kibana
6. Log back in with your custom role. You can do so by typing the custom
role name into the mock saml auth
<img width="460" alt="Screenshot 2025-05-22 at 9 23 13 PM"
src="https://github.com/user-attachments/assets/8e7f659b-5fe9-4e74-8c57-b420467d309e"
/>
---------
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
## 📓 Summary
As a result of discussing a closer alignment between Product and
configuration naming, this change renames the observability `essentials`
tier to `logs_essentials`.
As a consequence, the specific configuration file loaded for this tier
is now named `serverless.oblt.logs_essentials.yml`.
Furthermore, this means that switching between the `complete` and
`logs_essentials` tier should now be done with
```yml
pricing.tiers.enabled: true
pricing.tiers.products:
- name: observability
tier: complete # Accepted values for this tier are: complete, logs_essentials
```
## Summary
Introduces a new config in the security serverless plugin to hide other
plugins' UI (making them inaccessible).
It uses the `core.application.registerAppUpdater` API.
@elastic/kibana-visualizations I did some cleanup around the custom
global search's `registerResultProvider`, which seems to be a workaround
from times before `visibleIn` functionalities. This way, the search
result depends on the plugin being accessible. My change introduces a
small text update in the search result, though. To me, now it looks more
consistent with the rest of the analytics applications. Let me know if
you think that's an issue.
| Prev | New |
|------|-----|
|
|
|
### Goal
This is needed by the `AI4DSOC` team to hide some applications outside
the Security Solution:
```yaml
xpack.securitySolutionServerless.inaccessibleApps:
- dashboards
- visualize
- maps
- lens
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tomasz Ciecierski <tomasz.ciecierski@elastic.co>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/4490
We need to introduce a tier concept in Kibana to offer tiered versions
of our Observability solution.
Some time ago, the security team did something similar to introduce
tiered product lines, and this work lays the foundation for a Kibana
shared solution that can work with product tiers.
This PoC introduces a new core `PricingService` to manage feature
availability based on subscription tiers in serverless deployments. The
implementation enables:
- Tier-aware feature registration.
- Dynamic configuration loading based on
`serverless.<project-type>.<tier>.yml` files.
- Client/server APIs for feature checks based on available tier
(`isFeatureAvailable()`)
- Backwards compatibility with existing project types (Search,
Observability, Security, Chat)
## 🚶 Architecture walkthrough
### Configuration
To have a mechanism that allows for performing changes at the
configuration level, the `PricingService` loads and validates a strict
configuration of product tiers.
The available configuration is defined as follows:
```yml
# serverless.oblt.yml (default config)
pricing.tiers.enabled: true
pricing.tiers.products:
- name: observability
tier: complete
# serverless.oblt.complete.yml
xpack.infra.enabled: true
xpack.slo.enabled: true
xpack.features.overrides:
// Etc...
# serverless.oblt.essentials.yml
xpack.infra.enabled: false
xpack.slo.enabled: false
// Etc...
# Optionally, security solution could set their product tiers from their configuration files, as they are already supported by the core pricing service
# serverless.security.yml
pricing.tiers.enabled: true
pricing.tiers.products:
- name: security
tier: complete
- name: endpoint
tier: complete
- name: cloud
tier: complete
```
The Control Plane team will update how the kibana-controller inject the
configuration in the `kibana.yml` file to reflect the values set during
the project creation.
It will also auto-load any optional
`serverless.<project-type>.<tier>.yml` matching the config definition
when tiers are enabled.
The configuration is strictly validated against typed products. It might
be very opinionated to store this validation in a core package, but it
ensures strong typing across the codebase to register product features
and ensure a fast-failing check in case the product tiers do not exist.
### Pricing service
As far as the configuration-based approach is great to disable whole
plugins and override configs, it doesn't cover all the scenarios where a
specific tier wants to limit minor parts of a plugin feature (e.g., for
o11y limited onboarding, we cannot disable the whole plugin).
To cover these cases, the `PricingService` exposes a mechanism to
register features associated with specific tiers.
This is unbound from the `KibanaFeatureRegistry` mechanism, and we could
consider extending its behaviour in the future as needed. Once product
features are registered, the core start contract exposes a simple client
to detect when a feature is available.
<img width="1453" alt="Screenshot 2025-05-23 at 12 35 11"
src="https://github.com/user-attachments/assets/05267c00-afe0-49c6-b518-b1ce8f4a0546"
/>
## ✏️ Usage
To launch Kibana with a specific product tier (e.g. observability
`essentials`, mostly limiting to logs features), update the
`pricing.tiers.products` in the serverless project configuration file:
```yml
# serverless.oblt.yml
pricing.tiers.enabled: true
pricing.tiers.products:
- name: observability
tier: essentials
```
The above will run a Kibana serverless project in this specific tier and
will load the configuration defined in `serverless.oblt.essentials.yml`,
which currently disables a couple of plugins.
Given this context, let's take a limited o11y onboarding when the
subscription tier is `essentials`:
```ts
// x-pack/solutions/observability/plugins/observability_onboarding/server/plugin.ts
export class ObservabilityOnboardingPlugin {
public setup(core: CoreSetup) {
// ...
// Register a feature available only on the complete tier
core.pricing.registerProductFeatures([
{
id: 'observability-complete-onboarding',
products: [{ name: 'observability', tier: 'complete' }],
},
]);
// ...
}
}
// x-pack/solutions/observability/plugins/observability_onboarding/public/application/onboarding_flow_form/onboarding_flow_form.tsx
const { core } = useKibana();
const isCompleteOnboardingAvailable = core.pricing.tiers.isFeatureAvailable('observability-complete-onboarding');
if (isCompleteOnboardingAvailable) {
return <CompleteOnboarding />;
} else {
return <EssentialsOnboarding />;
}
```
The results of the above changes will look as follows once Kibana is
running:
| Complete tier | Essentials tier |
|--------|--------|
| <img width="2998" alt="Screenshot 2025-05-23 at 13 51 14"
src="https://github.com/user-attachments/assets/bcf7c791-4623-42e4-91ce-0622d981e7e7"
/> | <img width="2996" alt="Screenshot 2025-05-23 at 13 53 36"
src="https://github.com/user-attachments/assets/429c82eb-761c-4aa1-b13d-81ac95301e60"
/> |
The tiers client is also available server-side through the
`getStartServices()` function, such that ad-hoc activity/registrations
can be performed.
## 👣 Next Steps
- [x] Implement pending core tests
- [x] Document API usage in README
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This is a followup to https://github.com/elastic/kibana/pull/220675
where we added a new `xpack.alerting.rules.run.ruleTypeOverrides` inside
the `serverless.security.yml`.
After some investigation we realized that it overrides the same config
declared in the root `serverless.yml` file. Since the root file contains
the overrides for the security specific configs, we decided to move
those into the `serverless.security.yml`.
More details in [internal
discussion](https://elastic.slack.com/archives/C5TQ33ND8/p1747748907000299).
## Summary
With these changes we increase the attack discovery schedule rule
execution timeout to `30m` on Serverless. The attack discovery
generation can take a while and the default `1m` on Serverless does not
give much time to do complex AI work.
The identical timeout for the ESS set in this PR
https://github.com/elastic/kibana/pull/219099
Also, as part of this PR, we do the check whether the execution was
interrupted due to the timeout. In this case we throw an exception and
prevent reporting generated attack discoveries. This is a workaround
until a proper aborting added in alerting framework
https://github.com/elastic/kibana/issues/219152
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
## Summary
Pin the prebuilt rules package version to the one containing promotion
rules needed for AI4SOC to work.
Note: this is only for test purposes, the package will be removed once
AI4SOC is ready to be released and the promotion rules are added to the
production rules package.
## Summary
Addresses https://github.com/elastic/kibana/issues/204227
Instead of having to explicitly disable other solutions' plugins in the
`serverless.(es|o11y|security|chat).yml` files, this PR proposes an
approach to filter them out directly in the plugin discovery mechanism.
The PR had to remove:
* a bunch of project-specific configurations that are no longer defined
in each project.
* some global serverless configurations that refer project-specific
settings.
Risks:
* Serverless deployments overriding configs that are no longer known.
* Serverless project type A relying on plugin from project type B in
some way (side effect?).
Mitigation:
* Since this is a configuration, we can simply override it
(`plugins.allowlistPluginGroups`) if something is broken.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes bug introduced by: https://github.com/elastic/kibana/pull/213509
where serverless search & enterprise search could not load list of
available connector types from the connectors plugin. This was caused by
2 things in serverless, 1) the entire plugin was disabled and 2) the
plugin id was renamed.
Updated the `contentConnectors` plugin to have a `ui.enabled` config
value to override just disabling the management UI from being registered
for Serverless Search, while still allowing the plugin to be enabled.
And updated the usages of the `searchConnectors` plugin in
`enteprise_search` & `serverless_search` to account for it being renamed
to `contentConnectors`
Of note this bug would have been caught by FTRs, but they have been
skipped for being
[flakey](https://github.com/elastic/kibana/issues/203462) for some time,
and have proven [hard
fix](https://github.com/elastic/kibana/pull/205971) given the current UX
😔
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
## Summary
Introduces a new fleet config variable to be able to set the default the
fleet setting for `prerelease_integrations_enabled`.
This is to be used in the new search_ai_lake tier for the ai4dsoc
project as we want to enable pre-release versions by default.
## How to test
1. Set `xpack.fleet.prereleaseEnabledByDefault: true` in your
`kibana.dev.yml`
2. Start up elasticsearch and kibana
3. Navigate to the integrations page and the toggle to enable should be
on
<img width="750" alt="Screenshot 2025-04-16 at 3 25 50 PM"
src="https://github.com/user-attachments/assets/17d14630-94f5-4f2a-ab32-d733d0b36d48"
/>
OR
1. Add the following to `serverless.security.dev.yml`:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
2. Restart Kibana serverless for security
3. Navigate to the Configurations -> Integrations page
4. Click on the 'Splunk' integration and verify it loads the page
<img width="750" alt="Screenshot 2025-04-16 at 5 15 28 PM"
src="https://github.com/user-attachments/assets/ba4bf986-1b47-4703-9f33-9a0a7a437539"
/>
___
Relates: https://github.com/elastic/security-team/issues/11789
**!!MAJORITY OF THE CHANGED FILES ARE MOVED OR COPIED!!**
### Vision
According to the product vision we will build a new simple UI/UX in the
future https://github.com/elastic/security-team/issues/11790
This PR is a first iteration on enabling Content Connectors Management
UI in Serverless Kibana Stack Management.
Elastic Managed content connectors will be available only for Security
and Observability projects.
### Current PR scope
1. Used initial search_connectors plugin and renamed it to
content_connectors + moved from `x-pack/solutions/search` to
`x-pack/platform/plugins/shared`
2. Copy relevant connectors UI and routes from enterprise_search plugin.
3. Introduce the new Stack Management card/navigation option under the
Data section.
4. Enabled this plugin only in Serverless for Security and Observability
projects.
5. For making PR smaller Pipelines tab was not moved. And according to
Search team vision this functionality should be dropped anyway soon.
6. Extended fleet package logic to include elastic_connectors for
security and o11y serverless projects
7. Added back `search:agentless-connectors-manager` task
In Stack Management navigation:
<img width="2062" alt="Screenshot 2025-04-15 at 3 51 43 PM"
src="https://github.com/user-attachments/assets/5c93ba01-9a6a-4eac-a21d-1370f03b8f35"
/>
Stack Management cards:
<img width="2081" alt="Screenshot 2025-04-10 at 8 41 43 PM"
src="https://github.com/user-attachments/assets/3def1c12-561b-4a84-8241-4dd61cd9313d"
/>
Create Elastic Managed Connector UI (on Agentless):
<img width="1822" alt="Screenshot 2025-04-15 at 3 55 29 PM"
src="https://github.com/user-attachments/assets/6e9fea48-85e7-43df-919d-0e5492d0e704"
/>
Create Self Managed Connector UI:
<img width="2064" alt="Screenshot 2025-04-15 at 3 55 49 PM"
src="https://github.com/user-attachments/assets/d5051898-c8fa-4e41-b9ea-b41d4ed4a0d5"
/>
### Next steps
- [ ] Remove duplicated code between content_connectors,
enterprise_search and serverless_search
- [ ] Extract [common server
libs](https://github.com/elastic/kibana/tree/main/x-pack/solutions/search/plugins/enterprise_search/server/lib)
to the shared package `kbn-search-connectors`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Artem Shelkovnikov <artem.shelkovnikov@elastic.co>
Co-authored-by: Artem Shelkovnikov <lavatroublebubble@gmail.com>
Co-authored-by: Kyle Pollich <kyle.pollich@elastic.co>
## Summary
Hides security sub-privileges for ai4soc/search_ai_lake tier.
### Reasoning for changes added to `x-pack/packages/security`:
Currently, the feature description of Security feature is tied to the
fact that it has a list of sub-privileges. This is true on ESS and
`essentials/complete` serverless tiers.
With the introduction of the lower `search_ai_lake` tier, security
feature would not have any sub-privileges available and thus it does not
make sense to show that description.
The ideal way to handle this would be to load feature privileges config
settings at the plugin level
(security_solution/security_solution_serverless) and set `description`
to `null | undefined` based on the tier, as currently the feature
privileges settings live in [kibana_features file
(v2_features)](795094d8c6/x-pack/solutions/security/packages/features/src/security/v2_features/kibana_features.ts (L72))
(also another set in v1_features) and the plugins only select a set of
those based on the [feature keys
available](d4a33a2b61/x-pack/solutions/security/plugins/security_solution_serverless/common/pli/pli_config.ts)
on each tier. The refactoring to pass in feature configs at the plugin
level (instead of just feature keys) is not in the scope of the work cut
out for RSA conf.
Thus the other simpler approach in this PR is to allow overriding the
description field on the tier specific config file.
## How to Test
1. While on the Kibana root directory, run ES/Kibana on serverless mode
with:
```bash
yarn es serverless --kill --projectType security --kibanaUrl=http://0.0.0.0:5601
```
and on a new window
```bash
yarn serverless-security --no-base-path
```
Enable the AI for SOC tier, by adding the following to your
`serverless.security.dev.yaml` file:
```json5
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
2. Once Kibana is up and running login in with the `admin` role using
the role dropdown.
3. Navigate to `app/management/roles/edit`
4. Click on `Assign to space` button and assign a space to that role on
the `Assign role to spaces` flyout.
5. Expand the `Security` category and verify that `Security` feature is
listed in the list of features.
6. Also verify that there is neither an accordion icon beside `Security`
feature nor a description text under it about sub-privileges.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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
- [ ] [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
- [ ] 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)
- [ ] 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.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
## Summary
Removes unused code from the Investigate and Investigate app plugin.
Removes all references to those plugins in storybook, i18n, types, etc.
Removes codeowner requirements for those plugins
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> [!CAUTION]
> Do not merge yet!
> This PR is mergeable based on the assumption that we do not allow
downgrading to `search_ai_lake` tier from `essentials`/`complete` or
`trial` `complete/essentals`.
## Summary
On serverless with following sets of product types/lines timelines and
notes are not available to the user.
```json5
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' }
]
```
or
```json5
[
{ product_line: 'security', product_tier: 'search_ai_lake' }
]
```
or with
```json5
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
{ product_line: 'security', product_tier: 'search_ai_lake' }
]
```
This applies to custom role creation flyout where timelines/notes
privileges are not available for RBAC.
### Screenshots (where timeline and notes are not available)
#### Custom role creation
Also on alerts page notes and timelines is not available action items.
Trying to access these via URL does not show them either.
#### Current alerts page (with timelines and notes not available)
#### Alert details via URL (without notes on the expanded flyout)
## How to Test
1. While on the Kibana root directory, run ES/Kibana on serverless mode
with:
```bash
yarn es serverless --kill --projectType security --kibanaUrl=http://0.0.0.0:5601
```
and on a new window
```bash
yarn serverless-security --no-base-path
```
Enable the AI for SOC tier, by adding the following to your
`serverless.security.dev.yaml` file:
```json5
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
2. Once Kibana is up and running login in with the `admin` role using
the role dropdown.
3. Navigate to `app/management/roles/edit`
4. Click on `Assign to space` button and assign a space to that role on
the `Assign role to spaces` flyout.
5. Expand the `Security` privileges and verify that only 4
sub-privileges are seen and that Timelines and Notes are not among them.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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
- [ ] [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
- [ ] 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)
- [ ] 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.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
## Summary
~**DO NOT MERGE:** depends on
https://github.com/elastic/kibana/issues/213468~
This PR reintegrates the work from the `workchat_m1` branch into `main`:
- introduces a 4th solution type, `chat`, that will be used for the
*WorkChat* project type.
- edit things in various platform code to introduce/handle that new
project type
- add plugins and packages for the workchat app.
### To AppEx reviewers:
File change count is scary, but you can safely ignore anything from
`xpack/solutions/chat` (given it's solution code), and focus on your
owned changes, which are way more reasonable
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe McElroy <joseph.mcelroy@elastic.co>
Co-authored-by: Rodney Norris <rodney.norris@elastic.co>
Co-authored-by: Jedr Blaszyk <jedrazb@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Meghan Murphy <meghan.murphy@elastic.co>
Removes the "disabled" flag for Security's Entity Store feature from the
Security Solution's serverless configuration (i.e., effectively enabling
the feature in Serverless).
This feature has already been tested in ECH.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In https://github.com/elastic/kibana/pull/170234, we added validation on
the security solution settings in serverless that is enabled through the
`xpack.securitySolution.enableUiSettingsValidations` config setting. In
this PR, we move this setting to `config/serverless.security.yml` so
that it follows the sustainable architecture principles.
## Summary
Enables the SIEM Migrations feature in serverless. The experimental flag
will be cleaned later.
> [!NOTE]
To release this feature as planned (Friday 28th March 2025), this PR
needs to merge between Monday **24** and Thursday **27**
### Screenshot
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
The intent is to have a centralised place to store the list of Kibana
solutions and serverless project types.
To that end, this PR creates a `@kbn/projects-solutions-groups` package.
It also adds the new solution type `'chat'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Towards https://github.com/elastic/response-ops-team/issues/248
In this PR, I'm setting the default `xpack.task_manager.capacity` value
to `20` for security serverless projects. We've incremented this setting
gradually via gitops over the past few months and now it's set to `20`
across all environments. Before we cleanup the gitops repo, we need to
roll this out to all environments for the setting to remain in place.
# Release note
Legacy OpenSSL algorithms have been disabled by default. Further
information on which algorithms can be found at
https://docs.openssl.org/3.0/man7/OSSL_PROVIDER-legacy. These can be
re-enabled by adding `--openssl-legacy-provider` to
`$KBN_PATH_CONF/node.options`
