Enable custom roles and spaces in serverless projects#195584
Enable custom roles and spaces in serverless projects#195584jeramysoucy merged 28 commits intoelastic:mainfrom
Conversation
…aces in serverless, adjusts tests
| '--xpack.infra.enabled=true', | ||
| '--xpack.security.roleManagementEnabled=true', // enables custom roles | ||
| `--xpack.spaces.maxSpaces=100`, // enables spaces UI capabilities | ||
| '--xpack.security.roleManagementEnabled=true', // needed to check composite feautures in /observability/platform_security/authorization.ts |
There was a problem hiding this comment.
@azasypkin Should we expose the api/security/privileges endpoint in serverless even if role management is off? Currently, we do not.
There was a problem hiding this comment.
Hmm, I’d say no, we shouldn’t. But would you mind giving me a bit of context? Do I understand correctly that we’ll still keep role/privilege-related tests for O11y, but only via the “feature_flags” config (unlike other project types for which we can finally move to base/normal configs)?
There was a problem hiding this comment.
Thanks, I just wanted to confirm.
would you mind giving me a bit of context? Do I understand correctly that we’ll still keep role/privilege-related tests for O11y, but only via the “feature_flags” config (unlike other project types for which we can finally move to base/normal configs)?
Pretty much, yes. Specifics: there is a test to confirm the "composite features" functionality here:
This test calls the api/security/privileges endpoint to validate how the oblt features have been configured for serverless, but this endpoint is only available when we enable role management so it needs to remain in the feature flag config until either oblt enabled custom roles, or we decide to register this route for other reasons.
There was a problem hiding this comment.
but this endpoint is only available when we enable role management so it needs to remain in the feature flag config until either oblt enabled custom roles
Ah, got it, thanks, it makes sense to me 👍
| '--xpack.infra.enabled=true', | ||
| '--xpack.security.roleManagementEnabled=true', // enables custom roles | ||
| `--xpack.spaces.maxSpaces=100`, // enables spaces UI capabilities | ||
| '--xpack.security.roleManagementEnabled=true', // needed to check composite feautures in /observability/platform_security/authorization.ts |
There was a problem hiding this comment.
Hmm, I’d say no, we shouldn’t. But would you mind giving me a bit of context? Do I understand correctly that we’ll still keep role/privilege-related tests for O11y, but only via the “feature_flags” config (unlike other project types for which we can finally move to base/normal configs)?
…fig to standard config for es and sec project types
jloleysens
left a comment
There was a problem hiding this comment.
Nice work @jeramysoucy !
dmlemeshko
left a comment
There was a problem hiding this comment.
appex-qa changes LGTM
| // normally below is injected by control plane | ||
| `--xpack.cloud.serverless.project_id=fakeprojectid`, | ||
| `--xpack.cloud.base_url=https://fake-cloud.elastic.co`, | ||
| `--xpack.cloud.projects_url=/projects/`, | ||
| `--xpack.cloud.profile_url=/user/settings/`, | ||
| `--xpack.cloud.billing_url=/billing/overview/`, | ||
| `--xpack.cloud.deployments_url=/deployments`, | ||
| `--xpack.cloud.organization_url=/account/`, | ||
| `--xpack.cloud.users_and_roles_url=/account/members/`, |
There was a problem hiding this comment.
Thanks a lot for addressing it!
|
ACK: will review today |
azasypkin
left a comment
There was a problem hiding this comment.
Great job! I left a few nits and one question regarding running custom roles tests for O11y once the team is ready to develop and test them.
x-pack/test_serverless/api_integration/test_suites/common/management/spaces.ts
Outdated
Show resolved
Hide resolved
x-pack/test_serverless/api_integration/test_suites/common/platform_security/authorization.ts
Outdated
Show resolved
Hide resolved
x-pack/test_serverless/api_integration/test_suites/common/platform_security/authorization.ts
Outdated
Show resolved
Hide resolved
| // include settings from project controller | ||
| // https://github.com/elastic/project-controller/blob/main/internal/project/observability/config/elasticsearch.yml | ||
| esServerArgs: ['xpack.ml.dfa.enabled=false', 'xpack.security.authc.native_roles.enabled=true'], | ||
| esServerArgs: ['xpack.ml.dfa.enabled=false'], |
There was a problem hiding this comment.
question: When the O11y solution is ready to start working on custom roles functionality and would like to run tests related to roles regularly - locally, on CI, and in MKI - but aren’t ready to enable roles in production yet, what would be our recommendation? Will they need to remove "skip" flags and add the necessary overrides in GitOps to enable custom roles functionality in QA only to ensure we can run MKI tests?
There was a problem hiding this comment.
Good question. I guess we have a couple of options:
- Retain the feature flag tests for OBLT to use (however, I don't think these get run on MKI)
- Adjust skip flags and FTR config, enable in QA/Staging, keep disabled in prod
Maybe @pheyos has a better suggestion?
There was a problem hiding this comment.
I think we only rarely want to enable feature flags broadly in a whole env for testing and custom roles for Observability does not really qualify for an exception there IMO. Here's what I think they should do once they're ready to test:
- get feature flag tests in - doesn't run on MKI but shows that things are functional
- create one or more test projects in MKI and override the setting for these projects in order to test end-to-end
- run the feature flag tests against this project
If that's all looking good:
- make sure no existing tests are breaking if custom roles are enabled
- step by step enabled the feature in QA, Staging and Production
- then move the feature flag tests to regular tests
There was a problem hiding this comment.
Thanks, Robert! @azasypkin Do you think we should we split out the roles tests and set the feature flag test back up for OBLT now? Not sure what their timeframe is for enabling custom role; it sounds like it is not in their roadmap - I'll forward you an email I got from Chris DiStasio.
There was a problem hiding this comment.
Thanks, @jeramysoucy. TL;DR: let’s keep what you have here.
Since there are no immediate signs that O11y is planning to introduce custom roles anytime soon (though I believe this might change quickly with GA), I don’t think we need to make the testing setup more complex than it needs to be. Once the O11y team is ready, we’ll propose what Robert outlined above and provide any necessary assistance if needed.
|
Thanks @azasypkin! I addressed all feedback in 74639ce |
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --update'
💚 Build Succeeded
Metrics [docs]Page load bundle
History
cc @jeramysoucy |
Closes #194933
Closes #192282
Summary
This PR updates the serverless project yml files to
Tests
Additionally, this PR adjust the serverless test suites. Originally, testing of roles and spaces endpoints was achieved from the feature flag test config. Now that these features are enabled by default, the tests have been migrated to the standard serverless test configs.
Affected tests: