-
Notifications
You must be signed in to change notification settings - Fork 60
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
[BUG] 403 Forbidden Error When Mapping 'all_access' Role to LDAP Group in OpenSearch #153
Comments
@yoicomment You would also need to specify any existing users and backend_roles for the role mapping in the terraform code. |
As you can see, I specified "ldap_group" as "backend_roles". Shouldn't that be enough? I don't want to assign "all_access" to users explicitely. Besides that, I found a security setting: Does it fail because it is set to the default value? |
@yoicomment The user you are authenticating with from the Terraform OpenSearch provider would continue to need access if you are using HTTP basic auth. Are you using HTTP basic auth? |
Yes, I'm using the admin user for that |
@yoicomment I too get 403 error if I remove admin from the role mapping for the following configuration as admin is a user from the internal user database and loses access if it is not part of the role mapping.
|
This is my "internal_users.yml" file.
This is my "roles_mapping.yml" file:
I use this for:
The name of the ldap group is:
Now, I wanna assign the role to this ldap group:
And this does not work for me. |
@yoicomment Yes, we have admin user in the roles_mapping.yml and the role mapping created using the YAML will be replaced with the role mapping created by applying the Terraform code. With backend_roles = ["admin", "all_admins"], it will work. |
Why need to add "admin" here? I don't have a ldap group named "admin" |
@yoicomment admin is the user we are authenticating with from Terraform OpenSearch Provider. |
I'm utterly confused. Why would you add a user to "backend_roles"? |
admin was already specified under backend_roles in your roles_mapping.yml, the same needs to be specified again in the terraform code. |
What if I omit "admin" from:
and have only:
What would happen then? |
Would the user "admin" still have the role of "all_access"? |
@yoicomment If admin is removed from backend_roles = ["admin", "all_admins"], admin will no longer be mapped to all_access. |
@rblcoder but why need to add it to backend_roles when it is already set in the roles_mapping.yml file? |
@rblcoder Somehow, the role mapping from roles_mapping.yml file is overwritten by the terraform roles mapping. Isn't that strange? |
@yoicomment roles_mapping.yml is applied using securityadmin.sh script. After the .opendistro_security index is initialized, you can use OpenSearch Dashboards or the REST API to manage your users, roles, and permissions. Three ways to map users to roles The rest api PUT _plugins/_security/api/rolesmapping/ Creates the specified role mapping if it does not already exist or replaces it if it already exists. This is the api called by the Terraform OpenSearch Provider. Since the role mapping already exists, it is replaced when we call the REST API. |
@rblcoder okay, this makes sense! Thank you :) |
Thanks @rblcoder |
@prudhvigodithi she smart tho, aws should hire her |
What is the bug?
When attempting to map the "all_access" predefined role in OpenSearch to an LDAP group, the process fails and results in an error. The specific error message received is "Error: elastic: Error 403 (Forbidden)". This suggests a permission issue, but the exact cause is unclear.
How can one reproduce the bug?
What is the expected behavior?
The expected behavior is that the "all_access" role should successfully map to the specified LDAP group, granting members of this group the appropriate access permissions within OpenSearch.
What is your host/environment?
[Please provide details about your operating system, version of OpenSearch, and any other relevant environment details.]
Do you have any additional context?
The text was updated successfully, but these errors were encountered: