# KubeArmor Fargate Integration
### Problem Statement
Secure workloads on managed service providers like AWS Fargate where we don't have access to Linux Primitives or Host to probe information from
## Requirements
- Entrypoint Modification
- Sidecar addition
- CAP_SYS_PTRACE
## Design
### Whether to create new repo or modify KubeArmor/KubeArmor?
- We start with a new repo, create a POC and then see through this
- As of now we think a small codebase is only needed to be duplicated which can be refactored to be imported in general
## HLD
### EKS Fargate
https://excalidraw.com/#room=0017a2f420a3e729ed51,OBRbFxGFmOrV7raWnukP9g

### ECS Fargate
https://excalidraw.com/#room=9502a5ac147969916938,4igqW9lvaRxAqglH-RJe3A

## TaskList/Misc Notes
Tasklist
- [x] 1. Check basic file/proc/net ops
- [x] 2. Check enforcement, how exactly do we permission denied leveraging ptrace
- [x] 3. Get an idea about how to leverage this inside a container to monitor and enforce every thing in the container
- Probably check pdig and falco trace
- https://github.com/krisnova/falco-trace/
- https://github.com/falcosecurity/pdig
- Verify if fargate allows to exec into a container
- Check https://github.com/fntlnz/falco-inject to see if we can run without modifying container
- [x] 4. Design how to exactly execute ptrace code and communicate inside and outside container
- ~~Do we build everthing in C?~~
- ~~Or we use C for only monitoring and enforcement and somehow converse between Go and C program~~
- ~~How to deal with updating policy rules and things like that~~
- NOO, We roll with GO
- Leverage libbseccomp-go + std syscall
- POC in progress at https://github.com/daemon1024/bluelock
- [ ] 5. Check if all details available under each of the syscalls we are leveraging or we need to create maps and other things to share details across syscalls
- Details like
- Protocol in Network
- Source process in file/net
- Read only or write in file ops
- [ ] 6. Check path reconstruction logic for file/procs
- Might need to leverage prepend path functions
- [x] 7. Design how to aggregate logs and send it to whatever or wherever we do
- [x] sidecar and sidekick
Notes:
- FalcoSideKick running in sidecar
- Need to modify sidekick to support KubeArmor telemetry data
- Should be a quick change in the verification logic here
- https://github.com/falcosecurity/falcosidekick/blob/80c0bc1489835ad7d60a4f2e103b20d5a3e7ea00/handlers.go#L43
- Where do we get container information??
- /proc/self/cgroup
- https://stackoverflow.com/questions/20995351/how-can-i-get-docker-linux-container-information-from-within-the-container-itsel
- About Listening or Watching
- If k8s available we leverage CRDs
- Else we have a gRPC/HTTP listener which waits for some client to send policies
- We check for config values to see if any policy exists before starting the container
- Do we need Policy Matcher??
- Can we add which policy we based our decision on in the sidecar??
- Do we want to integrate default posture??
- Do we want audit policies??
- Master Worker Architecture can cause issues, perhaps we have ephemeral pods/containers/tasks so let's keep each sidecar happen independently
Misc:
- ptrace + seccomp test - https://www.alfonsobeato.net/c/filter-and-modify-system-calls-with-seccomp-and-ptrace/
- Linux Syscall Table - https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md#x86_64-64_bit
- Go-sandbox - https://github.com/criyle/go-sandbox/tree/master/ptracer
Which syscalls to leverage
- open
- openat
- execve
- execveat
- connect
- accept
To be checked later
- unlink
- unlinkat
- bind
- listen
- read
- readlink
# Task List
1. Create a minimal observer and setup feeder infrastructure
- Only observe execve
- Fill up all the data we need for telemetry
- Modify Sidekick
- Try leveraging Slack/Discord/AWSCloudLogs
2. Set up rule watcher/listener infrastructure
- rule watcher for k8s: test on eks fargate
- listener: test on ecs fargate
3. Implement Enforcer
- ptrace+seccomp
- how to expose data?
- where to have rule checking whether to allow or not




