DEV Community: Serge Zhuravel

Introducing the Ennote CLI: Next-Generation, Zero-Persistence Secret Management

Serge Zhuravel — Wed, 24 Jun 2026 17:50:12 +0000

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

For years, developers and security teams have been locked in a tug-of-war over how to handle application secrets. The traditional workflow - copying and pasting sensitive API keys into plaintext .env files - has always been a massive security liability. Hardcoded secrets leak into version control, linger on developer laptops indefinitely, and create a sprawling attack surface.

Today, we are thrilled to announce the Ennote Security CLI: an identity-driven, zero-persistence secret manager built from the ground up for modern developers and CI/CD environments.

The Ennote CLI bridges the gap between human identity (SSO) and your infrastructure, allowing you to fetch, inject, and manage enterprise secrets without ever writing a plaintext .env file to disk.

Here is a look at what makes the Ennote CLI the most secure way to manage your environment variables.

🚀 The Magic of Process Injection (Zero-Persistence)

The core philosophy of the Ennote CLI is Zero-Persistence. Secrets belong in memory, not on your hard drive.

Instead of piping variables or writing out configuration files, the CLI securely injects your secrets directly into the memory space of a child process.

For example, to run your local Node server with your production Stripe keys, you simply run:

ennote secret get "stripe-keys" -- npm run dev

What happens under the hood?

The CLI authenticates your identity.
It fetches the stripe-keys payload via a secure, TLS 1.3 encrypted gRPC tunnel.
It resolves your $PATH and executes npm run dev.
The secrets are injected directly into the execution environment (cmd.Env) of that specific process tree.
When the process terminates, the secrets vanish. Nothing is ever written to disk.

Architectural Security & Post-Quantum Cryptography

Enterprise security isn't just a feature; it's our foundational principle. The Ennote CLI operates on a strict Zero-Persistence threat model, heavily fortified against modern attack vectors:

Hardware-Backed Cryptography: We implement Ephemeral Elliptic-Curve Diffie-Hellman (X25519) combined with Post-Quantum CRYSTALS-Kyber (Kyber-1024) encapsulation.
RAM-Only Decapsulation: Secrets are decapsulated strictly in volatile memory. Plaintext Data Encryption Keys (DEKs) are explicitly destroyed using compiler-safe memory wiping routines before functions exit to defeat memory scraping.
OS-Native Keyrings: Authentication tokens are never stored in plaintext config files. We utilize the native OS Keyring (macOS Keychain, Windows Credential Manager, Linux Secret Service).
Strict Transport Security: All remote gRPC connections require TLS 1.3, complete with hardcoded downgrade prevention.

Seamless Developer Experience & CI/CD Ready

Security shouldn't come at the cost of developer velocity.

For local development, getting started is as easy as running ennote auth login. This opens your system browser, authenticates you via your organization's SSO (Google, Microsoft, GitHub), and securely stores a session token in your OS keyring.

What about automated pipelines? The Ennote CLI is fully equipped for headless CI/CD environments (GitHub Actions, GitLab CI, Jenkins). Simply provision a Machine Identity Token and inject it via the environment:

# Example: GitHub Actions
steps:
  - name: Run Database Migrations
    env:
      ENNOTE_TOKEN: ${{ secrets.ENNOTE_MACHINE_TOKEN }}
      ENNOTE_ORGANIZATION_ID: org_123
      ENNOTE_WORKSPACE_ID: wrk_prod
      ENNOTE_DO_NOT_TRACK: 1
    run: |
      ennote secret get "db-credentials" -- npm run migrate

(Note: Ennote automatically handles complex JSON serialization, injecting primitives directly as strings to ensure compatibility with standard application parsers).

Verifiable Provenance & Supply Chain Security

You shouldn't have to blindly trust the binaries you install. Every Ennote CLI release is entirely automated and cryptographically verifiable:

SBOMs: We attach a standard SPDX/CycloneDX SBOM (.sbom.json) to every compiled artifact.
Keyless Signatures: All release checksums are signed using Sigstore Cosign via GitHub OIDC tokens.
Zero Human Intervention: No human developer possesses the cryptographic keys to publish or sign a release.

Get Started Today

The Ennote CLI is available today with pre-compiled binaries for all major operating systems.

macOS & Linux (Homebrew):

brew install ennote-io/tap/ennote

Windows (Scoop):

