enclave-runc-wrapper: Add runc wrapper as a bridge with k8s #17
Conversation
vadorovsky
force-pushed
the
policies
branch
2 times, most recently
from
b1f21c1 to
8b7e091
Compare
Signed-off-by: Michal Rostecki <[email protected]>
vadorovsky
force-pushed
the
policies
branch
2 times, most recently
from
59cbe28 to
df53f9e
Compare
|
Overall PR question: will runc always be available? |
Usually yes, runc is the default runtime used by the most of CRI servers (containerd-cri, cri-o etc.). So far I would focus on it. There are some other OCI-compatible runtimes, but usually made just as an experiment (i.e. crun). |
Thanks for the explanation! Resolved and replied to some conversations. Awaiting for re-review on ones left open. |
This change adds the runc wrapper which has a purpose of applying policies set through Kubernetes namespaces. For now, it uses the namespace labels proposed in the PSP Replacement KEP[0]. The runc wrapper checks whether the container which is about to be started was scheduled by kubelet (by checking runc annotations set by kubelet / runtime servers). If some non-default policy is set, that policy is written for the particilar container to the BPF map, so then BPF programs can be aware of that policy. For now, there is no way of proving that those annotations really come from Kubernetes. Coming up with some sane way of securely proving that will be something to implement in a follow up work. [0] kubernetes/enhancements#2582 Fixes: #3 Signed-off-by: Michal Rostecki <[email protected]>
Since the runc wrapper got introduced, it's more convenient to register new containers through it, instead of detecting then through BPF programs. This change also fixes the way how PID is determined for each process. Another change is denying to launch any runc processes which are not children of the runc wrapper. Signed-off-by: Michal Rostecki <[email protected]>
|
@nickgerace Your comments should be addressed now, PTAL |
This commit brings the following changes to the Vagrant ecosystem: - memory increased to 8GB - no restart after provisioning the control plane components - using upstream kubeadm and upstream containerd runtime - adding several useful packages Signed-off-by: Michal Rostecki <[email protected]>
Starting from now, registering containers is handled by the runc wrapper and the role of the BPF runtime map becomes rather to find the unwrapped runc processes and deny them. Signed-off-by: Michal Rostecki <[email protected]>
Dockerfile
Outdated
| rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* | ||
| WORKDIR /usr/local/src | ||
| # Build libbpf and bpftool from the newest stable kernel sources. | ||
| ENV KERNEL_TAG v5.13.1 |
There was a problem hiding this comment.
Is this something that could be overridden at build? If so, would it make sense to make it an ARG?
There was a problem hiding this comment.
Good point, ARG can be overriden at build, ENV can't. Will change to ARG then.
There was a problem hiding this comment.
Done. I also added a possibility to override the tag in Makefile, so you can do:
make KERNEL_TAG=v5.12.15
or use any tag from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
Signed-off-by: Michal Rostecki <[email protected]>
3 participants
This change adds the runc wrapper which has a purpose of applying
policies set through Kubernetes namespaces. For now, it uses the
namespace labels proposed in the PSP Replacement KEP[0].
The runc wrapper checks whether the container which is about to be
started was scheduled by kubelet (by checking runc annotations set by
kubelet / runtime servers). If some non-default policy is set, that
policy is written for the particilar container to the BPF map, so then
BPF programs can be aware of that policy.
For now, there is no way of proving that those annotations really come
from Kubernetes. Coming up with some sane way of securely proving that
will be something to implement in a follow up work.
[0] kubernetes/enhancements#2582
Fixes: #3
Signed-off-by: Michal Rostecki [email protected]