Allow including access lists in other access lists

[lxea]

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] --has member-->B(user A)
    C[acl B] --has member-->A
    C --has member--> D(user B)
    E[acl C] --has member-->C

Loading

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

Depends on #47828.

[fspmarshall]

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.

[lxea]

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

[justinas]

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

[lxea]

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

[r0mant]

@lxea @justinas @fspmarshall @jakule We do need to support nested access lists (both EntraID and Github can have nested groups/teams) but I agree that cycles ("A" is member of "B", "B" is a member of "C", "C" is a member of "A") add too much complexity in the system so let's prevent them and see if anyone complains. I can't come up with a reasonable real-world scenario where such group membership could be useful.

Let's also not call them "recursive". Let's call them "nested".

[codingllama]

Drive-by review, as this is related to other stuff I was just looking at. Added a couple questions.

[r0mant]

@lxea Is this implementation ready for re-review now that the RFD is approved, have you applied all changes discussed in the RFD?

[github-actions]

🤖 Vercel preview here: https://docs-awm8nb9xb-goteleport.vercel.app/docs/ver/preview