Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[POC] Draft lambda rule type implementation #1

Draft
wants to merge 10 commits into
base: main
Choose a base branch
from
Draft

[POC] Draft lambda rule type implementation #1

wants to merge 10 commits into from

Conversation

XavierM
Copy link
Collaborator

@XavierM XavierM commented Dec 12, 2023

Summary

Summarize your PR. If it involves visual changes include a screenshot or gif.

Checklist

Delete any items that are not applicable to this PR.

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk Probability Severity Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space. Low High Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. High Low Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled. Medium High Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

@XavierM XavierM marked this pull request as draft December 12, 2023 22:01
XavierM pushed a commit that referenced this pull request Dec 12, 2023
@dmlemeshko @pheyos
@kibanamachine @azasypkin
[FTR] add service to test user roles on serverless (elastic#170417)
d75103e 
## 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 elastic#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: 

#1
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4081
elastic#2
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4114

---------

Co-authored-by: Robert Oskamp <[email protected]>
Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Aleh Zasypkin <[email protected]>
@XavierM XavierM changed the title [POC} Draft lambda rule type implementation [POC] Draft lambda rule type implementation Dec 12, 2023
umbopepato pushed a commit that referenced this pull request May 20, 2024
@elena-shostak
[FTR] Session Concurrency Test (elastic#183409)
a74d12c 
## Summary
Set `security.session.cleanupInterval` to 5h for session concurrency
test.

### **Prerequisites**

- Task for session cleanup with [default schedule set to
1h](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security/server/config.ts#L222).
- Task polling interval is set to
[3000ms](https://github.com/elastic/kibana/blob/main/x-pack/plugins/task_manager/server/config.ts#L13).
- We override `scheduledAt` once we make a request in
[runCleanupTaskSoon](https://github.com/elastic/kibana/blob/main/x-pack/test/security_api_integration/tests/session_concurrent_limit/cleanup.ts#L145).

### **Hypothesis**

Taking into consideration that:

- `session_cleanup` task is not the only one scheduled during test run.
- There is sort of an exponential backoff implemented for task polling
if there are too many retries.
- Clock jitter.

I had a hypothesis that if our whole test run exceeds 1h or polling
interval gets adjusted because of retries we might end up executing the
scheduled cleanup before we trigger `runCleanupTaskSoon` (this is there
we drop 1 session already).

### **FTR runs (x55 each)**

- `cleanupInterval` set to 5h:
[#1](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5986)
:green_circle:,
[elastic#2](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5987)
:green_circle:
- `cleanupInterval` set to default 1h:
[#1](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5983)
:green_circle:,
[elastic#2](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5982)
:red_circle: (has 2 failures out of 55)


### Checklist

- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed

### 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)

__Fixes: https://github.com/elastic/kibana/issues/149091__
umbopepato pushed a commit that referenced this pull request Sep 23, 2024
@adcoelho
[ResponseOps][Cases] Design Review changes #1 (elastic#192356)
6f7bc21 
Connected to elastic#188187

## Summary

- Changed the cases `Settings` button and icon
- Changed the the `Additional fields` title to `Custom fields` for
consistency

<img width="1728" alt="Screenshot 2024-09-09 at 20 15 39"
src="https://github.com/user-attachments/assets/1fb1232a-f958-4d4d-8694-f85cc8872237">
<img width="1443" alt="Screenshot 2024-09-09 at 20 34 27"
src="https://github.com/user-attachments/assets/0fbdae02-65a6-4128-adc7-39f51cc2d5e6">
<img width="1370" alt="Screenshot 2024-09-09 at 20 34 57"
src="https://github.com/user-attachments/assets/c216407a-ac13-4579-8007-531c79d52de7">
umbopepato pushed a commit that referenced this pull request Nov 14, 2024
@gsoldevila
[Sustainable Kibana Architecture] Update plugins (wave #1) (elastic#1…
a5517d9 
…95375)

## Summary

Follow-up of elastic#195367
As part of the Sustainable Kibana Architecture initiative, this PR
leverages the mechanisms and concepts introduced in
elastic#194810, updating plugins that
were considered to be solution-specific in Luke's
[PoC](elastic#179710).

This might trigger linting rule violations in CI, and help uncover
conflicts related to forbidden dependencies.
As soon as they are resolved, we can proceed to classify solutions'
plugins.
umbopepato pushed a commit that referenced this pull request Nov 14, 2024
@azasypkin @elasticmachine
fix(security, features): do not expose UI capabilities of the depreca…
deeb9fe 
…ted features (elastic#198656)

## Summary

This PR ensures that we don’t expose UI capabilities for deprecated
features since they’re unnecessary, and the code should rely on the UI
capabilities of the replacement features instead.

Additionally, this PR transforms the `disabledFeatures` property of
Space objects returned from our programmatic and HTTP APIs to replace
any deprecated feature IDs with the IDs of their replacement features,
ensuring that feature visibility toggles work for deprecated features as
well.

## How to test

1. Run Kibana FTR server with the following config (registers test
deprecated features):
```shell
node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/features.config.ts
```
2. Once server is up and running create Space with the
`case_1_feature_a` **deprecated** feature disabled:
```shell
curl 'http://localhost:5620/api/spaces/space' -u elastic:changeme \
  -X POST -H 'Content-Type: application/json' -H 'kbn-version: 9.0.0' \
  --data-raw '{"name":"space-alpha","id":"space-alpha","initials":"s","color":"#D6BF57","disabledFeatures":["case_1_feature_a"],"imageUrl":""}'
```
3. Log in to Kibana and [navigate to a Space
`space-alpha`](http://localhost:5620/app/management/kibana/spaces/edit/space-alpha)
you've just created. Observe that deprecated `Case #1 feature A`
(`case_1_feature_a`) isn't displayed, and instead you should see that
replaces deprecated one - `Case #1 feature B` (`case_1_feature_b`):

![Screen Shot 2024-11-01 at 17 40
59](https://github.com/user-attachments/assets/5b91e71c-7d46-4ff1-bf73-d148622e8ec4)

Co-authored-by: Elastic Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@XavierM @umbopepato