[doa-renovate]

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Update	Change
ghcr.io/siderolabs/talosctl	patch	v1.15.0-alpha.2 → v1.15.0-beta.0
siderolabs/talos	patch	v1.15.0-alpha.2 → v1.15.0-beta.0

---

Release Notes

siderolabs/talos (ghcr.io/siderolabs/talosctl)

v1.15.0-beta.0

Talos 1.15.0-beta.0 (2026-11-10)

Welcome to the v1.15.0-beta.0 release of Talos!
This is a pre-release of Talos

Please try out the release binaries and report any issues at
https://github.com/siderolabs/talos/issues.

Allow filtering incoming packets by the destination IP and link

A new NetworkLinkIngressConfig allows filtering incoming packets by link and the destination IP.
If destinationAddresses is left empty, it defaults to the node addresses, plus the broadcast, multicast and IPv6 link-local addresses.

apiVersion: v1alpha1
kind: NetworkLinkIngressConfig
name: enp0s2.35
destinationAddresses:
    - 1.2.3.4/32

NetworkLinkIngressConfig should not be used in the following scenarios:

1. When using the Cilium CNI with the kube-proxy replacement
2. With pod-to-pod network direct routing (without a tunnel like VXLAN)
3. MetalLB (L2 or BGP), Cilium LB IPAM and kube-vip service mode all deliver packets whose destination is the LB IP so they won't work

BGP MD5 Authentication

BGPInstanceConfig neighbors now accept an authPassword to enable TCP MD5 signature authentication (RFC 2385) of the BGP session,
including for VRF-bound BGP instances:

apiVersion: v1alpha1
kind: BGPInstanceConfig
name: fabric
localASN: 65001
neighbors:
  - address: 192.0.2.1
    peerASN: 65000
    authPassword: s3cr3t

The password is redacted from the machine configuration output. The BGPInstanceConfigs resource is now sensitive: the os:admin role reads it in full, while the other roles get it with the password replaced by REDACTED.

Boot Partition Wait

Talos now waits for the partition it was booted from to be discovered before declaring the system volumes (META, STATE) missing
and entering maintenance mode, so that disks enumerated late (SD cards, USB, some RAID controllers) are not mistaken for a fresh machine.

On UEFI systems booted via systemd-boot the boot partition comes from the LoaderDevicePartUUID EFI variable, while the GRUB configuration
now passes the talos.boot.partuuid=<UUID> kernel argument (probed by GRUB at boot). The detected boot partition is published as the bootpartition resource.

containerd Configuration Version 4

Talos now generates containerd configuration with version = 4 (previously version = 3).

containerd only migrates configuration from older versions, so any custom CRI configuration provided via
CRICustomizationConfig documents (or shipped by system extensions) is now interpreted as version 4, and settings
which moved in version 4 are silently ignored (only a Ignoring unknown key in TOML warning is logged by containerd).

In version 4, the top-level server sections moved into plugin configuration blocks, so the following patches need to be adjusted:

version 3	version 4
[metrics] address	[plugins."io.containerd.server.v1.metrics"] address
[metrics] grpc_histogram	[plugins."io.containerd.metrics.v1.grpc-prometheus"] grpc_histogram
[grpc] address, uid, gid, max_recv_message_size, max_send_message_size	[plugins."io.containerd.server.v1.grpc"] (same keys)
[grpc] tcp_address, tcp_tls_ca, tcp_tls_cert, tcp_tls_key, tcp_tls_common_name	[plugins."io.containerd.server.v1.grpc-tcp"] address, tls_ca, tls_cert, tls_key, tls_common_name
[ttrpc] address, uid, gid	[plugins."io.containerd.server.v1.ttrpc"] (same keys)
[debug] address, uid, gid	[plugins."io.containerd.server.v1.debug"] (same keys)

For example, the containerd metrics customization documented for previous versions of Talos:

apiVersion: v1alpha1
kind: CRICustomizationConfig
name: enable-metrics
content: |
  [metrics]
    address = "0.0.0.0:11234"

should now be written as:

apiVersion: v1alpha1
kind: CRICustomizationConfig
name: enable-metrics
content: |
  [plugins."io.containerd.server.v1.metrics"]
    address = "0.0.0.0:11234"

Note that [debug] level, format and log_trace_id stay at the top level, and that the ttrpc address is no longer
derived from the grpc address: if the grpc address is customized, the ttrpc plugin address has to be set explicitly.

CPU Scaling Configuration

CPU frequency scaling can now be configured declaratively with the CPUScalingConfig document, instead of through kernel arguments
or raw SysfsConfig keys:

apiVersion: v1alpha1
kind: CPUScalingConfig
name: all-cores
selector:
  match: true
governor: performance

Settings apply to the cpufreq policies matched by the selector, which targets cores by property rather than by index, so a machine
whose cores are not uniform can be configured without hardcoding how many it has:

apiVersion: v1alpha1
kind: CPUScalingConfig
name: performance-cores
selector:
  match: cpu.core_type == "performance"
governor: performance
---
apiVersion: v1alpha1
kind: CPUScalingConfig
name: efficiency-cores
selector:
  match: cpu.core_type == "efficiency"
governor: powersave

core_type is reported on Intel hybrid CPUs, and on Arm systems mixing core designs (big.LITTLE) whose firmware rates the
capacity of each core; it is empty on uniform machines.

The selector matches against the fields of the CPUScalingStatus resource, and may also set energyPerformancePreference,
minFrequencyKhz and maxFrequencyKhz. Where several documents match the same policy, the one whose name sorts first wins, and the
document which claimed a policy is reported on the resulting CPUScalingSpec resource. Removing the configuration restores the
values the machine booted with.

Setting a cpufreq attribute through both CPUScalingConfig and SysfsConfig is rejected, as the two would otherwise overwrite each
other continuously.

Kubelet Credential Provider Config Files

The KubeCredentialProviderConfig document supports a new configFiles field to provide configuration files for the credential provider plugins.
Each file is written to the /etc/kubernetes/credentialproviders directory, so it can be referenced in the args of a credential provider:

apiVersion: v1alpha1
kind: KubeCredentialProviderConfig
configuration:
  apiVersion: kubelet.config.k8s.io/v1
  kind: CredentialProviderConfig
  providers:
    - name: acr-credential-provider
      apiVersion: credentialprovider.kubelet.k8s.io/v1
      matchImages:
        - "*.azurecr.io"
      defaultCacheDuration: 10m
      args:
        - /etc/kubernetes/credentialproviders/azure.json
configFiles:
  - name: azure.json
    content: |
      {
        "cloud": "AzurePublicCloud",
        "tenantId": "<tenant-id>",
        "useManagedIdentityExtension": true
      }

Disk SMART Status

Talos can now collect SMART (Self-Monitoring, Analysis and Reporting Technology) health information from disks,
exposed via the new SMARTStatus resource (one per disk, keyed by the disk device name).

Collection is controlled by the presence of the new DiskSMARTConfig document: while the document is part of
the machine configuration SMART status is collected, and removing the document disables collection (any
SMARTStatus resources already produced are removed as well). There is no enabled field.

apiVersion: v1alpha1
kind: DiskSMARTConfig
interval: 30m0s

talosctl gen config and talosctl cluster create emit this document by default, so SMART status collection
is enabled by default for machine configurations generated by Talos 1.15. Clusters upgraded from an earlier
version keep their existing machine configuration, which carries no DiskSMARTConfig document, so SMART
status collection stays off there until the document is added.

