Product Update: Post-Quantum Cryptography meets <1s Kubernetes Syncs

Serge Zhuravel — Wed, 27 May 2026 06:00:53 +0000

Engineering teams are actively seeking alternatives to the operational complexity of legacy enterprise vaults and the limitations of consumer-grade tools. We built the upgrade. Engineered to eliminate unencrypted YAMLs and legacy password managers, Ennote Security delivers a true zero-persistence architecture. Whether you are migrating from HashiCorp Vault, replacing 1Password, or securing native Kubernetes workloads, here is how The Identity-Driven Secret Manager bridges the gap between identity and infrastructure.

Kubernetes Smart Agent: <1s Synchronization without the Overhead

Bypass the operational overhead of HashiCorp Vault and proprietary SDKs. Our lightweight, Helm-deployed agent establishes an outbound-only gRPC stream for real-time updates directly to native Kubernetes resources.

Zero Network Friction: No inbound ports, webhooks, or open firewall rules required.
Zero Code Changes: Applications consume secrets via standard envFrom variables.
Auto-Rollout: By adding the restart annotation, the agent automatically rotates pods the millisecond secrets change in your Ennote dashboard.

View Agent Documentation ↗

Transparent, Zero-Persistence Cryptography

When evaluating an enterprise secrets manager, the fundamental security question is not just how data is encrypted, but where and for how long the plaintext keys exist.

Volatile Memory Only: Plaintext keys exist only in RAM for the milliseconds a cryptographic operation occurs.
Absolute Zero Persistence: At no point are plaintext DEKs written to disk, logs, or persistent storage.
Post-Quantum Ready: All data is encrypted via Client-Side AES-256-GCM, enveloped by NIST-standard CRYSTALS-Kyber (Kyber-1024) to protect against "harvest-now-decrypt-later" attacks.

Read the Engineering Deep-Dive ↗

Enterprise Sovereign Control: AWS KMS Integration (BYOK)

Take sovereign control over your organization's cryptography. Expanding on our existing Google Cloud KMS capabilities, Ennote’s Bring Your Own Key (BYOK) architecture now allows you to connect your own AWS KMS to envelope our Internal KMS keys. By wrapping our internal infrastructure with your key, you maintain absolute cryptographic authority, allowing you to instantly revoke access to your data if a breach is suspected.

Learn about BYOK Architecture ↗

A Lightning-Fast, Identity-Driven Interface

We’ve completely refreshed the Ennote Web UI, specifically designed for engineering workflows. Natively integrated with your SSO and RBAC, it’s easier than ever to manage team passwords, API keys, and access controls with a complete chain of custody alongside your infrastructure.

Start Using | Join Community Group | Talk to an Architect

Why Strict "Zero Trust" Breaks Secret Management (And How We Built a Zero-Persistence Vault Instead)

Serge Zhuravel — Mon, 11 May 2026 20:13:43 +0000

This is a technical deep dive into the cryptography behind Ennote's enterprise architecture. You can read the original full-length post on our engineering blog.

When evaluating an enterprise secrets manager, the fundamental security question isn't just how data is encrypted, but where and for how long the plaintext keys exist.

Many platforms market themselves as strict "Zero Trust" (implying End-to-End Encryption where the server knows absolutely nothing). We don't make this claim. Why? Because mathematically strict E2EE fundamentally breaks enterprise secret management workflows.

If you use strict E2EE, there is no centralized authority. If Developer A creates a database password and the company later hires Developer B, the server cannot grant Developer B access. Developer A must manually come online, decrypt the payload locally, and re-encrypt it with Developer B's public key.

This destroys automated onboarding, makes central Role-Based Access Control (RBAC) impossible, and turns machine-to-machine Kubernetes syncing into a fragile nightmare.

We needed a different approach. We prioritized workable, highly governed enterprise security by guaranteeing Zero Persistence.

Here is the cryptographic stack we built to achieve it.

1. Hybrid Cryptography & Transient Envelope Encryption

To get the best of both worlds - centralized RBAC and absolute data security - we use Hybrid Cryptography.

We use the blazing speed of symmetric cryptography to encrypt the actual secrets, and the highly secure, identity-verified nature of asymmetric cryptography to protect and distribute the symmetric key itself.

Local Generation: The client generates a random 256-bit Data Encryption Key (DEK) locally in volatile memory (RAM).
Symmetric Payload Encryption: The payload is encrypted with this DEK using Client-Side AES-256-GCM.
Asymmetric Encapsulation: The DEK is then encapsulated using our Organization-level KMS Public Key.

At no point are plaintext DEKs written to disk, logs, databases, or persistent storage. They exist only in volatile memory for the duration of a cryptographic operation (measured in milliseconds).

2. The Root of Trust: Post-Quantum Kyber

Our architecture begins with absolute hardware security. The master seeds for our internal KMS are protected by Cloud HSMs (FIPS 140-2 Level 3 validation).

From this root, Ennote generates Post-Quantum asymmetric keys using CRYSTALS-Kyber (Kyber-1024), a NIST Post-Quantum standard that protects against "harvest-now-decrypt-later" attacks. Crucially, these Kyber keys are established at the Organization level, not the individual resource level, allowing us to enforce centralized RBAC.

3. Identity Verification: Why We Dropped RSA for X25519

To securely transmit secrets to your developers or our Kubernetes Smart Agent, we have to mathematically verify identity.

We could have used legacy RSA, but RSA requires massive 2048-bit or 4096-bit keys that are computationally expensive to generate on the fly. Instead, every client generates an ephemeral Curve25519 (ECC X25519) key pair for Elliptic-Curve Diffie-Hellman (ECDH) key agreement.

X25519 delivers equivalent or greater security with a fraction of the key size (256 bits). Because they are incredibly fast to generate and require minimal bandwidth, they allow our Kubernetes Agent to maintain an outbound-only gRPC stream for real-time, sub-1-second updates without exhausting cluster CPU.

4. Enterprise Sovereignty: BYOK & Confidential Computing

For teams that need an absolute "kill switch," we built a BYOK (Bring Your Own Key) integration with GCP and AWS KMS.

During an access request under BYOK, the DEK is briefly decapsulated inside a secure KMS enclave. To eliminate the risk of volatile memory extraction during this transient "re-wrapping" phase, our enclaves utilize Confidential Computing.

This hardware-based isolation encrypts the data while it is in-use within RAM, completely preventing memory dumps or hypervisor-level inspection by any party - including malicious actors, host OS admins, or even our cloud infrastructure providers.

The Result: Sub-Second K8s Sync

We engineered the heavy, centralized decryption bottlenecks out of the architecture. By combining Client-Side AES-256, Kyber-1024 encapsulation, ephemeral X25519 identity verification, and Confidential Computing, we achieved true Zero-Persistence.

This allows our lightweight Kubernetes Agent to sync secrets directly to Native K8s Secrets in under 1 second via an outbound-only gRPC stream - requiring zero code changes and zero unencrypted YAMLs.

Over to you! 👇

Building security tools always involves balancing usability, speed, and strict cryptography.

How is your team currently handling secret delivery in Kubernetes?
Are you still relying on polling loops, or have you moved to event-driven architectures?

Let’s chat in the comments! If you want to see this architecture in action, check out Ennote Security.

DEV Community: Ennote Security