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

RBAC: conditionally exclude certain labels without a full blown deny #20145

Closed
Tracked by #22526
programmerq opened this issue Jan 12, 2023 · 3 comments
Closed
Tracked by #22526
Assignees
Labels
c-dbl Internal Customer Reference c-dc Internal Customer Reference c-ju Internal Customer Reference c-ns Internal Customer Reference c-un Internal Customer Reference feature-request Used for new features in Teleport, improvements to current should be #enhancements rbac Issues related to Role Based Access Control

Comments

@programmerq
Copy link
Contributor

What would you like Teleport to do?

It should be possible for a role to express "allow all except" without using a full-blown deny rule.

What problem does this solve?

A teleport user is supposed to have access to hundreds of resources but needs to submit an access request for a small number of resources only (prod). The labeling strategy for a large number of resources is dynamic and inconsistent enough, that it would be much easier to say "allow all but this". Using a simple deny rule will not work because the deny will still take precedence if this user were to request access to the prod server via access workflows.

If a workaround exists, please include it.

  • A painful approach would be to expect the Teleport administrator to script out a process that would update a role with a long and ever-changing list of matching patterns.

Things that were investigated, but didn't work out.

  • It looks like no conditional options exist for node_labels, db_labels, and other label allow rules in RoleSpecV5. Potentially, a where/filter could only apply a deny if the user doesn't have the role granted by an access request.

    deny:
        db_labels:
            Env: production

    Something like where: !contains(user.spec.roles, "prodrole" could make the above deny only activate if the user hasn't issued an access request for prodrole.

  • Use of a negative lookahead assertion in the allow rule. Golang uses re2, which does not support negative lookahead assertions.

    allow:
        db_labels:
            Env: '^(?!production))' # pcre style negative lookahead does not work
@programmerq programmerq added feature-request Used for new features in Teleport, improvements to current should be #enhancements rbac Issues related to Role Based Access Control c-dbl Internal Customer Reference labels Jan 12, 2023
@klizhentas
Copy link
Contributor

If we use expression of the labels matching, we can implement this in scope of #10204

@nklaassen nklaassen self-assigned this Feb 14, 2023
@pschisa pschisa added the c-ju Internal Customer Reference label Feb 15, 2023
@pnrao1983 pnrao1983 added the c-un Internal Customer Reference label Feb 16, 2023
@pschisa pschisa added the c-ns Internal Customer Reference label Mar 24, 2023
@oshati oshati added the c-dc Internal Customer Reference label Apr 13, 2023
@jdconti jdconti mentioned this issue May 30, 2023
14 tasks
@russjones
Copy link
Contributor

@jdconti This will be addressed by @nklaassen as part of his new Predicate work in Teleport 14 (maybe a Teleport 13.x release).

@nklaassen
Copy link
Contributor

This is addressed by label expressions released in 13.1.1

For the example you could write

allow:
    db_labels_expression: |
        labels["Env"] != "production"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-dbl Internal Customer Reference c-dc Internal Customer Reference c-ju Internal Customer Reference c-ns Internal Customer Reference c-un Internal Customer Reference feature-request Used for new features in Teleport, improvements to current should be #enhancements rbac Issues related to Role Based Access Control
Projects
None yet
Development

No branches or pull requests

7 participants