<p>I have a set of vendor-provided containers that work together to provide a service, let's call them A, B and C - the Kubernetes cluster runs one of each, in separate pods.</p>

<ul>
<li>Container A is a frontend Nginx container that mostly forwards stuff to container B. The frontend allows you to signup an account, which is really an API call forwarded to container B.</li>
<li>Container B is the backend - it has a proprietary in-memory database, and stores the accounts there. When an account is created, a security token is also created and stored. (Users can retrieve that token through API calls via A.)</li>
<li>Container C is a bridge to some stuff outside the cluster. But crucially, you configure it with an environment variable containing a valid security token from a user account stored in container B. C uses that token to talk to B through A.</li>
</ul>

<p>Ideally I would like to deploy this all in one go - meaning I somehow need to create an account in container B (by calling A), then get that value into the environment variable for C.</p>

<p>Some thoughts:</p>

<ul>
<li>I can't use an init container to SQL insert a new user because the database isn't exposed. </li>
<li>I can build containers on top of the vendor containers to edit config/scripts etc, but replacing binaries is probably out of scope.</li>
<li>I can <strong>just about</strong> script the backend API through A to B. However, it's challenging as it makes use of XSRF tokens that persist between requests, etc. Any suggestions for the simplest tools/libraries to use to achieve that are welcome.</li>
<li>If I do script that account creation, I would then need to get that token into the Deployment for container C - I could use a ConfigMap, but then I would need to call the Kube API to modify the ConfigMap from within the cluster, and that doesn't seem like a great idea to me.</li>
</ul>

<p>To me, the only viable solution is to put an initContainer on C that will query B (via A) for the security token, then write that to a shared volume. Then I would build on top of container C to read from the shared volume, set the environment variable internal to the container and start the vendor's process. But then I have to manage the secret for the user account.</p>

<p>Are there any improvements on that approach, or anything completely different I haven't considered?</p>

Oli
<p>Performing API operations from inside a container is not an antipattern. Block startup of your process on <strong>C</strong> until the <code>initContainer</code> runs and updates the <code>Secret</code> containing the token. Don't use a <code>ConfigMap</code> for secrets; the <code>Secret</code> object exists for these purposes, and you can pull a <code>Secret</code> into a <code>PodSpec</code> - as env vars, or a volume mount - the same way you pull a <code>ConfigMap</code> (with some minor syntax variation).</p>

<p>The only trouble I can see you potentially running into is that you'll be dealing with multiple replicas, so you might want to randomise some of the <code>Secret</code> name. Create it in the <code>initContainer</code>, pass the randomised name across in the filesystem since <code>Pods</code> share a filesystem, then consume it in the main container and delete the <code>Secret</code> after the env var or mount gets set up. <code>Secrets</code> and <code>ConfigMaps</code> can disappear after a <code>Pod</code> starts up without affecting their presence inside the <code>Pod</code>.</p>

<p>You'll also probably want some way of cleaning up the user accounts, as you're essentially creating a new user every time a replica starts and won't have an opportunity to delete it. A <code>CronJob</code> might be the way forward for that - list the user accounts matching your naming convention, then restart the deployment and delete the accounts in the list you fetched before the restart. That way you won't be pulling the rug out on any active replicas.</p>
