-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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.
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
[Security Solution] [Cypress] SAML for Serverless login and role testing #172655
[Security Solution] [Cypress] SAML for Serverless login and role testing #172655
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in slack, we should try to use some shared functionality to handle all this SAML stuff. This will make it more stable and easier to maintain in the future. There's currently work going on to move the SAML test logic into the kbn-test
package so it can also be used by Cypress tests, see #172678.
@MadameSheema is there a reason to NOT use the shared functionality?
Not at all :) In this draft PR I'm reusing the initial code Dima wrote, I was not aware of the I already synced with @dmlemeshko and will wait for the above-mentioned PR to finalize the integration with Cypress. |
/ci |
/ci |
/ci |
/ci |
/ci |
Pinging @elastic/security-solution (Team: SecuritySolution) |
/ci |
x-pack/test/security_solution_cypress/cypress/e2e/explore/overview/overview.cy.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. 👍🏼
@@ -571,6 +571,7 @@ ${JSON.stringify(cypressConfigFile, null, 2)} | |||
KIBANA_PASSWORD: credentials.password, | |||
|
|||
CLOUD_SERVERLESS: true, | |||
IS_SERVERLESS: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cant we use only one of these two flags in lines 573 and 574? If this is not a big rework.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These flags represent two different things.
IS_SERVERLESS
is used for both FTR and cloud environments.CLOUD_SERVERLESS
is used for just deployed projects on the cloud, this cannot be used for the FTR serverless environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for explore changes, thanks!
💛 Build succeeded, but was flaky
Failed CI Steps
Test Failures
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
@@ -16,6 +16,9 @@ export JOB=kibana-security-solution-chrome | |||
|
|||
buildkite-agent meta-data set "${BUILDKITE_JOB_ID}_is_test_execution_step" "true" | |||
|
|||
mkdir .ftr | |||
retry 5 5 vault kv get -format=json -field=data secret/kibana-issues/dev/security-quality-gate/role-users > .ftr/role_users.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We recently implemented a change where we're accessing vault
through a variable path. I think for this to be future-proof to some degree, we should also care for that branching in here. However, the utility function that we use cannot be parameterized with extra args in its current state.
If this is urgent, we can go with this.
If you have some time to chisel the edges, I'll follow up with the details, so you can add it to this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved with suggested fix incoming in #173005
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Detection Response area LGTM. Thanks for this PR implementation
Successfully log in by different roles, created for test qa depoloyment
Note: in PR description , when testing MKI deployment, script in second step should be
Execute yarn cypress:open:qa:serverless
Observation: most of the tests against MKI failed when I run it locally, Chrome just crashed
We detected that the Chrome Renderer process just crashed.
We have failed the current spec but will continue running the next spec.
This can happen for a number of different reasons.
If you're running lots of tests on a memory intense application.
- Try increasing the CPU/memory on the machine you're running on.
- Try enabling experimentalMemoryManagement in your config file.
- Try lowering numTestsKeptInMemory in your config file during 'cypress open'.
You can learn more here:
https://on.cypress.io/renderer-process-crashed
Have you seen it before? Is it possibly related to this PR?
} | ||
``` | ||
|
||
As role names please use: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should list of these role match ROLES enum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something I want to double check with @maximpn when he is back. The listed roles are the ones available on serverless and are the ones we can retrieve cookies from so I've the feeling we might be missing roles on that enum.
@vitaliidm you are right around the script!! thanks for noticing! about the failure, I didn't see it before. |
Relates to:
Summary
In this PR we are using the code implemented on #170417 and #172678 to allow SAML and role testing inside Cypress.
BASE_ENV_URL
variable to use the proper QA environment (pending to be done in follow-up PRs, to extract this value so it is not hardcoded cc @dkirchan )IS_SERVERLESS
environment variable needed for the logic on the login task. This changed implied to update thees_archiver
file to continue work as expected.TEST_CLOUD_HOST_NAME
environment variable needed for the code we are reusing to retrieve the session cookie for MKI.role_users.json
file needed by the code we are reusing to get the different session cookies on MKItest <role>
(@dmlemeshko is it possible to have as username just the role? Is this something that can impact other tests and teams?)How to test it in your machine
Serverless FTR
x-pack/test/security_solution_cypress
yarn cypress:open:serverless
E2E testing
Serverless MKI
Setup a valid Elastic Cloud API key for QA environment:
User menu button
located on the top right of the header.Organization
.API keys
tab.Create API key
button.Create API key
Store the saved key on
~/.elastic/cloud.json
using the following format:Store the email and password of the account you used to login in the QA Environment at the root directory of your Kibana project on
.ftr/role_users.json
, using the following format:If you want to execute a test with a role different from the default one, make sure you have created the user under your organization and is added to the above json following the format:
x-pack/test/security_solution_cypress
yarn cypress:open:qa:serverless
E2E testing