Identity ≠ Zero Trust. See how enforcing least-privilege, encrypted networks, and policy-as-code inside the stack closes gaps that many DevOps teams miss.
Most zero trust conversations start with identity and stop there.
Teams invest in multi-factor authentication, single sign-on, and fine-grained access control for users and services. They scan tokens, rotate secrets, and audit logs. But beneath all that, the infrastructure often operates under a fundamentally different assumption: that once you're past the login screen, the platform itself can be trusted.
That's where things quietly break.
In practice, most infrastructure isn't designed to enforce least privilege, limit lateral movement, or verify every action. It either simply allows or it doesn’t. And when infrastructure isn't built to enforce trust boundaries, every zero trust policy remains at a concept level, at best.
Which is why this isn’t merely about missing a feature; it’s about the architectural posture of the stack itself. Atmosphere takes a different approach by making infrastructure enforce the trust boundaries.
Identity that Actually Gates Access
Atmosphere doesn’t treat identity as an add-on. It uses OpenStack Keystone as its core identity engine, with Keycloak enabling SSO and federation through LDAP, SAML, and OpenID Connect in Hosted and On-Premise deployments. That means identity enforcement is baked into how infrastructure resources are provisioned not just how dashboards are accessed.
Teams can scope roles to specific projects, APIs, or services, define policies with application credentials that don’t leak user secrets, and enforce multi-factor authentication across the board. Every token, every interaction, every credentialed call is checked and scoped. There are no unchecked trust boundaries lingering in the background.
In public clouds, identity often gates the control plane. With Atmosphere, it gates the infrastructure itself.
Isolation that’s Structural
If your network defaults to flat IP ranges or shared tenants, zero trust ends at the subnet.
Atmosphere uses Open Virtual Network (OVN) to ensure tenant-level network isolation from the outset. Each project operates in its own address space, with per-tenant routers, isolated firewalls, and security groups enforcing explicit rules. Stateful firewall enforcement is built in instead of being manually configured or vendor-wrapped.
And when performance matters, advanced networking doesn’t compromise security. Features like SR-IOV, DPDK, and ASAP2 (available in Hosted and On-Premise editions) allow for hardware acceleration while maintaining segmentation and inspection. Throughput doesn't have to come at the cost of visibility.
Encryption that’s Actually Enforced
Atmosphere enforces encryption by design.
Block storage volumes use native Ceph encryption with keys managed centrally through a dedicated Key Management Service (KMS). TLS is enforced across all APIs and internal services, with centralized certificate management. Kubernetes secrets can integrate with this same KMS, ensuring consistent policy enforcement across workloads and orchestrators.
For teams requiring stricter guarantees, on-premise HSM integration is available in the Hosted and On-Premise editions. Whether you're securing bootstrapped clusters, tenant data, or control plane communications, Atmosphere makes encryption policy-enforceable, not optional.
Kubernetes that Doesn’t Assume Trust
Hot take but a Zero Trust model that forgets about containers isn’t a Zero Trust model.
Atmosphere provisions Kubernetes clusters using OpenStack Magnum and a custom Cluster API driver. These clusters live in isolated tenant networks. RBAC controls are enforced natively. Secrets are secured through KMS integrations. Namespaces can be isolated by design, not retrofitted later.
Clusters are designed for continuity - they auto-heal, scale, and upgrade without relaxing security boundaries. Bootstrapping doesn’t skip steps. Privilege doesn’t propagate unchecked.
So, this isn’t “Kubernetes under zero trust.” This is Kubernetes provisioned under enforced boundaries from the moment the control plane starts.
Visibility that Doesn’t Hit a Wall
Zero trust is also about auditability. And most observability stacks stop short when they hit the hypervisor.
Atmosphere changes that - it supports full integration with Prometheus, Grafana, Loki, and AlertManager, letting teams design their own observability pipelines. With NVIDIA DCGM exporters, teams can track GPU memory usage, process-level stats, and thermal throttling without bolting on disconnected exporters or fighting platform restrictions.
The usage service tracks compute, storage, and network consumption at the project level, with aggregated admin views available in Hosted and On-Premise environments. GPU-hour tracking isn’t native, but can be added via telemetry integrations using Prometheus and custom tagging.
That way even monitoring becomes an extension of the security model.
Policy that’s Codified and Enforced
Atmosphere allows infrastructure policy to be defined as code, backed by OpenStack Heat.
Nested templates can enforce security requirements: network segmentation, encryption flags, RBAC scopes, and resource quotas. Stack policies let you define how instances are provisioned, what flavors are available, and where workloads can live. The enforcement is automatic. And because it’s code, it’s versioned, reviewable, and auditable - a win-win.
Failover and Recovery that Keeps Trust Boundaries Intact
Resilience is a zero trust issue.
Atmosphere supports rolling upgrades for Kubernetes clusters and live migration for compute workloads (in Hosted and On-Premise editions), ensuring availability without relaxing boundary enforcement. DR tooling like Kubernetes Velero can be integrated upon request to protect workloads across sites and clusters.
Storage resilience comes via Ceph with options for erasure-coded tiers, NVMe-backed pools, and custom replication strategies. These features are configurable (and not automatic but the infrastructure makes them possible), and Atmosphere gives teams the architectural space to deploy them correctly.
Configurability that Matches Your Security Posture
Atmosphere’s Hosted and On-Premise editions offer full control over infrastructure components.
Teams can define custom compute flavors, enforce resource quotas, and assign hardware passthrough (like GPU or NIC) to tenants directly. PCI passthrough, SR-IOV, and flavor tuning are available but gated by infrastructure compatibility and team policy.
Nothing is assumed, everything is explicit.
Enforcement >> Policy Handbooks
Most platforms treat infrastructure as a neutral substrate where segmentation, verification, and auditability are add-ons to be layered above. But zero trust doesn’t work unless the platform itself enforces it, baking it into the architecture.
Atmosphere was built to support that kind of architecture - from network isolation to workload-level encryption, from project-scoped RBAC to policy-as-code enforcement.
If your current stack stops verifying once the user logs in, it might be time to evaluate whether zero trust is actually being enforced or just assumed.
Want to see how Atmosphere could fit into your security model?
Our team works with DevOps and security engineers to plan architecture, policies, and integrations tailored to your environment, whether it’s hybrid, hosted, or fully on-premise. You can see and verify this for your self with a proof of concept. Chat with someone from the VEXXHOST team to get access to the PoC.
