Source: containerjournal.com (original coverage, March 2020)
Overview
Zettaset announced the release of XCrypt Kubernetes Encryption, extending its software-defined encryption platform to support Kubernetes. The addition enables IT and security teams to centralize encryption policy management across multiple Kubernetes clusters — an increasingly critical capability as container-based workloads move into regulated, enterprise environments.
What XCrypt Kubernetes Encryption Does
Kubernetes ships with a built-in Secrets mechanism designed to protect sensitive configuration values such as tokens, API keys, and passwords. However, Kubernetes Secrets on its own does not provide a comprehensive solution for encrypting the underlying data volumes that microservices read from and write to.
XCrypt Kubernetes Encryption is positioned as a complementary extension rather than a replacement for Kubernetes Secrets:
- Kubernetes Secrets — protects tokens, credentials, and other small configuration payloads stored in etcd.
- XCrypt Kubernetes Encryption — encrypts data at rest on the persistent storage volumes attached to Kubernetes workloads, using AES-256.
Prior to this release, Zettaset’s encryption platform focused on data stored by Docker containers on physical storage systems. The Kubernetes extension brings that same protection to orchestrated, multi-cluster environments and adds centralized key and policy management.
Why Centralized Encryption Management Matters for Kubernetes
One of Kubernetes’ core strengths — the ability to schedule and move container workloads dynamically across nodes and clusters — is also a challenge for encryption operations. When workloads migrate, the encryption policies and keys governing their data must follow seamlessly.
Without centralized management, teams face several practical problems:
- Key sprawl — every microservice can generate its own encryption keys, making rotation and auditing complex.
- Inconsistent policy enforcement — different clusters may apply different encryption standards, creating compliance gaps.
- Operational overhead — manual key management does not scale alongside ephemeral, auto-scaling workloads.
By centralizing encryption policy through XCrypt, Zettaset argues that organizations can automate these concerns as part of a broader DevSecOps pipeline, treating encryption configuration as code rather than an after-the-fact operational task.
Software-Defined Encryption vs. Hardware-Based Approaches
Enterprise IT has historically relied on hardware security modules (HSMs) and hardware-based encryption for performance and trust reasons. The concern was straightforward: software-layer encryption adds CPU overhead, potentially degrading application throughput.
Zettaset’s position is that modern compute density, combined with hardware-accelerated AES-NI instructions available in current-generation x86 and ARM processors, makes software-defined AES-256 encryption practical without significant latency impact. The company claims minimal overhead for applications accessing encrypted data, though independent benchmarks for XCrypt specifically are not available to validate this claim.
The software-defined model does offer concrete operational advantages over HSM-centric architectures in cloud-native environments:
- No hardware procurement or rack-space dependency.
- Policy changes can be version-controlled and deployed through CI/CD pipelines.
- Encryption scope can expand or contract alongside Kubernetes cluster scaling events.
Enterprise Adoption: The Encryption Gap in Kubernetes Environments
According to Zettaset CEO Tim Reilly, cybersecurity concerns — including the absence of robust at-rest encryption — remain one of the primary barriers slowing enterprise Kubernetes adoption. Many legacy monolithic applications already encrypt their data stores. When development teams migrate those workloads to microservices architectures on Kubernetes, they need equivalent or stronger encryption guarantees for the data those microservices consume.
This creates a migration decision: modernize the encryption layer of the legacy application, or rebuild the application as a cloud-native service from the ground up. Reilly suggests that in many cases, replacing an encryption engine inside a large monolithic application may be more costly and time-consuming than rebuilding the application as microservices on Kubernetes with encryption handled at the platform layer.
Post-Quantum Cryptography: A Longer-Term Driver
The announcement also touched on a longer-term concern: post-quantum cryptography. As quantum computing hardware matures, many of the asymmetric encryption algorithms (such as RSA and elliptic-curve cryptography) that protect data in transit and at rest may become vulnerable to quantum-enabled attacks. Nation-state actors are already considered capable of harvesting encrypted data today to decrypt it once sufficient quantum compute capacity becomes available — a strategy sometimes called “harvest now, decrypt later.”
While AES-256 symmetric encryption is considered more quantum-resistant than RSA at equivalent key sizes, the broader cryptographic ecosystem will require updates. This means enterprise IT organizations will need to assess and potentially replace encryption engines in legacy applications over the coming years — another argument, Zettaset contends, for adopting software-defined, centrally managed encryption that can be updated without rearchitecting underlying applications.
Note: NIST finalized its first set of post-quantum cryptographic standards in 2024. Organizations evaluating long-term encryption strategies should review NIST’s guidance independently of any vendor’s roadmap.
Encryption and DevSecOps: Shifting Left
The broader industry trend toward DevSecOps — embedding security controls into the development and delivery pipeline rather than bolting them on post-deployment — creates a natural opportunity for software-defined encryption. When encryption is managed through APIs, Helm charts, or Kubernetes Operators, developers and platform engineers can include encryption configuration in the same infrastructure-as-code workflows they use for everything else.
How much responsibility for encryption configuration ultimately shifts left to developers versus remaining with dedicated security or platform teams is still an open question in most organizations. However, the more encryption becomes a configurable, automatable platform capability, the lower the friction of enforcing it consistently across all workloads.
Key Takeaways
- Zettaset XCrypt Kubernetes Encryption extends native Kubernetes Secrets with at-rest volume encryption using AES-256.
- Centralized policy management across multiple clusters addresses key sprawl and policy inconsistency at scale.
- Software-defined encryption enables encryption configuration to be managed as code within DevSecOps pipelines.
- Post-quantum concerns are accelerating the need for flexible, updatable encryption infrastructure.
- The “encrypt everything” momentum, driven in part by cloud providers like AWS, continues to reduce the cost and complexity argument against broad encryption adoption.