teleport
teleport copied to clipboard
gravitational
Allow including access lists in other access lists
Allows recursive inclusion of Access Lists in other Access Lists.
For example, with the hierarchy below, user A would inherit traits and roles from acl C, acl B, and acl A, while user B would traits and roles from acl C and acl B:
flowchart TD
A[acl A] -->B(user A)
C[acl B] -->A
C --> D(user B)
E[acl C] -->C
changelog: Allow nested inclusion of Access Lists as Members and Owners in other Access Lists
RFD: https://github.com/gravitational/teleport/blob/master/rfd/0170-nested-accesslists.md
E: https://github.com/gravitational/teleport.e/pull/4549
Is there an RFD or other design document for this feature somewhere? My gut reaction to the idea of access list recursion (or cross-dependency of any kind) is that it seems risky and hard to reason about.
In general, I'm of the opinion that composition of access-control primitives should have a well-defined acyclic hierarchy wherever possible. One of the key design goals of a good access-control system should be to mitigate/prevent human error, both on the part of the programmer and the end user. Keeping the compositional structure as simple as possible to trace, reason about, and model is an important part of that.
Is there an RFD or other design document for this feature somewhere? My gut reaction to the idea of access list recursion (or cross-dependency of any kind) is that it seems risky and hard to reason about.
In general, I'm of the opinion that composition of access-control primitives should have a well-defined acyclic hierarchy wherever possible. One of the key design goals of a good access-control system should be to mitigate/prevent human error, both on the part of the programmer and the end user. Keeping the compositional structure as simple as possible to trace, reason about, and model is an important part of that.
There isn't an RFD but I'm happy to write one up. Keeping the hierarchy acyclic seems like it would be ideal, however I'm not sure if the services being integrated with (Azure Entra groups @justinas) support cycles in their group hierarchies
There isn't an RFD but I'm happy to write one up. Keeping the hierarchy acyclic seems like it would be ideal, however I'm not sure if the services being integrated with (Azure Entra groups @justinas) support cycles in their group hierarchies
Entra (sadly) seems to support cycles. Generally we'd like to represent the imported data as faithfully as possible. Maybe we could assume that cycles are uncommon in real-life scenarios and refuse to process such data, but that decision would not be up to me I think 🙂 /cc @jakule
There isn't an RFD but I'm happy to write one up. Keeping the hierarchy acyclic seems like it would be ideal, however I'm not sure if the services being integrated with (Azure Entra groups @justinas) support cycles in their group hierarchies
Entra (sadly) seems to support cycles. Generally we'd like to represent the imported data as faithfully as possible. Maybe we could assume that cycles are uncommon in real-life scenarios and refuse to process such data, but that decision would not be up to me I think 🙂 /cc @jakule
Maybe having it require --force flag in the terminal/a warning in the ui, if the data being imported or acl being modified introduces a cycle would be useful? or maybe that would just be unnecessary overhead
@lxea Is this implementation ready for re-review now that the RFD is approved, have you applied all changes discussed in the RFD?
We should detect if an owner of an access list attempts to add themselves via a dynamic access list relation during member membership updates.
cc @smallinsky, looks like this was covered in the PR for enterprise here, did you have a chance to review that?
Rebased, fixed build errors, added some validation for nesting exceeding 10 levels, and got the e/frontend side of stuff working. Still need to add tests for all this & debug the role/trait inheritance – it seems to mostly work now, but there are some odd perm issues I ran into while doing some testing.
🤖 Vercel preview here: https://docs-h573z0uwv-goteleport.vercel.app/docs/ver/preview
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
🤖 Vercel preview here: https://docs-jfqmbinf2-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-iyqd86r24-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-lx3fbnqsb-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-644o4ht22-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-nfrskcfli-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-7e1jhov2f-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-jk55ltqw1-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-5468qxfo7-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-bhkwt1r6j-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-s05s4z4ac-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-bn5nrerw8-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-1olx6a2ox-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-virr7lsc4-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-qn5nxf6q0-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-qxzbpcbxf-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-cw6kcy0nr-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-coevqa9i3-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-ag8nd4ddt-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-l7i558wmc-goteleport.vercel.app/docs/ver/preview
🤖 Vercel preview here: https://docs-rj7w3d810-goteleport.vercel.app/docs/ver/preview