provide a portable mechanism for processes within container to obtain their image and container ids

[lpgc]

There are a number of use cases where the ability to portably obtain a container's image identity and its instance identity.

The most obvious is for logging; in larger systems where there are a significant # of container instances and image versions it is useful for processes therein to be able to "tag" their log output with both identities which as a tuple uniquely identify a particular instance from all its peers.

Other use cases, involve platform runtime serviceability components (e.g in the Java platform) where this information can also be used by the platform in order to correlate multiple forensic artifacts that may be generated over the lifetime of a particular container version(s) and instance(s).

This could simply be provided by requiring that the r/t expose those identifiers to processes therein by establishing a pair of standard environment variables such as OCI_IMAGE_ID and OCI_INSTANCE_ID or similar.

[mtrmac]

OTOH this goes against the idea of isolating containers from the system. A common unprivileged container has no business knowing where on the host its files are located (or even if they are located on the host), and the easiest definitions of image/container IDs would probably point to specific host paths for the image store and per-container mounts.

My impression of the logging use cases is that they both can, and for better security should, be handled by a node-level log forwarder/collector, not by each container annotating its own output. Doing this in a collector is:

• more consistent (does not require container/application changes)
• more secure (a compromised container can not affect the value)
• potentially more efficient (a collector could annotate the full identity along with other metadata on container creation, and then only reference it, e.g. using only a container ID, on subsequent log entries)

---

If this needs to exist at all, I’d prefer standardizing the format and semantic guarantees (e.g. is the ID required to be stable / required to be different across reboots? across hosts in what kind of domain?), but only making them available if the user deploying the container explicitly opts in.

[lpgc]

"A common unprivileged container has no business knowing where on the host its files are located (or even if they are located on the host), and the easiest definitions of image/container IDs would probably point to specific host paths for the image store and per-container mounts."

I completely agree with your remark regardind container isolation, however I am not proposing exposing any location information whatsoever, I am only proposing exposing the image digest value and the container instance id, and not any host (or other) path information.

Where the container filesystem is located on a host is not useful for any of the use cases, the identity of the image, and an instance of it are, and while an external logger could potentially inject these values, this makes the task of gathering all
the possible artifacts that a containerized r/t is extremely onerous and costly and is not practical for a platform such as
Java (or any other language r/t for that matter) when the container ecosystem could simply expose the image digest and
instance id to the container itself, in the same way other environmental information is injectable into containers today.

[mtrmac]

At least in one implementation an image (config) digest directly points to a node path /var/lib/containers/storage/overlay-images/$digest/, and the container ID directly points to a /var/lib/containers/storage/overlay-containers/$digest.

Of course actually exploiting that would require a sandbox breakout, but it’s a piece of the puzzle.

[lpgc]

just to be clear I am proposing exposing the value of:

• the "digest" object found in the OCI image manifest config comnponent
• the "id" object described in the runtime spec container "state" definition...

[sudo-bmitch]

Another option, instead of environment variables, would be mounting a file inside the container. That file could be built in tmpfs, mounted read-only to a well known location like /run/oci-metadata, and use a format like json that allows more values to be added in the future without breaking existing functionality. The other field that I'd find useful would be labels on the image or container, which allows other build and run time information to be propagated into the container.

And I think we all agree, anything we do to implement this should only be on the container side (and associated image), no host level details like paths, hostname, or IP address of the host running the container should be visible from inside the container.

[lpgc]

Another option, instead of environment variables, would be mounting a file inside the container. That file could be built in tmpfs, mounted read-only to a well known location like /run/oci-metadata, and use a format like json that allows more values to be added in the future without breaking existing functionality. The other field that I'd find useful would be labels on the image or container, which allows other build and run time information to be propagated into the container.

And I think we all agree, anything we do to implement this should only be on the container side (and associated image), no host level details like paths, hostname, or IP address of the host running the container should be visible from inside the container.

I really like this proposal, (I think its also "compatible" with the mechanism employed by the k8s downwards API).

I would also +1 your suggestion regarding adding the image tags to this metadata, since those also are known to, and significant, to the components and tools that form the container ecosystem, I had actually wondered about those also.

[sudo-bmitch]

Related is this old issue from Docker: moby/moby#8427

[mtrmac]

Of course actually exploiting that would require a sandbox breakout, but it’s a piece of the puzzle.

Compare GHSA-c3xm-pvg7-gh7r where an attacker benefits from knowing the pod ID in Kubernetes.

[XSAM]

Another option, instead of environment variables, would be mounting a file inside the container. That file could be built in tmpfs, mounted read-only to a well known location like /run/oci-metadata, and use a format like json that allows more values to be added in the future without breaking existing functionality. The other field that I'd find useful would be labels on the image or container, which allows other build and run time information to be propagated into the container.

I like this one.

I am working on observability. Sometimes, it is hard to solve a problem on the container infrastructure, says containerd, without finding the buggy container first. Having a container id is really helpful by identifying the container. And, we can correlate a service with the underlying infrastructure, so we know exactly the place where the errors come from even within a massively distributed system, like on a Kubernetes cluster.

Kubernetes has the downwards API that can cast Pods' metadata to container env variables, but it cannot cast a container id; it can only cast something like the pod name. However, the pod name only provides a little help in identifying the container since the pod name is not unique, may be reused, on k8s, like the pods created by StatefulSet. And, to find a mapping from the container name to container id, we need to search the pod schedule logs or watch the k8s API. There are other ways like deploying a sidecar that can access the k8s API or the container daemon to fetch the container id, but it is a kind of wasting resources (We just want a container id), and it brings security concerns. Therefore, these approaches are not perfect and only work on k8s. What about containers running on the bare metal?

I do find a way to fetch container id within a container by reading the cgroup file /proc/self/cgroup. However, it is an undocumented behavior of container runtime. It is unstable and may change in the future, just like this approach is not going to work with cgroup v2. Using an undefined and unstable method to fetch container id makes me feel unsafe and upset. open-telemetry/opentelemetry-go#2418

I would like to help to settle a standard way to fetch container id within the container. But I am not sure about anyone from the community is working on this. Anything I can do to make it happen?

[imliuda]

we are facing the same problem, we want to collect coredump in containers, and some jvm logs and metrics, we need to distinct different lifecycle of a single container. we need to know the container id before starting our busyness process, then i can set jvm logs, and metrics to a path with container id suffix.