Graylog 4.0 permission issue

Graylog Central (peer support)
1

I am trying to migrate to graylog 4.0. I can see that the permission model has changed but doesn’t really resolve any of the issues we had in 3.3.
The Reader role still provides too much access. Specifically a Reader user can see the inputs view and therefore inputs not related to them which in our environment is not acceptable.
Additionally it is still impossible to have a user without Reader and Admin roles.
So basically we still have to create bespoke roles and assign these to the users.

Having said that, in 4.0 the API does not work anymore when trying to override the roles. I get the error below. Could you please advise? We are really stuck on this one as this is preventing us from upgrading.

image
image974×766 70.5 KB

Thanks.

2

OK so it turns out that with graylog 4.0 you now have to put the userId rather than the convenient username in the request. So yeah overall it’s gotten worse in 4.0 than it was in 3.3…
It would be good to improve this going forward.

3

That change is also mentioned in changelog and upgrade notes:

  • Change /users resource to use the user ID instead of the user name as parameter.
  • In 4.0 we changed the following user API endpoints to expect a user ID parameter instead of the username

https://docs.graylog.org/en/4.0/pages/changelog.html#id9

https://docs.graylog.org/en/4.0/pages/upgrade/graylog-4.0.html#change-of-api-endpoint-for-user-retrieval-and-modification

4

Thanks. I think the bottom line is that the Reader role provides too much access and therefore forces us to create a bespoke role and to override the users roles using the API.

5

You can still create custom role without permission to read inputs:
curl -i -X POST -u admin:PASS -H 'Content-Type: application/json' -H 'X-Requested-By: cli' 'http://172.28.128.15:9000/api/roles' -d @role-reader2.json

File content role-reader2.json:

{
  "name": "Reader2",
  "description": "Reader role without input",
  "permissions": [
        "clusterconfigentry:read",
        "indexercluster:read",
        "messagecount:read",
        "journal:read",
        "messages:analyze",
        "metrics:read",
        "fieldnames:read",
        "buffers:read",
        "system:read",
        "jvmstats:read",
        "decorators:read",
        "throughput:read",
        "messages:read"
      ],
  "read_only": false
}

Then assign newly created role to newly created user. This way you can assign whichever role to newly created user. Or you can assign/unassign role for user from System - Roles. If you try to unassign role from System - Users and Teams it’s not possible without Reader role. Anyway Reader role can’t be unassigned by web gui, if assigned once.

But you can unassign Reader role from user using API:
curl -i -X DELETE -u admin:tdXd3RMW -H 'Content-Type: application/json' -H 'X-Requested-By: cli' 'http://172.28.128.15:9000/api/authz/roles/ROLE_ID/assignee/USERNAME'

ROLE_ID can be received by this little bash snippet:

#!/bin/bash
# Unassign Reader role for user
# Username
USERNAME="test5"

# Get id of Role (Reader)
ROLE="Reader"
ROLEID=$(curl -s -X GET -u admin:PASS -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'X-Requested-By: cli' 'http://172.28.128.15:9000/api/authz/roles?page=1&per_page=50&sort=name&order=asc'| jq -r '.roles[] | select(.name=="'"$ROLE"'") | .id')

# Unassign Reader role
curl -i -X DELETE -u admin:PASS -H 'Content-Type: application/json' -H 'X-Requested-By: cli' 'http://172.28.128.15:9000/api/authz/roles/'"$ROLEID"'/assignee/'"$USERNAME"''
6

Oh yeah this is what I did. Would just be easier to remove the input permission from the default Reader role. Or come up with more specific roles as a business user with Reader role for instance do not need to see any of the System drop down but a technical Reader user might,

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.