Security and Hardening

The appliance includes security controls for its software and services. Operators must also protect administrative access, virtual machines and recovery files.

Management, appliance nodes and ERS applications have separate administrative interfaces. A person with Management administrator access, cluster credentials or hypervisor control has extensive authority over the deployment. Restrict access to these administrative systems.

Built-in Protections

Protection	What the appliance provides	Limits
Minimal node operating system	Talos nodes have no SSH server, interactive host shell or package manager. Normal administration uses the Talos API and declared machine configuration.	This applies to appliance nodes. The Fedora CoreOS Management host has a separate root SSH interface. See Talos OS hardening.
Authenticated Management operations	Management uses Gitea-backed sign-in and requires administrator status for operational APIs and administrative tools. Browser access uses HTTPS, with supplied-certificate and ACME options.	Administrator access is broad. The initial self-signed certificate needs an explicit trust decision or replacement; HTTPS alone does not establish the server’s identity.
Temporary cluster access in Management	Management holds the appliance artifact bundle in memory for a six-hour access lease. Expiry, eviction and normal shutdown retire it and attempt to close external Kubernetes and registry access.	Remote closure is best effort after host loss or node unreachability. The lease does not create a source-IP allowlist or revoke credentials in downloaded artifacts. Talos remains the authenticated control path between leases.
Encrypted configuration secrets	Managed secret files use SOPS, a tool that encrypts configuration values with age keys. Flux decrypts the protected configuration when applying it.	Authorized administrators and running workloads can access required plaintext. Repository encryption does not encrypt every disk, database, log or clipboard.
Protected backup content	Backup producers encrypt captured members with the installation’s age recipient before storing them. The recovery private key stays in the installation artifact bundle. Backup producers do not receive it.	The outer bundle inventory is not secret. Protect the artifacts as well as backups; possessing both can permit recovery of sensitive data.
Cluster networking controls	Cilium supplies workload networking with WireGuard encryption enabled. Targeted policies restrict access to monitoring services and optional export components.	These controls do not cover every network path or give every workload a default-deny policy. Management host traffic and external interfaces need their own protections.
Workload restrictions	Components such as MariaDB and the customer metrics adapter run without root privileges, disable privilege escalation and drop Linux capabilities. Selected components also use read-only filesystems and restricted network access.	Some infrastructure needs broader privileges. Management’s nested Kubernetes runtime uses a privileged outer container and must run on a trusted Management host, whether an ISO VM, workstation or operator-created VM.
Controlled configuration publication	Management records supported configuration changes in Git and publishes selected artifacts for Flux to apply. Ordinary permanent changes follow that configuration path.	Repository history and artifact digests do not replace access control, review or an independent audit archive.

Protection

What the appliance provides

Limits

Minimal node operating system

Talos nodes have no SSH server, interactive host shell or package manager. Normal administration uses the Talos API and declared machine configuration.

This applies to appliance nodes. The Fedora CoreOS Management host has a separate root SSH interface. See Talos OS hardening.

Authenticated Management operations

Management uses Gitea-backed sign-in and requires administrator status for operational APIs and administrative tools. Browser access uses HTTPS, with supplied-certificate and ACME options.

Administrator access is broad. The initial self-signed certificate needs an explicit trust decision or replacement; HTTPS alone does not establish the server’s identity.

Temporary cluster access in Management

Management holds the appliance artifact bundle in memory for a six-hour access lease. Expiry, eviction and normal shutdown retire it and attempt to close external Kubernetes and registry access.

Remote closure is best effort after host loss or node unreachability. The lease does not create a source-IP allowlist or revoke credentials in downloaded artifacts. Talos remains the authenticated control path between leases.

Encrypted configuration secrets

Managed secret files use SOPS, a tool that encrypts configuration values with age keys. Flux decrypts the protected configuration when applying it.

Authorized administrators and running workloads can access required plaintext. Repository encryption does not encrypt every disk, database, log or clipboard.

Protected backup content

Backup producers encrypt captured members with the installation’s age recipient before storing them. The recovery private key stays in the installation artifact bundle. Backup producers do not receive it.

The outer bundle inventory is not secret. Protect the artifacts as well as backups; possessing both can permit recovery of sensitive data.

Cluster networking controls

Cilium supplies workload networking with WireGuard encryption enabled. Targeted policies restrict access to monitoring services and optional export components.

These controls do not cover every network path or give every workload a default-deny policy. Management host traffic and external interfaces need their own protections.

Workload restrictions

Components such as MariaDB and the customer metrics adapter run without root privileges, disable privilege escalation and drop Linux capabilities. Selected components also use read-only filesystems and restricted network access.

Some infrastructure needs broader privileges. Management’s nested Kubernetes runtime uses a privileged outer container and must run on a trusted Management host, whether an ISO VM, workstation or operator-created VM.

Controlled configuration publication

Management records supported configuration changes in Git and publishes selected artifacts for Flux to apply. Ordinary permanent changes follow that configuration path.

Repository history and artifact digests do not replace access control, review or an independent audit archive.

Recommended separation of management and application-client networks, with restricted administrative APIs and protection of the hypervisor and storage.

Figure 1. Recommended access boundaries; this is not a complete firewall or encryption map.

Isolate administrative Access

Place Management on a dedicated management network. Permit its HTTPS interface only from approved administrator workstations or an organization’s controlled remote-access service.
Restrict Management host SSH to approved maintenance sources. Keep it blocked from application-client networks and the Internet, including during initial boot.
Allow Talos and Kubernetes administrative APIs only along the required management paths. Expose ERS application interfaces to their intended clients without exposing internal database, registry or monitoring services with them.
Allow external DNS, time, HSM, backup, registry and monitoring connections according to the deployment plan. Test both allowed access and rejected access from an unauthorized network.

