...
- Issue discussion/Dev updates
- L3AF R2
- RBAC https://github.com/l3af-project/l3af-arch/discussions/57
- Option 1: RBAC framework using x.509 PKI Certificate Attributes
- Not every CA will issue those types of certs (w/usernames)
- Option 2 OATH
- No work required. Just consume already existing resources.
- Many enterprises already using it.
- ex: Windows Active Directory
- Option 3. Digital Signature based Authorization with mTLS
- Minimal overhead.
- Partly extensible. Partly standards compliant.
- Protocols mature, framework not so mature.
- Option 4. SHA256 Hash based Authorization with mTLS
- Don't want l3af to be the actual auth service.
- Custom implementation
- Option 1: RBAC framework using x.509 PKI Certificate Attributes
- We don't want to take ownership by building our own RBAC
- Building an e2e RBAC does not align with L3AF goals
- Also managing the RBAC lifecycle
- Enterprises should use their own control plane to manage L3AFd
- Supporting only 2 roles at first is okay, but we have to be extensible
- Most enterprises will have central control.
- Leave it up to them.
- Option 2. mTLS with OAuth 2.0 Client Authentication, but:
- If nobody is going to use anything other than read/write then we do not need to build RBAC now.
- Give a recommendation on how to integrate RBAC
- Document how L3AFd could integrate with the above
- Give a recommendation on how to integrate RBAC
- If nobody is going to use anything other than read/write then we do not need to build RBAC now.
- Building an e2e RBAC does not align with L3AF goals
- https://github.com/l3af-project/l3afd/pull/229
- https://github.com/l3af-project/l3afd/pull/242
- Loading XDP and TC program blockers
- https://github.com/l3af-project/l3afd/issues/191
- https://github.com/florianl/go-tc/issues/17 - Need to update our issue.
- RBAC https://github.com/l3af-project/l3af-arch/discussions/57
- L3AFD v2.1
- L3AF on Windows
- L3AF R2
...