Feature: Urunc on immutable (ReadOnly) k8s such as talos

[qdrddr]

There are immutable k8s OS that by default are readonly:

• Talos
• SLE Micro
• openSUSE MicroOS
• Fedora CoreOS (FCOS)

Immutable k8s offer greater security protection.

I would like to be able to run urunc on immutable systems without issues.

[cmainas]

Hello @qdrddr ,

yes, this would be a nice integration. Let's use this issue to track this integration.

[OdysseasKalaitsidis]

Hello @qdrddr @cmainas, i find this issue really interesting. I'd be happy to help prototype the Talos extension and test the setup if needed.

[kastakhov]

Hi @cmainas @OdysseasKalaitsidis ,

I have a working Talos v1.13+ Cilium PoC based on the official urunc v0.7.0 release. The main blockers found were:

• v0.7.0 runs chmod/chown on bind-mounted monitor binaries, which fails with EROFS on Talos’ read-only extension filesystem. A small downstream patch is required. Current main has reworked this mount path and no longer appears affected.

• OCI file mounts are appended as another CPIO archive. Unikraft stops at the first trailer, so mounted ConfigMaps, Secrets and /etc/resolv.conf are missing. This still exists on current main; the PoC merges the files into the original archive. I have created OCI file mounts are not extracted from Unikraft initrd #985 issue for this.

• Modern Unikraft configuration hard-codes 8.8.8.8. The PoC passes Kubernetes’ resolver from the OCI /etc/resolv.conf; current main still hard-codes it. I saw there are some already created PRs related to this, like feat: forward guest DNS to Docker's embedded resolver #793, feat(network): add support for forward guest localhost DNS for unikraft #966. However, it does not fully solve Kubernetes DNS resolving; CoreDNS normally has a non-loopback ClusterIP, so that path leaves the resolver unset and feat(network): add support for forward guest localhost DNS for unikraft #966 falls back to 8.8.8.8.

• A Talos extension cannot currently provide /etc/urunc/config.toml. QEMU works with defaults, but the default virtiofsd path does not match the extension path, so that rootfs mode needs another solution.

With Cilium, socketLB.hostNamespaceOnly=true is required so ClusterIP translation happens in the endpoint TC path. The Unikraft VM does not make socket calls from the pod cgroup.

[cmainas]

Hello @kastakhov ,

thank you for these useful information

* v0.7.0 runs chmod/chown on bind-mounted monitor binaries, which fails with EROFS on Talos’ read-only extension filesystem. A small downstream patch is required. Current main has reworked this mount path and no longer appears affected.

As soon as #982 gets merged, we will have a new release. In general this PR will help us integrate better with such setups, because our manual setup was never taking into account such systems.