Rotational disks are never spun up just to be probed: a disk in standby is detected via ATA
CHECK POWER MODE and its SMART data is left untouched until it is active again.

To retrieve SMART statuses:

talosctl get smart

The resource reports an overall health verdict, temperature, power-on hours and power cycles, NVMe wear
indicators (percent used, available spare, critical warning, media errors) and, for ATA/SATA disks, the raw
SMART attribute table with per-attribute thresholds.

Disk Free

A new talosctl diskfree command (aliased to df) reports storage and inode usage for mounted volumes.

Ethernet Flow Control

The EthernetConfig document now supports configuring Ethernet link flow control (802.3x pause frames)
with the new flowControl field, similar to the ethtool -A command:

apiVersion: v1alpha1
kind: EthernetConfig
name: eno1
flowControl:
  rx: true      # accept incoming pause frames
  tx: false     # don't transmit pause frames
  autoneg: true # autonegotiate flow control

Omitting the flowControl field leaves the link's flow control configuration unchanged.
Current flow control settings are reported on the EthernetStatus resource.

Extension Service Configuration

ExtensionServiceConfig is supported only for extension services whose service manifest explicitly declares a configuration dependency:

depends:
  - configuration: true

Using ExtensionServiceConfig with a service that does not declare this dependency is unsupported and has undefined startup behavior.
The service might start before its configuration is rendered, leaving config files or environment variables unavailable until a later service restart.
Extension authors must declare the dependency before documenting ExtensionServiceConfig support.

talosctl gen removed subcommands

The following talosctl gen subcommands have been removed:

• talosctl gen ca
• talosctl gen crt
• talosctl gen csr
• talosctl gen key
• talosctl gen keypair

These commands where historically used to generate pieces of Talos PKI, but they are no longer needed
as talosctl gen config and talosctl gen secrets now generate all required PKI material automatically.

Blank Virtual Machine Disks

A virtual machine disk can now be provisioned as an empty volume in a storage pool, rather than only
as a CD-ROM attached from a content library:

apiVersion: v1alpha1
kind: VirtualMachineConfig
name: vm1
disks:
  - name: data
    pool: pool1
    size: 100GiB
    format: qcow2
    provision:
      blank: {}

The pool must be declared by a StoragePoolConfig document in the same machine configuration; a disk
naming an undeclared pool is now a configuration error rather than a virtual machine that silently
never starts.

Four behaviours are worth knowing before you rely on this:

• Volumes are adopted by name and are never deleted. The volume is named after the virtual
  machine and the disk, so removing the disk from the configuration leaves the data in place, and
  re-declaring the same virtual machine and disk names in the same pool reattaches it. Reclaiming
  the space is a deliberate, out-of-band act. talosctl get storagepoolvolumestatuses lists
  managed volumes, not retained orphan files: their statuses disappear when their requests and
  consumers are gone. Inspect the pool's backing directory to discover retained files before
  reclaiming space; confirm a file is no longer in use before deleting it.
• Disks grow only. Raising size grows the volume the next time no virtual machine has it open,
  because growing one underneath a running guest corrupts qcow2 metadata and is invisible to the
  guest for raw. The pending growth is reported on the volume's status.
• A smaller size is reported and ignored. Shrinking would truncate a filesystem the guest laid
  out, so it is refused rather than applied; the disk stays attachable and the virtual machine keeps
  running.
• Remove all virtual machine references together with a StoragePoolConfig document. Removing a
  referenced pool alone is rejected by configuration validation. Remove or update every virtual
  machine referencing it in the same configuration change. During teardown, consumers release
  the pool before it is undefined and its backing directory can be unmounted. The volume files
  survive.

Provisioning a disk from a content library image is not implemented yet; provision.fromImage is
still only supported on a cdrom.

Ignore Ctrl-Alt-Delete

Setting ignoreCtrlAltDelete: true in the SecurityProfileConfig document makes Talos log and ignore Ctrl-Alt-Delete instead of rebooting the machine.
Ctrl-Alt-Delete still reboots the machine until a configuration with this option is applied.

Image Layers Synced to Disk

The CRI containerd now syncs each unpacked image layer to disk (syncfs) before committing the snapshot.
Previously, a power loss or a hard reset shortly after an image pull could leave a committed layer with zero-length files:
containers using the image failed with exec format error, and the broken snapshot was reused until the image was removed by hand.

This applies to all image layers unpacked by the CRI containerd: images pulled by the kubelet, the kubelet and etcd images pulled by Talos,
and images imported into the CRI containerd with talosctl image import.

Each synced layer flushes all dirty data of the EPHEMERAL filesystem, which can slow down image pulls and add I/O latency on write-heavy nodes.
If image pull performance matters more than crash consistency, the sync can be disabled with a machine configuration patch:

apiVersion: v1alpha1
kind: CRICustomizationConfig
name: disable-sync-fs
content: |
    [plugins."io.containerd.service.v1.diff-service"]
      sync_fs = false

Snapshots already broken by an earlier crash are not repaired: remove the affected image (e.g. talosctl image rm) so that it is pulled again.

IPVS Support

Following Kubernetes deprecation of IPVS support (kube-proxy), Talos Linux now ships IPVS as kernel modules which are not loaded by default.

If you require IPVS support, you can enable it by loading the following kernel modules:

• ip_vs (core)
• ip_vs_rr, ip_vs_wrr, ip_vs_lc, ip_vs_sh or ip_vs_mh (scheduling algorithms)
• xt_ipvs (nftables/iptables match)

On-demand Kernel Module Loading

The kernel can once again ask Talos to load a module on demand (request_module()), e.g. when a driver loads a helper module while probing a device,
or when DRBD loads its transport module.
Talos handles the kernel's modprobe usermode helper call and loads the module (shipped with Talos or a system extension) by the requested name,
applying the parameters from KernelModuleConfig if the module is listed in the machine config.
Such modules no longer need to be listed in the machine config, and the order of the listed modules is not important.

Requests via subsystem aliases (e.g. fs-*, net-pf-*, crypto-*), which userspace can trigger via mounts, sockets, etc., are refused,
so on-demand loading can't be used to load arbitrary modules from workloads.
The outcome of each request is logged to the kernel log (talosctl dmesg).

Kernel Log Extra Tags

The KmsgLogConfig document now supports an extraTags field which attaches additional key-value pairs
to every kernel log message sent to that destination:

apiVersion: v1alpha1
kind: KmsgLogConfig
name: apiSink
url: https://kmsglog.api/logs
extraTags:
  cluster: staging-west
  node: worker-1

Tags are scoped to the destination they are configured on, so different endpoints can receive different tags.
The keys facility, seq, clock, priority, msg, talos-time and talos-level are reserved and rejected,
as they are set by Talos itself.

kube-apiserver Webhook Kubeconfigs

Webhook authorization and webhook token authentication can now be configured with the Kubernetes configuration documents,
without the .cluster.apiServer.extraVolumes of the legacy v1alpha1 configuration.
Talos renders the webhook kubeconfig into the kube-apiserver static pod, and sets the kube-apiserver configuration to point to it.

KubeAuthorizerConfig has a new kubeconfig field for the Webhook authorizer type, and Talos sets the webhook.connectionInfo for it:

apiVersion: v1alpha1
kind: KubeAuthorizerConfig
name: my-authorizer
type: Webhook
webhook:
  timeout: 3s
  subjectAccessReviewVersion: v1
  matchConditionSubjectAccessReviewVersion: v1
  failurePolicy: Deny
