Reputation: 21
I'm creating an agent service that accepts network calls and can trigger commands in any other container in the same pod. This, of course, isn't the usual use case of pods, but I know some CI tools do something similar, such as Jenkins and it's Kubernetes plugin.
Currently, I have it working using kubectl in the agent container and have it running kubectl exec <pod> -c <container> -- <command>
and it works fine. But it seems like a big opportunity for vulnerabilities.
In order for the agent to have kubectl exec access, it needs to have privilege on pod/exec
which gives it access to all pods in the same namespace.
rules:
- apiGroups: [""]
resources: ["pods", "pods/exec"]
verbs: ["get", "list", "watch", "create"]
If there aren't any better ways to approach this, I'll just bake the exec commands into my agent in such a way that it'll only accept calls to the same pod.
But my big concern is around executing unknown code from the agent and it getting access to more than it should. In the Jenkins example, if someone has a pipeline that tests their code and they were malicious and included a test which actually uses the kubernetes-client library and calls out to the other pods in the namespace, how would you prevent that while still enabling the container to container communication?
I'd appreciate any suggestions!
Upvotes: 2
Views: 1027
Reputation: 61699
Sounds like you want to execute commands in the pod but you don't want to hit the kube-apiserver. Also, looks like your application is listening for a trigger (on some sort of even based broker or application) and executing the command.
My suggestion would be to just have the application 'shell out' run the command itself instead of just having kubectl
run it on the same pod with exec
. You didn't specify what language your application is written in but most common languages have a library to do an exec system call or manage processes. i.e Golang, Python, etc.
✌️
Upvotes: 3