UIDMapping/GIDMapping Support

[qsfang]

Is there a way to support UIDMapping/GIDMapping using nri?

// PodSandbox linux-specific metadata
type LinuxPodSandbox struct {
        // UIDMapping specifies user mappings for supporting user namespaces.
	UIDMappings []LinuxIDMapping `json:"uidMappings,omitempty"`
	// GIDMapping specifies group mappings for supporting user namespaces.
	GIDMappings []LinuxIDMapping `json:"gidMappings,omitempty"`

	state         protoimpl.MessageState
	sizeCache     protoimpl.SizeCache
	unknownFields protoimpl.UnknownFields
	....
	Namespaces   []*LinuxNamespace `protobuf:"bytes,5,rep,name=namespaces,proto3" json:"namespaces,omitempty"`                      // for NRI v1 emulation
	Resources    *LinuxResources   `protobuf:"bytes,6,opt,name=resources,proto3" json:"resources,omitempty"`                        // for NRI v1 emulation
       

}

[lengrongfu]

This is more difficult, as nri can only obtain the ID of the container before it is started, but not the ID after it is started. This feature has already been implemented in runc.

[rogowski-piotr]

So, is it possible to retrieve the structure related to UIDMapping/GIDMapping during the container start-up phase (e.g., at the StartContainer stage)?

[utam0k]

Each mounts in OCI Runtime Spec has UID/GID mapping. https://github.com/opencontainers/runtime-spec/blob/main/config.md#posix-platform-mounts

So, it'd better Mount has these field.

[utam0k]

I'm not sure who is responsible for triaging the issue in NRI, but @mikebrow and @saschagrunert WDYT?

[mikebrow]

Is there a way to support UIDMapping/GIDMapping using nri?

// PodSandbox linux-specific metadata
type LinuxPodSandbox struct {
        // UIDMapping specifies user mappings for supporting user namespaces.
	UIDMappings []LinuxIDMapping `json:"uidMappings,omitempty"`
	// GIDMapping specifies group mappings for supporting user namespaces.
	GIDMappings []LinuxIDMapping `json:"gidMappings,omitempty"`

	state         protoimpl.MessageState
	sizeCache     protoimpl.SizeCache
	unknownFields protoimpl.UnknownFields
	....
	Namespaces   []*LinuxNamespace `protobuf:"bytes,5,rep,name=namespaces,proto3" json:"namespaces,omitempty"`                      // for NRI v1 emulation
	Resources    *LinuxResources   `protobuf:"bytes,6,opt,name=resources,proto3" json:"resources,omitempty"`                        // for NRI v1 emulation
       

}

I believe work is needed to add support.

We can discuss at what levels of pod/container construction we would publish UID/GID information/mappings and/or allow any edits. I believe we need support for certain device types, especially to add UIDs for a mount/device... @klihub

As @utam0k correctly surmises, the extended fields of each container mount includes uid/gid mappings and these could be published through the nri.. The pod's uid/gid run as information should also be available as read only meta..

To add/remove/modify, adjust, these mappings might also be doable.. but of course this may effect the client/kubelet security context mounts needed by the runtime. I think when it comes to adjustments this request would need to follow the pattern currently being worked for other security context fields.

[klihub]

@mikebrow @qsfang When we consider this, I think a few important questions are 1) what are the use cases that would need this and, 2) how prevalent they are ? Based on that we can then decide what to do: 1) to implement this right away (which I think would imply that we want to include this in the 1.0 content), 2) delay this post 1.0, or 3) decide not to go for for the time being.

[qsfang]

@mikebrow @qsfang When we consider this, I think a few important questions are 1) what are the use cases that would need this and, 2) how prevalent they are ? Based on that we can then decide what to do: 1) to implement this right away (which I think would imply that we want to include this in the 1.0 content), 2) delay this post 1.0, or 3) decide not to go for for the time being.

@klihub In our scenario，we need the specified host user uid(eg 1000) mapping to root user (uid 0)in container, and container will mount cpfs data dir through hostPath, the root user in container mapping to real uid (eg 1000) when accessing cpfs data.

The CRI-O provide similar capabilities https://github.com/cri-o/cri-o/blob/main/tutorials/userns.md

[klihub]

@qsfang Thanks for that pointer. Now I think I understand much better what you are after. As @mikebrow stated, work is needed and we need to think at which level and how to add the necessary bits for this.

If we choose to go for extending NRI so that CRI-O-equivalent ID-mapping functionality could be implemented using NRI alone (which is tempting) then this is not just a simple feature addition, like #155 for instance, since we currently don't have any pod-level adjustments (or edits as @mikebrow usually calls them), only container-level ones. And since conceptually pods do not exist in the OCI Spec/runc level, more (implementation detail) divergence can be expected between how those are handled in CRI-O and containerd than for containers. So then I'll suspect that will require some extra head scratching.

[klihub]

@mikebrow I'd say based on the above train of thoughts that if we decide to go for this, then getting such capbility merged is clearly post-1.0 material. The only (tangentially) related changes I'd like to make prior to 1.0 is to get rid of the artificial StateChange on-the-wire NRI event and unfold it to multiple proper messages, one for each it can now represent (RunPodSandbox, UpdatePodSandbox, StopPodSandbox, RemovePodSandbox, PostCreateContainer, PostStartContainer, PostUpdateContainer).

[klihub]

@utam0k @lengrongfu @qsfang I have one more related question: Is it enough for you guys to get the per-mount UID- and GID-mappings exposed to NRI plugins, or do you need to be able to adjust/modify those mappings from NRI plugins as well ?

[qsfang]

@utam0k @lengrongfu @qsfang I have one more related question: Is it enough for you guys to get the per-mount UID- and GID-mappings exposed to NRI plugins, or do you need to be able to adjust/modify those mappings from NRI plugins as well ?

@klihub In my scenario, it's better that nri can specify UID- and GID- mappings by annotation . Especially we want to map container root user to real host non-root user (not just for security consideration)

[klihub]

@qsfang: Exposing this on the input side is really straightforward.

We simply need to define the protobuf/type for LinuxIDMappings, provide To/From conversion functions to OCI, add the UID/GID mappings fields to Mount and use these conversion function on the input side to fill in those missing/new fields. I have a working branch with that here: https://github.com/klihub/nri/tree/devel/mount-linux-id-mappings

In principle you could also alter the mappings with that branch already by removing a mount with existing mappings then re-adding it with different ones. But since I don't understand the full chain of how that mapping gets set up in the first place and what other side effect the necessary preconditions for that to happen have, I really don't know if that could really work with this minimal implementation.

@qsfang: You posted links to related annotation handling in cri-o. Do you have simple instructions also for containerd (for instance, a pod spec and any necessary other k8s or containerd configuration that might need to be altered wrt. defaults) to trigger behavior where we end up in the runtime with an OCI Spec mount that has non-empty UID or GID mappings set ?