Part of https://github.com/elastic/kibana/issues/155764.
In this PR, I'm setting the
`xpack.task_manager.allow_reading_invalid_state` serverless setting to
`false` so Kibana doesn't allow reading invalid state when loading
tasks.
I'm also doing the same for the functional tests to ensure valid task
state is always read.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/163340
This PR disables graph in serverless. Specifically:
- creates a serverless yml setting for disabling graph
- adds the setting in serverless.yml
## Summary
fixes https://github.com/elastic/kibana/issues/160337
This PR
- hides cases in the serverless Elasticsearch project, cases APIs throw
error
- throws 403 from API when `owner=cases` for security or observability
serverless mode
- verifies the behaviour in serverless functional as well as
api_integration tests
**How to test**
- Boot up `es` serverless solution and make sure that `cases` from the
navbar is hidden and cannot not be accessible through url as well
- Boot up `observability` or `security` serverless solutions and make
sure that `cases` is available in the navbar and works fine
- Boot up classic kibana and make sure that the left navbar has the same
menu entries it always had.
### 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
20c1974e-44f0-45b0-80aa-e644fec148ff
### For maintainers
- [x] 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>
Reverts elastic/kibana#159674
The Elasticsearch team has changed their guidance about `fast_refresh`
and want this setting to be applied from within an Elasticsearch plugin
## Summary
Adds the necessary yml settings to the serverless config. These settings
are making ui changes in dashboards / visualizations editors and they
apply for all projects.
For testing run `yarn start --serverless=es` and check that the ui is
working as expected with the legacy editors (TSVB, agg based) in a read
only mode.
Starting in Node.js 17 the IP address from a DNS lookup resolves in the
order returned from the resolver. Prior versions resolve with IPv4
addresses sorted before IPv6 addresses.
This restores the previous behavior. In distributions, this can be
configured via the `--dns-result-order` flag in `node.options`.
Closes#163006
[Node.js 17
changelog](https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V17.md)
[Documentation](https://nodejs.org/docs/latest-v18.x/api/cli.html#--dns-result-orderorder)
Testing
1) Resolve localhost to 127.0.0.1 and then ::1 in `/etc/hosts`
2) `yarn start`. Logs should indicate connecting to elasticsearch over
127.0.0.1:9200
## Summary
Closes https://github.com/elastic/kibana/issues/160141
The avatar menu needs to be displayed for serverless. It was previously
required to be hidden in serverless, so a config 'showNavLinks' was
added. This config is no longer needed, so it has been removed.
## Testing
Start KB with the `--serverless` flag and login as `elastic`.
The Avatar should appear in the top right coner.
## Summary
This PR sets up the reporting plugin for the serverless implementation
by adding properties to the existing reporting config.
Image reporting is enabled for dev mode but disabled for serverless.
Canvas is disabled for serverless.
## To Test
Run `yarn es snapshot --license trial` in one terminal and then `yarn
start`. Load sample data and you should be able to see the option to
have PDF and PNG reports in Dashboard's Share Menu.
Now run `yarn es snapshot --license trial` and `yarn serverless-es`. You
should see that Dashboard's share menu does not include PDF or PNG
Reports. However there is still the option to see run CSV reports and
see the Reporting in Management.
### 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>
Co-authored-by: Timothy Sullivan <tsullivan@elastic.co>
## Summary
First step for https://github.com/elastic/security-team/issues/6677
Aim of this PR is embed Discover in Security Solution. Discover must be
embedded as a complete app with certain set of capabilities working. The
set capabilities that need to working are listed here :
https://github.com/elastic/security-team/issues/6673
Release notes should be based on
https://github.com/elastic/security-team/issues/6673
### ⚠️ Note
- These changes are only available in serverless mode of security
solution behind a feature-flag called `discoverInTimeline`. Adds below
options to `serverless.security.yml`:
```yaml
# Serverless security specific options
xpack.securitySolution.enableExperimental:
- discoverInTimeline
```
You can use below command to run serverless instance of security
solution :
```bash
yarn serverless-security
```
This Implements following changes for each plugin.
### Discover
1. Exports Discover App as Lazy component.
2. Ability to override Discover Services.
3. Adds a parameter `mode` which switches off/on certain options based
on the `mode`. `Mode` has possible values of `embedded` and
`standalone`. For example, `embedded` switches off Discover breadcrumb
syncing, because consuming app may not need it.
### Unified Search
1. Ability to export a Search bar with custom depedency instances.
2. For example, today Unified Search uses a singleton global
`dataService` which store global KQL filters and queries. This
customization, let consumers of unified search to pass a new instance of
`dataService`.
4. Please see below diagram for more clarity.
### Navigation
1. Ability to export a custom stateful TopNav Menu which includes:
- DataView picker
- KQL Search Bar
- TimeRange Selector
2. Currently navigation consumes an instance of unified service which
uses a global singleton `data` service.
3. This PR creates a new instance of unified search which is then passed
to navigation to get a custom instance of `TopNav` Menu.
### Security Solution
1. Imports Discover Container Component
2. Uses customization point to pass a custom query bar.
3. Implements Custom KQL Query Bar with below customizations
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
This is a follow-up to https://github.com/elastic/kibana/pull/160671,
where the Management plugins were disabled using `contextRef`.
The configs for disabling the UI of the security management plugins were
added in https://github.com/elastic/kibana/pull/158186. In this PR, they
are changed so that they follow the same convention for disabling the
Management plugins - setting the default values of the configs to `true`
and explicitly setting them to `false` in the `serverless.yml` file.
This way, we have a clear view in `serverless.yml` of all
plugins/functionalities that have been disabled.
## Summary
This moves alerting in Serverless Search to the Stack Management
alerting page, and removes
To remove these rule types, I had to disable the observability,
securitySolution, uptime, monitoring and infra plugins and make sure
that their server plugins (not just the frontend plugins) respected the
`enabled: false` flag.
Closes https://github.com/elastic/kibana/issues/160160
## Summary
This PR adds functionality to the new autocomplete generation script for
creating an `availability` property in the spec files that is used for
filtering out endpoints that are not available in the current
environment (e.g. `serverless` or `stack`). It also adds a config
setting in the console plugin that specifies the current environment.
This setting is also configured accordingly for serverless.
**How to test**
1. Checkout the [ES specification
repo](https://github.com/elastic/elasticsearch-specification)
2. Run the command with `node scripts/generate_console_definitions.js
--source <ES_SPECIFICATION_REPO> --emptyDest` where
`<ES_SPECIFICATION_REPO>` is the absolute path to the root of the ES
specification repo
3. Start the classic Kibana and verify that Console suggests only
endpoints that are available in the `stack` environment.
4. Start Kibana in any of the serverless modes and verify that Console
suggests only endpoints that are available in the `serverless`
environment.
Here are some example endpoints that can be used for testing:
| Endpoint | Available in Stack | Available in Serverless |
| ------------- | ------------- | ------------- |
| [POST
_bulk](https://github.com/elastic/elasticsearch-specification/blob/main/specification/_global/bulk/BulkRequest.ts)
| Yes | Yes |
| [DELETE
_security/oauth2/token](https://github.com/elastic/elasticsearch-specification/blob/main/specification/security/invalidate_token/SecurityInvalidateTokenRequest.ts)
| Yes | No |
Closes: https://github.com/elastic/kibana/issues/155330
Adds `index.fast_refresh` to `.apm-custom-link` in order to ensure fast
index refreshes on serverless (1 second periodic refreshes instead of 5
second which is the new default on serverless).
This is pending on Elasticsearch adding support for `index.fast_refresh`
(https://github.com/elastic/elasticsearch/pull/96660)
---------
Co-authored-by: miriam.aparicio <miriam.aparicio@gmail.com>
Co-authored-by: Miriam <31922082+MiriamAparicio@users.noreply.github.com>
## Summary
closes: https://github.com/elastic/kibana/issues/159685
- Renaming _x-pack/plugins_:
`serverless_security` -> `security_solution_serverless`
`ess_security` -> `security_solution_ess`
- All the related configurations and types have also been renamed.
- i18n translation prefixes updated
- relocation of internal `security_solution_serverless` directories to
be consistent with `security_solution_ess`
### Eslint
I also added the plugins in the `.eslintrc` configuration, defining the
same rules as the `security_solution` plugin.
All eslint errors have been addressed (mainly _type_ imports errors)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/159392
## Summary
This PR hides the feature visibility section on the space management
screen and disables adding `disabledFeatures` when creating or updating
spaces using the REST API or spaces client on serverless.
## Screenshot
## Testing
1. Start Kibana in serverless mode: `yarn start --serverless`
2. Edit default space and observe that the feature visibility section is
not rendered
3. Quit Kibana and restart using classic mode: `yarn start`
4. Edit default space and observe that the feature visibility section is
rendered correctly
5. Other considerations:
- Disabling feature visibility in the classic offering should throw an
error (`xpack.spaces.allowFeatureVisibility: false`)
- Enabling feature visibility on serverless should throw an error
(`xpack.spaces.allowFeatureVisibility: true`)
Partially addresses https://github.com/elastic/kibana/issues/159590
## Summary
This PR disables the Advanced settings plugin for all projects in
serverless.
**How to test:**
1. Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
serverless-{mode}` where {mode} can be `es`, `security`, or `oblt`.
2. Verify that the Advanced settings app is not accessible and its
endpoint (`app/management/kibana/settings`) leads to the Stack
Management landing page.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces two changes:
(1) Refactors the handler resolution logic to _not_ depend on the
`--serverless` cli arg by adding a new piece of config
`server.versioned.routeResolution` that accepts `newest | oldest`. This
piece of config is passed down instead of the `serverless` cli arg as
well as updating test cases
(2) Adds a new piece of config to turn off the client version checking.
This will be needed for rolling upgrades to allow old browser traffic to
reach new Kibana servers when there is stack version change.
Close https://github.com/elastic/kibana/issues/158723
## Open questions
* Do we want to make the version check still take _major_ version bumps
into account?
## Summary
Until [this issue](https://github.com/elastic/kibana/issues/153720) is
resolved, this config flag allows us to access the task manager
background worker utilization API in serverless to support autoscaling
of background task deployments
## To Verify
Run es: `yarn es snapshot`
Run serverless on this branch: `yarn serverless-es`
Verify you see the following warning in the logs:
```
[2023-06-12T12:47:19.641-04:00][WARN ][plugins.taskManager] Disabling authentication for background task utilization API
```
and you can access `/api/task_manager/_background_task_utilization`
without logging in
# Summary
This PR adapts the endpoint RBAC to the new Serverless PLI features
architecture.
The changes are the following:
## App Features
### New appFeatures keys for endpoint
The `endpointExceptions` PLI has been added to the _Endpoint Essentials_
product tier and `endpointResponseActions` to the _Endpoint Complete_
686bc2eeaa/x-pack/plugins/serverless_security/common/pli/pli_config.ts (L20-L23)
### Endpoint appFeatures capabilities config
The features configuration for each appFeature (PLI) has been added.
They will be configured within the Security Kibana features only when
the appFeature is enabled by the selected Security product type. (Note
that all of them will be always added in regular ESS deployments, only
in Serverless we'll have different product types)
4d9f0c3a6f/x-pack/plugins/security_solution/server/lib/app_features/security_kibana_features.ts (L170-L198)
These are the capabilities that seemed relevant to me for each PLI, but
I don't have enough expertise in Endpoint operations to know for sure
what Kibana sub-features and capabilities need to be included in each
appFeature. The PLIs are in a private spreadsheet with the following
descriptions.
- endpointExceptions:
- endpointResponseActions:
I'll need Endpoint team members to confirm there's no missing or wrong
capability in each appFeature config.
### Host isolation capabilities
It is important to mention that in the configuration above, to have some
capabilities available we are adding some sub-features directly using
the `subFeatureIds` entry, but for host_isolation capabilities, we are
doing it in a slightly different way, using the `subFeaturesPrivileges`,
this way the privileges are added to existing subFeatures.
The reason is we need to have the _write_ (isolate operation) only in
payment product types, but the _read_ and _delete_ (release operation)
capabilities should be always available, to allow releasing previously
isolated hosts after a product downgrade.
To do this we always include the `host_isolation_all` and
`host_isolation_exceptions_all` subFeatures in the base configuration,
but they only contain _read_ and _delete_ capabilities by default, only
when the product tier allows the proper appFeatures the _write_
capability is added to the same subFeatures privileges.
## Endpoint Authz module
### Remove "superuser" specific check
This specific check:
```
// user is superuser, always return true
if (isSuperuser) {
return true;
}
```
Has been removed, this has no behavioral impact, superuser has all
capabilities enabled anyway.
### Remove usage of `endpointRbacEnabled` and `endpointRbacV1Enabled`
experimental flags
They are already enabled by default. superuser will still have the
authorization to access all the features. The only change is the
endpoint sub-features will always be visible in the Kibana Privilege
section of the Role management page, they were hidden when these
experimental flags were disabled.
### Remove double _write_ check for _read_ authorizations:
We were doing unnecessary checks for the _write_ capabilities in the
_read_ authorizations, like: ```
const canReadEndpointList = canWriteEndpointList ||
hasKibanaPrivilege(fleetAuthz, 'readEndpointList');
```. Sub-features already add _read_ and _write_ capabilities on the
`all` privilege, so these double checks were unnecessary.
### Extract `hasHostIsolationExceptionsItems` flag
This flag was used to grant _read_ and _delete_ authorization for Host
Isolation Exceptions (HIE) when there is data, basically turning them
free features when there is data to perform the actions. This is needed
to allow users to remove HIE after a license downgrade scenario, which
is good.
However, we needed to do this API call from outside the auth module, in
every place we needed to call `calculateEndpointAuthz`, and we were also
adding the responsibility to do some auth-specific logic with licenses
outside the auth module, which is not good.
In addition, it is not very consistent to make authorization depend on
the existence of data to perform an action. Authorization should be
based only on the role capabilities and tiers/licenses, if some parts of
the application want to show/hide stuff depending on the data, that's
not the auth module's responsibility.
I checked all the places where we use the HIE _read_ and _delete_
authorizations, and the only place where we really need them to be
denied (when there is no data) is in the _links_, we need to remove the
HIE link from the app in this situation.
So, this PR moves the data check to the links.ts module, making the
_read_ and _delete_ permissions always granted without a license (they
will still be useless without data), the same way the `canUnIsolateHost`
authorization works. And then doing the async data check to remove the
HIE link in the _management/links.ts_ module itself, only in the last
case where we really need to know it:
4d9f0c3a6f/x-pack/plugins/security_solution/public/management/links.ts (L257-L262)
This flag extraction is unrelated to the integration of the new
architecture, I included it only to extract complexity from the _authz_
module and simplify its usage, but this change can be rolled back if we
consider it.
# Testing
- To start the application in ESS (non-serverless) mode, run it normally
with `yarn start`. Everything should keep working as usual with all
features available and capabilities should only be restricted by the
user role.
- To start the application in Serverless mode run with `yarn
serverless-security`. It sets a random root path, so access the main URL
at "http://localhost:5601/" to be redirected.
By default the "Endpoint Complete" product line is selected in the
_serverless.security.yml_ config, so everything should be available as
in ESS with the default config.
686bc2eeaa/config/serverless.security.yml (L11-L15)
Once in Serverless mode, in order to see the difference between product
types, we can change the _Endpoint_ `product_tier` to `essentials`, as
per the pli_config, this change should remove all the capabilities
included by the `endpointResponseActions` appFeatures config.
To check how the application behaves without the `endpointExceptions`
PLI, we can remove the _Endpoint_ `product_line` entirely from the
product array, leaving the _Security_ `product_line` alone.
# Next steps
## Upselling page
The product upselling page has not been registered for endpoint pages in
this PR, so when any of these pages are unauthorized because of the
serverless product tier, and they are accessed directly by URL they
still show the `Privileges required` screen.
This is arguably not entirely correct. However, an upselling page can be
registered to display a "Buy a higher tier" message when the privilege
is denied because of the product type, if it is unauthorized because of
the user role the "Privileges required" page will still show.
I did not include the endpoint upselling page in this PR to keep it
simple, but the registry is already implemented in the main proposal, we
can define and register them in a follow-up PR.
## Superuser role in authz module
Almost all "superuser" role conditionals have been removed from the
Endpoint authz module, but there is only one check left here:
24330f2356/x-pack/plugins/security_solution/common/endpoint/service/authz/authz.ts (L85)
This `canAccessEndpointManagement` flag looks deprecated, and it seems
to be used incorrectly in the few places where it is checked. If we
could fix the places that it is used, checking the proper authz flag, we
could definitively remove the `userRoles` parameter from the
`calculateEndpointAuthz` function, this will have an impact in the
different places where this function is called since they will no longer
need any async logic.
---------
Co-authored-by: Pablo Neves Machado <pablo.nevesmachado@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/155371
## Summary
PR adds Serverless Onboarding flow using Custom Integration. This would
also lay the foundation for us to complete get rid of Home Tutorial App
and move the remaining `onPrem` and `cloud` tutorials which are
currently still loaded using Home Tutorial App.
1. Adds new Custom Integration for Serverless Onboarding (Toggling Home
AApp Tutorial Integration)
2. Since we are migrating away from the Home App Tutorials, lot of
existing code has been duplicated and refactored for the custom
implementation. Home App Tutorial would require the Server to register
all the steps and the client to only register a custom component which
then would be loaded by Home App Tutorial component. We don't need to
follow this approach any more. All the UX logic has now been moved to
the Public folder with only Custom Integration done on the
`server/plugin.ts`.
3. As we are not sure how the solutions will be informed about being
running on Serverless or not, I have introduced a new variable in
`serverless.oblt.yml` file called `xpack.apm.serverlessOnboarding:
true`. With this the development has been done. This can be changed to
actual logic once we know more.
4. A new configuration `xpack.apm.managedServiceUrl` for accessing
Managed Service URL is also being added by Control Plane team as part of
https://elasticco.atlassian.net/browse/CP-2403. Hence this PR expects
this property to be present for Serverless.
5. Unit tests to toggle between `secret_token` and `api_key` depending
on availability has been added. No API Tests were added as no new API
created. Cypress Tests cannot be added due to Serverless
## Need help reviewing the PR ?
1. `config/serverless.oblt.yml` - Adds the new flag which would enable
this flow
2. `x-pack/plugins/apm/common/tutorial/tutorials.ts` - Defines the
configuration required to register the APM's Tutorial Custom Integration
3. `x-pack/plugins/apm/public/components/app/tutorials/commands` - This
directory contains all the agent specific data required to load the
TABLE with settings required for configuring APM MIS.
4. `x-pack/plugins/apm/public/components/app/tutorials/instructions` -
This folder contains all the individual agent specific instructions in
the format used by
[EuiSteps](https://eui.elastic.co/#/navigation/steps#complex-steps)
5. `x-pack/plugins/apm/public/components/routing` - Here we register our
custom route
6. Changes on the server side a quite small and they only register the
custom integration.
7.
`x-pack/plugins/apm/public/components/app/tutorials/serverless_instructions.tsx`
- This file currently defines all the logic for registering Serverless
instructions. We will soon have similar files for `onPrem` and `cloud`
instructions
### Risk Matrix
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| The flow depends on presence of a flag in `kibana.yml` file. | Low |
High | By default this flow will be disabled and would fallback to
traditional onboarding in absence of the flag. |
### Demo
d60f0610-1fea-4540-86f5-2d72ab97f640
### Updated Demo with Create API Button inside the table
e84d8d6c-a048-4638-9b63-45080feca90b
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Since the only way to reach logs onboarding is manually entering the url
it has been decided to enabled this plugin by default.
In serverless it was already enabled by default through the config.
Resolves#159028Resolves#159047
## Summary
Hide create spaces button when limit is reached.
## Screenshot
## Testing
1. Set the maximum number of allowed spaces to 1
```yml
xpack.spaces.maxSpaces: 1
```
2. Verify that the create spaces button is hidden and that a callout is
displayed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes: #155154 (introduced in #149878), builds on #155436 .
- Adds tests to ensure the configuration merging order, check those for
reference.
- Updates the README to explain the intention
For the tests, I needed to output something to the logs. I hope it's not
a big issue to log it. If needed, I might hide that behind a verbose- or
feature flag.
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
issue: https://github.com/elastic/kibana/issues/158810
follow-up of: https://github.com/elastic/kibana/pull/158179
Improves the Security AppFeatures architecture:
- SubFeatures now preserve always the same order in the Security Kibana
config, despite the order of processing of enabled appFeatures.
- Change the `productTypes` config format
- Update `getProductAppFeatures` to:
- process the new `productTypes` format.
- include _essentials_ tiers PLIs inside _complete_ tiers automatically.
- AppFeatures module now receives an array of PLIs instead of an object
- AppFeatures config now uses only SubFeature IDS instead of
`subActions` config objects directly
- Upselling components updated and `useProductTypeByPLI` implemented to
display the Product Type required
[Documentation](https://docs.google.com/document/d/1Ms8d8d_fbTTRHlBroEAKGNMNk3jFFgOAkVDRhqLxAPQ/edit?pli=1#)
issue: https://github.com/elastic/kibana/issues/158810
## Summary
This PR is a cleanup to make [this
POC](https://github.com/elastic/kibana/pull/155420) production ready
- Serverless PLI features splitting in Security Solution, to allow/deny
access to configured functionalities, using the current Kibana RBAC
service.
- Create the Upselling service to display Serveless-specific prompts in
the application when features are not available
- Create a `SecurityRoutePageWrapper` component that wraps Pages and
displays the upsell when necessary.
- We will refactor the code base to use `SecurityRoutePageWrapper`
everywhere on another PR.
- Create an Upsell page and section for entity analytics
bd8db822-2f4b-4545-9da7-bedc07d93f90
### test:
Serverless: `yarn serverless-security`.
* To change the product line you have to update
`xpack.serverless.security.productLineIds` on
`config/serverless.security.yml`.
ESS: `yarn start`
### Glossary
* PLI - Product Line Item (`Alert Triage`, `Osquery`, `Cases` , ... )
* Product Line - The product that the user is subscribed to (Security
Essentials, Security Complete, ...)
* essSecurity - New plugin with code that only runs for ESS offer
(non-serverless).
* App Feature - A security solution feature or group of features that
can be disabled for a product line. It can be mapped to PLIs (`Alert
Triage`, `Osquery`, `Cases` , ... ).
* Capability - A string that when present represents that the user can
access a given feature. A capability could be of the type UI or API
(`read_cases`, `crud_cases`, ...).
### Current architecture
### New architecture
### How does it work?
Every serverless product line (endpointEssentials, cloud essentials) can
define which features are enabled:
69d0fc15f4/x-pack/plugins/serverless_security/common/pli/pli_config.ts (L12-L19)
For ESS (non-serverless) offer we enable all features by default.
69d0fc15f4/x-pack/plugins/ess_security/server/constants.ts (L10-L13)
A feature can define privileges:
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/security_kibana_features.ts (L177-L185)
When the feature is enabled the privileges get merged into the base
config and injected into kibana features.
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/app_features.ts (L61-L70)
### TODO
- [x] lazy load these components
- [x] Add unit test to:
- ~SecurityRoutePageWrapper
x-pack/plugins/security_solution/public/common/components/security_route_page_wrapper/index.tsx~
-
~x-pack/plugins/security_solution/public/common/hooks/use_upselling.ts~
-
~x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts~
-
~x-pack/plugins/security_solution/public/common/lib/upsellings/upselling_service.ts~
- ~x-pack/plugins/serverless_security/common/pli/pli_features.ts~
-
~x-pack/plugins/serverless_security/public/components/upselling/register_upsellings.tsx~
-
~x-pack/plugins/security_solution/server/lib/app_features/app_features.ts~
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Partially addresses https://github.com/elastic/kibana/issues/157756
## Summary
This PR disables the Search Sessions plugin for serverless.
**How to test:**
1. Start Elasticsearch with `yarn es snapshot` and Kibana with yarn
`serverless-{mode}` where `{mode}` can be `es`, `security`, or `oblt`.
2. Verify that the Search Sessions app is not accessible and its path
(`app/management/kibana/search_sessions`) leads to the Stack Management
landing page.
## Summary
This PR makes the Migrate plugin disable-able for serverless.
Partially addresses https://github.com/elastic/kibana/issues/157756
**How to test:**
1. Start Elasticsearch with `yarn es snapshot` and Kibana with yarn
`serverless-{mode}` where `{mode}` can be `es`, `security`, or `oblt`.
2. Verify that the Migrate plugin doesn't show up in the nav bar and its
path (`management/data/migrate_data`) leads to the Stack Management
landing page.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#150884
## Summary
Adds both strictTransportSecurity and disableEmbedding to the
serverless.yml config file, which sets the defaults for Kibana running
in a serverless configuration. Note that the disabling of embedding is
for the serverless MVP, with a plan to more strategically and explicitly
allow embedding of specific resources in future releases.
- `server.securityResponseHeaders.strictTransportSecurity:
max-age=31536000; includeSubDomains`: Adds the
`strict-transport-security` response header. The browser should remember
that a site, including subdomains, is only to be accessed using HTTPS
for 1 year.
- `server.securityResponseHeaders.disableEmbedding`: true adds the
`X-Frame-Options` response header with a avalue of `SAMEORIGIN` and adds
`frame-ancestors 'self'` to the `content-security-policy` response
header.
Note: if you are running without TLS enabled locally, you can disable
the `strict-transport-security` response header by overriding the
setting in kibana.dev.yml (see Testing step 8 below).
### Testing (locally)
1. Start Elasticearch
3. Start Kibana with `yarn start --serverless`
4. Sign into Kibana and open your browser's dev tools
5. In the network tab, inspect one of the requests for localhost
6. In the Headers tab, verify the above defined headers and values are
present
7. Stop Kibana, and restart normally with `yarn start`
8. Repeat the process in steps 4-6 and verify that the above defined
headers and values are not present
9. Stop Kibana, edit the Kibana.dev.yml file by adding
`server.securityResponseHeaders.strictTransportSecurity: null`
10. Start Kibana with `yarn start --serverless`
11. Repeat the process in steps 4-6 and verify that the headers and
values associated with disableEmbedding are present while the
`strict-transport-security` response header is not present.
