<p>As an IT contractor, I was tasked with fixing an issue in a client's software which made simple use of a third-party library to encrypt or decrypt byte strings. For reasons relating to AWS temporary access tokens, the library required occasional reinitialisation for a fresh access token to be acquired (via AWS EKS) and used.</p>
<p>I came up with a simple solution in which initialization and use of this library was relegated to a child process forked for the purpose, with input and output strings passed each way in hex via a couple of pipes. Then to reinitialize the library the parent could simply kill the child process and fork a new one.</p>
<p>Seems pretty standard stuff, used everywhere in Unix. But the client rep said this might cause problems in a Kubernetes pod, relating to access rights and process monitoring among other things. Is he correct, or is he (as I suspect) being an over-cautious pearl clutcher?</p>
<p>If he is right then what kind of problems can arise, and how can these be avoided?</p>

<blockquote>
<p>But the client rep said this might cause problems in a Kubernetes pod, relating to access rights and process monitoring among other things.</p>
</blockquote>
<p>There is nothing special about kubernetes with respect to child processes and access rights. It's just Unix processes: a child runs with the same credentials as the parent and can access the same files and other resources as the parent.</p>
<p>The process monitoring question is worth exploring in a little more detail. Typically, we say that containers in general -- not just in Kubernetes, but in docker/podman/etc as well -- should have a single entrypoint. In other words, you don't want to create a single container running multiple services, like a webserver and a database. This is because in a multi-entrypoint container, the failure of a service is hidden from the container management tools, so the container runtime can't destroy and re-create the container in response to the service failure.</p>
<p>As long as your application is able to respond properly to the child process dying unexpectedly -- both by calling <code>wait()</code> on it to clean up the process entry and properly respawning it when necessary -- you're in good shape.</p>