kubeconfig: |
  apiVersion: v1
  kind: Config
  clusters:
    - name: my-authorizer
      cluster:
        server: http://127.0.0.1:9051/authorize
  contexts:
    - name: my-authorizer
      context:
        cluster: my-authorizer
  current-context: my-authorizer

The new KubeAuthenticationWebhookConfig document configures webhook token authentication (e.g. for aws-iam-authenticator),
and Talos sets the --authentication-token-webhook-* flags of kube-apiserver accordingly:

apiVersion: v1alpha1
kind: KubeAuthenticationWebhookConfig
version: v1beta1
cacheTTL: 5m
kubeconfig: |
  apiVersion: v1
  kind: Config
  clusters:
    - name: aws-iam-authenticator
      cluster:
        server: https://127.0.0.1:21362/authenticate
        certificate-authority-data: <base64 CA certificate>
  contexts:
    - name: webhook
      context:
        cluster: aws-iam-authenticator
  current-context: webhook

The kubeconfig should be self-contained, as kube-apiserver can't access files on the host: certificates and keys should be specified inline
(*-data fields), and tokenFile, exec and auth-provider are not supported.
If no certificate authority is specified, kube-apiserver trusts the root CAs of the machine (including TrustedRootsConfig).
Kubeconfigs are redacted from the machine configuration the same way as other secrets.

As kube-apiserver can't read files from the host, a KubeAuthorizerConfig with webhook.connectionInfo.type: KubeConfigFile is now rejected,
as well as authentication-token-webhook-* flags in KubeAPIServerConfig extraArgs.
The authorizer name should be a valid DNS-1123 subdomain, as required by kube-apiserver.

kube-network-policies Arguments

The KubeFlannelCNIConfig document has a new kubeNetworkPoliciesArgs field which replaces the default command-line arguments of kube-network-policies
(--hostname-override=$(MY_NODE_NAME) and --v=2), e.g. to change log verbosity or format.
kube-network-policies serves metrics on :9080 on all node addresses by default; use --metrics-bind-address=127.0.0.1:9080 to restrict it to the loopback interface.

Kubelet Image GC Thresholds

Talos now defaults kubelet imageGCHighThresholdPercent to 75 and imageGCLowThresholdPercent to 65 (upstream defaults are 85 and 80).

The upstream image GC high threshold matches the default imagefs.available<15% hard eviction threshold, so the node was put
into DiskPressure (and tainted for evictionPressureTransitionPeriod) before image GC had a chance to run.

The defaults are applied only if neither of the thresholds is set in machine.kubelet.extraConfig.
On upgrade, nodes with disk usage above 75% will garbage collect unused images.

Kubelet Resource Manager State

Talos now validates the kubelet CPU manager and memory manager state files (/var/lib/kubelet/cpu_manager_state, /var/lib/kubelet/memory_manager_state)
the same way kubelet does on startup, and removes a state file kubelet would refuse to load before starting kubelet.

Previously only a change of the manager policy was detected, so changing e.g. reservedSystemCPUs or reservedMemory, or
a change of the CPU/NUMA topology of the machine, left kubelet unable to start until the state file was removed manually.

Only the rendered KubeletConfiguration (machine.kubelet.extraConfig) is checked: the resource manager settings passed as kubelet
command line flags via machine.kubelet.extraArgs (e.g. --cpu-manager-policy, --reserved-cpus) are not taken into account.

KubePrism Readiness Check

KubePrism can now check the health of the Kubernetes API server upstreams via the readiness endpoint (/readyz), instead of a TCP connection attempt.
This allows KubePrism to stop routing new connections to an API server which accepts TCP connections, but is not ready to serve requests
(e.g. it lost connection to etcd, or it is shutting down).

The readiness check is enabled with the readinessCheck field of the KubePrismConfig document, and it is enabled by default for machine configuration generated for Talos 1.15+.
The readiness check requires unauthenticated access to the /readyz endpoint of the API server (the default since Talos 1.14, see KubeAuthenticationConfig).

KubeSpan Peer Endpoint Filters

KubeSpan now supports filtering the endpoints received from other peers via filters.peerEndpoints in the KubeSpanConfig document.

While filters.endpoints filters the addresses a node advertises to the whole cluster, filters.peerEndpoints filters the endpoints
received from other peers before the node connects to them, affecting only that node. This allows excluding peer-advertised endpoints
which are known to be unreachable from a node (e.g., addresses of a private network the node is not connected to), so that KubeSpan
endpoint rotation never attempts them.

Live Volume Growth

Talos now supports live growth of partition and disk volumes with xfs, ext4 and btrfs filesystems, without unmounting the volume or stopping workloads.
The partition should be the last one on the disk to be grown, and the filesystem should be grown after the partition is resized. Talos does not support shrinking volumes.

The UserVolumeConfig of type: disk now supports a grow field, which can be set to true to allow the volume to grow when the underlying disk is resized.

LLDP Neighbor Discovery

Talos now listens for LLDP on physical Ethernet interfaces and reports neighbors through the LLDPNeighborStatus resource.
Reported information includes chassis and port IDs, system and port descriptions, system names, management addresses, and VLANs.
The built-in listener does not transmit advertisements; use the lldpd system extension when advertising is required.

Secure Boot images no longer have lockdown=confidentiality enabled by default

Secure Boot images no longer have lockdown=confidentiality enabled by default.
This change was made to improve compatibility with eBPF tooling under default schematic.
This means that Secure Boot images will now have lockdown=integrity enabled by default (implicitly), which is the recommended setting for most users.
Users can override it by adding lockdown=confidentiality to the kernel command line through Image Factory if they require it.

MACVLAN Links

Talos Linux now supports creating MACVLAN links with a new MacVLANConfig document:

apiVersion: v1alpha1
kind: MacVLANConfig
name: eth0.macvlan
parent: eth0
mode: bridge # optional, defaults to `bridge`
addresses:
  - address: 192.168.1.100/24

The source mode is not supported yet, as it requires a list of allowed source MAC addresses.

Memory Protection on Small Machines

Talos protects the memory of its own processes (machined, system services, CRI, kubelet) from reclaim via cgroup memory.min and memory.low.
On machines with less than ~1.6 GiB of memory these protections are now scaled down proportionally, so that at most one third of the memory is hard-protected.
Previously, on 1 GiB machines more than half of the memory (including page cache) was protected, so workloads could be OOM-killed with plenty of page cache still in memory.

Multipath Configuration

The multipath-tools system extension now reads /etc/multipath.conf from the Talos host instead of using ExtensionServiceConfig.
The multipathd service waits for this file and bind-mounts it read-only into its service container.

Before updating the extension, apply a machine config patch that deletes the existing ExtensionServiceConfig document and adds an EtcFileConfig document:

apiVersion: v1alpha1
kind: ExtensionServiceConfig
name: multipathd
$patch: delete
---
apiVersion: v1alpha1
kind: EtcFileConfig
name: multipath.conf
mode: 0o644
contents: |
  defaults {
      user_friendly_names yes
      find_multipaths no
      path_selector "round-robin 0"
  }

The extension does not provide a default configuration, so multipathd remains waiting until /etc/multipath.conf is present.

NFS External Volumes

Talos now supports NFS as an ExternalVolumeConfig filesystem type alongside virtiofs, allowing nodes to mount network exports at /var/mnt/<name> through the existing block volume machinery.

