## Summary
This PR adds the structure for workchat FTR tests and adds a few initial
tests as an example.
### Details about initially added tests
New test directories:
- `x-pack/test_serverless/api_integration/test_suites/chat`
- load a few common tests (that run on all project types)
- run `platform` security tests (taken over from `search` project type)
- `x-pack/test_serverless/functional/services/svl_chat_navigation.ts`
- load the `home page` common test
- run a simple navigation test, using the `svlChatNavigation` service
that has been introduced as an example
Note that these tests mostly serve as examples to prove things are
actually running and will have to be adjusted / removed / extended over
time. The purpose of this PR is NOT to add proper test coverage.
Closes#213469
---------
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
## Summary
This PR makes `security` a required field for route registration. To
incorporate the new required filed, changes has been made:
1. **Test file updates**. A lot of the updates made in this PR were made
in tests.
2. **Versioned route security configuration**. For the versioned route
`security` config has been lifted up to the top-level definition:
Before
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
...
}, handler)
.addVersion({
version: 1,
validate: false,
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
});
```
After
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
...
}, handler)
.addVersion({
version: 1,
validate: false,
});
```
3. **Type adjustments for route wrappers**. Type changes has been made
in:
-
`x-pack/solutions/observability/plugins/infra/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/metrics_data_access/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/synthetics/server/routes/types.ts`
-
`x-pack/solutions/observability/plugins/uptime/server/legacy_uptime/routes/types.ts`
Security was made an optional field for the wrappers defined in those
files, since the default security is provided in the wrapper itself and
then passed down to the core router.
### 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
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
__Closes: https://github.com/elastic/kibana/issues/215331__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The intent is to have a centralised place to store the list of Kibana
solutions and serverless project types.
To that end, this PR creates a `@kbn/projects-solutions-groups` package.
It also adds the new solution type `'chat'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/176219.
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come in around 2 weeks.
These first PRs are simply preparing the code by wiring up the
`UserProvideService`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
## Summary
closes#190221
This PR enables `mock-idp-plugin` when Kibana is started with stateful
FTR config for deployment-agnostic tests:
```
node scripts/functional_tests_server --config=x-pack/test/api_integration/deployment_agnostic/configs/stateful/platform.stateful.config.ts
```
<img width="1574" alt="image"
src="https://github.com/user-attachments/assets/494e89ee-cd65-4dde-86da-a5e2c28ec40d">
You can pick up one of the the role defined for stateful SAML
authentication in
https://github.com/elastic/kibana/blob/main/packages/kbn-es/src/stateful_resources/roles.yml
Note: this plugin is only enabled locally for a better manual testing
experience, it is **not loaded on CI**
It is done to unify DevEx when folks work on deployment-agnostic tests
and would like to confirm the functionality under the same role for both
stateful and serverless deployments.
Thanks @azasypkin for the help, again :)
How to test:
- start the servers using
`x-pack/test/api_integration/deployment_agnostic/configs/stateful/platform.stateful.config.ts`
config and go to `http://localhost:5620`
- try to login with different roles, make sure valid role is applied in
top right profile menu
## Summary
This PR has breadth, but not depth. This adds 3 new `eslint` rules. The
first two protect against the use of code generated from strings (`eval`
and friends), which will not work client-side due to our CSP, and is not
something we wish to support server-side. The last rule aims to prevent
a subtle class of bugs, and to defend against a subset of prototype
pollution exploits:
- `no-new-func` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-new-func
- `no-implied-eval` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-implied-eval. Note that this
function implies that it prevents no-new-func, but I don't see [test
cases](https://github.com/eslint/eslint/blob/main/tests/lib/rules/no-implied-eval.js)
covering this behavior, so I think we should play it safe and enable
both rules.
- `no-prototype-builtins` to prevent accessing shadowed properties:
https://eslint.org/docs/latest/rules/no-prototype-builtins
In order to be compliant with `no-prototype-builtins`, I've migrated all
usages and variants of `Object.hasOwnProperty` to use the newer
[`Object.hasOwn`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn).
## Summary
Add `data-test-subj` html properties for:
- mock IDP login button
- in 2 places for connectors
Required for defining synthetic tests for Serverless
## 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
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>
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>
