## Summary
This PR is part of the Kibana Sustainable Architecture effort.
The goal is to start categorising Kibana packages into _generic
platform_ (`group: "platform"`) vs _solution-specific_.
```
group?: 'search' | 'security' | 'observability' | 'platform'
visibility?: 'private' | 'shared'
```
Uncategorised modules are considered to be `group: 'common', visibility:
'shared'` by default.
We want to prevent code from solution A to depend on code from solution
B.
Thus, the rules are pretty simple:
* Modules can only depend on:
* Modules in the same group
* OR modules with 'shared' visibility
* Modules in `'observability', 'security', 'search'` groups are
mandatorily `visibility: "private"`.
Long term, the goal is to re-organise packages into dedicated folders,
e.g.:
```
x-pack/platform/plugins/private
x-pack/observability/packages
```
For this first wave, we have categorised packages that seem
"straightforward":
* Any packages that have:
* at least one dependant module
* all dependants belong to the same group
* Categorise all Core packages:
* `@kbn/core-...-internal` => _platform/private_
* everything else => _platform/shared_
* Categorise as _platform/shared_ those packages that:
* Have at least one dependant in the _platform_ group.
* Don't have any `devOnly: true` dependants.
### What we ask from you, as CODEOWNERS of the _package manifests_, is
that you confirm that the categorisation is correct:
* `group: "platform", visibility: "private"` if it's a package that
should only be used from platform code, not from any solution code. It
will be loaded systematically in all serverless flavors, but solution
plugins and packages won't be able to `import` from it.
* `group: "platform", visibility: "shared"` if it's a package that can
be consumed by both platform and solutions code. It will be loaded
systematically in all serverless flavors, and anybody can import / use
code from it.
* `group: "observability" | "security" | "search", visibility:
"private"` if it's a package that is intented to be used exclusively
from a given solution. It won't be accessible nor loaded from other
solutions nor platform code.
Please refer to
[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)
for any related questions.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In Kibana CI we try to replicate MKI env as much as possible and keeping
roles privileges in sync is important. It often leads to test passing on
KIbana PRs / on-merge pipelines and later failing against real
serverless projects on MKI.
Currently the process is manual, this PR updates predefined security
serverless roles based on
https://github.com/elastic/elasticsearch-controller/pull/771
## Summary
This pr adds 2 new sub feature permissions to the cases plugin in
stack/security/observability, that behave as follows. The first is for
controlling the ability to reopen cases. When Cases has the read
permission, and the reopen permission is not enabled, users have
permissions as before. When enabled, users can move cases from closed to
open/in progress, but nothing else. If a user has all and this
permission, they can do anything as before, if the option is unselected,
they can change case properties, and change a case from open to
anything, in progress to anything, but if the case is closed, are unable
to reopen it.
The 2nd permission is 'Add comment'. When enabled and the user has case
read permissions, users can add comments, but not make any other changes
to the case. When the user has read and this deselected, read functions
as before. When a user has this permission and cases is all, this
functions as all. When they have all but this permission is deselected,
the user can do everything normally, except add cases comments.
### Checklist
- [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/packages/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
---------
Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#192233
Just in time for Thanksgiving - a full buffet of FIPS testing fixes
Usage of non-compliant algorithms manifest as runtime errors, so it is
imperative that we attempt to run all tests possible with Kibana in FIPS
mode. However, several overrides are needed to run Kibana in FIPS mode,
resulting in setup that make it impossible to run.
## In this PR
- Enable Unit tests for FIPS pipeline
- Enable Integration Tests for FIPS pipeline
- Enable Full FTR suite for FIPS pipeline (smoke test had originally run
a subset)
- Skip tests that break with overrides
- Fix/change tests to work in FIPS mode to maximize coverage
- Examine necessity of MD5 when installing from source (TBD based Ops PR
feed back, see self review below)
- Remove md5 from es_file_client options
## Latest Successful FIPS Test Run
https://buildkite.com/elastic/kibana-fips/builds/268
---------
Co-authored-by: Brad White <Ikuni17@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Larry Gregory <larry.gregory@elastic.co>
closes [#3874](https://github.com/elastic/observability-dev/issues/3874)
## 📝 Summary
This PR adds new kibana privilege feature to control access to `Data Set
Quality` page under Stack Management's `Data` section.
Had to fix a lot of tests since the `kibana_admin` role gets access by
default to all kibana features one of which now is the `Data Set
Quality` page. At the same time this made the `Data` section visible to
any user with `kibana_admin` role.
## 🎥 Demo
https://github.com/user-attachments/assets/ce8c8110-f6f4-44b8-a4e7-5f2dd3deda66
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Updating default roles for Oblt project and ES nodes settings for
Security project to match elasticsearch-controller configuration
Adding obs teams for review to bring attention: we need to copy changes
from controllers manually to make sure our serverless simulation in
Kibana CI is close to real MKI env
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/185601
## Summary
Using non-compliant algorithms with Node Cryptos createHash function
will cause failures when running Kibana in FIPS mode.
We want to discourage usages of such algorithms.
---------
Co-authored-by: Sid <siddharthmantri1@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Updated `js-yaml` to `4.1.0`.
This PR also introduces a type override for the `js-yaml` load function
to maintain compatibility across the codebase. Specifically, updated
type definition of the load function looks as follows:
```typescript
function load<T = any>(str: string, opts?: jsyaml.LoadOptions): T;
```
The original type definition of the load function in `js-yaml` changed
from `any` to `unknown`. This change would require extensive type
updates throughout the entire repository to accommodate the `unknown`
type. To avoid widespread type changes and potential issues in the
codebase, the type is overriden back to `any` for now.
This is a temporary measure, we plan to address the necessary type
changes in subsequent PRs, where teams will gradually update the
codebase to work with the `unknown` type.
### 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
## Release note
Updated `js-yaml` to `4.1.0`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
The problem we're trying to solve here is to get access to
`elasticsearch-serverless` logs when they're started in docker
containers in the background (and `elasticsearch`, although currently we
don't test against that in docker for now).
## Solution
In essence:
- we needed to remove the `--rm` flag, this would allow for the
containers to stay present after they're done.
- after this, we can run `docker logs ...` on FTR post-hooks, save
these, then archive these files to buildkite
- because the containers are not removed upon finishing, we need to
clean up dangling containers before starting up
Backporting is probably not necessary, because this is only applicable
for serverless - and serverless is only supposed to run on main.
Solves: https://github.com/elastic/kibana/issues/191505
## Summary
Updates usage of `js-yaml` `load` and `dump` to `safeLoad` and
`safeDump`, in preparation for a major version update of dependency,
where the default behavior will be that of the safe function variants.
## Note to reviewers
`safeDump` will throw if it encounters invalid types (e.g. `undefined`),
whereas the `dump` function will still write the file including the
invalid types. This may have an affect within your use cases - if
throwing is not acceptable or is unhandled. To avoid this the
`skipInvalid` option can be used (see
https://github.com/nodeca/js-yaml#dump-object---options-) - this will
write the file, stripping out any invalid types from the input.
Please consider this when reviewing the changes to your code. If the
`skipInvalid` option is needed, please add it, or let us know to make
the change.
---------
Co-authored-by: Sid <siddharthmantri1@gmail.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
Co-authored-by: Elena Shostak <elena.shostak@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
closes#190212
This PR moves realm roles and mapping creation from FTR service to
`kbn/es` package in oder to configure ES properly when you start servers
with ` node scripts/functional_tests_server.js --config
<path/to/stateful_config_with_SAML_setup>`
It allows to start servers and investigate test scenario manually (e.g.
reproduce failure)
Thanks a lot to @azasypkin for ideas how to simplify and minimize the
code change.
Instead of 2 API calls to ES in FTR service we copy roles.yml to ES
config directory before its start and create role mapping via API (but
using template) as a part of security setup
How to test:
```
node scripts/functional_tests_server.js --config x-pack/test/api_integration/deployment_agnostic/stateful.config.ts
curl -X GET "http://localhost:9220/_security/role_mapping" -H "Content-Type: application/json" -u elastic:changeme
```
you should get the valid mapping back
Note: if you try to load Kibana manually, it won't work due to missing
mock-idp-plugin in stateful #190221 But automated tests are functional
and can be run via script.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
## [Security Solution] [Attack discovery] Attack Discovery RBAC / Display an upgrade CTA for the serverless essentials product tier
### Summary
This PR adds Role Based Access Control (RBAC) to Attack discovery.
Security users may enable or disable the new `Attack Discovery` RBAC feature shown in the figure below:
_Above: The new `Attack discovery` RBAC feature_
It is possible to for example, configure a custom role that enables Attack discovery, but disables the assistant, as illustrated by the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_all_assistant_none` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Trial | ✅ | ❌ | ❌ | ❌ |
| `has_attack_discovery_all_assistant_none` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Enterprise | ✅ | ❌ | ❌ | ❌ |
_Above: An example role that enables Attack discovery, but disables the assistant_
See the `Desk Testing` section of this PR for details.
This PR also fixes an issue where Attack discovery does not display an upgrade call to action (CTA) for the serverless _essentials_ product tier, per the before and after screenshots below:
#### Before
_Above: Before the fix, an upgrade CTA is NOT displayed for the serverless essentials product tier_
#### After
_Above: After the fix, an upgrade CTA is displayed for the serverless essentials product tier_
The fix above is implemented by adopting the upselling framework.
### New Feature ID
This PR adds a new Feature ID for attack discovery:
```typescript
export const ATTACK_DISCOVERY_FEATURE_ID = 'securitySolutionAttackDiscovery' as const;
```
in `x-pack/packages/security-solution/features/src/constants.ts`
### Upselling framework usage
This PR updates the Attack discovery page to use the upselling framework via the following summarized steps:
1. Removed the branching logic from `x-pack/plugins/security_solution/public/attack_discovery/pages/upgrade/index.tsx`, and moved the component to an upselling `section` component in `x-pack/packages/security-solution/upselling/sections/attack_discovery/index.tsx`, where the component was renamed to `AttackDiscoveryUpsellingSection`.
This `section` component handles (just) the styling of the upselling message and actions (by itself, without the page wrapper), and receives the following props:
```typescript
interface Props {
actions?: React.ReactNode;
availabilityMessage: string;
upgradeMessage: string;
}
```
The self managed and serverless-specific actions and `i18n` messages are passed down via the components described in the later steps below.
2. Removed all previous references to the `Upgrade` component (and references to `useProductTypes`) from the Attack discovery page in `x-pack/plugins/security_solution/public/attack_discovery/pages/index.tsx`, because the framework manages the upgrade case instead of the page itself.
3. Created an upselling `page` component `AttackDiscoveryUpsellingPage` in `x-pack/packages/security-solution/upselling/pages/attack_discovery/index.tsx`.
This component handles (just) the styling of the _page_ that wraps the Attack discovery `section`. It passes the same props to the previously described `AttackDiscoveryUpsellingSection` component.
4. Created a self-managed-specific `AttackDiscoveryUpsellingPageESS` component in `x-pack/plugins/security_solution_ess/public/upselling/pages/attack_discovery/index.tsx`
This component passes self-managed-specific upgrade action buttons / links and `i18n` strings to the previously described `AttackDiscoveryUpsellingPage`
5. Also for self managed, added a new `AttackDiscoveryUpsellingPageLazy` component to the existing file: `x-pack/plugins/security_solution_ess/public/upselling/lazy_upselling.tsx`
This component lazy loads the previously described `AttackDiscoveryUpsellingPageESS` component.
6. Added registration for the previously described `AttackDiscoveryUpsellingPageLazy` component to the existing `UpsellingPages` section in `x-pack/plugins/security_solution_ess/public/upselling/register_upsellings.tsx` with a `minimumLicenseRequired` of `enterprise`:
```
minimumLicenseRequired: 'enterprise',
```
7. Created a serverless-specific `AttackDiscoveryUpsellingPageServerless` component in `x-pack/plugins/security_solution_serverless/public/upselling/pages/attack_discovery/index.tsx`
This component passes serverless-specific `i18n` messages to the platform agnostic `AttackDiscoveryUpsellingPage` component.
8. Also for serverless, added a new `AttackDiscoveryUpsellingPageLazy` component to the existing file: `x-pack/plugins/security_solution_serverless/public/upselling/lazy_upselling.tsx`
9. Added registration for the previously described `AttackDiscoveryUpsellingPageLazy` component to the existing `upsellingPages` section in `x-pack/plugins/security_solution_serverless/public/upselling/upsellings.tsx` with the `assistant` PLI:
```
pli: ProductFeatureKey.assistant,
```
10. Added the `${ASSISTANT_FEATURE_ID}.ai-assistant` capability as an OR condition (via nested array, per the [framework](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts#L11-L22)) to the Attack discovery link in `x-pack/plugins/security_solution/public/attack_discovery/links.ts`. This addition enables the security route wrapper to check for upselling pages in serverless:
```
capabilities: [[`${SERVER_APP_ID}.show`, `${ASSISTANT_FEATURE_ID}.ai-assistant`]],
```
11. Added `licenseType: 'enterprise'` to the Attack discovery link in `x-pack/plugins/security_solution/public/attack_discovery/links.ts` to require an `enterprise` license for self managed
### Upgrade CTA gallery
The screenshots in this section document the CTA (or Welcome message when the feature is licensed) displayed for various license levels after the fix:
#### Users with the `None` privilege
If users with the `None` privilege manually enter an Attack discovery URL, e.g. `http://localhost:5601/app/security/attack_discovery`, the framework will display the following error prompt:
#### Self managed BASIC
#### Self managed PLATINUM
#### Self managed TRIAL
#### Self managed ENTERPRISE
#### Serverless ESSENTIALS
#### Serverless COMPLETE
## Desk Testing
### Severless: Desk testing (just) the upgrade CTA
Reproduction steps:
1) Comment-out any preconfigured connectors in `config/kibana.dev.yml`
2) Edit the configuration of `config/serverless.security.yml` to enable the `essentials` product tier:
```yaml
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'essentials' }
]
```
3) Start Elasticsearch
```sh
yarn es serverless --projectType security
```
4) Start a development instance of Kibana
```
yarn start --serverless=security --no-base-path
```
5) Navigate to Security > Attack discovery
**Expected result**
- An upgrade CTA is displayed, as illustrated by the _after_ screenshot below:
- The video tour is NOT displayed for serverless, as noted in the [original PR](https://github.com/elastic/kibana/pull/182605#issuecomment-2100607857)
**Actual result**
- An upgrade CTA is NOT displayed, as illustrated by the _before_ screenshot below:
### Desk testing Self Managed
To desk test self manged, we will:
1) Create (three) roles for testing
2) Create (three) users assigned to the roles
3) Test each role at `Basic`, `Trial`, `Platinum`, and `Enterprise` levels to verify:
- `Attack discovery` link visibility in the Security solution navigation
- Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable
- The upsell empty prompt includes the `Subscription plans` and `Manage license` actions
- When Attack discoveries are generated, the `View in Ai Assistant` button and popover menu action are enabled / disabled, based on availability of the `AI Assistant` feature
#### Creating (three) roles for testing
In this section, we will start a new (development) self managed deployment, and create the following three roles via Kibana Dev Tools:
- `has_attack_discovery_all_assistant_all`
- `has_attack_discovery_all_assistant_none`
- `has_attack_discovery_none_assistant_all`
To start the deployment and create the roles:
1) Add a pre-configured GenAI connector to `config/kibana.dev.yml`
2) Start a new (development) instance of Elasticsearch:
```sh
yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-07-31a
```
3) Start a local (development) instance of Kibana:
```
yarn start --no-base-path
````
4) Login to Kibana as the `elastic` user
5) Generate some alerts
6) Navigate to Dev Tools
7) Execute the following three API calls to create the roles:
<details><summary>PUT /_security/role/has_attack_discovery_all_assistant_all</summary>
<p>
``` ts
PUT /_security/role/has_attack_discovery_all_assistant_all
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_securitySolutionAssistant.minimal_all",
"feature_securitySolutionAttackDiscovery.minimal_all",
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
<details><summary>PUT /_security/role/has_attack_discovery_all_assistant_none</summary>
<p>
``` ts
PUT /_security/role/has_attack_discovery_all_assistant_none
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_securitySolutionAttackDiscovery.minimal_all",
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
<details><summary>PUT /_security/role/has_attack_discovery_none_assistant_all</summary>
<p>
``` ts
PUT /_security/role/has_attack_discovery_none_assistant_all
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_securitySolutionAssistant.minimal_all",
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
#### Creating (three) users assigned to the roles
In this section, we will create the following three users via Kibana Dev Tools using the API calls below (expand for details):
- `attack_discovery_all_assistant_all`
- `attack_discovery_all_assistant_none`
- `attack_discovery_none_assistant_all`
1) Navigate to Dev Tools
2) Execute the following three API calls to create the users:
<details><summary>POST /_security/user/attack_discovery_all_assistant_all</summary>
<p>
``` ts
POST /_security/user/attack_discovery_all_assistant_all
{
"username": "attack_discovery_all_assistant_all",
"password": "changeme",
"roles": [
"has_attack_discovery_all_assistant_all"
],
"full_name": "Attack Discovery All Assistant All",
"email": "user@example.com",
"metadata": {},
"enabled": true
}
```
</p>
</details>
<details><summary>POST /_security/user/attack_discovery_all_assistant_none</summary>
<p>
``` ts
POST /_security/user/attack_discovery_all_assistant_none
{
"username": "attack_discovery_all_assistant_none",
"password": "changeme",
"roles": [
"has_attack_discovery_all_assistant_none"
],
"full_name": "Attack Discovery All Assistant None",
"email": "user@example.com",
"metadata": {},
"enabled": true
}
```
</p>
</details>
<details><summary>POST /_security/user/attack_discovery_none_assistant_all</summary>
<p>
``` ts
POST /_security/user/attack_discovery_none_assistant_all
{
"username": "attack_discovery_none_assistant_all",
"password": "changeme",
"roles": [
"has_attack_discovery_none_assistant_all"
],
"full_name": "Attack Discovery None Assistant All",
"email": "user@example.com",
"metadata": {},
"enabled": true
}
```
</p>
</details>
#### Testing each role at `Basic`, `Trial`, `Platinum`, and `Enterprise` levels
In this section, we will test each of the self managed `Basic`, `Trial`, `Platinum`, and `Enterprise` license levels with the three roles we created for testing.
##### Testing the `has_attack_discovery_all_assistant_all` role
1) Login as the `attack_discovery_all_assistant_all` user
2) Navigate to the Security solution
3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_all_assistant_all` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_all` | Trial | ✅ | ❌ | ❌ | ✅ |
| `has_attack_discovery_all_assistant_all` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_all` | Enterprise | ✅ | ❌ | ❌ | ✅ |
##### Testing the `has_attack_discovery_all_assistant_none` role
1) Login as the `attack_discovery_all_assistant_none` user
2) Navigate to the Security solution
3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_all_assistant_none` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Trial | ✅ | ❌ | ❌ | ❌ |
| `has_attack_discovery_all_assistant_none` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Enterprise | ✅ | ❌ | ❌ | ❌ |
##### Testing the `has_attack_discovery_none_assistant_all` role
1) Login as the `attack_discovery_none_assistant_all` user
2) Navigate to the Security solution
3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_none_assistant_all` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_none_assistant_all` | Trial | ❌ | ❌ | ❌ | ❌ |
| `has_attack_discovery_none_assistant_all` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_none_assistant_all` | Enterprise | ❌ | ❌ | ❌ | ❌ |
---------------------------------------------
### Serverless Testing
To desk test serverless, we will test the `essentials` and `complete` product tiers to verify:
- `Attack discovery` link visibility in the Security project navigation
- Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable
- The upsell empty prompt does NOT include the `Subscription plans` and `Manage license` actions
- When Attack discoveries are generated, the `View in Ai Assistant` button and popover menu action are enabled
#### Essentials tier testing
1) Add a pre-configured GenAI connector to `config/kibana.dev.yml`
2) Edit the configuration of `config/serverless.security.yml` to enable the `essentials` product tier:
```yaml
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'essentials' },
{ product_line: 'endpoint', product_tier: 'essentials' },
]
```
2) Start a new (development) instance of Elasticsearch:
```sh
yarn es serverless --clean --projectType security
```
3) Start a local (development) instance of Kibana:
```
yarn start --serverless=security --no-base-path
````
4) select the `admin` role
5) Generate some alerts
6) Verify your observations match the expected behavior in the table below:
| Role | Tier | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `viewer` | essentials | ✅ | ✅ | ❌ | ❌ |
| `editor` | essentials | ✅ | ✅ | ❌ | ❌ |
| `t1_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `t2_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `t3_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `threat_intelligence_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `rule_author` | essentials | ✅ | ✅ | ❌ | ❌ |
| `soc_manager` | essentials | ✅ | ✅ | ❌ | ❌ |
| `detections_admin` | essentials | ✅ | ✅ | ❌ | ❌ |
| `platform_engineer` | essentials | ✅ | ✅ | ❌ | ❌ |
| `endpoint_operations_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `endpoint_policy_manager` | essentials | ✅ | ✅ | ❌ | ❌ |
| `admin` | essentials | ✅ | ✅ | ❌ | ❌ |
| `system_indices_superuser` | essentials | ✅ | ✅ | ❌ | ❌ |
### Complete tier testing
1) Stop the running Kibana server (from the previous Essentials tier testing)
2) Edit the configuration of `config/serverless.security.yml` to enable the `complete` product tier:
```yaml
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'complete' },
{ product_line: 'endpoint', product_tier: 'complete' },
]
```
3) Restart a local (development) instance of Kibana:
```
yarn start --serverless=security --no-base-path
````
4) Verify your observations match the expected behavior in the table below:
| Role | Tier | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------|----------|--------------------|-------------|--------------------|---------------------------|
| `viewer` | complete | ✅ | ❌ | ❌ | ✅ |
| `editor` | complete | ✅ | ❌ | ❌ | ✅ |
| `t1_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `t2_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `t3_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `threat_intelligence_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `rule_author` | complete | ✅ | ❌ | ❌ | ✅ |
| `soc_manager` | complete | ✅ | ❌ | ❌ | ✅ |
| `detections_admin` | complete | ✅ | ❌ | ❌ | ✅ |
| `platform_engineer` | complete | ✅ | ❌ | ❌ | ✅ |
| `endpoint_operations_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `endpoint_policy_manager` | complete | ✅ | ❌ | ❌ | ✅ |
| `admin` | complete | ✅ | ❌ | ❌ | ✅ |
| `system_indices_superuser` | complete | ✅ | ❌ | ❌ | ✅ |
## Summary
### This PR introduces a new type of API integration tests in FTR:
deployment-agnostic
#### Test suite is considered deployment-agnostic when it fulfils the
following criteria:
**Functionality**: It tests Kibana APIs that are **logically identical
in both stateful and serverless environments** for the same SAML roles.
**Design**: The test design is **clean and does not require additional
logic** to execute in either stateful or serverless environments.
### How It Works
Most existing stateful tests use basic authentication for API testing.
In contrast, serverless tests use SAML authentication with
project-specific role mapping.
Since stateful deployments also support SAML, deployment-agnostic tests
**configure Elasticsearch and Kibana with SAML authentication in both
cases**. For roles, stateful deployments define 'viewer', 'editor', and
'admin' roles with serverless-alike privileges.
New `samlAuth` service has `AuthProvider` interface with 2 different
implementations: depending on environment context (serverless or
stateful) appropriate implementation is used. But it remains on service
level and hidden in test suite.
test example
```
export default function ({ getService }: DeploymentAgnosticFtrProviderContext) {
const samlAuth = getService('samlAuth');
const supertestWithoutAuth = getService('supertestWithoutAuth');
let roleAuthc: RoleCredentials;
let internalHeaders: InternalRequestHeader;
describe('GET /api/console/api_server', () => {
before(async () => {
roleAuthc = await samlAuth.createM2mApiKeyWithRoleScope('admin');
internalHeaders = samlAuth.getInternalRequestHeader();
});
after(async () => {
await samlAuth.invalidateM2mApiKeyWithRoleScope(roleAuthc);
});
it('returns autocomplete definitions', async () => {
const { body } = await supertestWithoutAuth
.get('/api/console/api_server')
.set(roleAuthc.apiKeyHeader)
.set(internalHeaders)
.set('kbn-xsrf', 'true')
.expect(200);
expect(body.es).to.be.ok();
const {
es: { name, globals, endpoints },
} = body;
expect(name).to.be.ok();
expect(Object.keys(globals).length).to.be.above(0);
expect(Object.keys(endpoints).length).to.be.above(0);
});
});
}
```
Please read
[readme](966822ac87/x-pack/test/api_integration/deployment_agnostic/README.md)
for more details and step-by-step guide. It should help migrating
existing serverless tests to deployment-agnostic, assuming requirements
are met.
### Examples
Deployment-agnostic tests:
```
x-pack/test/api_integration/deployment_agnostic/apis/console/spec_definitions.ts
x-pack/test/api_integration/deployment_agnostic/apis/core/compression.ts
x-pack/test/api_integration/deployment_agnostic/apis/painless_lab/painless_lab.ts
```
Configs to run it:
```
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/oblt.serverless.config.ts
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/search.serverless.config.ts
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/security.serverless.config.ts
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/stateful.config.ts
```
PR is a compact version of #188737 with reduced changes in existing
serverless tests.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: elena-shostak <165678770+elena-shostak@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Closes#184948
## Summary
Implements creation of role-scoped API key using admin-scoped
privileges. This ensures that the API keys can be created for any role
scope, and further, that we can use the lowest privileged roles possible
for each API integration test.
## Note to reviewers
Most of the widespread changes here are simply function name changes.
- createApiKeyForRole -> createM2mApiKeyWithRoleScope
- invalidateApiKeyForRole -> invalidateM2mApitKeyWithRoleScope
- getSessionCookieForRole ->
getInteractiveUserSessionCookieWithRoleScope
M2m = Machine to machine. We wanted to be more specific about the
intention - API keys are typically for machine to machine automations
and apps, and cookies are typically for human interactive users.
cc: @azasypkin @dmlemeshko
---------
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
This PR introduces Alert Suppression for ML Detection Rules. This
feature is behaviorally similar to alerting suppression for other
Detection Engine Rule types, and nearly identical to the analogous
features for EQL rules.
There are some additional UI behaviors introduced here as well, mainly
intended to cover the shortcomings discovered in
https://github.com/elastic/kibana/issues/183100. Those behaviors are:
1. Populating the suppression field list with fields from the anomaly
index(es).
1. Disabling the suppression UI if no selected ML jobs are running
(because we cannot populate the list of fields on which they'll be
suppressing).
1. Warning the user if _some_ selected ML jobs are not running (because
the list of suppression fields may be incomplete).
See screenshots below for more info.
### Intermediate Serverless Deployment
As per the "intermediate deployment" requirements for serverless, while
the schema (and declared alert SO mappings) will be extended to allow
this functionality, the user-facing features are currently hidden behind
a feature flag. Once this is merged and released, we can issue a "final"
deployment in which the feature flag is enabled, and the feature
effectively released.
## Screenshots
* Overview of new UI fields
<img width="1044" alt="Screenshot 2024-05-16 at 3 22 02 PM"
src="8c07700d-5860-4d1e-a701-eac84fc35558">
* Example of Anomaly fields in suppression combobox
<img width="881" alt="Screenshot 2024-06-06 at 5 14 17 PM"
src="9aa6ed99-1e02-44a0-ad1b-785136510d68">
* Suppression disabled due to no jobs running
<img width="668" alt="Screenshot 2024-06-17 at 11 23 39 PM"
src="a8636a52-31bd-4579-9bcd-d59d93c26984">
* Warning due to not all jobs running
<img width="776" alt="Screenshot 2024-06-17 at 11 26 16 PM"
src="f44c2400-570e-4fde-adce-e5841a2de08d">
## Steps to Review
1. Review the Test Plan for an overview of behavior
2. Review Integration tests for an overview of implementation and edge
cases
3. Review Cypress tests for an overview of UX changes
4. Testing on [Demo
Instance](https://rylnd-pr-181926-ml-rule-alert-suppression.kbndev.co/)
(elastic/changeme)
1. This instance has the relevant feature flag enabled, has some sample
auditbeat data, as well as the [anomalies archive
data](https://github.com/elastic/kibana/tree/main/x-pack/test/functional/es_archives/security_solution/anomalies)
for the purposes of exercising an ML rule against "real" anomalies
1. There are a few example rules in the default space:
1. A simple [query
rule](f6f5960d-7e4b-40c1-ae15-501112822130)
against auditbeat data
1. An [ML
rule](9122669e-b2e1-41ce-af25-eeae15aa9ece)
with per-execution suppression on both `by_field_name` and
`by_field_value` (which ends up not actually suppressing anything)
1. An [ML
rule](0aabc280-00bd-42d4-82e6-65997c751797)
with per-execution suppression on `by_field_name` (which suppresses all
anomalies into a single alert)
## Related Issues
- This feature was temporarily blocked by
https://github.com/elastic/kibana/issues/183100, but those changes are
now in this PR.
## Checklist
- [x] Functional changes are hidden behind a feature flag. If not
hidden, the PR explains why these changes are being implemented in a
long-living feature branch.
- [x] Functional changes are covered with a test plan and automated
tests.
* [Test Plan](https://github.com/elastic/security-team/pull/9279)
- [x] Stability of new and changed tests is verified using the [Flaky
Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner) in
both ESS and Serverless. By default, use 200 runs for ESS and 200 runs
for Serverless.
* [ESS - Cypress x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6449)
* [Serverless - Cypress x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6450)
* [ESS - API x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6447)
* [Serverless - API x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6448)
- [ ] Comprehensive manual testing is done by two engineers: the PR
author and one of the PR reviewers. Changes are tested in both ESS and
Serverless.
- [ ] Mapping changes are accompanied by a technical design document. It
can be a GitHub issue or an RFC explaining the changes. The design
document is shared with and approved by the appropriate teams and
individual stakeholders.
- [ ] (OPTIONAL) OpenAPI specs changes include detailed descriptions and
examples of usage and are ready to be released on
https://docs.elastic.co/api-reference. NOTE: This is optional because at
the moment we don't have yet any OpenAPI specs that would be fully
"documented" and "GA-ready" for publishing on
https://docs.elastic.co/api-reference.
- [ ] Functional changes are communicated to the Docs team. A ticket is
opened in https://github.com/elastic/security-docs using the [Internal
documentation request (Elastic
employees)](https://github.com/elastic/security-docs/issues/new?assignees=&labels=&projects=&template=docs-request-internal.yaml&title=%5BRequest%5D+)
template. The following information is included: feature flags used,
target ESS version, planned timing for ESS and Serverless releases.
---------
Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Currently, when you start both Serverless Elasticsearch (`yarn es
serverless --projectType=oblt` and Serverless Kibana (`yarn start
--serverless=oblt`) locally, by default the stack will be configured in
a way that developers are encouraged to use native users via the Kibana
native login form. The problem is that this doesn't correspond to what
our users use in production, where we solely rely on SAML-mapped users
that are different from the native users in a number of notable ways.
The problem is exacerbated by the fact that all native users you can use
during Serverless development locally **are operator users**. As a
result, this has led to a number of missed bugs in functionalities that
worked well locally but were broken for our users in production.
The only way to test Serverless Kibana locally with SAML-mapped users is
to include `--ssl` flags in both Elasticsearch and Kibana run commands,
but since it's not a default go-to command, many developers don't use
it. Also, with `--ssl` flag, both Elasticsearch and Kibana are set up
with TLS using self-signed certificates, even though TLS is only
required for Elasticsearch to configure the SAML realm. For Kibana, this
is rather annoying since browsers complain about non-trusted
certificates. Moreover, even with the `--ssl` argument, developers are
still presented with the option to pick an operator user, which has
proven to be very tempting due to a habit developed over many years.
The goal of this PR is to synchronize the local developer experience
with the experience we provide to our users in production and includes
the following changes:
* The `yarn es serverless --projectType=oblt|security|es` command will
automatically configure TLS and test-only SAML security realm for
Serverless Elasticsearch by default, but will still assume that
Serverless Kibana is NOT configured with TLS.
* The `yarn start --serverless=oblt|security|es` command will NOT
automatically configure TLS for Kibana to supress browser and HTTP
client warnings, but will still assume that Serverless Elasticsearch is
configured with TLS.
* The `yarn start --serverless=oblt|security|es` command will also try
to configure SAML authentication provider, and will hide the option to
use basic credentials to log in as an operator.
As a result, whenever a developer starts Serverless Elasticsearch and
Serverless Kibana locally with the default commands and navigates to
`http://localhost:5601` (notice `http://` and not `https://`), they will
be greeted with the following screen (only SAML project-specific roles
available by default):
__NOTE:__ If they click on `More login options` or navigate to `/login`
route directly, they will still be able to log in as an operator user,
if needed.
## Breaking changes
Unfortunately, due to the nature of Elasticsearch SAML configuration,
which requires the Kibana URL to be known at the time Elasticsearch is
started, and the fact that `kbn-es` cannot distinguish between cases
when `--ssl` is not provided and when TLS is explicitly disabled with
`--no-ssl`, the previously recommended configuration with the `--ssl`
argument for both Elasticsearch and Kibana will no longer work by
default. It will require an additional `--kibanaUrl` argument for the
`kbn es` command. For example, the following commands will lead to an
unusable experience since Elasticsearch will expect Kibana to be
configured WITHOUT TLS:
```bash
yarn es serverless --projectType=oblt|security|es --ssl
yarn start --serverless=oblt|security|es --ssl
```
This command will need to change to this:
```bash
yarn es serverless --projectType=oblt|security|es --ssl --kibanaUrl=https://localhost:5601
yarn start --serverless=oblt|security|es --ssl
```
We can potentially fix this if we somehow teach `kbn-es` CLI arguments
parser to distinguish between `--no-ssl` and missing `--ssl`, but I
didn't manage to find a way to do that.
## Supported configurations
1. Default or Elasticsearch TLS only, Elasticsearch is configured with
TLS, Kibana is configured WITHOUT TLS, SAML-test realm is configured and
native login form is hidden:
```bash
yarn es serverless --projectType=oblt|security|es [--ssl]
yarn start --serverless=oblt|security|es
```
2. Full TLS, both Elasticsearch and Kibana are configured with TLS,
SAML-test realm is configured and native login form is hidden:
```bash
yarn es serverless --projectType=oblt|security|es --ssl --kibanaUrl=https://localhost:5601
yarn start --serverless=oblt|security|es --ssl
```
3. No TLS, both Elasticsearch and Kibana are configured WITHOUT TLS,
SAML-test realm is NOT configured and only native login form for
operator users is available. We need `--no-ssl` for Kibana since by
default it assumes Elasticsearch is running with TLS enabled in
Serverless:
```bash
yarn es serverless --projectType=oblt|security|es --no-ssl
yarn start --serverless=oblt|security|es --no-ssl
```
## Notes
Forcing developers to use TLS for Elasticsearch with self-signed
certificates by default might be a little annoying for them as they
might need to adjust their tooling. If this change is merged, I'm going
to send an email with the relevant information to help developers
overcome these annoyances.
For example, if they query Elasticsearch with `curl` or `wget`, they
need to also specify `-k`/`--insecure` or `--no-check-certificate`
arguments respectively to ignore certificate errors.
TLS also makes it a bit difficult to intercept traffic coming from
Kibana to Elasticsearch with tools like Wireshark, but it's still
possible with a few more hoops. One just needs to run Kibana with a few
special command line arguments:
```bash
NODE_OPTIONS="--no-warnings --tls-cipher-list=AES128-SHA --tls-keylog=/some-path/keylog.txt" yarn start --serverless=oblt|security|es
```
And then use the created `keylog.txt` file to decrypt traffic
automatically in Wireshark: right-click an encrypted TLS packet and
click on `Protocol Preferences -> (Pre)-Master-Secret log filename…` and
choose the `keylog.txt` file in the dialog (more details can be found
[here](https://tutorialtech.net/how-to-decrypt-nodejs-tls-traffic-with-wireshark/)):
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
When we're seeing errors in FTR or on the serverless verification
pipeline, we have difficulty connecting back what version of
ES-Serverless is behind the tag `:latest`.
With a recent addition to the ES Serverless docker image, this info is
now contained in labels of the image.
This PR highlights this info in the verification pipeline, as well as
the FTR output from `kbn-es`.
- Serverless verification pipeline:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote/builds/1454
- FTR:
## Summary
The most recent versions of the Serverless Elasticsearch disable native
role mappings by default and this conflicts with the Mock IDP
package/plugin that we use for local development and tests. To unblock
ES snapshot promotion I explicitly enable native role mappings for Mock
IDP only, but eventually we should consider switching to a file-based
role mapping (`config/operator/settings.json`, I didn't manage to make
it work in a reasonable amount of time).
```bash
$ cat config/operator/settings.json
{
"metadata": {
"version": "%s",
"compatibility": "8.4.0"
},
"state": {
"role_mappings": {
"mock-idp-mapping": {
"enabled": true,
"role_templates": [
{
"format": "json",
"template": "{\"source\":\"{{#tojson}}groups{{/tojson}}\"}"
}
],
"rules": {
"all": [
{
"field": {
"realm.name": "cloud-saml-kibana"
}
}
]
}
}
}
}
}
```
/cc @albertzaharovits
Closeselastic/kibana-operations#96
[new pipeline run](https://buildkite.com/elastic/kibana-fips/builds/28)
[old pipeline run](https://buildkite.com/elastic/kibana-fips/builds/24)
- Fixes OpenSSL compilation so that it does not overwrite the OS version
and break OS functionality.
- Fixes issue where ES would not start due to ML pipe being unable to
write to Vagrant synced folder.
- Reenabled ML in FIPS pipeline
- Fixes permission where Kibana could not write UUID file.
- Fixes smoke test exit code not reporting correctly.
- Fixes Buildkite annotation for failed tests
[example](https://buildkite.com/elastic/kibana-fips/builds/23).
- Switches the base VM image from RHEL9 to Ubuntu due to RHEL9
subscription requirements to install repo packages.
- This blocked installing Chrome, causing tests using Webdriver to fail.
---------
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
When running serverless FTR locally, the data store is the same as for
local development. This data pollution can cause unintended results in
tests. This PR forces FTR to run in a clean data store every time in
`.es/stateless-cluster-ftr/*` and retains development data at
`.es/stateless/*`.
## Summary
The existence of `kibanaUrl` in the default parameters leads to the SAML
role provider being enabled for `yarn es docker --ssl` and then ES
crashing on startup. This option should only be a default for `yarn es
serverless --ssl`
## Summary
Closes https://github.com/elastic/kibana/issues/174771
While the security team works on Custom Roles for serverless, we want to
hide the content behind a feature flag.
An existing config option that was used to hide the Roles UI during the
initial phases of serverless has been repurposed, and will now toggle
both the Roles UI and the Roles Routes
`xpack.security.confg.ui.roleManagementEnabled` has been changed to
`xpack.security.confg.roleManagementEnabled` and will have to be set to
`true` in a config file while in serverless mode to show the Roles card
on the management screen and enable the UI/routes.
## Reviewers
Ive included a `viewer`:`changeme` user for testing (It will be removed
after approval).
## Testing
### xpack.security.config.roleManagementEnabled
1. In your `kibana.yml`, add
`xpack.security.confg.roleManagementEnabled: true`
2. Start up in serverless mode locally, login in with
`elastic_serverless`:`changeme`
3. Click `Project Settings` > `Management`
4. `Roles` card should display under `Other`
5. Navigate to `Roles`, it displays, but the `Edit Roles` page does not
work yet.
### Test as Viewer
1. In your `kibana.yml`, add either above option as you prefer
2. Start up in serverless mode locally, login in with
`viewer`:`changeme`
3. Click `Project Settings` > `Management`
4. `Roles` card should NOT display under `Other` and the `roles` URL
should not work.
## Screenshots
Roles card
<img width="1281" alt="Screenshot 2024-02-05 at 3 22 12 PM"
src="a1285ada-7ff7-495f-88a6-9847b3245518">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
## Summary
This PR updates FTR functional tests shared b/w projects to use SAML
authentication instead of login with default user and kibana `/login`
route.
Few notes for reviewers:
- admin role was added to each project roles.yml file and its definition
matches cloud one.
- please check your tests if selected role is as expected: the goal is
to run test with the role that has minimal required permissions, but
some tests were failing with lower access role:
- `viewer` - read only
- `editor` / `developer` for write actions (e.g. save search)
- `admin` if full access required
- svl_common_page.ts was updated:
- `cleanBrowserState()` is added to reset state b/w test suites by
deleting all cookies, clearing session & local storages.
- `loginWithRole(role: string)` starts with `cleanBrowserState()` call,
then sets the new cookie based on provided role and validates the role
is applied correctly. On its finish browser is at Kibana home screen.
- `loginAsAdmin()` and `loginWithPrivilegedRole()` to login as admin and
editor/developer roles.
- `forceLogout()` is only required in tests that use basic
authentication. It starts with `cleanBrowserState()` call and then loads
`/logout` route (we can't load base url because mock-id-plugin will
trigger redirects). On its finish browser is at Cloud login screen.
For @elastic/kibana-operations :
This change affects the login in the functional serverless tests (18
config files at the moment) and while it seems to be stable enough, it
might be the reason of sudden flakiness/failures on CI.
[Flaky-test-runner
60x](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5107)
to verify login via cookie is stable
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
## Summary
in https://github.com/elastic/kibana/pull/174284 we split serverless
roles into individual files per project.
If you run `yarn es serverless --ssl` ES will be provisioned only with
roles specified for elastisearch project type.
To use roles for oblt/security projects, you have to override roles file
with `--resources` flag:
```
yarn es serverless --ssl --resources /Users/dmle/github/kibana/packages/kbn-es/src/serverless_resources/project_roles/security/roles.yml
```
Since it is confusing and not dev-friendly approach, this PR adds new
required flag to `serverless` script: `--projectType`
Usage:
`yarn es serverless --projectType=es --ssl`
`yarn es --serverless=oblt --ssl`
roles.yml file will be picked up based on `projectType` value, you still
have an option to override it using `--resources` flag
How to test:
`yarn es serverless --project-type=oblt --ssl`
`yarn start serverless=oblt --ssl`
You should be able to login with all roles defined or Observability (and
other) project.
Cli docs were updated:
```
[main][~/github/kibana]$ node scripts/es --help
usage: es <command> [<args>]
Assists with running Elasticsearch for Kibana development
Available commands:
snapshot - Downloads and run from a nightly snapshot
source - Build and run from source
archive - Install and run from an Elasticsearch tar
build_snapshots - Build and collect ES snapshots
docker - Run an Elasticsearch Docker image
serverless - Run Serverless Elasticsearch through Docker
To start a serverless instance use the 'serverless' command with
'--projectType' flag or use the '--serverless=<ProjectType>'
shortcut, for example:
es --serverless=es
Global options:
--help
```
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
## Summary
in #174284 we split serverless roles into individual files per project.
This PR updates mock-idp-plugin we use to simulate SAML auth in "local"
setup to fetch roles based on `projectType` from the respective yml
file:
- since we read roles from a yml file, new end point `GET
/mock_idp/supported_roles` was added to handle it.
- loginPage & rolesSwitcher hooks are updated to fetch roles via http
- hardcoded roles removed
Few other changes were made:
- move `readRolesFromResource` from `kbn-test` to `kbn-es` for
convenience: it is used to read ES resource files.
- move `system_indices_superuser` to the bottom of the file so it won't
be the first choice in UI role selector (+ we plan to remove the value
in the future)
- Change MOCK_IDP_REALM_NAME to `cloud-saml-kibana` as it is the actual
provider name we use in setup.
<img width="1026" alt="image"
src="060b3c21-9c1a-4210-8b5f-2d574a8f78e7">
<img width="1593" alt="image"
src="4afde9df-5a7e-4ae5-a9f5-ab18b871fc1b">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
To make local/CI testing env closer to MKI experience this PR updates
serverless roles for each project to be defined in its own yml file.
When FTR tests are run, only project specific roles defined in the file
are provisioned. I use `kbnTestServer.serverArgs` from FTR config to get
projectType from `--serverless=<projectType>` and pass it to `kbn-es`.
If you start ES using `es serverless [<args>]` it will provision roles
defined for 'es' project by default, you need to use `--resources` flag
to override it with roles for other project types.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
### This PR enables user roles testing in FTR
We use SAML authentication to get session cookie for user with the
specific role. The cookie is cached on FTR service side so we only make
SAML auth one time per user within FTR config run. For Kibana CI service
relies on changes coming in #170852
In order to run FTR tests locally against existing MKI project:
- add `.ftr/role_users.json` in Kibana root dir
```
{
"viewer": {
"email": "...",
"password": "..."
},
"developer": {
"email": "...",
"password": "..."
}
}
```
- set Cloud hostname (!not project hostname!) with TEST_CLOUD_HOST_NAME,
e.g.
`export TEST_CLOUD_HOST_NAME=console.qa.cld.elstc.co`
### How to use:
- functional tests:
```
const svlCommonPage = getPageObject('svlCommonPage');
before(async () => {
// login with Viewer role
await svlCommonPage.loginWithRole('viewer');
// you are logged in in browser and on project home page, start the test
});
it('has project header', async () => {
await svlCommonPage.assertProjectHeaderExists();
});
```
- API integration tests:
```
const svlUserManager = getService('svlUserManager');
const supertestWithoutAuth = getService('supertestWithoutAuth');
let credentials: { Cookie: string };
before(async () => {
// get auth header for Viewer role
credentials = await svlUserManager.getApiCredentialsForRole('viewer');
});
it('returns full status payload for authenticated request', async () => {
const { body } = await supertestWithoutAuth
.get('/api/status')
.set(credentials)
.set('kbn-xsrf', 'kibana');
expect(body.name).to.be.a('string');
expect(body.uuid).to.be.a('string');
expect(body.version.number).to.be.a('string');
});
```
Flaky-test-runner:
#1https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4081#2https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4114
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Attempting to merge #170852 again now that the release artefact step has
been fixed as part of https://github.com/elastic/kibana/pull/171457
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Related to [#166340](https://github.com/elastic/kibana/issues/166340)
## Summary
Add mock identity provider and utils to test serverless user roles.
## Screenshot
### 1. Login selector
<img width="767" alt="Screenshot 2023-11-08 at 15 18 18"
src="82b4a29f-65b4-45d2-bed3-6d9f74043c48">
### 2. Single sign on screen
<img width="437" alt="Screenshot 2023-11-09 at 12 30 46"
src="3d5b6f26-5409-4169-a627-bcf6d09836d9">
### 3. User profile page
<img width="1041" alt="Screenshot 2023-11-08 at 17 36 22"
src="50bd4a5a-f9a8-4643-9384-9a352701b011">
## Testing
SAML is only supported by ES when running in SSL mode.
1. To test the mock identity provider run a serverless project in SSL
mode using:
```bash
yarn es serverless --ssl
yarn start --serverless=es --ssl
```
2. Then access Kibana and login in using "Continue as Test User".
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Adding `feature_securitySolutionAssistant.all` to all roles in Kibana.
Cypress test added to check different tiers have different authorization
to AI Assistant:
`x-pack/test/security_solution_cypress/cypress/e2e/ai_assistant/`
- `ai_assistant_feature_complete.cy.ts`
- `ai_assistant_feature_essentials.cy.ts`
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
issue: https://github.com/elastic/kibana/issues/168245
Adding missing "Analytics" features to all Security roles:
```
- feature_discover.all
- feature_dashboard.all
- feature_canvas.all
- feature_graph.all
- feature_maps.all
- feature_visualize.all
```
In order to verify the Discover link is present in the sidenav a new
cypress test for serverless has been added to:
`x-pack/test/security_solution_cypress/cypress/e2e/navigation/navigation.cy.ts`
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
**Addresses:** https://github.com/elastic/kibana/issues/164451
## Summary
This PR allows to run role based reused between ESS and Serverless Cypress tests.
## Details
The main idea behind is to make environmental differences for tests unnoticeable. As Serverless env already has roles and users but ESS env allows to create any possible role and user we just need to create Serverless roles and corresponding users + specific ESS roles and corresponding users in ESS env before running any ESS tests. This way tests will run in a similar env and don't have to bother by roles/users creation in test suites. This is achieved by using separate Cypress support files (Cypress includes `support/e2e.js` by default) `ess_e2e.ts` and `serverless_e2e.ts` executed for corresponding environments. `ess_e2e.ts` contains logic to create mentioned above roles and users while `serverless_e2e.ts` doesn't contain such logic.
_Only one user created per role and user has the same name as its corresponding role with `changeme` password._
To have an ability to create roles we need to store their definitions somewhere. It's also convenient to have JSON definitions instead of YAML. Plus Serverless roles should be pulled from `project-controller` repo but it's not addressed in this PR. I've chosen the following locations
- Serverless Security roles in `packages/kbn-es/src/serverless_resources/security_roles.json`. While `@kbn/es` is a common package it has `serverless_resources` folder containing `roles.yml` with a mix of `https://github.com/elastic/project-controller/blob/main/internal/project/observability/config/roles.yml`, `https://github.com/elastic/project-controller/blob/main/internal/project/esproject/config/roles.yml` and `https://github.com/elastic/project-controller/blob/main/internal/project/security/config/roles.yml` copied from `project-controller` and used for ES data restore. As there is no automation yet it looks logical to keep Security roles subset next to ES Serverless resources.
- ESS Security specific roles in `x-pack/plugins/security_solution/common/test/ess_roles.json`
On top of that the following has been done
- `reader` role replaced with `t1_analyst` where possible in tests (besides `e2e/explore/cases/attach_alert_to_case.cy.ts` but it's purely ESS test so it's fine) as `reader` is ESS specific and make harder to run the same tests in ESS and Serverless environments but both roles are almost equivalent
- `login()` helper function accepts all known roles (Serverless + ESS) but throws an exception if a custom ESS role is used under Serverless env
- `x-pack/plugins/security_solution/server/lib/detection_engine/scripts/roles_users` isn't necessary anymore as `security_roles.json` + `ess_roles.json` contain all the necessary data to create roles and users
### Does it enable role support for MKI environments?
No. This PR only enabling role support for Non-MKI Serverless environments. MKI env has predefined roles but not users. This will be addressed in a follow up PR.
## Flaky test runner
Two unskiped in this PR Serverless Cypress tests using non default role `detection_response/detection_alerts/missing_privileges_callout.cy.ts` and `detection_response/prebuilt_rules/prebuilt_rules_install_update_authorization.cy.ts` [150 runs](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3723) 🟢 (there is one env related failure but it doesn't look related to the changes in this PR)