apiVersion: v1alpha1
kind: ExternalVolumeConfig
name: shared
filesystemType: nfs
mount:
  nfs:
    server: 10.0.0.10
    path: /export
    version: "4.1"

Supported version values are 3, 4, 4.1, and 4.2.
The mount.nfs spec configures the kernel NFS client:

• Connectivity: server (hostname or IP; IPv6 is bracketed automatically) and absolute path are required; optional port, transport (tcp/udp), and NFSv3-only mountPort/mountTransport (otherwise rpcbind discovery is used).
• NFSv3 locking: locking (local default / remote) controls nolock/lock; Talos does not run rpc.statd, so local (nolock) is the safe default. You need rpc.statd extension for remote locking.
• Recovery: recovery (hard/soft/soft-error) maps to hard/soft/softerr.
• Tuning: timeout (timeo, deciseconds), retransmissions (retrans), readSize/writeSize (rsize/wsize, 1024–1048576 multiples of 1024), connections (nconnect, 1–16, TCP only), reservedPort (resvport/noresvport), and security (none/sys; Kerberos flavors are unsupported as Talos does not run rpc.gssd).
• NFSv4 enforces tcp transport.

Common mount flags (readOnly, disableAccessTime, secure) apply as with other volume types.
Validation rejects mountPort/mountTransport/locking outside NFSv3 and udp for NFSv4.

NUMA Topology and VM Placement Validation

Talos reports host NUMA nodes, CPU membership and total node memory through the NUMATopology resource.
Explicit VM CPU pins and memory-node selections are checked against the host before starting or replacing a guest.
Invalid placement leaves an existing guest running; CPUs and guest memory may intentionally use different nodes.
This validates placement, not available memory capacity or reservations. Host inventory is not exposed in container mode.

Redacted Resources

Resources which might carry secrets are marked sensitive, and reading them used to require the os:admin role.
Such a resource can now be read with the os:reader and os:operator roles as well, with the sensitive values
of the spec replaced by REDACTED; the resource carries the talos.dev/redacted annotation to say so.

talosctl get asks for this automatically, so with a reduced-role talosconfig it now prints resources
which previously came back as PermissionDenied:

$ talosctl -n 172.20.0.2 get linkspecs kubespan -o yaml
node: 172.20.0.2
metadata:
    namespace: network
    type: LinkSpecs.net.talos.dev
    id: kubespan
    annotations:
        talos.dev/redacted: "true"
spec:
    name: kubespan
    wireguard:
        privateKey: REDACTED

With the os:admin role nothing is redacted, and the talosctl get output is unchanged.

A resource which has nothing left to read once redacted - the Kubernetes secrets, for one - is not served in a
redacted form at all, and still requires the os:admin role.

More resource types are now marked sensitive, as they carry the extra arguments, the environment variables and
the manifests of the machine configuration verbatim: StaticPod, Manifest, ExtraManifestsConfig,
ControllerManagerConfig, SchedulerConfig, AdmissionControlConfig, ContainerSpec,
ContainerInstanceSpec, Environment, MetaKey, UniqueMachineToken and PlatformConfig. All of them
support redaction, so they stay readable with any role, but a client which doesn't ask for redaction
(including a talosctl older than this release) needs the os:admin role to read them.

Route Updates

RouteSpec resource IDs now match the key the Linux kernel uses for routes: routing table, address family, destination and priority (metric),
e.g. inet4/10.0.0.0/8/1024 instead of inet4/10.0.0.1/10.0.0.0/8/1024.
The gateway, the output link and the multipath next-hops are no longer part of the ID, so changing them updates the route in place
(RTM_NEWROUTE with NLM_F_REPLACE) without the route ever being missing, e.g. when a BGP route switches between a single next-hop and ECMP.

