Security context for core dump handler

[nevotz]

Hi ,
i really like this project , but after going to the deamonset.yaml i notice that the SecurityContext has privileged set to true .
and this is problematic from security perspective .
can you recommend more strict permission i can use and still use the tool ?

thx

[No9]

Hey @nevotz thanks for the kind feedback
The pod has raised privileges so that it can modify the host sysctls core_pattern suid and limits.
These are node-level sysctls and are outside of the kubernetes configuration.
To mitigate this the default install puts it into a new namespace and access to that namespace can be restricted.

Also depending on your k8s version you may be able to look at using platform specific config e.g. Openshift has machine config
But this would require a flag in the code to not run the host config from the pod but it's doable.

If you think something has been missed then please make a suggestion and we can see how it can be incorporated.

I was also thinking of splitting the agent from the deployment to mitigate this some more but that work hasn't started yet.

[No9]

From what I can see from the K3s docs its a lightweight k8s implementation without support for infrastructure config.
So I don't think the machine config option going to be possible in that instance but the k3s folks would be in a better position to confirm.

You could run the agent on the directly on the node with a .env containing the required config
This would require a PR that enables the agent to just run the config and a flag to disable the deployment when the agent runs as a container. It shouldn't be that complicated to implement but the tests would require some consideration.

[nevotz]

basically your nice tool is already deployed and working ,
im just don't know how to hardening the security context

[No9]

ok let me summarize where we are:
Currently the tool must run with the privileged : true config as it modifies the host node with sysctls that are not configurable from k8s.
This is mitigated by:

1. Not providing any external entrypoints to the pod so an external attacker cannot directly make calls to gain elevated privileges
2. Installing into a dedicated namespace so that further RBAC can be defined if internal privilege escalations are concern.
   e.g. an internal developer logging into the pod and attacking from there

RBAC is possible to configure on k3s and there is discussion on it in this SO post
https://stackoverflow.com/questions/67210000/rbac-role-based-access-control-on-k3s

Future Option 1

If you are not allowed to deploy the pod with privileged : true then a change to the code would be required to configure the node out of band.
This would require the following modifications:

1. Enable the agent to run the config standalone and as root on the host node
2. Add a flag to disable the config when the agent runs as a container.
   This would increase the complexity of the deployment as the node config will likely need to be ran outside of helm.

Future Option 2

If the concern is a continuously running privileged pod then the host config and the agent could be split into two containers where the host config is done from a short running privileged pod and the agent running as with no privileges.

Both the future options will require code changes and are not on the immediate roadmap but an indication of which one would be preferred will help prioritize the work when it commences

[nevotz]

ok from another angle ,
can i change the Kind from DaemonSet to Deployment ?
this will help me to change the replicaset ans stay in privileged : true mode

[No9]

OK I'm not sure why changing from a DaemonSet to a Deployment makes a difference as both require a privileged container spec.
But if it works for you that's cool. I won't be changing the project to use Deployments though as DaemonSet is the correct object type
(i.e. Run once per node) for this project.