0

I'm planning to have an initcontainer that will handle some crypto stuff and then generate a source file to be sourced by a container. The source file will be dynamically generated, the VARS will be dynamic, this means I will never know the VAR names or it's contents. This also means I cannot use k8s env. The file name will always be the same.

I know I can change the Dockerfile from my applications and include an entrypoint to execute a script before running the workload to source the file, but, still, is this the only option? There's no way to achieve this in k8s?

My container can mount the dir where the file was created by the initcontainer. But it can't, somehow, source the file?

apiVersion: v1
kind: Pod
metadata:
  name: pod-init
  namespace: default
spec:
  nodeSelector:
    env: sm
  initContainers:
    name: genenvfile
    image: busybox
    imagePullPolicy: Always
    command: ["/bin/sh"]
    # just an example, there will be a software here that will translate some encrypted stuff into VARS and then append'em to a file
    args: ["-c", "echo MYVAR=func > /tmp/sm/filetobesourced"]
    volumeMounts:
    - mountPath: /tmp/sm
      name: tmpdir
  containers:
    image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
    imagePullPolicy: IfNotPresent
    name: mypod-cm
    tty: true
    volumeMounts:
    - mountPath: /tmp/sm
      readOnly: true
      name: tmpdir
  volumes:
    name: tmpdir
    emptyDir:
      medium: Memory

The step-by-step that I'm thinking would be:

  1. initcontainer mounts /tmp/sm and generates a file called /tmp/sm/filetobesourced
  2. container mounts the /tmp/sm
  3. container source the /tmp/sm/filetobesourced
  4. workload runs using all the vars sourced by the last step

Am I missing something to get the third step done?

JGG
  • 304
  • 2
  • 12
  • Does the secret has to be tightly coupled together with lifecycle of this Pod(i.e., a new secret required for each new container spin up)? – congbaoguier Aug 16 '21 at 14:53
  • Have you tried to mount the generated file as `/etc/environment`? – SYN Aug 16 '21 at 15:27
  • @SYN I believe /etc/environment, /etc/profile, /etc/profile.d/*.sh.. or any other /etc/ will not work for the workloads. Those are executed during the login of a user. Right? – JGG Aug 16 '21 at 18:17
  • @congbaoguier yes. The encrypted "stuff" is valid only during the life of the pod. – JGG Aug 16 '21 at 18:18

1 Answers1

1

Change the command and/or args on the main container to be more like bash -c 'source /tmp/sm/filetobesourced && exec whatevertheoriginalcommandwas'.

coderanger
  • 52,400
  • 4
  • 52
  • 75
  • Thx for contributing @coderanger. Still, I'm looking for something that does not change the behavior of the Dockerfile. You are asking me to override the entrypoint, right? I can't, because we have a live environment and different kinds of entrypoints(+apps) are used. Or maybe I misunderstood your answer. Maybe you could provide an example of running something first then continue to execute the entrypoint/workload as it was meant to be. – JGG Aug 16 '21 at 18:27
  • Nope, there is no option which meets those requirements. Docker does not expose the original command in a generic way. – coderanger Aug 16 '21 at 19:15