Make image.rootless default to true to avoid chroot limit #432

New Issue

2023-04-10T15:06:04Z

wxiaoguang commented

2023-04-10 15:06:04 +00:00

(Migrated from gitea.com)

It seems that some containers have limitations for chroot (SYS_CHROOT capability)

Users have to manually to make the containers support SYS_CHROOT, which is not a well-known knowledge.

I guess if make image.rootless default to true, there won't be any chroot problem any more?

It seems that some containers have limitations for `chroot` (SYS_CHROOT capability) Users have to manually to make the containers support SYS_CHROOT, which is not a well-known knowledge. I guess if make `image.rootless` default to true, there won't be any chroot problem any more?

pat-s commented

2023-04-10 20:56:27 +00:00

(Migrated from gitea.com)

I guess we could do it without causing major issues for existing setups. Using a rootless image is better anyhow.

A common environment in which this is anyhow required is Openshift.

@justusbunsi What is your opinion?

I guess we could do it without causing major issues for existing setups. Using a rootless image is better anyhow. A common environment in which this is anyhow required is Openshift. @justusbunsi What is your opinion?

justusbunsi commented

2023-04-10 21:10:19 +00:00

(Migrated from gitea.com)

Hm. It would definitely be a breaking change from a chart point of view and it seems there are necessary changes to be done beforehand (#396). Rootless images are for sure preferred over root-based ones. So I have nothing against such switch in a long run.

justusbunsi commented

2023-04-10 21:11:45 +00:00

(Migrated from gitea.com)

As an alternative to making it default, we could add explicit security capabilities for the rootless image.

justusbunsi commented

2023-04-10 21:17:15 +00:00

(Migrated from gitea.com)

From a ssh perspective: are existing openssh generated server keys compatible with the built-in ssh server from rootless image? If not this would be an issue.

pat-s commented

2023-04-11 21:47:50 +00:00

(Migrated from gitea.com)

Hm. It would definitely be a breaking change from a chart point of view and it seems there are necessary changes to be done beforehand (#396). Rootless images are for sure preferred over root-based ones. So I have nothing against such switch in a long run.

Good catch. Though arguably openshift is a special case (always) and I am not so sure if supporting it unconditionally would/should be the goal of all default chart settings. I think on a "normal" k8s there would probably be no issues.

From a ssh perspective: are existing openssh generated server keys compatible with the built-in ssh server from rootless image? If not this would be an issue.

I remember having switched from root to rootless at some time in our instance without facing any SSH related issues. So I'd say they're compatible.

As an alternative to making it default, we could add explicit security capabilities for the rootless image.

That would probably be good regardless of the switch to rootless.

> Hm. It would definitely be a breaking change from a chart point of view and it seems there are necessary changes to be done beforehand (#396). Rootless images are for sure preferred over root-based ones. So I have nothing against such switch in a long run. Good catch. Though arguably openshift is a special case (always) and I am not so sure if supporting it unconditionally would/should be the goal of all default chart settings. I think on a "normal" k8s there would probably be no issues. > From a ssh perspective: are existing openssh generated server keys compatible with the built-in ssh server from rootless image? If not this would be an issue. I remember having switched from root to rootless at some time in our instance without facing any SSH related issues. So I'd say they're compatible. > As an alternative to making it default, we could add explicit security capabilities for the rootless image. That would probably be good regardless of the switch to rootless.

pat-s commented

2023-05-28 16:34:16 +00:00

(Migrated from gitea.com)

From a ssh perspective: are existing openssh generated server keys compatible with the built-in ssh server from rootless image? If not this would be an issue.

I thought about this again. I assume that if this would be an issue, we would have heard of it in the main repo already as presumably many people already switched from rootfull to rootless since the existence of the rootless variant.

In addition, the change will be listed in the changelog and they can still go back to the rootfull image to continue like before.

Hence I'd say we can switch - I'll prepare a PR.

> From a ssh perspective: are existing openssh generated server keys compatible with the built-in ssh server from rootless image? If not this would be an issue. I thought about this again. I assume that if this would be an issue, we would have heard of it in the main repo already as presumably many people already switched from rootfull to rootless since the existence of the rootless variant. In addition, the change will be listed in the changelog and they can still go back to the rootfull image to continue like before. Hence I'd say we can switch - I'll prepare a PR.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunny/helm-chart#432

Make image.rootless default to true to avoid chroot limit #432

Make `image.rootless` default to true to avoid chroot limit #432