Skip to content
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

Reloading remote cluster credentials via API fails for users with manage privilege #111543

Closed
n1v0lg opened this issue Aug 2, 2024 · 1 comment · Fixed by #111535
Closed

Reloading remote cluster credentials via API fails for users with manage privilege #111543

n1v0lg opened this issue Aug 2, 2024 · 1 comment · Fixed by #111535
Assignees
Labels
>bug :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC Team:Security Meta label for security team

Comments

@n1v0lg
Copy link
Contributor

n1v0lg commented Aug 2, 2024

Elasticsearch Version

8.13.0 or higher.

Java Version

bundled

Problem Description

The Nodes reload secure settings API requires the manage cluster privilege.

In clusters running versions >=8.13.0, however, it fails to reload remote cluster credentials for the API key-based remote cluster security model, unless users have the all cluster privilege (or manage AND manage_security).

Any call made by a user with only manage results in the following error message:

"reason" : "action [cluster:admin/xpack/security/remote_cluster_credentials/reload] is unauthorized for user [<...>] with effective roles [<...>], this action is granted by the cluster privileges [manage_security,all]"

This error message is misleading since all secure settings, apart from remote cluster credentials, still reload successfully for users with only manage cluster privileges.

To reload remote cluster credentials, the workaround is to make the reload request with a user with the all cluster privilege (or manage AND manage_security).

Reloading other secure settings is still possible with only the manage cluster privilege, and the reported error can be ignored.

This is a regression introduced by: #103215

Steps to Reproduce

Create role and user with manage privilege:

PUT /_security/role/role
{
    "cluster": [
        "manage"
    ]
}

PUT /_security/user/user
{
    "password": "<...>",
    "roles": ["role"]
}

Call the reload settings API with that user:

POST /_nodes/reload_secure_settings

This will result in an error message with failure reason:

"reason" : "action [cluster:admin/xpack/security/remote_cluster_credentials/reload] is unauthorized for user [user] with effective roles [role], this action is granted by the cluster privileges [manage_security,all]"

Logs (if relevant)

No response

@n1v0lg n1v0lg added >bug needs:triage Requires assignment of a team area label labels Aug 2, 2024
@n1v0lg n1v0lg self-assigned this Aug 2, 2024
@n1v0lg n1v0lg added the :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC label Aug 2, 2024
@elasticsearchmachine elasticsearchmachine added the Team:Security Meta label for security team label Aug 2, 2024
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)

@elasticsearchmachine elasticsearchmachine removed the needs:triage Requires assignment of a team area label label Aug 2, 2024
@n1v0lg n1v0lg changed the title Reloading remote cluster credentials via API fails for users with only manage privilege Reloading remote cluster credentials via API fails for users with manage privilege Aug 2, 2024
n1v0lg added a commit to n1v0lg/elasticsearch that referenced this issue Aug 9, 2024
Due to the `cluster:admin/xpack/security` action name prefix, the
internal action
`cluster:admin/xpack/security/remote_cluster_credentials/reload` to
reload remote cluster credentials fails for users that have the `manage`
cluster privilege. This does not align with our documentation and the
overall permission requirements for reloading secure settings.  

This PR renames the action to match the `manage` privilege. Since this
is a local-only action there are no BWC concerns with this rename. 

Fixes: elastic#111543
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Sep 4, 2024
Due to the `cluster:admin/xpack/security` action name prefix, the
internal action
`cluster:admin/xpack/security/remote_cluster_credentials/reload` to
reload remote cluster credentials fails for users that have the `manage`
cluster privilege. This does not align with our documentation and the
overall permission requirements for reloading secure settings.  

This PR renames the action to match the `manage` privilege. Since this
is a local-only action there are no BWC concerns with this rename. 

Fixes: elastic#111543
davidkyle pushed a commit to davidkyle/elasticsearch that referenced this issue Sep 5, 2024
Due to the `cluster:admin/xpack/security` action name prefix, the
internal action
`cluster:admin/xpack/security/remote_cluster_credentials/reload` to
reload remote cluster credentials fails for users that have the `manage`
cluster privilege. This does not align with our documentation and the
overall permission requirements for reloading secure settings.  

This PR renames the action to match the `manage` privilege. Since this
is a local-only action there are no BWC concerns with this rename. 

Fixes: elastic#111543
elasticsearchmachine pushed a commit that referenced this issue Sep 17, 2024
Due to the `cluster:admin/xpack/security` action name prefix, the
internal action
`cluster:admin/xpack/security/remote_cluster_credentials/reload` to
reload remote cluster credentials fails for users that have the `manage`
cluster privilege. This does not align with our documentation and the
overall permission requirements for reloading secure settings.  

This PR renames the action to match the `manage` privilege. Since this
is a local-only action there are no BWC concerns with this rename. 

Fixes: #111543

Co-authored-by: Elastic Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC Team:Security Meta label for security team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants