SPIKE: Building a Secrets Manager on SPIFFE Workload Identity

Hook

What if your secrets manager never needed to manage credentials—because every workload already had a cryptographically verifiable identity?

Context

Traditional secrets management systems face a chicken-and-egg problem: how do applications authenticate to retrieve secrets without hardcoding credentials? This bootstrap problem has spawned countless solutions—from Kubernetes service accounts to AWS IAM roles to AppRole tokens—each adding complexity and attack surface. Meanwhile, the SPIFFE project solved workload identity through x.509 certificates issued based on kernel-level attestation, giving every service a cryptographic identity without manual credential distribution.

SPIKE takes the logical next step: if SPIFFE already provides strong, automated workload identity, why not use it as the foundation for secrets management? Rather than bolting SPIFFE onto an existing secrets system as one authentication method among many, SPIKE makes SPIFFE identity the only authentication mechanism. This architectural decision eliminates entire categories of security concerns—no master tokens to rotate, no authentication credentials to leak, no complex policy mapping between external identities and internal permissions. For teams already running SPIRE, SPIKE offers secrets management with zero additional credential overhead.

Technical Insight

SPIKE's architecture consists of four components that work together through mTLS channels authenticated by SPIFFE. At the core sits Nexus, the secrets store that handles all encryption, decryption, and persistence. Nexus doesn't trust anything without a valid SPIFFE SVID (SPIFFE Verifiable Identity Document), which means every request must arrive over mTLS with a certificate chain validating back to the SPIRE trust domain.

Here's what authenticating to SPIKE looks like from a workload's perspective. Your application doesn't need credentials—it just needs access to the SPIFFE Workload API socket, typically mounted at /tmp/spire-agent/public/api.sock. Using the SPIFFE Go library, fetching a secret becomes:

package main

import (
    "context"
    "fmt"
    "github.com/spiffe/go-spiffe/v2/workloadapi"
    "github.com/spiffe/spike/pkg/api"
)

func main() {
    ctx := context.Background()
    
    // Fetch X509-SVID from SPIRE agent
    source, err := workloadapi.NewX509Source(ctx)
    if err != nil {
        panic(err)
    }
    defer source.Close()
    
    // Create SPIKE client with mTLS using SVID
    client, err := api.NewClient("https://nexus.spike.svc:8443", source)
    if err != nil {
        panic(err)
    }
    
    // Retrieve secret - authentication is implicit via mTLS cert
    secret, err := client.GetSecret(ctx, "database/password")
    if err != nil {
        panic(err)
    }
    
    fmt.Printf("Secret: %s\n", secret.Value)
}

Notice what's missing: no token management, no credential rotation logic, no authentication configuration. The SPIFFE SVID is automatically rotated by the SPIRE agent (typically every hour), and the new certificate is seamlessly used for subsequent requests. Authorization happens server-side based on the SPIFFE ID extracted from the certificate (something like spiffe://example.org/service/api-server).

The second architectural component, Keeper, solves a specific distributed systems problem: root key availability during failover. Traditional secrets systems store root keys encrypted on disk, requiring decryption during startup—which itself requires credentials or manual intervention. SPIKE's Keeper nodes hold root key shards in memory across a distributed cluster. When a Nexus instance needs to decrypt secrets, it requests key reconstruction from Keeper nodes over mTLS. This design enables instant failover: spin up a new Nexus instance, and it can immediately access secrets by communicating with existing Keeper nodes. The tradeoff is deliberate—root keys never touch persistent storage, reducing attack surface at the cost of requiring Keeper availability.

The third component, Pilot, is the CLI for administrative operations. Rather than SSH-ing into servers or using database clients directly, all admin work flows through Pilot, which translates commands into mTLS API calls to Nexus:

# Pilot CLI examples - all authenticated via SPIFFE
spike secret put database/password "supersecret123"
spike secret get database/password
spike policy attach spiffe://example.org/service/api-server to database/*
spike policy list spiffe://example.org/service/worker

Each Pilot command establishes an mTLS connection using the operator's SPIFFE identity (assigned through SPIRE's operator registration), sends the request, and closes the connection. This architecture contains administrative access within the SPIFFE trust boundary—no SSH keys, no VPN access, no bastion hosts.

The fourth component, Bootstrap, handles initial system setup by securely generating root keys, splitting them into shards using Shamir's Secret Sharing, and distributing shards to initial Keeper nodes. This happens once during deployment, after which the root key exists only in Keeper memory and as distributed shards.

SPIKE's policy model maps SPIFFE IDs directly to secret paths using glob patterns. A policy might state: spiffe://prod.example.org/ns/payments/sa/api can read payments/database/* but not write. Because SPIFFE IDs are hierarchical and cryptographically verified, you can structure policies that mirror your infrastructure—namespaces, services, and environments all encoded in identity rather than managed through separate authentication systems.

Gotcha

SPIKE's dependency on SPIFFE infrastructure is both its greatest strength and its primary limitation. If you're not already running SPIRE across your environment, adopting SPIKE means deploying and operating a complete identity control plane first. SPIRE requires agents on every node, registration entries for every workload, and careful trust domain design. For organizations without this foundation, the operational overhead may outweigh SPIKE's benefits, especially when mature alternatives like Vault offer multiple authentication methods that integrate with existing infrastructure.

The project's development maturity status is explicit and non-negotiable: this is not production-ready software. The GitHub repository clearly warns about breaking changes and undiscovered bugs. While the architecture is sound, production secrets management demands battle-tested code, extensive audit trails, compliance certifications, and emergency recovery procedures that only come with maturity and wide adoption. The limited community size (163 stars) means you'll be pioneering solutions to operational problems rather than following established runbooks. There's also minimal ecosystem tooling—no Terraform providers, no comprehensive Kubernetes operators, no GUI for teams that need visual secret management. You're committing to CLI-driven workflows and potentially building integration tooling yourself.

Verdict

Use if: You're already operating SPIRE for workload identity and want secrets management that's architecturally aligned with zero-trust principles, your team values lightweight, purpose-built tools over feature-rich platforms, and you're comfortable running alpha-stage software in development/staging environments while contributing to its maturation. SPIKE is particularly compelling for cloud-native teams that have invested in SPIFFE and want to eliminate credential sprawl without adding heavyweight infrastructure. Skip if: You need production-ready secrets management today, don't have SPIFFE infrastructure deployed (or don't want to operate it), require mature ecosystem tooling and integrations, or need compliance certifications and vendor support. Organizations evaluating secrets management for the first time should start with Vault or cloud-provider solutions unless they're already committed to SPIFFE as their identity foundation.