On 9/4/19 5:21 PM, Alexei Starovoitov wrote:

On 9/4/19 8:16 AM, Daniel Borkmann wrote:

quoted

opening/creating BPF maps" error="Unable to create map
/run/cilium/bpffs/tc/globals/cilium_lxc: operation not permitted"
subsys=daemon
2019-09-04T14:11:47.28178666Z level=fatal msg="Error while creating
daemon" error="Unable to create map
/run/cilium/bpffs/tc/globals/cilium_lxc: operation not permitted"
subsys=daemon

Ok. We have to include caps in both cap_sys_admin and cap_bpf then.

quoted

And /same/ deployment with reverted patches, hence no CAP_BPF gets it up
and running again:

# kubectl get pods --all-namespaces -o wide

Can you share what this magic commands do underneath?

What do you mean by magic commands? Latter is showing all pods in the cluster:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/#viewing-finding-resources

I've only been using the normal kubeadm guide for setup, it's pretty straight
forward, just the kubeadm init to bootstrap and then the kubectl create for
deploying if you need to give it a spin for testing:

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#tabs-pod-install-4

What user do they pick to start under? and what caps are granted?

The deployment is using a 'securityContext' with 'privileged: true' for the
the container spec as majority of CNIs do. My understanding is that this is
passed down to the underlying container runtime e.g. docker as one option.

Checking moby go code, it seems to exec with GetAllCapabilities which returns
all of the capabilities it is aware of, and afaics, they seem to be using
the below go library to get the hard-coded list from where obviously CAP_BPF
is unknown which might also explain the breakage I've been seeing:

https://github.com/syndtr/gocapability/blob/33e07d32887e1e06b7c025f27ce52f62c7990bc0/capability/enum_gen.go

Thanks,
Daniel