* OCI file mounts are appended as another CPIO archive. Unikraft stops at the first trailer, so mounted ConfigMaps, Secrets and /etc/resolv.conf are missing. This still exists on current main; the PoC merges the files into the original archive. I have created [OCI file mounts are not extracted from Unikraft initrd #985](https://github.com/urunc-dev/urunc/issues/985) issue for this.

A temporary workaround (to just "make it work") would be the use of 9pfs for Unikraft.

* Modern Unikraft configuration hard-codes 8.8.8.8. The PoC passes Kubernetes’ resolver from the OCI /etc/resolv.conf; current main still hard-codes it. I saw there are some already created PRs related to this, like [feat: forward guest DNS to Docker's embedded resolver #793](https://github.com/urunc-dev/urunc/pull/793), [feat(network): add support for forward guest localhost DNS for unikraft #966](https://github.com/urunc-dev/urunc/pull/966). However, it does not fully solve Kubernetes DNS resolving; CoreDNS normally has a non-loopback ClusterIP, so that path leaves the resolver unset and [feat(network): add support for forward guest localhost DNS for unikraft #966](https://github.com/urunc-dev/urunc/pull/966) falls back to 8.8.8.8.

Yes, we need to handle the DNS configuration for non-LInux guests better and reading /etc/resolve/conf to set the Unikraft's cli arguments appropriately is the correct approach. Feel free to open an issue for this.

* A Talos extension cannot currently provide /etc/urunc/config.toml. QEMU works with defaults, but the default virtiofsd path does not match the extension path, so that rootfs mode needs another solution.

Is there any path (e.g. /opt) that can be used for the configuration? Looking at https://oneuptime.com/blog/post/2026-03-03-install-kata-containers-runtime-on-talos-linux/view#kata-configuration there is a way for Kata, so we can do the same for urunc.

In general, the integration of Kata Containers with Talos is a good reference.

[kastakhov]

Yes, we need to handle the DNS configuration for non-LInux guests better and reading /etc/resolve/conf to set the Unikraft's cli arguments appropriately is the correct approach. Feel free to open an issue for this.

Sure things, I can create a PR for fixing this issue, however without #966 it won't work anyway.

Is there any path (e.g. /opt) that can be used for the configuration? Looking at https://oneuptime.com/blog/post/2026-03-03-install-kata-containers-runtime-on-talos-linux/view#kata-configuration there is a way for Kata, so we can do the same for urunc.

Yes, we can use some another path, like /var/etc/urunc/config.toml to use non-default configuration for urunc, but as far as I see, right now /etc/urunc/config.toml is hardcoded. This can be either be configurable while building or using patches. I can create some PR for this issue as well.

As soon as #982 gets merged, we will have a new release. In general this PR will help us integrate better with such setups, because our manual setup was never taking into account such systems.

If we can fix those issues before release as well, it would be nice, as we would no need to create patches as workarounds for them while building urunc extension.

[Anand-240]

Hey @cmainas @kastakhov @qdrddr, on the config path blocker and which path to use: instead of moving /etc/urunc/config.toml to another fixed spot, better to make it resolvable like Kata does (KATA_CONF_FILE env var first, then a search path). For urunc:

1. A URUNC_CONFIG_PATH env var if set, so a Talos extension can point urunc at an available path at runtime.

2. A build time default. urunc already uses ldflags (Makefile line 58, -X main.version), so no new machinery needed: making the const UruncConfigPath (urunc_config.go line 25) a var lets an extension build set /var/etc/urunc/config.toml without patching source.

3. Fallback search order if neither is set (/etc/urunc, /var/etc/urunc, /usr/share/urunc), first that exists. LoadUruncConfig already defaults when the file is missing, so it stays safe.

Small change, the path is only used in three spots (create.go 77, guest_rootfs.go 62, main.go 138). One caveat: the shim and urunc binary run in different contexts, so on Talos the env var has to reach both, hence doing env and build time default together.

@kastakhov you mentioned a possible PR for this too. Happy to take just this slice (resolution plus unit tests and a docs/configuration.md note) so you can stay on DNS and #985, if that works.

[kastakhov]

Hi @Anand-240,
This sounds good to me, willt take care about DNS in k8s and #985 issues.
Just one small thing about DNS issue, I'd use #793 and #966 as a base, they are not merged yet, but looking on their threads seems it would be done soon enough. Please correct me if I'm wrong here.

[Anand-240]

Sounds good, thanks @kastakhov, that split works. I'll pick up the config path slice.
@cmainas before I open the PR, does the three layer shape above look right to you (a URUNC_CONFIG_PATH env var, an ldflags overridable default, then a search order), or would you rather keep it to just a build time override? Happy to go either way, just want to match what you'd prefer to maintain.

[cmainas]

Hello all,

I have created a new issue #987 for the configuration path. Let;s move the related discussion there.

Regarding the DNS configuration in Unikraft, we can directly integrate it to https://github.com/urunc-dev/urunc/pull/966/changes. No reason for 2 PRs for a similar fix. I can add it as a review comment to reference this discussion.