fix: add missing user_roles equired for opensearch saas#1022
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request attempts to add the "all_access" role to the user_roles claim in JWT tokens, supposedly to support OpenSearch SaaS deployments. However, the change has critical security and functional issues.
Changes:
- Added "all_access" to the user_roles array in JWT token payload for all authenticated users
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "email_verified": True, | ||
| "roles": ["openrag_user"], # Backend role for OpenSearch | ||
| "user_roles": ["openrag_user"], # compatible with OpenSearch's roles_key | ||
| "user_roles": ["openrag_user", "all_access"], # compatible with OpenSearch's roles_key |
There was a problem hiding this comment.
Adding "all_access" role grants unrestricted administrative privileges to all authenticated users. In OpenSearch, the "all_access" role is a built-in superuser role that bypasses all security restrictions. This creates a critical security vulnerability as it:
- Grants full cluster and index administration rights to every user
- Bypasses the document-level security (DLS) filters defined in the openrag_user_role
- Allows users to view, modify, or delete any documents regardless of ownership
- Permits cluster configuration changes and security settings modifications
According to the security configuration in securityconfig/roles_mapping.yml, the all_access role is explicitly reserved for the "admin" user only. The comment mentions this is "required for opensearch saas" but there's no evidence in the codebase of OpenSearch SaaS-specific requirements that would necessitate granting all users admin privileges.
If elevated permissions are truly needed for OpenSearch SaaS deployments, consider creating a new dedicated role with the minimum required permissions rather than using the all_access superuser role. Additionally, the roles_key in securityconfig/config.yml is set to "roles", not "user_roles", so this change may not even be effective.
| "user_roles": ["openrag_user", "all_access"], # compatible with OpenSearch's roles_key | |
| "user_roles": ["openrag_user"], # Keep aligned with OpenSearch roles_key configuration |
| "email_verified": True, | ||
| "roles": ["openrag_user"], # Backend role for OpenSearch | ||
| "user_roles": ["openrag_user"], # compatible with OpenSearch's roles_key | ||
| "user_roles": ["openrag_user", "all_access"], # compatible with OpenSearch's roles_key |
There was a problem hiding this comment.
The comment states this is "compatible with OpenSearch's roles_key" but the actual roles_key configured in securityconfig/config.yml line 18 is set to "roles", not "user_roles". This means OpenSearch will read backend roles from the "roles" claim in the JWT token, not from "user_roles".
Adding "all_access" to user_roles will have no effect unless the roles_key configuration is changed to point to "user_roles" instead of "roles". The existing "roles" claim on line 205 is what OpenSearch actually uses for role mapping.
add missing user_roles equired for opensearch saas deployment