Add non-root support for PodImpersonation

[mallardduck]

Related to: rancher/rancher#53280

Issue

When calling PodImpersonation.CreatePod if the input pod *v1.Pod has non-root SecurityContext the added containers do not match the pod and cause errors.

CreateContainerConfigError (container's runAsUser breaks non-root policy (pod: "dashboard-shell-p2r7h_cattle-system(3179f6df-3ca5-4f59-a2f7-256bf3fd1fbb)", container: init-kubeconfig-volume))

Solution

Modify PodImpersonation to ensure it will not add explicit root user configs. This way it will inherit the values from the Pod's config and can be run as non-Root.

Testing

Tested local branch/package alongside my PR to Rancher using the newest Shell RC.

Other Thoughts

I'm not sure what other context this code is used in so there may be issues related to that blindspot. If we assume the context always relates to the rancher/shell image then this is less concerning. Since we can always know that the /home/shell exists for non-root access.

[Copilot]

Pull request overview

This PR adds non-root support for PodImpersonation by removing explicit root user configurations (RunAsUser and RunAsGroup) from init containers and the proxy container. The intent is to allow these containers to inherit security context settings from the pod level, enabling the code to work with pods that have non-root security contexts. Additionally, file paths are changed from /root/.kube/config to /home/shell/.kube/config to match the expected home directory for non-root users.

Key changes:

• Removed explicit RunAsUser and RunAsGroup settings from init and proxy containers
• Changed KUBECONFIG paths from /root/.kube/config to /home/shell/.kube/config
• Modified SecurityContext handling to preserve or inherit container settings

Reviewed changes

Copilot reviewed 2 out of 4 changed files in this pull request and generated 5 comments.

File	Description
pkg/podimpersonation/podimpersonation.go	Modified SecurityContext handling for init and proxy containers to support non-root execution; updated KUBECONFIG paths from /root to /home/shell
go.mod	Added Kubernetes version replace directives to pin all k8s.io dependencies to v0.34.1/v1.34.2
go.sum	Updated checksums for new and updated dependencies including extensive k8s.io module additions
.gitignore	Added .idea directory to ignore list and reordered entries

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The SecurityContext handling logic may override settings from the original container's SecurityContext. If container.SecurityContext is not nil, this code directly assigns it to the init container, which could include settings like RunAsUser, RunAsNonRoot, AllowPrivilegeEscalation, etc. that may not be appropriate for the init container's purpose. Consider creating a new SecurityContext that only copies specific required fields from the container's SecurityContext rather than using it directly.

Suggested change

	securityContext = container.SecurityContext
	//We must override ReadOnlyRootFilesystem value to false for same reason as above.
	securityContext.ReadOnlyRootFilesystem = &f
	// Create a copy of the container's SecurityContext so that updates
	// for the init container do not mutate the original container's settings.
	scCopy := *container.SecurityContext
	// We must override ReadOnlyRootFilesystem value to false for same reason as above.
	scCopy.ReadOnlyRootFilesystem = &f
	securityContext = &scCopy

[Copilot]

The init container command uses chown to change file ownership to UID 1000, but without explicitly setting RunAsUser, the init container will inherit the pod's SecurityContext. If the pod is configured to run as a non-root user other than UID 1000, the chown command may fail due to insufficient permissions. Consider either preserving the RunAsUser: 0 for the init container (to allow chown to work), or changing the approach to not require chown (e.g., using fsGroup).

[Copilot]

This comment mentions "same reason as above" but there is no clear reference to what "above" means in this context since the comment was likely moved. The comment should be more self-contained and explicit about why ReadOnlyRootFilesystem must be set to false (i.e., because the init container needs to write to the emptyDir volume).

Suggested change

	//We must override ReadOnlyRootFilesystem value to false for same reason as above.
	// We must override ReadOnlyRootFilesystem to false because the init container needs
	// to write to the emptyDir volume when copying and changing permissions on the
	// kubeconfig file.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.