...
- Make repo config into the json config and support local file
- Where is the json .cfg?
- The comments are the only docs we have for the config.
- Would be nice to have a doc for this
- When should PRs be approved how many approvals needed?
- 2 separate from the submitter
- `Monitoring the expiration of TLS certs.
- Added configurable warning
- 30 day warning by default
- Running L3AFd on Azure VM.
- use port 8080
- clone l3afd repo run go install
- Use port 7080
- Change the port
- Roadmap and Release schedule Initial
- Release will increase our badging score
- What are the big rocks?
- mTLS
- Trust based on CA
- Trust if it's signed by CA and matches pattern
- define repos per eBPF package
- Atul working on this now
- Security RBAC - Read only user vs. Admin.
- mTLS
- Having L3AFD running on an Azure VM in Windows and Linux
- Running rate limiting and XDP root on Windows
- Signed eBPF programs(?) - Stretch goal.
- Multiple repo support.
- mTLS - key should never be in the source code or a cfg.
- Could be in a separate file that only the l3afd user can access it.
- Use cloud services for prod.
- Every time we generate a new token.
- Client can use the token until we regenerate
- Sign token for read user then that is part of the hash
- the role is signed in the token.
- If we have a token with the assigned role then we can auth and validate the user.
- Use local file store for dev and cloud provider option for prod.
- Timeframe:
- 1-2 months
- Thoughts about release cadence
- Every 2-3 months(?) - too aggressive
- Let's try 6 months for starters.
- Eventually go to quarterly
- Long term roadmap
- Chaining semantics
- Cilium has their own semantics
- Standardize XDP dispatcher
- Have multiple progs attach to interface on XDP
- Approach is impossible on the TC side
- Testing now.
- lib XDP convert into golang
- directly call APIs from l3afd
- Newer version of prog with mult eBPF progs attached in priority
- l3af chaining and Cilium not compat.
- Should we change our semantics?
- tracking progs and maps
- Should be seamless in kube environment
- Should we change our semantics?
- desktop apps for l3afd
- Running on service
- Looking at using core. (Linux Kernel)
- write eBPF progs to leverage core semantics across different kernel releases
- Move everything to latest libBPF
- Move to latest libBPF APIs
- Package signing
- We support mostly network now
- Observability is separate
- Network chaining
- Had plans like adding observability into l3af platform
- Support of Kprobes/Uprobes
- l3afd daemon as robust as possible
- Package manager (marketplace stuff)
- Do we have a secure mode that makes sure eBPF programs that are not in the l3afd set are unloaded.
- if l3afd is inserting programs for security and someone outside of l3afd and unloads one of the sec progs.
- l3afd should detect and enforce this.
- if l3afd is inserting programs for security and someone outside of l3afd and unloads one of the sec progs.
- eBPF program enforcement
- right now it won't pick this up until you make a change.
- Chaining semantics
- PR to add to l3af-arch: https://github.com/l3af-project/l3afd/pull/76
- Add issue to l3af-arch issue
- Start drafting form this initial set of requirements
Action Items
Future Agenda Items
...