fix(config)!: remove own_index default roles mapping

[robertpaschedag]

Description

Remove the own_index default roles mapping from config/roles_mapping.yml.

• Category: Maintenance
• Why these changes are required? The own_index roles mapping maps all users (*) to a role that grants full access to an index named like the username. This is an overly permissive default that weakens the security posture out of the box.
• Old behavior: All users automatically received full access to an index matching their username via the default roles mapping. New behavior: No default mapping for own_index exists; administrators must explicitly configure this mapping if needed.

We want to use the opensearch-k8s-operator to setup our clusters. The overall defaults (roles and roles_mapping) are very good (and we want to keep them). But with additional authentication backends (like OIDC / SAML / LDAP) this would allow any authenticated user to potentially create an index with their name (which is not what we want in a production cluster).

Still...the old behaviour can be enabled again by providing this roles mapping manually again (if this is needed). As I do not know, if truly users exist, that rely on this roles mapping....this could be a BREAKING CHANGE.

This own_index roles mapping makes perfectly sense for some "demo / gym / playground" cluster to "play around".

Issues Resolved

N/A

Testing

No new testing required — this is a configuration-only change removing a default mapping. Existing tests pass.

Check List

• New functionality includes testing
• New functionality has been documented
• New Roles/Permissions have a corresponding security dashboards plugin PR
• API changes companion pull request created
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit f823fff)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[cwperks]

Thank you for this PR @robertpaschedag . This is also something I'd like to do, but I think it should be done on a major release given that it could be considered a Breaking Change. Is there a workaround that would be suitable for your setup before a major release?

Edit: On second thought, I would be ok with removing this in a minor version. @nibix thoughts?

[robertpaschedag]

Thank you for this PR @robertpaschedag . This is also something I'd like to do, but I think it should be done on a major release given that it could be considered a Breaking Change. Is there a workaround that would be suitable for your setup before a major release?

Edit: On second thought, I would be ok with removing this in a minor version. @nibix thoughts?

@cwperks I think, the only true workaround would be to pass a copy of the roles_mapping.yml (with own_index removed) into the secret (used by the operator). Even if the operator would support to make sure, that some "object" is absent, this would only last as long as the securityconfig job does not run again.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.00%. Comparing base (e408f5c) to head (f823fff).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6147      +/-   ##
==========================================
+ Coverage   74.92%   75.00%   +0.08%     
==========================================
  Files         453      453              
  Lines       29111    29111              
  Branches     4386     4386              
==========================================
+ Hits        21810    21835      +25     
+ Misses       5275     5253      -22     
+ Partials     2026     2023       -3     

see 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Persistent review updated to latest commit f823fff

[nibix]

@cwperks @robertpaschedag

I think it is totally fine to remove this role mapping in a minor version, for the following reasons:

• It only affects newly set up clusters, existing clusters are not affected
• The role mapping itself seems to be undocumented, so the awareness is low (this is actually a good reason in support of removing it)

We should however document this in the CHANGELOG.md file to provide minimum awareness just in case people observe unexpected changes.

[cwperks]

We should however document this in the CHANGELOG.md file to provide minimum awareness just in case people observe unexpected changes.

@nibix the CHANGELOG process has been supplanted by a groomed git log + LLMs to help craft the release notes text. For 3.7.0 release there will be a release notes PR which we can edit from there.

[robertpaschedag]

should I update the branch again (merge latest code) or is this something you will take care of? Thanks.

[cwperks]

should I update the branch again (merge latest code) or is this something you will take care of? Thanks.

no need, that failing check is flaky