[Security Solution][Endpoint] Refactor Cypress login task and ensure consistent use of users across ESS and Serverless tests

[paul-tavares]

Summary

• Cypress login task refactored:
  • login(user?) : logs use in using the default user or one of the users supported by security solution and endpoint management tests
  • login.with(username, password) : Logs a user in by using username and password
  • login.withCustomRole(role) : creates the provided role, creates a user for it by the same role name and logs in with it
• The Cypress process for loading users into Kibana only applies to non-serverless (at the moment). For serverless, it only validates that the username being used is one of the approved user names that applies to serverless
  • FYI: the creation/availability of serverless roles/users for testing is an ongoing effort by the kibana ops team
• New generic RoleAndUserLoader class. Is initialized with an map of Roles and provide a standard interface for loading them.
  • A sub-class (EndpointSecurityTestRolesLoader) was also created for the endpoint security test users, which uses the existing set of role definitions
  • The resolver_generator_script was also updated to use the new EndpointSecurityTestRolesLoader class for handling the --rbacUser argument

[elasticmachine]

Pinging @elastic/security-defend-workflows (Team:Defend Workflows)

[tomsonpl]

Thanks for doing this, as usual a piece of good work done 👏
The only thing that comes to my mind is why do we need two approaches to login - login and loginServerless. Please correct me if I got it wrong, but my understanding is that the each test now has to be specific about env's login functionality which makes it not reusable with usage of tags.
What I mean is if we have a spec that should run in two envs (@ess, @serverless) I believe we should ust use 'login' in the spec and somewhere behind the scenes we should login properly.
Does this make sense?
Approved anyway, again it's a great work 👍 Thanks!

[tomsonpl]

can we spread KIBANA_KNOWN_DEFAULT_ACCOUNTS here? Or you want to keep it separated?

[paul-tavares]

The const is actually an array, thus why I did not use it here... but, thats a good point. I'm going to convert it to an object and then just spread it here so that we keep it centralized.

[paul-tavares]

Hey @tomsonpl - thanks for the review.

Re: need for login() and loginServerles()

you are right. I refactored login() to the only one that we will use, but forgot to delete the loginSeverless() task. I will do that now. Thanks for catching that 🙏

[ashokaditya]

Thanks for the refactor. 🚢

[ashokaditya]

nit: If it's...

[ashokaditya]

Q: Is this something for later?

[paul-tavares]

yes. I did not change it just yet in order to limit the amount of refactor - just in case that changing it to soc_manager requires test changes

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: e1cf3ee

Failed CI Steps

• FTR Configs #28
• Defend Workflows Cypress Tests #5

Test Failures

• [job] [logs] Defend Workflows Cypress Tests #5 / Endpoints page "after all" hook for "Shows endpoint on the list" "after all" hook for "Shows endpoint on the list"
• [job] [logs] Defend Workflows Cypress Tests #5 / Endpoints page "before all" hook for "Shows endpoint on the list" "before all" hook for "Shows endpoint on the list"
• [job] [logs] FTR Configs #28 / serverless security UI Case View "before all" hook in "Case View"

Metrics [docs]

Unknown metric groups

ESLint disabled in files

id	before	after	diff
securitySolution	66	67	+1

Total ESLint disabled count

id	before	after	diff
securitySolution	520	521	+1

History

• 💚 Build #161205 succeeded 36f1736
• 💛 Build #160989 was flaky 7f4e9e7
• 💔 Build #160969 failed e86d1cb
• 💛 Build #160889 was flaky 55324ef

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @paul-tavares