Implement runInContainer

[miekg]

I thinking of implementing run-in-container, but I'm wondering about auth. I don't fully understand it yet from the k8s side, but I do think it makes sense to have a defense in depth and also check the local user on the system.

So I'm thinking of utilizing ssh and using the user ID from the kubectl call (how to get that though?) and then performing a ssh USER@localhost and dropping you in the /var/run/systemk/UID directory; which you can escape as you are free to roam the system; just like normal ssh. And commands given are dropped for the time being, but we may just want to go with garbage in; garbage out.

[miekg]

I would be nice if VK would give the user in the context, right now there isn't a lot there...

[miekg]

doing an exec /bin/bash as the current user is a Bad Idea (tm) because we run as root currently.

[miekg]

this might be problematic:

% ./kubectl exec --stdin --tty uptimed -- /bin/bash
Defaulting container name to uptimed.
Use 'kubectl describe pod/uptimed -n default' to see all of the containers in this pod.
Error from server: error dialing backend: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

[miekg]

this will also impact #5

[pires]

In Kubernetes the only way to define UID/GID is in a Pod spec. Kubernetes is not opinionated when it comes to validate that: some security firms sell container runtime integrations that validate/enforce during container startup; and/or admission plug-ins for doing it while the request to create a Pod is in-flight.

The Kubernetes API also doesn't mandate for user information other than an identity proof that can be validated by the authorization layer, and even that is not expected to carry UID/GID.

For starters, I'd run containers either as specified UID/GID or, if unspecified, use a default one, eg nobody.