Skip to content

Connect Applications to Secrets Manager¶

An application gets its secrets from AccuKnox Secrets Manager in one of two ways. Pick per application, and run both side by side in the same cluster if you need to.

  • Direct SDK or REST API

    The application asks Secrets Manager for the secret and keeps it in memory.

    • Most secure, nothing left in the namespace
    • Works on Kubernetes and virtual machines
    • A few lines of code

    Use the SDK

  • External Secrets Operator

    The operator syncs the secret into a Kubernetes secret the application already reads.

    • No application code change
    • A copy sits in the namespace
    • The app restarts to load a new value

    Use the operator

Samples Cover Python, Java, .NET and Node.js¶

Any language that can make an HTTPS call can read a secret. These have ready-made samples.

  • Python

    hvac, logging in as the pod's service account.

  • Java

    vault-java-driver, or Spring Cloud Vault with config only.

  • .NET

    VaultSharp, for IIS sites, Windows services and jobs.

  • Node.js

    node-vault, with an AppRole login.

  • REST API and scripts

    curl from a shell script, a batch job or a pipeline.

  • Any Kubernetes app, no code

    Keep reading the Kubernetes secret you read today.

The Two Methods Side by Side¶

Direct SDK or REST API External Secrets Operator
Application code change Small, a few lines None
Where the secret lives In application memory only In a Kubernetes secret, or an environment variable
Who else can read it Only the application Anyone with read access to that namespace or workload
Picks up a new value On the next read After the application restarts
Runs on Kubernetes and virtual machines Kubernetes

Both Methods Follow the Same Four Steps¶

The four steps of a secret request: authenticate, get a token, read the secret, and audit

The application, or the operator acting for it, proves its identity and gets a short-lived token tied to a policy. The token reads only the paths that policy allows, over TLS, and Secrets Manager logs every request.

See the Difference in the Diagrams¶

Before and after: a hardcoded secret in the application, then a direct call from the application to Secrets Manager

No Kubernetes secret or environment variable holds a copy, so a user who can read the namespace cannot read the secret.

Before and after: the application reads a Kubernetes secret, which the External Secrets Operator fills from Secrets Manager

The application keeps reading its Kubernetes secret, and the operator keeps that secret equal to the value in Secrets Manager.

Before and after: the application reads an environment variable that the External Secrets Operator fills from Secrets Manager

The operator can feed an environment variable instead. The same namespace exposure applies.

A running application does not reload the secret

The operator updates the Kubernetes secret within its refresh interval. An application that reads the secret at startup sees the new value only after it restarts. The WordPress and MySQL walkthrough shows this on a live cluster.

SCHEDULE DEMO