Routes which differ only in the next-hops (which can't be installed into the kernel at the same time) are now merged into a single route,
with the higher configuration layer taking precedence.
RouteStatus resource IDs are not changed.

SeccompProfileConfig

Seccomp profiles are now declared with the new SeccompProfileConfig document, one document per profile:

apiVersion: v1alpha1
kind: SeccompProfileConfig
name: audit.json
profile:
  defaultAction: SCMP_ACT_LOG

As before, every profile is written to /var/lib/kubelet/seccomp/profiles/<name>, so Kubernetes pods can use it with securityContext.seccompProfile.type: Localhost and localhostProfile: profiles/<name>.

The .machine.seccompProfiles field is deprecated in favor of SeccompProfileConfig documents. It keeps working, but a document may not reuse the name of a profile declared there.

Permissions of the Generated Files

talosctl now writes every file which might contain secrets with 0600 permissions (owner read/write only),
and it restricts the permissions of the files it overwrites as well.

This affects the machine configuration (talosctl gen config, talosctl machineconfig patch,
talosctl cluster create --skip-injecting-config), talosconfig and kubeconfig.

SELinux Workload Categories

A new selinuxCategories field of the SecurityProfileConfig document labels workloads with SELinux MCS categories,
so that workloads sharing an SELinux type still cannot access each other's processes and files. The categories are disabled
by default, and have to be enabled explicitly by setting selinuxCategories: true.

The categories are split three ways: the CRI labels pods with a random pair from c0-c767, containers declared via
ContainerConfig get a stable pair from c768-c1007 derived from their name, and c1008-c1023 are reserved for Talos
(the kube-apiserver static pod runs at s0:c1022,c1023, so that it keeps access to its audit log across reboots).

Pods run as pod_t, and privileged containers as pod_privileged_t, which reads the host files and /proc and ignores the
categories. spc_t is an alias of it, so charts written for Fedora and RHEL keep working. The kubelet gets
/sys/fs/selinux and the containers contexts file, so that it labels volumes and its plugin directories.

A pod writing files which outlive it, to a hostPath or a local volume, needs a fixed securityContext.seLinuxOptions.level,
else the pod of the next start cannot read them. The CRI skips the pairs of running containers when it draws one, so
the pair is exclusive only while the pod runs.

With the categories enabled, the CRI passes an SELinux label to every container runtime, so the runtimes which do not support
SELinux labels (e.g. gVisor, youki, Spin) fail to start pods.

Static Control Plane Endpoints

The new StaticEndpointsConfig document provides a static list of control plane node addresses and hostnames:

apiVersion: v1alpha1
kind: StaticEndpointsConfig
addresses:
  - 10.0.0.11
  - 10.0.0.12
  - 10.0.0.13

The list is merged with the control plane endpoints discovered via the discovery service, the Kubernetes API server endpoints, and the cluster control plane endpoint.
Worker nodes use these endpoints to reach trustd, and control plane nodes use them to join etcd.
Distributing the list to all machines in the cluster makes these operations independent of the discovery service and Kubernetes.

Every connection to the endpoints is authenticated with TLS, and unreachable endpoints are skipped, so a stale list doesn't break the cluster.

Talos Containers

Talos can now run OCI containers independently of Kubernetes. Containers are declared with ContainerConfig documents.
They are managed through the taloscontainers containerd namespace, and their state is reported in the corresponding ContainerStatus resources.
Also, talosctl dashboard ships a new Containers tab.

apiVersion: v1alpha1
kind: ContainerConfig
name: migrate
image: ghcr.io/example/migrate:v1.0.0
mounts:
  - volume:
      name: data
      destination: /data
lifecycle:
  restart:
    policy: on-failure
    maxRetries: 3
---
apiVersion: v1alpha1
kind: ContainerConfig
name: server
image: ghcr.io/example/server:v1.0.0
mounts:
  - volume:
      name: data
      destination: /data
resources:
  limits:
    memory: 512MiB
    swap: "0"
lifecycle:
  dependsOn:
    containers:
      - name: migrate
        condition: succeeded
  stopTimeout: 30s

talosctl containers, logs, stats and restart select these containers with --namespace taloscontainers.

Lifecycle

lifecycle.restart.policy sets when a container is run again after it exits: always (the default) after every exit, on-failure after a non-zero exit code or a failure to start, up to maxRetries times, and never not at all.
The restart waits delay (5s by default), which doubles with each restart of a container which ran for less than maxDelay, up to maxDelay.
A container which is not restarted reports completed or failed in ContainerStatus until its configuration changes or it is removed.
Changing the configuration of a container runs it again, and changing its policy starts the maxRetries count over.
Containers run again after a reboot or a restart of machined, so a container which runs once has to be safe to run again; talosctl restart only signals the container.

lifecycle.dependsOn.containers delays the start of a container until the containers it depends on are running and healthy,
or, with condition: succeeded, have exited with code 0 and are not restarted, e.g. to migrate a database schema or prepare a directory first.
A container depended on as succeeded must use the on-failure or never restart policy.
lifecycle.dependsOn also waits for the network to be ready and the time to be synchronized.

lifecycle.stopTimeout sets how long a container gets to exit after SIGTERM before it is killed (10s by default, at most 4m).
On shutdown, reboot and upgrade, containers are stopped in the reverse order of their dependencies.

Storage and Devices

mounts accept host paths, tmpfs, and with volume a UserVolumeConfig, ExistingVolumeConfig or ExternalVolumeConfig by name.
devices.rawVolume hands a RawVolumeConfig to a single container as a block device, without the privileged profile.

Security and Resources

When SELinux is enabled, Talos Containers use a dedicated SELinux domain; the privileged profile gets a writable /sys and is excluded from the per-container MCS categories.
security.seccompProfile.type selects the default seccomp profile, unconfined, or a localhost profile declared by a SeccompProfileConfig document.
runAs sets the user and group, and an image declaring a non-numeric USER is rejected unless runAs overrides it.
resources.limits caps the CPU, memory and swap of a container; see "Workload Memory Limits" for the aggregate limit of all containers and "SELinux Workload Categories" for their isolation.

Changes from 1.14

Talos 1.14 shipped an early version of ContainerConfig. Configurations written for it keep working, with these changes:

• dependsOn moved to lifecycle.dependsOn; the top-level key is deprecated, and setting both is rejected.
• dependsOn.networks is renamed to dependsOn.network, and mounts.userVolume to mounts.volume; the old keys are deprecated and ignored when the new ones are set.
• dependsOn.containers is now enforced.
• An image declaring a non-numeric USER is rejected instead of running as root.
• The mounts of the ContainerSpec resource no longer carry volumeID; the resolved volume ID is reported on ContainerMountStatus.
• The image entrypoint and arguments are now merged correctly when a config patch is applied, and containers running as a non-root user get their added capabilities.

talosctl Legacy Image APIs

talosctl image list, talosctl image pull and talosctl debug no longer fall back to the legacy MachineService.ImageList and MachineService.ImagePull APIs.
They now require the ImageService API, which is available in Talos 1.13 and later.

Talosctl upgrade improvements

For nodes running Talos 1.14 and newer the upgrade image is now automatically detected for each node.
Each node keeps its own Image Factory host, schematic, platform and SecureBoot setting, so nodes with different images can be upgraded with a single command.
Any of these, except the platform, can be changed with the CLI flags.

Upgrade to a new Talos version, keeping everything else as it is:

talosctl upgrade -n <NODES> --talos-version 1.15.0

Upgrade to a different schematic, e.g. to add a system extension:

talosctl upgrade -n <NODES> --schematic-id <SCHEMATIC_ID> --talos-version 1.15.0

--talos-version defaults to the version of talosctl, so set it explicitly to stay on the Talos version the nodes are running.

Upgrade to an exact installer image (it can't be combined with the flags above):

talosctl upgrade -n <NODES> --image factory.talos.dev/metal-installer/<SCHEMATIC_ID>:v1.15.0

The --image flag is now mandatory when upgrading nodes running Talos versions before 1.14.

Time Check API

The TimeService/TimeCheck API (talosctl time --check) is no longer available to the os:reader role, as it allows querying
arbitrary time servers from the node. The TimeService/Time API (querying the configured time server) is still available to os:reader.

PTP device paths are now strictly validated both in the machine configuration and in the API: the path should be directly under /dev,
the name should start with ptp (e.g. /dev/ptp0, /dev/ptp_kvm), and the device should be a PTP character device.

Filesystem Trim Chunking

The FilesystemTrimConfig document (and the per-volume trim settings) now support chunkSize, chunkDelay and minLength options.

By default, the whole filesystem is trimmed at once (same as the fstrim command), which issues discards for all free space back-to-back
and might cause latency spikes for other workloads on the same disk (e.g. etcd).
Setting chunkSize splits the trim into multiple operations with chunkDelay in between, while minLength skips free ranges smaller than the specified size.

trustd Server Certificate Verification

trustd server certificates are now issued with a trustd-specific extended key usage.

The new .machine.features.trustdCheckExtKeyUsage setting makes worker nodes accept only trustd server certificates with this extended key usage.
The setting is enabled by default for worker machine configuration generated for Talos 1.15+.

For existing clusters, enable the setting on worker nodes once all control plane nodes run Talos 1.15+:
worker nodes with the setting enabled fail to refresh the Talos API certificate if trustd runs an older version of Talos.

Component Updates

Linux: 7.3.1
Kubernetes: 1.38.0-beta.0
containerd: 2.3.7
runc: 1.5.2
CoreDNS: 1.14.7
systemd-udevd: 262
etcd: 3.7.3
Flannel CNI: 0.28.10

Talos is built with Go 1.27.3.

Virtual Machine Power Control

New talosctl hypervisor start|stop|reboot <vm-name> commands control the power state of Talos-managed virtual machines.

start and stop override the virtual machine's power state until the node reboots, without changing the machine configuration.
After a reboot, the virtual machine follows the powerState of its VirtualMachineConfig again.
reboot restarts a running guest and leaves the power state unchanged.

stop and reboot ask the guest to shut down or restart by default. Pass --graceful=false to destroy the domain instead.
The commands require the os:admin or os:operator role.

Virtual Machine Hardware Profiles

VirtualMachineConfig now accepts a profile field selecting the guest-visible CPU and machine type.
Talos ships three builtin profiles on amd64:

• host (default when profile is omitted): q35 machine, host-model CPU.
• passthrough: q35 machine, host-passthrough CPU.
• legacy: pc-i440fx-9.2 machine, kvm64 CPU, for guests that need a traditional PC chipset.

Custom profiles are defined with the new VirtualMachineProfileConfig document:

apiVersion: v1alpha1
kind: VirtualMachineProfileConfig
name: rack-a-compat
machine: pc-q35-9.2
cpu:
  mode: custom
  model: Haswell-noTSX-IBRS
  features:
    - name: pku
      policy: disable

machine accepts q35, pc, pc-q35-* or pc-i440fx-*. cpu.mode is host-model, host-passthrough or custom;
model, fallback (forbid by default, or allow) and features (policies require, disable, optional, force, forbid)
are only allowed with custom. The names host, legacy, passthrough and the compat- prefix are reserved.
Profiles are validated structurally only: Talos does not check that the host CPU supports the model, nor guarantee migration compatibility.

Profile changes, including switching a VM to a different profile, are not applied to running guests;
they take effect on the next deliberate stop and start of the virtual machine.
Hardware profiles are currently available only on amd64.

Virtual Machine Serial Console

Talos-managed virtual machines now expose their serial console over the Talos API, with no host shell access required.

talosctl hypervisor console <vm-name> attaches to the live serial console of a running VM.
Press Ctrl-] to detach without stopping the VM; Ctrl-C is forwarded to the guest.
Only one session can be attached to a VM at a time, and previous output is not replayed.
The command is supported on Unix clients only.

Serial output is also persisted on the host (with bounded retention), and can be read with talosctl logs --kind=vm <vm-name>,
including --tail and --follow. The new --kind flag (container, vm or service) selects the log source explicitly;
omitting it keeps the previous service/container routing.

Both the console and the VM logs require the os:admin role and a single target node.

Virtual Machine VNC Console

The new talosctl hypervisor vnc <vm-name> command forwards a virtual machine's graphical console to a local loopback TCP port.
Enable console.vnc.enabled in its VirtualMachineConfig; access requires the os:admin role and exactly one target node.

The listener accepts one viewer at a time and supports reconnecting without restarting the command.
Use a viewer that supports unauthenticated RFB.
Talos authenticates the tunnel, and no VNC TCP port is opened on the node.

VXLAN Links

Talos Linux now supports creating VXLAN links with a new VXLANConfig document:

apiVersion: v1alpha1
kind: VXLANConfig
name: vxlan100
id: 100 # VXLAN network identifier (VNI)
parent: eth0
local: 10.255.0.1 # or `group:` for a multicast group, but not both
port: 4789 # optional, defaults to 4789
learning: false # optional, defaults to true
addresses:
  - address: 192.168.1.100/24

Workload Memory Limits

The new WorkloadResourceConfig document sets independent aggregate memory limits for Kubernetes pods, Talos containers and virtual machines:

apiVersion: v1alpha1
kind: WorkloadResourceConfig
kubepods:
  memory:
    limit: 16GiB
taloscontainers:
  memory:
    limit: 4GiB
virtualMachines:
  memory:
    limit: 32GiB

Each root is optional. Limits are ceilings, not reservations, and do not cover swap or HugeTLB memory.
For kubepods, Talos derives systemReserved.memory so kubelet enforces the cap and adjusts Node Allocatable;
an explicit systemReserved.memory, conflicting kubelet flags or the Static memory manager cannot be combined with this limit.
Changing the Kubernetes cap restarts kubelet. Without Kubernetes, only the container and virtual machine limits apply.

Lowering a limit can OOM-kill workloads in that group, including QEMU guests or Kubernetes control-plane pods.
Talos exclusively owns memory.max on /taloscontainers and /virtualmachines.partition, even without this document.
Omitting their limits means unlimited aggregate memory; individual child limits still apply.
Kubelet system-reserved or kube-reserved memory enforcement on these roots is rejected regardless of this document;
CPU-only or compressible enforcement and reservations on unrelated roots remain supported.
Kubelet drop-in directories are rejected while any cap is active; without caps, their contents remain the operator's responsibility.
Removing the Kubernetes cap restores the original kubelet configuration. The document has no effect in container mode.

Contributors

• Andrey Smirnov
• Maja Bojarska
• Noel Georgi
• Mateusz Urbanek
• Utku Ozdemir
• Orzelius
• Mateusz Urbanek
• Dmitrii Sharshakov
• immanuwell
• Justin Garrison
• Noel
• Max Makarov
• Raphaël DUCOM
• Loki San
• Nico Berlee
• Oguz Kilcan
• Oscar Wieman
• Fábio Matavelli
• Jarrad S
• Sacha Weatherstone
• Tom Plant
• Aleksei Sviridkin
• Alexander Soelberg Heidarsson
• Angelos Petheriotis
• Bart van der Schans
• Brian Cappello
• Brian Topping
• Christoph Engelbert (noctarius)
• Daniel Chaplin
• David Haines
• Dennis Docter
• Dima Aratin
• Erwan Leboucher
• Evan Champion
• GeertJohan
• Hugo Meyronneinc
• Ian Atha
• Ivan Demchuk
• Jake Watson
• Jiri Tyr
• Joakim Nohlgård
• Kamil Szczygieł
• Karthik Chowdary
• Kuzia
• Kyle Tse
• Licia Seiker
• Louis Deconinck
• Matt Layher
• Matthew Kelch
• Michał Małyska
• MsfPablo
• Nicolas Brainez
• Ryuki Maruyama
• Scott Vandiver
• Spencer Smith
• Steffen Windoffer
• Steve Francis
• Steve Wills
• Winter
• dadbravo
• frauniki
• leppeK
• neiltalap
• saguila
• sasha-sup
• usman.malik_ext
• zavermax

Changes

478 commits

• @​3e36bec release(v1.15.0-beta.0): prepare release
• @​8d97c04 test: wait for container volumes to be unmounted on cleanup
• @​7fcafd4 fix: keep container-held volume mounts secure
• @​94a8028 fix: add new edge type to the controller dependencies API
• @​a989a97 fix: allow CPU-only kube-reserved enforcement with a kubepods limit
• @​171a6be fix: warn when the kubepods memory limit exceeds host memory
• @​cd490a2 fix: parse VM host ID lists the way libvirt does
• [@​beae0dd](https://redirect.github.c

[!IMPORTANT]
✂ PR body was truncated to here.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[claude]

Claude finished @doa-renovate[bot]'s task in 30s —— View job

---

レビュー結果

変更: deploy/backup/etcd-snapshot.yaml の talosctl イメージを v1.15.0-alpha.2 → v1.15.0-beta.0 に上げるだけ(1 行)。

指摘

1. 要確認: ノードの版が alpha.2 のまま(版の食い違い)

• 同ファイル 47 行目のコメントは「版は bootstrap/talos.sops.yaml の先頭の Talos の版と揃える」としています。
• 今のノードの版は bootstrap/talos.sops.yaml:18 の v1.15.0-alpha.2 です。tools/Dockerfile:15 の TALOSCTL_VERSION も alpha.2 のままです。
• この PR では Docker タグだけが先に beta.0 になり、siderolabs/talos の github-releases 側はまだ上がっていないようです。groupName: talos のグループ PR が部分的です。
• 影響: etcd snapshot の API はクライアントとノードが 1 つの prerelease ずれていても問題になる可能性は低いです。ただし「離れすぎないこと」の規約からは、ノードを beta.0 に上げる前にこの PR だけ先にマージしない方がよいです。ノードの更新と一緒に適用してください。

2. リリースノート確認(1.15.0-beta.0)

このリポジトリで影響しうる項目だけを挙げます。

• etcd スナップショット(talosctl etcd snapshot): 破壊的変更の記載は見当たりません。os:etcd:backup ロールの変更もありません。CronJob の引数 -e/-n ... etcd snapshot はそのまま使えます。
• Redacted Resources / Time Check API: ロールの扱いが変わった項目です。os:etcd:backup 専用の ServiceAccount には影響しません。
• talosctl の権限(0600): ファイルの書き出し権限が厳しくなりました。このジョブはもともと 0600 で書いています。runAsUser: 65532 で同じユーザーが読むので問題ありません。
• containerd 設定の version 4: CRICustomizationConfig や拡張が独自の CRI 設定を持つ場合は書き直しが必要です。bootstrap/talos.sops.yaml に該当の記述は見当たりませんでした。ノードを上げるとき [metrics] などを使っていないか確認してください。
• Secure Boot の lockdown 既定の変更 / kubelet の image GC 既定値(75/65) / kube-apiserver webhook: ノード更新時の話で、この PR(クライアントのイメージ)には直接関係しません。
• DiskSMARTConfig: talosctl gen config が既定で出力します。bootstrap/render.sh の生成物に差分が出るので、ノードを上げるときに確認してください。
• PT3 のカーネルモジュール: 「On-demand Kernel Module Loading」は alpha.2 から入っています。今回の追加の変更はありません。

3. セキュリティ / テスト

• シークレットの混入はありません。イメージのタグ指定のみです(digest ピンはこのリポジトリの他のイメージも使っていないので指摘しません)。
• 専用のテストはありません。マージ後の最初の CronJob 実行(13:00 UTC)で etcd.snapshot が作られ、notify.yaml が成功を検知するか確認してください。

結論

コードの不具合はありません。ただしノード側が alpha.2 のままなので、ノードや tools/Dockerfile の版を beta.0 に上げる作業と一緒に適用することを推奨します(要確認)。

[claude]

Claude finished @doa-renovate[bot]'s task in 25s —— View job

---

レビュー結果

変更は deploy/backup/etcd-snapshot.yaml の talosctl イメージを v1.15.0-alpha.2 から v1.15.0-beta.0 に上げる 1 行だけです。構文上の問題は見つかりませんでした。ただし、マージ前に確認が要る点が 1 つあります。

要確認: ノードの Talos の版とずれる

• etcd-snapshot.yaml のコメントは、版を bootstrap/talos.sops.yaml 先頭の Talos の版と揃えるよう求めています。
• この PR は talos.sops.yaml の # version: v1.15.0-alpha.2(18 行目)と tools/Dockerfile の TALOSCTL_VERSION を更新していません。マージすると、クライアントは beta.0、ノードは alpha.2 になります。
• renovate.json では groupName: talos を使っていますが、この PR には talosctl のイメージしか入っていません。siderolabs/talos の github-releases 側は別 PR になる可能性があります。
• 次のどちらかが必要です。
  • ノードを beta.0 に上げる PR(render.sh → apply-config → upgrade)と同時にマージする。
  • 先にマージするなら、beta.0 の talosctl で alpha.2 のノードに対して etcd snapshot が通ることを確認する。
• CronJob は 13:00 UTC に走り、失敗すると notify が鳴ります。マージのタイミングを合わせるのがよいです。

リリースノートとの突き合わせ(1.15.0-beta.0)

このリポジトリに影響しそうな項目を grep で確認しました。

• etcd snapshot / ServiceAccount の os:etcd:backup: ノートに破壊的変更の記載はありません。
• ロール変更: os:reader の TimeCheck 削除と、sensitive リソースの redaction 追加がありました。os:etcd:backup には関係しません。
• CRICustomizationConfig(containerd v4): 設定がリポジトリ内に無く、影響なしです。
• ExtensionServiceConfig: multipath の変更に関係する設定は無く、影響なしです。
• seccomp、SysfsConfig、kubelet の imageGC など: 該当設定はリポジトリ内に見つからず、影響なしです。
• KubePrism の readiness check: 1.15 以降で生成した設定の既定値です。cilium-values.yaml は localhost:7445 を使うだけなので影響なしです。
• オンデマンドのカーネルモジュール読み込み: talos.sops.yaml 55 行目のコメント(dvb-pt3 の復調・チューナー)に関わります。ノートによると、列挙しなくても読まれるようになります。ノードを上げる際に念のため確認してください。
• Secure Boot の lockdown: 既定が integrity になります。影響するのは Secure Boot を使う場合だけです。
• IPVS: カーネルモジュールになり、既定では読み込まれません。このリポジトリは Cilium を使っていて IPVS の記述も無いので、影響なしです。

その他

• セキュリティ上の問題(シークレットの混入など)は見つかりませんでした。
• テストはありません。マニフェストの版更新なので妥当です。
• beta.0 はプレリリースです。alpha からの追従は意図どおり(talos.sops.yaml のコメント参照)です。

結論: 内容に問題はありません。ノード側の版更新と合わせてマージしてください。

[claude]

Claude finished @doa-renovate[bot]'s task in 28s —— View job

---

レビュー結果

変更: Talos の版を v1.15.0-alpha.2 → v1.15.0-beta.0 に上げる 3 か所(1 行ずつ)です。

• bootstrap/talos.sops.yaml:18(# version:。render.sh が depName=siderolabs/talos で読む正本)
• deploy/backup/etcd-snapshot.yaml:49(talosctl イメージ)
• tools/Dockerfile:15(TALOSCTL_VERSION)

不具合・設計

問題ありません。以前のレビューで指摘された「ノードの版とクライアントの版のずれ」は、今回の同期で 3 か所が揃ったため解消しています。etcd-snapshot.yaml のコメントが求める「talos.sops.yaml と版を揃える」も満たしています。

要確認(マージ後の作業)

• talos.sops.yaml の版は render.sh が読む値で、ノードへの適用は手作業です(talos.md「当て方」)。マージしただけではノードは alpha.2 のままです。そのため、適用までは CronJob の beta.0 の talosctl が alpha.2 のノードに対して etcd snapshot を打つ状態になります。プレリリース 1 つ分のずれで、etcd snapshot の API に変更はないので問題になる可能性は低いです。13:00 UTC の最初の実行で etcd.snapshot ができ、notify.yaml が成功を検知することを確認してください。
• schematic 8e14763…(dvb-pt3、i915、intel-ucode、mei)が beta.0 向けにも Image Factory でビルドされるかは、リリースノートからは分かりません。ノードを上げる前に factory.talos.dev で beta.0 のインストーラーイメージが引けることを確認してください。

リリースノート(v1.15.0-beta.0)と、このリポジトリの設定の突き合わせ

• etcd snapshot と os:etcd:backup: 変更の記載はありません。CronJob の引数はそのまま使えます。
• Redacted Resources / Time Check API: os:reader に関する変更です。バックアップ用 ServiceAccount には影響しません。
• ファイル権限 0600: 影響しません。ジョブは /work に書き、同じユーザー(65532)で読みます。
• containerd 設定 version 4: リポジトリ内に CRICustomizationConfig はなく、影響しません。
• Secure Boot の既定の lockdown が integrity に変更: 影響するのは Secure Boot を使っている場合だけです。eBPF の互換性は上がる方向です。
• kubelet の imageGC 既定値(75/65): ノード更新後、ディスク使用率が 75% を超えていると未使用イメージが GC されます。変更後の挙動として認識しておけば十分です。
• IPVS がモジュール化: Cilium を使っていて IPVS の記述もないため、影響しません。
• オンデマンドのカーネルモジュール読み込み: dvb-pt3 の復調・チューナーのモジュールが列挙なしで読まれるようになります。現在の列挙は残しても問題ありません。
• DiskSMARTConfig の既定出力: talosctl gen config が新たに出力します。render.sh の生成物に差分が出るので、適用時に確認してください。SMART 収集が有効になります(既存の config では無効のままです)。
• KubePrism の readiness check: 1.15 以降で生成した config の既定値で、/readyz への無認証アクセスが前提です(1.14 以降の既定)。Cilium は localhost:7445 を使うだけなので影響しません。
• trustd の trustdCheckExtKeyUsage: worker 向けの既定値です。ノードは 1 台の control plane なので影響しません。

セキュリティ・テスト

• シークレットの混入はありません。talos.sops.yaml で変わったのは平文のコメント行だけで、SOPS の暗号文には触れていません。
• 専用のテストはありません。版の更新なので妥当です。

結論

コードの問題はありません。マージして問題ありません。ただしノードへの適用前に、beta.0 の Factory イメージが取れることを確認してください(要確認)。

[claude]

Claude finished @doa-renovate[bot]'s task in 24s —— View job

---

レビュー結果

変更: Talos の版を v1.15.0-alpha.2 → v1.15.0-beta.0 に上げる 3 か所(1 行ずつ)です。

• bootstrap/talos.sops.yaml:18(render.sh が読む正本のコメント行)
• deploy/backup/etcd-snapshot.yaml:49(talosctl イメージ)
• tools/Dockerfile:15(TALOSCTL_VERSION)

3 か所は揃っており、etcd-snapshot.yaml のコメントが求める「talos.sops.yaml と版を揃える」も満たしています。不具合は見当たりません。

要確認(マージ後・適用前)

• ノードは alpha.2 のまま: マージしてもノードへの適用は手作業です。適用までは beta.0 の talosctl が alpha.2 のノードに etcd snapshot を打ちます。リリースノートに etcd snapshot の変更はなく、prerelease 1 つ分のずれなので問題になる可能性は低いです。最初の CronJob(13:00 UTC)で etcd.snapshot ができ、notify.yaml が成功を検知することを確認してください。
• Image Factory: schematic 8e14763…(dvb-pt3、i915、intel-ucode、mei)の beta.0 向けインストーラーが factory.talos.dev で引けるかは、リリースノートからは分かりません。ノードを上げる前に確認してください。
• ドキュメント内の古い版の参照(任意): recovery/README.md:79 の Factory ISO の URL は v1.15.0-alpha.2 のままです。復旧手順の ISO はノードの版と合わせた方が安全なので、ノードを beta.0 に上げるときに更新してください。この PR で触れる必要はありません。

リリースノート(v1.15.0-beta.0)とこのリポジトリの突き合わせ

• etcd snapshot / os:etcd:backup: 変更の記載なし。CronJob の引数はそのまま使えます。
• Redacted Resources / Time Check API: os:reader に関する変更で、バックアップ用 ServiceAccount には影響しません。
• ファイル権限 0600: ジョブは /work に書き、同じユーザー(65532)で読むため影響なし。
• containerd 設定 version 4: リポジトリ内に CRICustomizationConfig はなく影響なし。
• オンデマンドのカーネルモジュール読み込み: alpha.2 から入っており、今回の追加変更はありません(talos.sops.yaml:55、talos.md:56 の記述は引き続き正しい)。
• IPVS のモジュール化: Cilium を使っていて IPVS の記述もないため影響なし。
• kubelet の imageGC 既定値(75/65): ノード更新後、ディスク使用率が 75% を超えていると未使用イメージが GC されます。認識しておけば十分です。
• Secure Boot の lockdown 既定が integrity に: Secure Boot を使っている場合のみ関係します。
• DiskSMARTConfig の既定出力: talosctl gen config が新たに出力するため、render.sh の生成物に差分が出ます。適用時に確認してください(既存 config では SMART 収集は無効のままです)。
• KubePrism の readiness check / trustdCheckExtKeyUsage: 1.15 以降で生成した config の既定値です。Cilium は localhost:7445 を使うだけで、control plane は 1 台のため影響なし。

セキュリティ・テスト

• シークレットの混入なし。talos.sops.yaml で変わったのは平文のコメント行だけで、SOPS の暗号文には触れていません。
• 版の更新のため専用のテストはなく、妥当です。

結論

コードの問題はありません。マージして問題ありません。ノードへの適用前に、beta.0 の Factory イメージが取れることを確認してください(要確認)。

[claude]

Claude finished @5ym's task in 16s —— View job

---

レビュー結果

変更: Talos の版を v1.15.0-alpha.2 → v1.15.0-beta.0 に上げる 3 か所(1 行ずつ)です。

• bootstrap/talos.sops.yaml:18(render.sh が読む正本のコメント行)
• deploy/backup/etcd-snapshot.yaml:49(talosctl イメージ)
• tools/Dockerfile:15(TALOSCTL_VERSION)

3 か所は揃っており、etcd-snapshot.yaml のコメントが求める「talos.sops.yaml と版を揃える」も満たしています。不具合は見当たりません。前回までのレビューから差分の内容は変わっていません。

要確認(マージ後・適用前)

• ノードは alpha.2 のまま: ノードへの適用は手作業なので、適用までは beta.0 の talosctl が alpha.2 のノードに etcd snapshot を打ちます。リリースノートに etcd snapshot の変更はなく、prerelease 1 つ分のずれなので問題になる可能性は低いです。最初の CronJob(13:00 UTC)で etcd.snapshot ができ、notify.yaml が成功を検知することを確認してください。
• Image Factory: schematic 8e14763…(dvb-pt3、i915、intel-ucode、mei)の beta.0 向けインストーラーが factory.talos.dev で引けるかは、リリースノートからは分かりません。ノードを上げる前に確認してください。
• 古い版の参照(任意・この PR では不要): recovery/README.md:79 の Factory ISO の URL は v1.15.0-alpha.2 のままです。ノードを beta.0 に上げるときに合わせてください。render.sh:236 のコメントには beta.0 の挙動(エスケープの違い)がすでに書かれています。

リリースノート(v1.15.0-beta.0)とこのリポジトリの突き合わせ

• etcd snapshot / os:etcd:backup: 変更の記載なし。CronJob の引数はそのまま使えます。
• Redacted Resources / Time Check API: os:reader に関する変更で、バックアップ用 ServiceAccount には影響しません。
• ファイル権限 0600: ジョブは /work に書き、同じユーザーで読むため影響なし。
• containerd 設定 version 4: リポジトリ内に CRICustomizationConfig はなく影響なし。
• オンデマンドのカーネルモジュール読み込み: alpha.2 から入っており、talos.sops.yaml:55 と talos.md:56 の記述は引き続き正しい。
• IPVS のモジュール化: Cilium を使い、IPVS の記述もないため影響なし。
• kubelet の imageGC 既定値(75/65): ノード更新後、ディスク使用率が 75% を超えていると未使用イメージが GC されます。認識しておけば十分です。
• Secure Boot の lockdown 既定が integrity に: Secure Boot を使っている場合のみ関係します。
• DiskSMARTConfig の既定出力: talosctl gen config が新たに出力するため、render.sh の生成物に差分が出ます。適用時に確認してください。
• KubePrism の readiness check / trustdCheckExtKeyUsage: 1.15 以降で生成した config の既定値です。Cilium は localhost:7445 を使うだけで、control plane は 1 台のため影響なし。

セキュリティ・テスト

• シークレットの混入なし。talos.sops.yaml で変わったのは平文のコメント行だけで、SOPS の暗号文には触れていません。
• 版の更新のため専用のテストはなく、妥当です。

結論

コードの問題はありません。マージして問題ありません。ノードへの適用前に、beta.0 の Factory イメージが取れることを確認してください(要確認)。