scoop bucket add ennote-io [https://github.com/ennote-io/scoop-bucket](https://github.com/ennote-io/scoop-bucket)
scoop install ennote

Universal Shell Script (CI/CD):

curl -sSfL [https://get.ennote.io/get-cli.sh](https://get.ennote.io/get-cli.sh) | sh

Say goodbye to leaked .env files and hello to identity-driven secret management.

Ready to dive deeper? Check out the official GitHub repository and read through our comprehensive CLI Reference Documentation to start securing your workflow today.

Ready to Upgrade Your Secret Management?

Stop compromising between security and developer velocity. Get started with Ennote today to see our Zero-Persistence architecture in action, or book a demo with our engineering team to learn how we can secure your infrastructure.

The Identity-Driven Cryptography Behind Ennote's Zero-Persistence Vault

Serge Zhuravel — Tue, 23 Jun 2026 05:39:44 +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 is not just how data is encrypted, but where and for how long the plaintext keys exist. As "The Identity-Driven Secret Manager", Ennote answers this by bridging the gap between infrastructure and identity.

Whether you are a developer logging into our clean, lightning-fast Web UI, a script utilizing our CLI, or a native Kubernetes agent, the cryptographic process is exactly the same. We deliver secure team sharing, enforced SSO, and a sub-1-second sync to infrastructure with zero code changes required and absolute Zero Persistence. To achieve this without compromising security, Ennote employs a verifiable Transient Envelope Encryption model. We do not claim "magic"; we rely on transparent, peer-reviewed cryptographic primitives. Here is exactly how Ennote works, what we use, and why.

1. Zero Persistence vs. Zero Trust (Why We Reject Buzzwords)

Many platforms market themselves as "Zero Trust" (implying strict End-to-End Encryption where the server infrastructure knows absolutely nothing and cannot mediate access). We do not make this claim, because true Zero Trust fundamentally breaks enterprise secret management workflows.

The Flaw of Zero Trust in Secret Sharing: In a mathematically strict Zero Trust (E2EE) model, 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 specifically with Developer B's public key. This approach destroys automated onboarding, makes central Role-Based Access Control (RBAC) impossible, and turns machine-to-machine syncing into a highly fragile, operational nightmare.
The Ennote Reality - Zero Persistence: Enterprise organizations require centralized governance. We built Ennote to provide seamless onboarding via built-in SSO (Google/Microsoft), full Role-Based Access Control (RBAC), and immutable Audit Logs to track every user action, creating a complete chain of custody for your data. To enable this secure team sharing, the Ennote internal KMS does mediate the cryptographic handshake to securely route access. However, plaintext keys exist only in volatile memory (RAM) for the duration of a cryptographic operation (milliseconds). At no point are plaintext DEKs written to disk, logs, databases, or persistent storage.

We reject the "Zero Trust" buzzword because we prioritize workable, highly-governed enterprise security. We guarantee Zero Persistence.

2. The Foundation: Hybrid Cryptography & Envelope Encryption

To achieve this Zero Persistence safely, we utilize Hybrid Cryptography via Envelope Encryption - the practice of locking a fast symmetric key inside of a highly secure asymmetric key.

In cryptography, there are two primary methods for securing data:

Symmetric Cryptography: Uses a single, shared key to both encrypt and decrypt data. It is highly efficient and capable of encrypting large payloads at lightning speed. However, it suffers from a distribution flaw: securely transmitting that single key over a network to the recipient creates a massive vulnerability.
Asymmetric Cryptography (Public-Key): Uses a mathematically linked pair of keys - a Public Key (to encrypt) and a Private Key (kept secretly by the owner to decrypt). This solves the distribution problem entirely, but asymmetric math is computationally heavy and far too slow to encrypt large payloads efficiently.

The Hybrid Approach: Ennote combines both methods. We use the blazing speed of symmetric cryptography to encrypt your actual secrets, and the highly secure, identity-verified nature of asymmetric cryptography to protect and distribute the symmetric key itself.

3. The Root of Trust & Organization-Level Governance

Ennote’s architecture begins with absolute hardware security. The master seeds for our Internal KMS are protected by Cloud HSMs (AWS KMS / Google Cloud KMS) featuring FIPS 140-2 Level 3 validation. This establishes an unhackable root of trust.

From this root, Ennote generates Post-Quantum asymmetric keys using CRYSTALS-Kyber (Kyber-1024), a NIST Post-Quantum standard that protects Data Encryption Keys (DEKs) against "harvest-now-decrypt-later" attacks.

Crucially, these Kyber keys are established at the Organization level.
Access to individual resources within your organization is not managed by blindly decrypting the entire vault. Instead, Ennote utilizes Full Role-Based Access Control (RBAC) and immutable Audit Logs to provide granular access control to each individual resource.

4. The Lifecycle of a Secret: High-Speed Payload Protection

When an engineer (via Web UI/CLI) or automated agent creates a secret, the platform executes the following flow:

Local Generation: The client generates a random 256-bit Data Encryption Key (DEK) locally in volatile memory (RAM).
Symmetric Payload Encryption: The data payload is encrypted with this DEK using Client-Side AES-256-GCM, ensuring authenticated encryption.
Asymmetric Encapsulation: The DEK is then encapsulated (enveloped) using the Organization-level KMS Public Key (Kyber) into a secure Key Capsule.
Blind Storage: We store the encrypted payload alongside the encapsulated DEK. The DEK is completely unreadable to the storage layer, and payloads remain entirely opaque to Ennote.

5. Identity Verification: Why We Use X25519 Over RSA

To securely transmit secrets to your developers or the lightweight Ennote Kubernetes Smart Agent, we must mathematically verify identity. Every client generates an ephemeral Curve25519 (ECC X25519) key pair for Elliptic-Curve Diffie-Hellman (ECDH) key agreement. Private keys never leave the device.

Why not use legacy RSA? Legacy RSA requires massive 2048-bit or 4096-bit keys that are computationally expensive and slow to generate on the fly. X25519 (Elliptic Curve Cryptography) delivers equivalent or greater security with a fraction of the key size (256 bits). Because X25519 keys are incredibly fast to generate and require minimal bandwidth, they perfectly enable the Ennote Agent to maintain its outbound-only gRPC stream for real-time, sub-1-second updates without exhausting cluster resources.

6. Ultimate Enterprise Control: BYOK & Transient Re-Wrapping

For enterprise customers who require absolute cryptographic sovereignty, Ennote offers Bring Your Own Key (BYOK) Support. It is strictly within this BYOK workflow that our transient "re-wrapping" operation occurs.

When an organization enables BYOK, they connect their own Google or AWS KMS (which natively supports asymmetric encryption) to envelope the Ennote Internal KMS keys.

During an access request under BYOK, the DEK is briefly decapsulated inside the secure KMS enclave in volatile memory (RAM).
The server immediately performs ECDH with the Client's Public Key, wraps the DEK using the customer's BYOK control logic and derived session key, and instantly flushes memory.

Because the customer owns the ultimate Key Encryption Key via their AWS/GCP KMS, they have complete control over the encryption of the DEK. If a breach is suspected, the customer can instantly revoke access at their own cloud provider level, instantly severing Ennote's ability to re-wrap the DEKs and rendering the vault cryptographically sealed.

7. The Zero-Persistence Guarantee & Confidential Computing

Through this precise combination of Client-Side AES-256-GCM, Organization-level Kyber-1024 encapsulation, ephemeral X25519 identity verification, and optional BYOK transient re-wrapping, Ennote achieves true Zero-Persistence.

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

Confidential Computing Protection: To entirely eliminate the risk of volatile memory extraction during the transient re-wrapping phase, our KMS 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 administrators, or our own cloud infrastructure providers. Physical theft of our disks yields absolutely no data.

8. Native Kubernetes Integration & Auto-Rollout

Ennote is designed to replace unencrypted YAMLs and eliminate the need for developers to learn new SDKs. This is powered by our proprietary Kubernetes Smart Agent, deployed directly via Helm.

The lightweight agent establishes an outbound-only gRPC stream - requiring no inbound ports or open firewall rules - to sync secrets directly to Native Kubernetes Secrets in under 1 second. Applications consume these secrets securely via standard envFrom variables with zero code changes required. Furthermore, by adding the restart annotation, Ennote enables Auto-Rollout: when secrets are updated in the Ennote dashboard, the agent automatically rotates the pods depending on those secrets, ensuring immediate and seamless consistency across your entire cluster.

9. Executive Q&A

Q: If you are faster than HashiCorp Vault, and you aren't strict Zero Trust, what security checks are you skipping?
A: None. We are faster because we engineered the bottleneck out of the architecture. Instead of relying on heavy, centralized decryption pipelines, we distribute the workload using highly efficient X25519 Elliptic Curve cryptography and Client-Side AES-256. Ennote doesn't skip security; we modernized the cryptography to match the sub-second speed of modern Kubernetes.

Q: Can a malicious insider at Ennote dump the RAM and steal our keys during the transient re-wrapping?
A: No. Ennote engineers have zero access to customer data keys, and all administrative actions require MFA and are heavily logged. Furthermore, the re-wrapping occurs inside a secure KMS enclave protected by Confidential Computing. Because the memory itself is hardware-encrypted while in use, RAM dumping is mathematically impossible.

Q: If you don't use strict "Zero Trust," how do I guarantee sovereignty over my data?
A: By deploying our BYOK integration. This connects your own AWS or GCP KMS directly to our enclave, giving you the ultimate hardware kill-switch. You maintain total cryptographic sovereignty; Ennote merely facilitates the sub-second routing and seamless RBAC.

Ready to Upgrade Your Secret Management?

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.