Security Considerations for WebHMI in Kubernetes

This topic covers the most important security practices for running WebHMI in a production Kubernetes cluster. The recommendations apply to both the Rancher-based and command-line deployment methods. Any differences are explicitly specified.

Protecting Cluster Access Credentials

The kubeconfig file ($HOME/.kube/config) and the Rancher admin account both grant full cluster-administrator access. Anyone who obtains either one can read and modify every resource in the cluster, including secrets, such as your TLS private key and container registry password.

Recommended practices:

  • Store the kubeconfig file only on managed, restricted machines. Do not copy it to shared drives or check it into source control.

  • Use a strong, unique password for the Rancher admin account. Enable multi-factor authentication if your Rancher version supports it.

  • Restrict access to the Rancher web interface (port 8443) to management networks only. It should not be reachable from the general user or OT network.

  • Rotate or revoke kubeconfig credentials if a management machine is compromised or decommissioned.

Encrypting Kubernetes Secrets

Kubernetes stores Secrets — your TLS private key, Docker Hub password, SMB credentials — with only base64 encoding, which is not encryption. Anyone who can run kubectl get secret or who has direct access to the underlying etcd database can easily decode the values.

The most practical countermeasure is RBAC (Role-based access control), which by default only allows cluster administrators to read secrets. Do not grant broad RBAC roles to regular users or to service accounts that do not need access to secrets. This alone eliminates the realistic risk for most on-premises industrial deployments.

An additional layer of protection can be achieved by enabling encryption at rest for secrets. In K3s, this is easily done using the --secrets-encryption option or during cluster provisioning via Rancher. This ensures that secrets stored in etcd are encrypted and remain unreadable if an attacker gains access to etcd data (such as backups or disk snapshots) without access to the control plane nodes. It does not prevent users with authorized cluster or node access from reading Secrets, but it reduces the risk of data exposure in partial compromise scenarios. Encryption keys can also be rotated using built-in K3s tooling if required. Enabling this is generally recommended for on-premises deployments, as it provides meaningful protection with minimal operational overhead.

Traffic Between WebHMI Pods and FrameWorX

Traffic from the WebHMI pods inside the cluster to the FrameWorX server outside the cluster is plain HTTP by default. This is acceptable when the cluster and the GENESIS machine are on the same private network or VLAN with no untrusted hosts between them—which is the expected topology for an on-premises installation.

If your network topology cannot guarantee that the path between the Kubernetes nodes and the GENESIS machine is isolated from untrusted devices, configure HTTPS on the FrameWorX web server, and then update the WebHMI Helm values to use it. Learn more

As an additional measure, restrict the FrameWorX machine's network firewall to enable its WebHMI port to be reachable only from the Kubernetes node IP range, not from the broader network.