I manage roughly 200 Linux servers across on-premises bare metal, two AWS regions, and a smaller GCP environment. Historically, access controls have been handled with host-level iptables rules plus AWS security groups and GCP firewall rules. That approach was manageable when the infrastructure was smaller, but keeping all three layers consistent has become increasingly difficult.
Cloud security groups are managed with Terraform, while host rules may change during runtime operations. Urgent changes can therefore diverge from the infrastructure-as-code state, and we do not have a dependable way to confirm that host firewalls, cloud controls, and network policies are synchronized at any given time.
I am investigating whether a centralized network security layer would be more practical than maintaining so much policy directly on each host. Zero trust network access keeps coming up, but most ZTNA material focuses on human users accessing applications rather than service-to-service traffic between infrastructure workloads.
Has anyone applied ZTNA or a similar zero-trust approach to non-human traffic across bare metal and multiple cloud providers? Would a service mesh, centralized firewall appliances, policy-distribution system, or drift-detection workflow be a better fit? I am especially interested in solutions that handle bare metal well and provide reliable enforcement and verification during urgent changes.
4 Answers
I would avoid making one product the only line of defense. Keep host and cloud controls as a safety boundary, then automate their configuration and verification from one policy source.
A scheduled or event-driven process can query AWS, GCP, network devices, and Linux hosts, compare the effective rules with the intended policy, and either alert or remediate. For urgent changes, an event-triggered check is more useful than a nightly job. I would generally alert first for unexpected changes unless automatic rollback is well tested, since blindly rewriting firewall rules can cause an outage.
Traditional ZTNA is usually designed around users accessing applications, so it may not map cleanly onto infrastructure traffic. For server-to-server communication, look at workload identity and policy distribution tools that can authenticate services with certificates or other machine identities rather than relying only on source IPs.
A service mesh can help with service-level identity and authorization, but many meshes are strongest inside a single Kubernetes or cloud-native cluster. They may be awkward for a mixed fleet spanning bare metal, virtual machines, and several providers. A broader overlay or workload-access platform may fit better if it can handle non-human identities consistently.
That distinction matches what we have found. The main concern is finding something that works across bare metal and virtual machines, rather than assuming every workload is part of a managed cluster.
Another workable pattern is centralized management for virtual firewall appliances deployed in each environment. Shared objects, policy templates, VPN configuration, and normalized logging can make AWS, GCP, and on-premises operations much easier to manage.
This does add appliance lifecycle and routing overhead, so it is not automatically simpler than host firewalls. A policy-as-code approach can work well too: assign servers roles such as environment, location, and function, generate the required host and cloud rules from those roles, and roll changes out gradually with canaries and health checks. The key is eliminating manual edits and making the effective policy observable.
A centralized firewall or secure network overlay can reduce the three-way synchronization problem by making one system authoritative for traffic that actually traverses it. This is useful for connecting on-premises and cloud networks and for applying consistent segmentation policies.
The important caveat is bare-metal traffic that does not pass through that enforcement point. You still need host-level controls, a routing design that guarantees the relevant flows use the central layer, or an agent that enforces workload identity locally. Before choosing a platform, map the traffic paths and confirm which controls can enforce policy for east-west traffic on every segment.
That bare-metal exception is the difficult part. A single control plane sounds attractive, but it is only genuinely centralized if the hosts cannot bypass the enforcement path.
Drift detection helps, but it needs to run immediately after operational changes or failed deployments. A periodic scan alone can leave a broken or overly permissive rule in place for too long.