This message was deleted.

We’re also transitioning from RancherOS on our nodes to Elemental so trying to track down where this may be happening

what… what deployment and pod are you talking about?

When I create a deployment (same image in both cases) and assign a env var in the rancher UI (either directly or via config map, etc) it is present in the

root

users environment in both RKE and RKE2 - but in RKE it is also present in the

/etc/environment

file in RKE.

That might be a difference between the docker and containerd runtimes? I don’t believe there’s any contract from Kubernetes that guarantees that environment variables are also injected into /etc/environment

gotcha - that would make sense - that helps narrow it down I guess

I’m not sure what you mean by “beyond the root user”. Environment variables are set for the init pid in each container, regardless of what user ID that process is run as. Past that point it’s up to the container’s entrypoint to set or not set environment variables for any other processes it executes. Are you doing something weird like running a ssh daemon in your pod, and logging into it interactively?

for most pods we’re not doing anything odd - but you’re correct in that I noticed this first in some development pods where we do connect to directly (not ssh) and expect those vars to be present

You should see variables set consistently for the container entrypoints, as well as any processes you start via

kubectl exec

. If you’re using some other process manager within the containers, or running some sort of remote access service that allows you to log in to pods via some other mechanism, you’d have to look at configuring that to pass through the vars properly.

ok that makes sense - still getting my head around the difference between our current stack and elemental/rke2/containerd

Is there a reason you can't get your environment variables as environment variables? Such as with the command

env

or in python with

import os ; os.environ

sort of methods?

the issue is when our developers change users in the container these values aren’t persisted

It sounds like they’re running some other server in the pod to get shells within it, and whatever is providing that does not pass through all the vars from Kubernetes

Yeah, I missed "other users in the pod" so multiple containers/processes.

Something else was also writing the vars to /etc/environment, but it’s not clear what that was as it is not standard behavior

previously it seems these were added to

/etc/environment

automatically and we didn’t realize this would change

having developers logging into pods is an anti-pattern to begin with so 🤷

I guess I can see that. If they've got multiple containers/processes in a single pod, I'd assume the last to start would write out since /etc would be shared.

we use a base image as a development container that devs connect to via VS Code

Within Linux only root can poke around in /proc and look at the environment for other users' processes, otherwise you can only see your own. I'd expect the same behavior inside containers.

so this is a bit of a special case deployment but I was trying to understand the behavior change and where it might be happening in regards to

/etc/environment

I think the original behavior is probably wrong from a security stance, as you don't want non-owner, non-root users to be able to read a process' environment variables. Things using Docker did tend to assume running as root even if you could change it, so being less concerned about user differences isn't that surprising. If you want to allow it anyway, I think you should probably tweak your running container to output it somewhere and chmod it world readable.

yah that makes sense - we only need a handful of them so I’ll prob go that route