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

Role definitions are not respected #82

Closed
tekollt opened this issue Jul 10, 2019 · 4 comments
Closed

Role definitions are not respected #82

tekollt opened this issue Jul 10, 2019 · 4 comments

Comments

@tekollt
Copy link

tekollt commented Jul 10, 2019

I have a tenant named TEST-TENANT

TEST-TENANT:
  reserved: false
  hidden: false
  description: "Test Opendistro Tenants and Security"
  static: false

I then have three roles, one that gives READ to the tenant, another that gives readwrite a third that grants permissions to indexes so we have a single place to manage it for both of the other roles. While have granular access to dashboards and what not.

ROLE-TEST-READ:
  reserved: false
  hidden: false
  cluster_permissions: []
  index_permissions: []
  tenant_permissions:
  - tenant_patterns:
    - "TEST*"
    allowed_actions:
    - "kibana_all_read"
  static: false
ROLE-TEST-READWRITE:
  reserved: false
  hidden: false
  cluster_permissions: []
  index_permissions: []
  tenant_permissions:
  - tenant_patterns:
    - "TEST*"
    allowed_actions:
    - "kibana_all_write"
  static: false
ROLE-TEST-INDICIES:
  reserved: false
  hidden: false
  cluster_permissions: []
  index_permissions:
  - index_patterns:
    - "*TEST*"
    dls: ""
    fls: []
    masked_fields: []
    allowed_actions: []
  tenant_permissions: []
    static: false

The roles are then mapped to two backend roles (openID).
Both roles have mapping to the indicies role in elastic, while it is 1:1 for the read and readwrite role.

ROLE-TEST-READWRITE:
  reserved: false
  hidden: false
  backend_roles:
  - "TEST-LOGS-READWRITE"
  hosts:
  - "*"
  users:
  - "*"
  and_backend_roles: []
ROLE-TEST-READ:
  reserved: false
  hidden: false
  backend_roles:
  - "TEST-LOGS-READ"
  hosts:
  - "*"
  users:
  - "*"
  and_backend_roles: []
ROLE-TEST-INDICIES:
  reserved: false
  hidden: false
  backend_roles:
  - "TEST-LOGS-READ"
  - "TEST-LOGS-READWRITE"
  hosts:
  - "*"
  users:
  - "*"
  and_backend_roles: []

The problem is that the role seems to not be respected. I have READ/WRITE permission to the tenant, even if i am only assigned to the backend role TEST-LOGS-READ
If remove the role TEST-LOGS-READWRITEs permission to the tenant, while still beeing assigned the access with the other role TEST-LOGS-READ - then the permission is respected and i have only READ access to the tenant.

I have verified that the user is only part of a single backend role.
We have also tried to remove the indicies role that is mapped to both backend roles.

@tekollt
Copy link
Author

tekollt commented Jul 10, 2019

Additional tests shows that as soon as we create a role mapping between a backend role (name does not need to exist at all, can use a bogus name) to a role in kibana with write access to the tenant, it basically overrides any other tenant-permission beeing applied to other roles with access to the same tenant.

@tekollt
Copy link
Author

tekollt commented Jul 10, 2019

My problem is related to kibana and property checks on the users field, as it does not allow me to keep it empty, i have been using wildcard to not match any or all users. Changing this to empy from the API or by using a bogus character fixes my problem.

But i would still assume it is a bug that role mapping ignores backend role type if users are '*'

@nateynateynate
Copy link
Member

Hi @tekollt !

It looks like @cliu123 submitted some code on Jan 11, 2021 that should have fixed this issue. Can you check that this is still an issue on the latest release of OpenSearch?

Thanks!

@davidlago
Copy link

Thanks @nateynateynate @tekollt! Closing this as most likely it is not an issue anymore. Please feel free to reopen if otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants