Bare-metal network bootstrap with SecureBoot (UKI) and encrypted STATE: recommended approach?

[mcanevet]

Hi,

I’m trying to understand the intended long-term approach for network bootstrap on bare metal, especially with SecureBoot (UKI) and encrypted STATE.

From what I see:

• Kernel network parameters (ip=, bond=, etc.) are not viable with UKI since the cmdline is embedded and immutable.
• talos.config.early is also delivered via the kernel command line, so it seems to inherit the same limitation (i.e. not suitable for dynamic per-node configuration).
• Relying on STATE for network config creates a bootstrap dependency when STATE is KMS encrypted, since networking is required before config can be applied.
• META configuration exists, but doesn’t seem aligned with the newer multi-doc / machine config workflows and feels more like a low-level mechanism.

This seems to leave a gap for environments that are:

• bare metal (no metadata service)
• SecureBoot-enabled (UKI)
• using static networking (no DHCP)
• with encrypted STATE

In such setups, what is the recommended and scalable way to bootstrap networking?

Is the expectation to:

• pre-build per-node images with embedded config?
• rely on DHCP for initial bootstrap?
• or is there another mechanism planned to address this use case?

Thanks!

[smira]

There are many ways to configure networking on bare-metal, some of them are in the docs.

In general, DHCP is the easiest of course.

With Image Factory it's pretty easy to create an image with static network configuration embedded one way or another.
There are ways with config in the ISO, etc.

But the answer depends on the specific environment. Like if it's static network config - how are even these nodes are booted uP?

[mcanevet]

Thanks, that helps clarify the intended approaches.

Thinking through this more, it seems that in environments with:

• no DHCP
• SecureBoot (UKI, so no mutable kernel cmdline)
• encrypted STATE with KMS

there is still a need for some form of early, pre-STATE network configuration that doesn’t rely on kernel parameters.

Today, the only mechanism that appears to satisfy those constraints is the META partition, since it’s available early in boot and not tied to the kernel cmdline.

However, META feels more like a low-level or legacy mechanism compared to the newer multi-document machine config model introduced in recent versions.

Would it make sense to move toward making this a more first-class approach? For example:

• persisting a subset of machine configuration (e.g. network) in META
• using the same multi-document format as regular machine config
• and treating it as the canonical “early config” layer before STATE is unlocked

That could provide a more consistent and scalable path for static / deterministic bare-metal environments, without relying on per-node image builds or kernel arguments.

Curious if this aligns with the current direction, or if there are reasons this approach wouldn’t fit with Talos design goals.

[smira]

META network config for metal is not going to be removed.

There is no boundary in machine configuration - it is always machine configuration, whether it's early or late - like I said you have numerous options, and you can use the one which fits your case.

[mcanevet]

WDYT of supporting new multi-doc format in META 0x0a in parallel to the YAML serialization of the COSI resource?
Auto-detection should be quite easy to do (if 0x0a containts "apiVersion" then it's the new multi-doc format).
That way, network configuration through META could be considered first-class citizen.

[smira]

Not yet, we might do that, but it's a bigger scope. It shouldn't be blocking you in any way right now.

[mcanevet]

I could contribute to that if it's OK for you. But if you're not ready to accept a contribution for that right now, I could totally understand.

[smira]

We have some internal discussion about it, but it's a bigger scope than your case, so we are not ready it yet.