Use Ports and network flows as a starting point. It is not a complete internal firewall matrix. Agree additional filtering between nodes with MTG, then verify installation, normal operations and recovery; indiscriminate blocking can break cluster communication.

Protect a Docker or Podman host

For container deployments, protect access to the host and container engine as administrator access to Management. Keep the host and runtime patched, restrict published ports, and protect the /var volume, TLS directory and Compose settings. Container privilege does not isolate Management secrets from host administrators. Configure storage encryption through the host or storage platform if your policy requires it.

The ISO’s console, factory SSH credential and live-host configuration rules below apply only to ISO hosts. They do not configure or harden an operator-created host.

Protect the ISO host’s SSH Access

The current Management ISO profile enables root password login with the factory credential root / root. The Management browser administrator password is a different credential. Network restriction of host SSH is required from first boot.

The host can retain authorized keys and a limited set of SSH policy settings. Ordinary browser and console setup do not provide a general host password-rotation workflow. If your policy requires key-only SSH, arrange the supported persistent host configuration with MTG before production use. Do not assume that adding a key disables password login.

The live host reconstructs its identity and SSH settings from persistent state at boot. A passwd command or an edit under /etc/ssh alone will not reliably persist after reboot. Verify the effective access policy after a reboot and retain a controlled hypervisor-console recovery path.

Keep network restrictions in place while a cluster access lease is active. The appliance opens authenticated Kubernetes and registry access to routable IPv4 sources permitted by the network, not just the Management host. Follow renewal, eviction and unconfirmed-closure guidance before assuming access has ended.

Establish Trust and limit Administrator Access

Use a certificate trusted by administrator workstations for the Management hostname. Choose supplied certificates or ACME as described in Management certificates. Track expiry and verify the hostname and chain after replacement.
Provision named administrator accounts through the organization’s Gitea process. Grant administrator status only to people who need appliance control, and review access when responsibilities change.
Protect the initial credentials and replace application bootstrap credentials using the relevant product’s supported procedure. Manage ERS users separately from Management users.
Use the organization’s protected administrative workstations and remote-access controls. If your policy requires multifactor authentication, enforce it at the identity or access service and test the operator sign-in process.
Sign out after work and close administrative tool tabs. Remove obsolete accounts and review retained cluster artifacts when somebody leaves the administration team.

See Manage access for the differences between Management, cluster and ERS accounts. Headlamp and Grafana use shared administrative access behind Management; they do not provide an independent per-user Kubernetes audit identity. A copied artifact bundle remains sensitive after the browser session ends. Coordinate credential replacement with MTG if that bundle is exposed.

Protect Disks, Credentials and Recovery Material

The Management state disk contains host keys, application credentials and TLS material. The ISO does not encrypt that state disk. SOPS configuration encryption and encrypted backups do not provide encryption for all VM disks or live application data.

Restrict who can read, copy, snapshot, export or attach the Management and appliance disks. Apply the organization’s storage encryption and key-management controls at the hypervisor or storage layer as required by that policy. Include VM exports, snapshots and decommissioned media in that policy, and verify that recovery operators can obtain the necessary storage keys during an outage.

Store downloaded artifact bundles in controlled recovery storage. Keep them available after loss of Management, but avoid leaving copies in browser download folders or shared directories. Retain completed full backups outside the appliance, preferably with independently administered retention or immutability controls. Test a restoration using the full recovery set in an isolated environment. See Configure and retain backups.

For deployments using an HSM, protect its administrator credentials and establish the vendor’s key backup and recovery process. Appliance backups do not recover external HSM keys. Use the HSM guide for supported integration steps and limits.

Keep Monitoring useful and private

Keep customer metrics access disabled unless it is needed. When enabling it, choose mTLS or Basic authentication over trusted HTTPS according to the monitoring system’s capabilities, and restrict the source network. Verify rejected access as well as a successful scrape. Follow Customer monitoring and Syslog when replacing an access policy.

Use authenticated, protected external log transport and retention where required. Audit records can contain sensitive original payloads. Review who can search or export them, verify receipt at the destination and assign responsibility for responding to alerts.

Local telemetry is excluded from appliance backups. The log pipeline does not collect the Kubernetes API server audit file, and dashboard audit viewers do not verify record signatures. If your policy requires complete or independently verifiable audit evidence, agree the collection and verification process before accepting the deployment. See Inspect health, logs and audits.

Maintain the supplied Software Baseline

Obtain appliance media and bundles through the agreed MTG distribution channel. Verify supplied checksums and retain the release identity with your deployment records. A checksum checks content integrity; its trust depends on how you obtained the expected value.

Review security advisories and schedule supported appliance and Management updates. Use the release’s compatibility instructions and prepare recovery material before maintenance. Avoid individually upgrading embedded components or applying arbitrary upstream hardening scripts to the running system; changes must remain compatible with the appliance configuration and recovery process.

Secure Boot, disk encryption, compliance certification and complete end-to-end traffic encryption must be assessed for the actual deployment. Using Talos, Kubernetes or a component with security controls does not confirm that the deployment meets those requirements. Record required controls, evidence and any accepted exceptions with the release review.

Verify the Deployment before Handover

Record the responsible owners and evidence for these checks:

Administrative endpoints reject access from unauthorized networks, including Management host SSH.
Administrator accounts and certificate trust match the approved access plan.
Secrets, VM disks, snapshots and artifact bundles have controlled storage and access.
A completed full backup is available outside the appliance and the complete recovery set has been tested.
Monitoring reaches its intended recipients and the required audit history can be retrieved.
Updates, incident response and credential exposure have an agreed owner and procedure.

Repeat the relevant checks after changes to networking, identity, certificates or software. Keep support contact details and recovery instructions available outside the appliance.