DEV Community: Riptides

Secretless AI-powered development flow

Riptides — Mon, 16 Feb 2026 17:20:44 +0000

Modern development increasingly happens inside different environments: local machine, containers, VMs, remote dev servers. At the same time, AI coding assistants like GitHub Copilot have supercharged developer productivity, but they've also amplified a critical security problem.

When you're using AI to generate infrastructure code, write boto3 scripts, or build Terraform configs at 10x speed, credential management is your primary failure point and the biggest security risk.

How do you securely give a VM or container access to cloud APIs without mounting credential files, passing secrets as environment variables, or copying keys into the environment, especially when AI assistants are generating code that needs those credentials?

And here's the real concern: With AI generates code you didn't write line-by-line, how confident are you that it won't accidentally log secrets, echo environment variables, or write credentials to temp files? Running AI-generated code in an environment with zero access to credentials means you can sleep better at night.

The conventional answer is still based on secrets: copy your ~/.aws/credentials file, mount it as a volume, set AWS_ACCESS_KEY_ID in your shell, or use instance profiles if you're lucky enough to be running in the cloud already.

But this approach has serious flaws:

Credential material tends to proliferate (copied into VM images, accidentally committed, or left behind in shared environments), the blast radius expands (every developer/VM/container with access can leak it), rotation becomes manual and painful (you have to chase down every place the secret landed), and you still get poor auditability (it’s hard to answer “who used which credentials, when?” and “which process touched what API?”).

This post shows a different approach: secretless development environments powered by Riptides. We'll use Lima VMs on macOS with GitHub Copilot as a practical example, but the same pattern applies to Docker containers, remote SSH sessions, cloud dev environments, or any workspace where your AI-generated code runs.

Why sandboxed environments matter for AI-generated code: Treat AI-generated code as untrusted by default, run it in a sandboxed VM or container with zero credential access so even accidental logs, debug outputs, or file writes can't leak credentials.

The problem with development credentials

Let's say you're a macOS developer building cloud-native applications. You want a clean Linux development environment, so you use Lima to run a lightweight Ubuntu VM. Now you need to run AWS CLI commands, test Terraform configs, or call AWS APIs from Python scripts inside that VM.

The standard approach: Copy your credentials

The typical workflow looks like this:

Export AWS credentials on your Mac:

   export AWS_ACCESS_KEY_ID=AKIA...
   export AWS_SECRET_ACCESS_KEY=...

Pass them to the VM via environment or mount:

   # Lima config
   env:
     AWS_REGION: us-west-2
     AWS_ACCESS_KEY_ID: AKIA...
     AWS_SECRET_ACCESS_KEY: ...

Or mount your credentials directory:

   mounts:
     - location: "~/.aws"
       writable: true

Run AWS commands inside the VM:

   limactl shell default
   aws ec2 describe-instances

This works. But you've just copied possibly long-lived secrets into an isolated environment where they're harder to rotate, easier to leak, and completely unaudited.

What can go wrong?

Credential files are persistent (they remain on the VM filesystem until manually deleted), and VM snapshots or “golden images” can quietly capture secrets as a side effect of reproducibility. Shared VM templates often turn into shared secrets, any process in the VM may be able to read credential files, and while AWS CloudTrail can tell you which IAM principal made a call, it usually won’t tell you which process or which workload inside your dev VM did it. When credentials expire or are compromised, rotation becomes a manual update process across every VM/container/config you touched.

Even if you use temporary credentials via AWS STS, you're still handling and storing secrets, they just happen to be short-lived secrets.

The AI coding assistant paradox

GitHub Copilot in VS Code promises 10x developer productivity. It generates infrastructure code, writes AWS automation scripts, and builds Terraform configurations in seconds.

But this productivity gain is bottlenecked by credential management:

Copilot can generate Terraform code, or a deployment script in seconds—yet you still end up stopping to configure AWS credentials, copy secrets into the VM, or manage API keys and access tokens.

The faster you code with AI, the more you're fighting with credentials.

And worse: the more code AI generates, the more opportunities for credential leakage. AI-generated scripts that echo variables, log debug output, or write to temporary files can accidentally expose secrets that weren't there before.

The security benefit: AI code + sandboxed environments + zero credentials

With that setup, you get multiple layers of protection:

AI-generated code runs in an isolated VM/container rather than on your host; there are no credentials on disk to leak even if the code behaves unexpectedly; and Riptides can tie credential injection and telemetry to the calling process.

This means you can trust AI to generate code at high speed without worrying about accidentally creating security vulnerabilities. Run it, test it, iterate, knowing that even if something goes wrong, credentials were never in play.

How Riptides solves the problem

Riptides eliminates stored secrets by injecting credentials dynamically at runtime, directly into the network requests that need them. The workload never stores, reads, or manages AWS credentials directly.

Here's how it works:

Every process gets a kernel-enforced identity

Riptides assigns a SPIFFE-based workload identity to each process, verified and enforced at the kernel level.
Credentials are injected on-the-wire

When a process (like the AWS CLI) makes an HTTPS request to AWS APIs, Riptides intercepts the connection in kernel space, fetches short-lived credentials, and injects them directly into the request using libsigv4.
No secrets on disk, ever

The AWS CLI runs normally, but it never sees credentials. No ~/.aws/credentials file. No environment variables. No mounted volumes.
Automatic rotation and refresh

Credentials are scoped to a single request or short time window. They expire quickly and are automatically refreshed.
Full auditability

Every credential usage is logged: which workload, which process, which API call, when.

If you're familiar with our earlier credential injection posts, this is the same approach applied to development environments:

The difference is that here we're applying it to a local development environment on macOS, making secure, secretless workflows practical for everyday AI-assisted coding.

Why this matters for GitHub Copilot (and other AI coding tools)

GitHub Copilot excels at generating cloud infrastructure code. But it can't solve the credential problem—it just makes it worse:

Workflow	Without Riptides	With Riptides
Copilot generates AWS code	You manually configure credentials	Credentials are injected automatically when the code runs in a jailed environment
Copilot writes Terraform	You mount `~/.aws` into your VM	No credential configuration needed; run in an isolated VM
Copilot builds deployment scripts	You copy secrets into environment variables	Scripts execute securely in jail without ever seeing secrets
Result	Slow, manual, error-prone credential management that negates AI gains	AI-accelerated development with defense in depth and near-zero credential overhead

You get the productivity of AI code generation without the security risks of credential sprawl or running untrusted code with full system access.

Note: While this post focuses on GitHub Copilot in VS Code, the same pattern should work with other AI coding environments like Cursor, Continue, Cody, and similar tools that support remote development or SSH workflows.

Why Lima VMs?

Lima is a lightweight Linux VM manager for macOS. It provides:

Lima gives you fast, native-ish integration (file sharing, port forwarding, and shell access) while still running a full Linux kernel—so Riptides can load its kernel module (unlike many desktop container setups). It’s also relatively lightweight and automation-friendly thanks to declarative YAML configuration and CLI tooling.

Lima is ideal for running Riptides in development because Riptides operates at the kernel level, requiring a Linux environment where kernel modules can be loaded. On macOS, Lima provides exactly that.

Architecture overview

How requests flow:

VS Code on macOS connects to the Lima VM via Remote-SSH
You use Copilot to generate code/commands, and run tools like AWS CLI and Terraform inside the VM
AWS CLI / Terraform attempts an HTTPS request to AWS APIs (for example ec2.amazonaws.com)
The Riptides kernel module intercepts the connection
The Riptides agent:
- Verifies the process identity
- Fetches short-lived AWS credentials (via federation or local provider)
- Passes credential material to the kernel module
The Riptides kernel module:
- Signs the HTTP request using libsigv4
- Injects the signed headers into the request
The request proceeds to AWS, fully authenticated
AWS CLI / Terraform receives a successful response — without ever seeing credentials

Setting up Lima with Riptides

Prerequisites

You’ll need macOS with Homebrew, Lima installed (brew install lima), and access to the Riptides kernel module + agent (currently closed source; contact Riptides Labs to request access—open source release planned for later in 2026).

Step 1: Start a Lima VM

Create a Lima VM configuration file riptides.yaml:

vmType: "vz"
os: "Linux"
arch: "default"

images:
  - location: "https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-amd64.img"
    arch: "x86_64"
  - location: "https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-arm64.img"
    arch: "aarch64"

cpus: 4
memory: "8GiB"
disk: "100GiB"

mounts:
  - location: "~"
    writable: true
  - location: "/tmp/lima"
    writable: true

provision:
  - mode: system
    script: |
      #!/bin/bash
      apt-get update
      apt-get install -y build-essential curl git awscli
      snap install terraform --classic

containerd:
  system: false
  user: false

Start the VM:

limactl start riptides.yaml

Step 2: Install Riptides

Once you have access to the Riptides repository, install via apt inside the Lima VM:

limactl shell riptides

# Add Riptides repository (provided after contacting Riptides Labs)
# Install Riptides (includes kernel module, agent, and systemd service)
sudo apt-get update
sudo apt-get install riptides

# Verify the kernel module is loaded
lsmod | grep riptides

Step 3: Connect VS Code Remote-SSH

To use GitHub Copilot in the Lima VM, connect via VS Code Remote-SSH. Lima VMs integrate seamlessly with VS Code Remote-SSH—see the Lima VS Code integration guide for more details.

Add the SSH config to your ~/.ssh/config:

limactl show-ssh riptides >> ~/.ssh/config

Then connect via the VS Code Command Palette (Remote-SSH: Connect to Host).

For other AI coding tools: Environments like Cursor, Continue, and Cody that support SSH remote development should work with the same configuration.

Step 4: Configure Riptides workload identities

To enable secretless AWS access, configure Riptides to recognize AWS CLI and Terraform processes and inject credentials automatically.

Define the AWS service

Create a Service resource that matches all AWS API endpoints:

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: amazonaws
  namespace: riptides-system
spec:
  addresses:
  - address: "*.amazonaws.com"
    port: 443
  external: true
  labels:
    svc:name: amazonaws

This tells Riptides to intercept HTTPS connections to any *.amazonaws.com domain.

Configure workload identity for AWS CLI

Create a WorkloadIdentity for the AWS CLI process:

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: awscli
  namespace: riptides-system
spec:
  workloadID: awscli
  connection:
    tls:
      intercept: true
  scope:
    agent:
      id: riptides/agent/local-copilot-lima
  selectors:
  - process:name: aws

This configuration:

This assigns identity to any process named aws, enables TLS interception so Riptides can inject credentials into HTTPS requests, and scopes the rule to the Lima VM agent (local-copilot-lima).

Configure workload identity for Terraform

Similarly, create a WorkloadIdentity for Terraform:

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: terraform
  namespace: riptides-system
spec:
  workloadID: terraform
  connection:
    tls:
      intercept: true
  scope:
    agent:
      id: riptides/agent/local-copilot-lima
  selectors:
  - process:name: terraform

With these workload identities in place, both AWS CLI and Terraform processes receive:

With these workload identities in place, both AWS CLI and Terraform gain identity-scoped credential injection, per-process connection telemetry (domain/port/protocol), automatic SigV4 signing, and better audit context (Riptides records workload identity + process details while CloudTrail records the resulting AWS API calls).

Complete the credential binding

After defining these resources, create an AWS CredentialSource and WorkloadCredential, then reference that credential from the WorkloadIdentity egress rule (as shown in our AWS credential injection guide). For AWS IAM trust relationship setup (OIDC + subject mapping), see Federating non-human identities with external IdPs.

Configure AWS CLI for TLS interception

Since Riptides intercepts TLS connections to inject credentials, you need to configure the AWS CLI to trust Riptides' CA certificate. Create or update ~/.aws/config:

[default]
output = json
region = eu-west-1
ca_bundle = /sys/module/riptides/certs/ca-certificates.crt

The ca_bundle points to the CA certificate that Riptides uses for TLS interception. (Depending on install/version, you may instead set AWS_CA_BUNDLE to a path like /sys/kernel/riptides/ca-certificates.crt.)

Using secretless AWS access in the Lima VM

Once Riptides is running, AWS CLI commands work without any credential configuration:

# No ~/.aws/credentials file
# No AWS_ACCESS_KEY_ID env var
# Just run AWS commands

aws ec2 describe-instances

Behind the scenes:

Riptides detects the aws process execution
The agent matches it against configured rules
The process is assigned a workload identity based on its runtime attributes
As the AWS CLI makes HTTPS requests, Riptides intercepts them
Short-lived credentials are injected into the request at the kernel level
The request proceeds to AWS, fully authenticated
The AWS CLI receives the response — never knowing credentials were involved

Real-world GitHub Copilot workflows with Riptides

These examples show how GitHub Copilot works seamlessly with Riptides—generating code that executes securely in a jailed environment without credential configuration.

(Here, “jailed” refers to running inside the Lima VM; Riptides’ core contribution is secretless, identity-scoped credential injection and per-process visibility.)

Copilot-generated Terraform workflow

Ask GitHub Copilot: "Help me query my EC2 instances with Terraform"

Copilot can help generate the AWS CLI command to list your instances:

First, list your existing EC2 instances:

Copilot can help generate the Terraform configuration. Create main.tf:

# No credentials configured - Riptides injects them automatically
provider "aws" {
  sts_region = "us-east-1"
}

# Query all running EC2 instances
data "aws_instances" "running" {
  filter {
    name   = "instance-state-name"
    values = ["running"]
  }
}

# Get details for each instance
data "aws_instance" "details" {
  for_each    = toset(data.aws_instances.running.ids)
  instance_id = each.value
}

# Output instance information
output "instances" {
  value = {
    for id, instance in data.aws_instance.details : id => {
      id            = instance.id
      instance_type = instance.instance_type
      ami           = instance.ami
      private_ip    = instance.private_ip
      public_ip     = instance.public_ip
      tags          = instance.tags
    }
  }
}

Run Terraform:

terraform init
terraform plan
terraform apply

# View the discovered instances
terraform output -json instances

After running the Terraform workflow, the Riptides UI shows exactly how many times credentials were injected for Terraform. In this example, you can see that the UI displayed 9 credential injections for the Terraform process:

Key point: Notice there's no credential configuration anywhere in the Terraform code or environment:

Key point: Notice there's no credential configuration anywhere in the Terraform code or environment—no ~/.aws/credentials file, no AWS_ACCESS_KEY_ID environment variable, and no credential blocks in the provider configuration. It’s just a plain provider with a region.

Terraform executes successfully because Riptides intercepts AWS SDK calls from the Terraform binary and injects credentials transparently at the kernel level.

The key difference: With Riptides, you can use Copilot to generate infrastructure code at full speed, then run it immediately in a jailed VM—no credential setup interrupting your flow, and no risk of the generated code accessing credentials it shouldn't.

You can confidently run AI-generated code knowing the VM jail restricts filesystem access, no credentials exist to leak, and even if Copilot generated code with unintended side effects, the blast radius is minimal.

Key benefits for AI-powered development

Security without friction, at AI speed

Riptides removes credential management from the loop: you never copy/mount/configure AWS credentials (even for Copilot-generated code), and you don’t need application changes—CLI commands, scripts, and Terraform configs just work. Protection is automatic for configured AWS-calling processes, so the flow becomes generate → run in jail → iterate without pausing to wire up secrets. The payoff is peace of mind: AI-generated code runs in an isolated environment with zero credential access.

Better collaboration

With no embedded secrets, VM templates can be shared, versioned in git, and distributed safely. Onboarding gets faster (less “here’s how to set up your AWS credentials” documentation), and teams get more consistent dev environments.

Improved auditability

Riptides logs which process made which call and makes it practical to correlate workload/process context with CloudTrail. Unexpected processes reaching for AWS APIs become visible, logged, and easier to investigate.

Complete network observability

Riptides provides real-time visibility into every network connection from your development environment.

See exactly which processes connect where: GitHub Copilot's Node.js runtime to api.individual.githubcopilot.com:443, AWS CLI to AWS service endpoints, Terraform to AWS APIs—all in real-time with full process-level detail. Essential for verifying AI-generated code behavior before trusting it.

Beyond Lima: Apply this pattern anywhere

While this post uses Lima VMs on macOS with GitHub Copilot as a concrete example, the same pattern applies to:

Docker containers (no more -v ~/.aws:/root/.aws mounts), remote dev servers over SSH, CI/CD pipelines, Kubernetes dev clusters, and cloud IDEs like Codespaces/Cloud9/Gitpod can all benefit from the same idea. In practice, it should also work with other AI coding environments (Cursor, Continue, Cody, etc.) as long as they support SSH or remote development.

The core principle remains the same: jailed environments + workload identity + zero credentials = AI code you can run confidently.

Conclusion

Development environments are often the weakest link in cloud security. Credentials get copied, mounted, committed to git, or left lying around in VM snapshots.

Riptides eliminates this problem by bringing the same secretless, identity-based security model that we've demonstrated for production workloads (AWS, GCP, OCI) to local development environments.

Key takeaways:

Key takeaways: AWS CLI, Terraform and other tools work without credential configuration—whether you wrote them or Copilot did. Isolation and credential injection are enforced at the OS/kernel layer (not in application code), the generated scripts/configs run unchanged in jailed environments, and credential usage becomes auditable with process-level detail. Most importantly, Copilot’s productivity isn’t throttled by credential setup, and you can run AI-generated code with confidence because credentials never exist in the environment.

Whether you're using Lima VMs, Docker containers, remote SSH sessions, or cloud-based development environments, Riptides provides a path to secretless development that doesn't compromise productivity.

Learn more

SPIFFE Identity Federation: Extending Trust Across Boundaries

Riptides — Mon, 09 Feb 2026 13:03:37 +0000

Workload identity has become a foundational primitive in modern infrastructure. Static credentials do not scale, degrade over time, and rarely explain why access should be allowed. The SPIFFE specification addresses this by defining a standard way to issue short-lived, cryptographically verifiable identities to workloads.

From the beginning, SPIFFE was designed with multiple administrative boundaries in mind. Real systems span clusters, cloud accounts, regions, organizations, and partners. Identity must cross those boundaries without collapsing everything into a single control plane.

SPIFFE identity federation exists to solve exactly this problem.

Trust domains as the foundation

SPIFFE organizes identity around trust domains.

A trust domain represents an administrative boundary with authority over:

its SPIFFE ID namespace
its trust anchors
the issuance of workload identities within that namespace

A workload identity is expressed as a SPIFFE ID, for example:

spiffe://prod.acme.corp/frontend

That identity is meaningful only because the verifier trusts the authority that governs the prod.acme.corp trust domain.

Within a single trust domain:

workloads receive SVIDs
SVIDs chain to the domain’s trust anchors
peers verify identities using those anchors

Federation begins when workloads must authenticate across trust domains.

Why federation is necessary

Consider two independent trust domains:

spiffe://payments.acme.corp
spiffe://inventory.acme.corp

Each domain:

operates its own control plane
issues and rotates its own identities
enforces its own policies
maintains its own trust anchors

If a workload in payments.acme.corp needs to communicate with a workload in inventory.acme.corp, identity must cross an administrative boundary.

Without federation, teams typically fall back to:

sharing trust anchors globally
terminating identity at gateways and re-issuing credentials
abandoning identity and relying on networks or secrets

All of these approaches erase workload identity at the boundary.

SPIFFE federation exists to avoid that outcome.

Federation as defined by the SPIFFE specification

Federation is a first-class concept in the SPIFFE specification.

The spec defines federation as the ability for a trust domain to verify identities issued by another trust domain without:

sharing private keys
merging control planes
centralizing identity issuance

To support this, the specification defines:

trust domain relationships
trust bundles
bundle endpoints
verification semantics

At the same time, the spec deliberately limits its scope to identity verification.

Trust bundles as the unit of trust

The core object used in federation is the SPIFFE trust bundle.

A trust bundle contains:

one or more trust anchors for a trust domain
optional metadata
no private key material

Trust bundles are the only artifacts exchanged during federation. No identities are delegated, and no keys are shared.

Standardized bundle endpoints

The SPIFFE federation specification defines standardized bundle exchange using SPIFFE bundle endpoints.

Bundle endpoints are HTTPS endpoints that serve trust bundles. Two authentication profiles are defined:

https_web, authenticated using Web PKI TLS
https_spiffe, authenticated using SPIFFE X.509-SVIDs

The specification requires that:

bundle endpoint clients MUST support both profiles
bundle endpoint servers MUST support at least one profile
TLS configurations meet defined security requirements

This ensures interoperability while allowing deployment flexibility.

How to establish federation

Assume the following trust domains:

spiffe://payments.acme.corp
spiffe://inventory.acme.corp

To federate:

payments.acme.corp is federated with:
- the trust domain name inventory.acme.corp
- the bundle endpoint URL for that domain
- the expected endpoint authentication profile
it periodically fetches the trust bundle from that endpoint
it validates the bundle according to the specification

Federation can be symmetric or asymmetric depending on configuration.

How verification works with federation

Federation does not change how workloads authenticate.

At runtime:

a workload presents its SVID
the verifier extracts the SPIFFE ID
the trust domain portion of the ID is identified
the corresponding trust bundle is selected
certificate chain verification proceeds normally

Federated identities are verified using the same cryptographic process as local identities.

Explicit and scoped trust

SPIFFE federation is explicit and opt-in.

Trust domains do not implicitly trust each other. Each federation relationship must be configured intentionally, including:

which trust domain is federated
where its bundle endpoint is located
how its bundle is authenticated
how often it is refreshed

The spec enables federation but does not force trust expansion.

What federation does not define

Even with standardized bundle exchange, the SPIFFE federation spec intentionally does not define:

authorization semantics
policy models
enforcement location
federation topology
governance or lifecycle rules

Federation answers one question only:

Can this workload identity be cryptographically verified as originating from the stated trust domain?

What that identity is allowed to do remains a separate concern.

Common misconceptions

Federation is often misunderstood.

It is not:

a global root CA
transitive by default
workload-level delegation
dynamic trust based on behavior

Federation operates strictly at the trust domain level and only affects identity verification.

Why federation alone is often insufficient

In theory, SPIFFE federation is clean and well-defined.

In practice, teams encounter issues when:

trust relationships grow faster than policy
bundles become stale or poorly governed
verification is decoupled from enforcement
identity context disappears after the handshake

These are not flaws in the specification. They are consequences of how identity is applied in real systems.

Federation is most effective when verification and enforcement remain tightly coupled.

Looking ahead

The SPIFFE federation specification provides a precise, interoperable foundation for extending workload identity across administrative boundaries.

What it intentionally leaves open is how federation is enforced, constrained, and observed at runtime.

In a follow up post, we will explore how Riptides approaches federation, enforces it below the application layer, and how runtime context changes the security properties of federated workload identity.

If you enjoyed this post, follow us on LinkedIn and X for more updates.

If you'd like to see Riptides in action, get in touch with us for a demo.

Zero-Touch Secrets: On-The-Wire Injection of Vault-Sourced Credentials

Riptides — Mon, 02 Feb 2026 14:37:31 +0000

In the previous post, Secure OpenAI API Key delivery with Riptides, we demonstrated how Riptides securely delivers short-lived OpenAI API keys sourced from Vault/OpenBao to AI agents using kernel-enforced sysfs files. That approach already eliminates static secrets, reduces blast radius, and removes the need for Vault clients or tokens in workloads.

This model provides several key advantages:

A dramatically reduced blast radius compared to static keys
A clean separation between identity, access policy, and application logic
Strong isolation between co-located workloads, enforced at the Linux kernel level
A familiar consumption model for developers (read a credential, use it)

This post goes further. Instead of delivering credentials to workloads, Riptides injects Vault-sourced credentials directly into outbound requests in kernel space at the moment they are sent. API keys and cloud credentials never appear in the application user space; not in files nor in configuration.

By combining Vault/OpenBao as the system of record for short-lived credentials with on-the-wire injection model of Riptides, organizations can enforce identity-based access to OpenAI and cloud APIs with zero secret handling in workloads, while preserving compatibility with existing applications.

Existing Riptides capability: secretless cloud credential injection

Before introducing Vault, Riptides already supported on-the-wire injection of temporary cloud credentials that it provisions itself, based on workload identity.

These credentials are:

Short-lived
Issued on demand
Never stored or managed by developers or operators

You can learn more about this capability in these posts:

In these scenarios, Riptides itself provisions temporary cloud credentials and injects them directly into outbound requests at write time, in kernel space.

No secrets.
No SDK changes.
No sidecars.

Why Vault / OpenBao changes the equation

The injection of Vault/OpenBao-sourced credentials does not replace existing cloud credential injection Riptides capability; it complements it.

Many organizations already rely on Vault or OpenBao as their central system for issuing:

Short-lived cloud provider credentials
Database credentials (both static and dynamic)
API keys for internal and external services

For these teams, replacing Vault is neither desirable nor realistic. This is where the approach presented in this post comes in.

By integrating Vault/OpenBao with Riptides via tokenex, organizations can now:

Keep Vault/OpenBao as the credential authority
Continue using existing Vault policies, TTLs, and audit logs
Eliminate secret distribution and handling on the infrastructure where workloads run
Apply the same on-the-wire injection model to credentials sourced from Vault

In other words, if you already use Vault to issue credentials, you can now consume those credentials without ever exposing them to workloads.

From secure delivery to full elimination of secrets in workloads

The sysfs-based approach presented previously already offers strong guarantees. But it still involves materializing credentials in user space, even if briefly and under kernel control.
On-the-wire injection takes the final step.

With this model:

Credentials are fetched from Vault/OpenBao
Authentication to Vault/OpenBao is JWT-based and tokenless
Credentials are injected directly into outbound requests in kernel space on demand
The workload never sees, stores, or processes the credential

We refer to this as on-the-write credential injection.

How it works at a high level

A workload initiates an outbound request

For example:
- An AI agent calling OpenAI
- A service accessing AWS APIs
Riptides intercepts the request in kernel space

No application changes. No SDK wrapping.
Credentials are requested from Vault/OpenBao
- No Vault tokens are stored or distributed
- Vault policies remain fully in control
Credentials are injected into the request at write time
- OpenAI API keys are added to HTTP headers
- Cloud credentials are injected in the appropriate protocol-specific form
The request leaves the node authenticated

The workload itself remains entirely unaware of the credential.

What we’ll show next

In the remainder of this post, we’ll demonstrate how:

OpenAI API keys issued by Vault/OpenBao can be injected on the wire using Riptides
AWS credentials sourced from Vault/OpenBao can be injected into cloud API requests using Riptides

Prerequisites

This guide assumes:

Vault or OpenBao is already running

JWT authentication is configured in Vault/OpenBao to trust the Riptides control plane as an OIDC issuer

The OpenAI secrets engine plugin is enabled and configured

The AWS secrets engine plugin is enabled and configured

Roles for generating OpenAI API keys and AWS credentials are already defined

On-the-wire injection of OpenAI API keys sourced from Vault/OpenBao

Define the external OpenAI service in Riptides

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: openai-api
  namespace: riptides-system
spec:
  addresses:
    - address: api.openai.com
      port: 443
  labels:
    app: openai-api
  external: true

This Riptides Service object declares OpenAI as an external dependency. It enables Riptides to apply identity-aware egress policies when workloads communicate with the OpenAI API.

Configure Vault/OpenBao as a credential source

apiVersion: core.riptides.io/v1alpha1
kind: CredentialSource
metadata:
  name: vault-openai-apikeys
  namespace: riptides-system
spec:
  vault:
    address: http://localhost:8200
    jwtAuthMethodPath: jwt
    role: <JWT-AUTH-ROLE>
    path: openai/creds/my-role
    audience: ["vault"]
    type:
      token:
        source: api_key

This CredentialSource tells Riptides:

Which Vault/OpenBao instance to connect to
Which JWT authentication role to use
Which secret path to read
That the credential should be treated as a bearer token

The OpenAI API key behaves as a bearer token and must be sent in the HTTP request header as:

Authorization: Bearer <API_KEY>

By setting the credential type to token, Riptides activates its built-in bearer token injection mechanism. The source field specifies which attribute in the Vault/OpenBao response contains the token value.

Riptides exchanges a workload identity JWT for a short-lived OpenAI API key, without requiring Vault tokens or SDKs inside the workload.

Define the workload identity for the AI agent

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: ai-agent
  namespace: riptides-system
spec:
  scope:
    agent:
      id: <AGENT_WORKLOAD_ID>
  workloadID: ai-agent
  selectors:
    - process:name: <AI-AGENT-PROCESS-NAME>

This object binds a SPIFFE-based workload identity to a specific process. Only the matching process is treated as the AI agent and is allowed to:

Authenticate to Vault/OpenBao
Receive OpenAI API keys
Use those credentials when calling the OpenAI API

Bind the credential source to the workload

apiVersion: core.riptides.io/v1alpha1
kind: CredentialBinding
metadata:
  name: vault-openai-apikeys-binding
  namespace: riptides-system
spec:
  workloadID: ai-agent
  credentialSource: vault-openai-apikeys
  propagation:
    injection:
      selectors:
        - app: openai-api

This CredentialBinding connects the AI agent identity with the Vault credential source and defines how the credential is applied. In this case, Riptides injects the OpenAI API key directly into outbound requests sent to the OpenAI API.

On-the-wire injection of AWS credentials sourced from Vault/OpenBao

Define the external AWS service in Riptides

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: aws-api
  namespace: riptides-system
spec:
  addresses:
    - address: *.amazonaws.com
      port: 443
  labels:
    app: aws-api
  external: true

This Service object declares the AWS API as an external dependency, allowing Riptides to apply identity-aware egress controls to AWS API calls.

Configure Vault/OpenBao as an AWS credential source

apiVersion: core.riptides.io/v1alpha1
kind: CredentialSource
metadata:
  name: vault-aws-creds
  namespace: riptides-system
spec:
  vault:
    address: http://localhost:8200
    jwtAuthMethodPath: jwt
    role: <JWT-AUTH-ROLE>
    path: aws/creds/my-role
    audience: ["vault"]
    type:
      aws: {}

By setting the credential type to aws, Riptides activates its built-in AWS credential injection mechanism. Under the hood, this uses the
libsigv4 library to sign AWS API requests in kernel space.

Define the workload identity for the AWS client

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: aws-cli
  namespace: riptides-system
spec:
  scope:
    agent:
      id: <AGENT_WORKLOAD_ID>
  workloadID: aws-cli
  selectors:
    - process:name: aws

This workload identity applies specifically to the AWS CLI process.

Bind the AWS credential source to the workload

apiVersion: core.riptides.io/v1alpha1
kind: CredentialBinding
metadata:
  name: vault-aws-creds-binding
  namespace: riptides-system
spec:
  workloadID: aws-cli
  credentialSource: vault-aws-creds
  propagation:
    injection:
      selectors:
        - app: aws-api

With this binding in place, Riptides injects Vault-issued AWS credentials directly into outbound AWS API requests without exposing credentials to user space, environment variables, or configuration files.

Key takeaways

Riptides supports two complementary models for secretless access:

Riptides-provisioned temporary credentials injected on the wire Ideal when you want Riptides to directly issue and inject cloud credentials.
Vault/OpenBao-sourced credentials injected on the wire Ideal when Vault is already your source of truth for cloud, database, or API credentials.

Both approaches share the same core properties:

No long-lived secrets
Kernel-level enforcement
Strong workload isolation
Minimal operational overhead
Clear auditability and policy control

On-the-wire injection of credentials represents the most secure end state: credentials never exist in workload user space at all.

And when that model isn’t feasible for business or technical reasons, the sysfs-based delivery approach remains available, still far more secure than traditional methods, and fully managed by Riptides at the kernel level.

Together, these options give organizations a practical, incremental path toward eliminating secrets from modern AI and cloud-native systems.

With these takeaways in mind, the next question is how this model fits into your existing security architecture.

Who should use which model?

Both credential injection models serve different organizational needs and maturity levels.

Use Riptides provisioned temporary credentials if:

You want the simplest path to secretless access for cloud and AI APIs
You are not already standardized on Vault/OpenBao
You prefer Riptides to handle the credential lifecycle end-to-end
You want an immediate reduction in secret sprawl with minimal platform changes

This model is ideal for teams adopting secretless infrastructure for the first time or for greenfield platforms.

Use Vault/OpenBao-sourced credentials if:

Vault/OpenBao is already your system of record for credentials
You issue short-lived cloud, database, or API credentials via Vault/OpenBao today
You want to preserve existing policies, audit trails, and governance controls
You need to consume credentials that Riptides cannot provision natively, but that Vault/OpenBao supports via a secrets engine plugin

This model is ideal for enterprises with mature security programs that want to eliminate secret handling at runtime without disrupting existing Vault/OpenBao workflows.

Both approaches share the same core guarantees: identity-based access, short-lived credentials, kernel-level enforcement, and zero secret distribution to developers or operators.

If you enjoyed this post, follow us on LinkedIn and X for more updates.

If you'd like to see Riptides in action, get in touch with us for a demo.

tokenex adds Vault & OpenBao support: Exchanging ID tokens (JWTs) for secrets without static credentials

Riptides — Mon, 26 Jan 2026 13:53:54 +0000

Introducing Vault & OpenBao support in tokenex open source library

Since its first release, tokenex has focused on identity-first credential acquisition exchanging short-lived identity tokens (JWT) for cloud credentials just-in-time, without baking secrets into code, files, or images.

Today, we’re extending that model with native support for HashiCorp Vault and OpenBao as credential providers in tokenex beyond cloud IAM.

With this new capability, tokenex can exchange ID tokens (JWTs) for secrets stored in Vault or OpenBao, using their built-in JWT authentication flows; no static Vault tokens, no long-lived credentials, and no manual secret distribution.

This addition makes Vault and OpenBao first-class participants in tokenex’s identity-driven workflow, allowing applications to retrieve both:

cloud-native credentials (AWS, GCP, Azure, OCI), and
infrastructure or application secrets (databases, APIs, internal services)

using the same identity-based access pattern.

In the next section, we’ll explain why this integration matters, how it complements tokenex’s existing capabilities, and what it unlocks for teams building secure, scalable systems.

Why we built this feature

tokenex was originally created to provide a unified, consistent interface for obtaining and refreshing cloud credentials across multiple providers including AWS, GCP, Azure, and OCI — by exchanging identity tokens for temporary credentials and streaming those credentials over a channel so applications never have to implement bespoke refresh logic themselves.

It already supports:

AWS: Exchanging ID tokens for temporary session credentials via Workload Identity Federation
GCP: Exchanging ID tokens for access tokens via federated identity
Azure: Exchanging ID tokens for access tokens using OAuth and Entra ID
OCI: Exchanging ID tokens for User Principal Session Tokens (UPST)
Generic token passthrough and Kubernetes secret watching for flexible integrations

This model enables developers to write single credential consumption logic, regardless of provider, while tokenex handles:

Identity token exchange
Credential refresh and rotation
Streaming updates to applications

While this already removed much of the complexity around cloud authentication, there was still a clear gap: enterprise secrets management.

Many real‑world systems don’t only need cloud API credentials. They also rely on database credentials, API keys, and other sensitive configuration, which are typically managed by platforms like HashiCorp Vault or OpenBao. These systems excel at issuing dynamic, short‑lived secrets, enforcing least privilege, and providing strong auditability, but consuming those secrets safely still requires glue code and identity plumbing.

By adding Vault/OpenBao as a first‑class credentials provider, tokenex now allows workloads to:

Exchange a JWT (ID token) for secrets using Vault/OpenBao JWT authentication
Retrieve static or dynamic secrets (for example, database credentials) without embedding Vault‑specific logic

With this addition, tokenex evolves from a cloud‑credential helper into a general identity‑to‑secret exchange layer. Applications authenticate once using identity, and tokenex handles the rest, regardless of whether the target is a cloud API or a centralized secrets manager.

This feature is a natural extension of tokenex’s core philosophy:

minimize credential handling in applications, centralize trust in identity, and let platforms issue short‑lived secrets on demand.

Demo: Using tokenex with OpenBao to publish PostgreSQL credentials

1. Deploy OpenBao and PostgreSQL

In this step, we deploy OpenBao and PostgreSQL as containers using Docker Compose.

OpenBao configuration

Create a file named vault.hcl with the following contents:

ui = true

storage "file" {
  path = "/vault/data"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}

api_addr     = "http://127.0.0.1:8200"
cluster_addr = "http://127.0.0.1:8201"

plugin_auto_register = true
plugin_auto_download = true
plugin_download_behavior = "fail"

plugin_directory = "/opt/openbao/plugins"

Note:
For simplicity, TLS is disabled and file-based storage is used.
This configuration is suitable for demos and local development only.

Docker Compose setup
Create a docker-compose.yml file:

services:
  openbao:
    restart: unless-stopped
    image: openbao/openbao:2.4
    container_name: openbao
    ports:
      - "8200:8200"
    cap_add:
      - IPC_LOCK
    volumes:
      - ./vault.hcl:/vault/config/vault.hcl:ro
      - vault-data:/vault/data
    environment:
      VAULT_ADDR: "http://127.0.0.1:8200"
    command: vault server -log-level=debug -config=/vault/config/vault.hcl

  postgres:
    image: postgres:18
    container_name: postgres
    restart: unless-stopped
    shm_size: 128mb
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: mysecretpassword
    ports:
      - "5432:5432"
    volumes:
      - pg-data:/var/lib/postgresql

volumes:
  vault-data:

  pg-data:

2. Initialize and unseal OpenBAO

docker exec openbao bao operator init -format=json > vault-init.json

docker exec openbao bao operator unseal $(jq -r '.unseal_keys_b64[0]' vault-init.json)
docker exec openbao bao operator unseal $(jq -r '.unseal_keys_b64[1]' vault-init.json)
docker exec openbao bao operator unseal $(jq -r '.unseal_keys_b64[2]' vault-init.json)

3. Configure JWT authentication in OpenBao

# Enable JWT authentication method
docker exec -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) \
  openbao bao auth enable jwt

# Configure the JWT authentication method
docker exec -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) \
  openbao bao write auth/jwt/config \
    bound_issuer="<OIDC_ISSUER_URL>" \
    oidc_discovery_url="<OIDC_DISCOVERY_URL>" \
    oidc_client_id="" \
    oidc_client_secret=""

bound_issuer: <OIDC_ISSUER_URL> – Issuer URL of your OIDC provider
oidc_discovery_url: <OIDC_DISCOVERY_URL> – URL for OIDC metadata discovery (keys, endpoints)

# Create a named role 'secret-reader' that authorizes JWTs with specific subject and audience claims
# Assign the 'read-secrets' policy to this role
docker exec -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) openbao \
  bao write auth/jwt/role/secret-reader \
    user_claim="sub" \
    bound_audiences="<JWT_AUDIENCE>" \
    bound_subject="<JWT_SUB_CLAIM>" \
    token_policies="read-secrets" \
    token_type="service" \
    expiration_leeway=150 \
    not_before_leeway=150 \
    role_type="jwt"

bound_audiences: <JWT_AUDIENCE> – Expected aud claim in JWT tokens
bound_subject: <JWT_SUB_CLAIM> – Expected sub claim in JWT tokens

# Create the 'read-secrets' policy
# Grants read access to the 'pg-dyn-dbuser' dynamic DB credential and the 'pg-dbuser1' static DB credential
docker exec -i -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) openbao \
  bao policy write read-secrets -<<EOF
path "database/creds/pg-dyn-dbuser" {
  capabilities = ["read"]
}

path "database/static-creds/pg-dbuser1" {
  capabilities = ["read"]
}
EOF

4. Configure database secrets engine

In this step, we enable the database secrets engine in OpenBAO and configure it to manage credentials for PostgreSQL, both dynamic (temporary) and static users.

# Enable database secrets engine
docker exec -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) openbao \
  bao secrets enable database

Configure the connection to PostgreSQL

# Configure connection to PostgreSQL
docker exec -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) openbao \
  bao write database/config/my-postgresql-database \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="pg-dyn-dbuser, pg-dbuser1" \
    connection_url="postgresql://{{username}}:{{password}}@postgres:5432" \
    username="postgres" \
    password="mysecretpassword"

Configure a dynamic role for temporary PostgreSQL users
Dynamic roles allow OpenBAO to generate short-lived database credentials automatically:

# Configure a role that maps a name in OpenBAO to an SQL statement to execute to create the database credential
docker exec -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) openbao \
  bao write database/roles/pg-dyn-dbuser \
    db_name="my-postgresql-database" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
        GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Note that {{name}}, {{password}}, and {{expiration}} are dynamically populated by OpenBAO.

Create a static PostgreSQL user
This user will be referenced by a static role in OpenBAO.

# Create a database user named 'dbuser1' in the PostgreSQL
docker exec -e PGPASSWORD=mysecretpassword  postgres psql -U postgres -c "CREATE USER \"dbuser1\" WITH PASSWORD 'pwd1'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"dbuser1\";"

Configure a static role in OpenBAO
Static roles allow OpenBAO to manage existing database users without creating new ones:

# Configure a static role that creates a link to a user named 'dbuser1' in the PostgreSQL database
docker exec -e VAULT_TOKEN=$(jq -r '.root_token' vault-init.json) openbao \
  bao write database/static-roles/pg-dbuser1 \
    db_name="my-postgresql-database" \
    username="dbuser1" \
    rotation_period="1d"

Note - pg-dbuser1 maps to the existing PostgreSQL user dbuser1 and rotation_period defines how often the password of the database user should be rotated

5. Demo application

This demo application logs both dynamic and static database credentials to stdout as they are issued and refreshed by OpenBAO.

package main

import (
    "context"
    "log"
    "os"
    "os/signal"
    "sync"
    "syscall"

    "emperror.dev/errors"
    "github.com/go-logr/logr"
    "github.com/iand/logfmtr"

    "go.riptides.io/tokenex/pkg/credential"
    "go.riptides.io/tokenex/pkg/token"
    "go.riptides.io/tokenex/pkg/vault"
)

func main() {
    // Create a cancellable context
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    // Create a logger
    opts := logfmtr.DefaultOptions()
    opts.Humanize = true
    opts.Colorize = true
    opts.AddCaller = true
    opts.CallerSkip = 2

    logger := logfmtr.NewWithOptions(opts)
    logfmtr.SetVerbosity(2)

    // Create a wait group to track goroutines
    var wg sync.WaitGroup

    // Set up graceful shutdown
    signalChan := make(chan os.Signal, 1)
    signal.Notify(signalChan, syscall.SIGINT, syscall.SIGTERM)
    logger.Info("Press Ctrl+C to stop...")

    go func() {
        sig := <-signalChan
        logger.Info("Received signal, shutting down...", "sig", sig)
        cancel()
    }()

    // Create an identity token provider
    // under the hood the credential provider uses OCI workload identity federation to fetch user principal session tokens from OCI
    // the credential provider exchanges an input ID token for an OCI user principal session token
    // the input ID token can be obtained from any OIDC compliant IDP (e.g. Google, Microsoft, Auth0, Okta, etc.)

    // for this example, we use a static ID token provider that returns a hardcoded ID token issued by an OIDC compliant IDP
    // in a real application, you would implement the `token.IdentityTokenProvider` interface to create a dynamic ID token provider that fetches the ID token from an OIDC compliant IDP
    idTokenProvider := token.NewStaticIdentityTokenProvider("<id-token-issued-by-idp>")

    // Create the Vault credentials provider
    vaultProvider, err := vault.NewCredentialsProvider(ctx, logger, "http://localhost:8200", nil)
    if err != nil {
        logger.Error(err, "Failed to create Vault credentials provider")
    }

    dynDBCredsChan, err := vaultProvider.GetCredentials(
        ctx,
        idTokenProvider,
        vault.WithJWTAuthMethodPath("jwt"),
        vault.WithJWTAuthRoleName("secret-reader"),
        vault.WithSecretFullPath("database/creds/pg-dyn-dbuser"),
    )
    if err != nil {
        logger.Error(err, "Failed to get dynamic database credentials")
    }

    // Process dynamic database credentials
    wg.Add(1)
    credentialsConsumer(logr.NewContext(ctx, logger.WithValues("secret_engine", "database", "credential_type", "dynamic", "secret_path", "/creds/pg-dyn-dbuser")), &wg, dynDBCredsChan, logDBCreds)

    staticDBCredsChan, err := vaultProvider.GetCredentials(
        ctx,
        idTokenProvider,
        vault.WithJWTAuthMethodPath("jwt"),
        vault.WithJWTAuthRoleName("secret-reader"),
        vault.WithSecretFullPath("database/static-creds/pg-dbuser1"),
    )
    if err != nil {
        logger.Error(err, "Failed to get static database credentials")
    }

    // Process static database credentials
    wg.Add(1)
    credentialsConsumer(logr.NewContext(ctx, logger.WithValues("secret_engine", "database", "credential_type", "static", "secret_path", "/static-creds/pg-dbuser1")), &wg, staticDBCredsChan, logDBCreds)

    // Wait for all goroutines to finish
    wg.Wait()
}

func credentialsConsumer(ctx context.Context, wg *sync.WaitGroup, credsChan <-chan credential.Result, credsLogger func(logr.Logger, *credential.VaultSecret)) {
    go func() {
        defer wg.Done()

        logger := logr.FromContextOrDiscard(ctx)
        for {
            select {
            case creds, ok := <-credsChan:
                if !ok {
                    logger.Info("credentials channel closed")

                    return
                }
                if creds.Err != nil {
                    logger.Error(creds.Err, "Error receiving credentials", errors.GetDetails(creds.Err)...)

                    return
                }

                dbSecret, ok := creds.Credential.(*credential.VaultSecret)
                if !ok {
                    logger.Error(errors.New("invalid credential type"), "expected *credential.VaultSecret")

                    return
                }
                credsLogger(logger, dbSecret)

            case <-ctx.Done():
                log.Println("Context cancelled, shutting down credentials handler")

                return
            }
        }
    }()
}

func logDBCreds(logger logr.Logger, dbSecret *credential.VaultSecret) {
    // Database secrets typically contain username and password
    username := dbSecret.Data["username"].(string)
    password := dbSecret.Data["password"].(string)

    logger.Info("credential", "username", username, "password", password)
}

Sample output:

0 info  | 11:00:29.398131 | Press Ctrl+C to stop...        caller=main.go:41
0 info  | 11:00:29.428805 | credential                     caller=main.go:220 secret_engine=database credential_type=static secret_path=/static-creds/pg-dbuser1 username=dbuser1 password=Qj-6l6OWghtonpucH6Vd
2 info  | 11:00:29.428858 | Published Vault secret         logger=vault_credentials caller=creds.go:245 secret_path=database/static-creds/pg-dbuser1 expiresAt="2026-01-15 13:51:17.428782 +0100 CET m=+6648.032605334"
2 info  | 11:00:29.428879 | Using RefreshOn time from credentials logger=vault_credentials caller=creds.go:252 refreshOn="2026-01-15 13:51:22.428782 +0100 CET m=+6653.032605334"
1 info  | 11:00:29.428885 | Scheduling credential refresh  logger=vault_credentials caller=creds.go:260 refreshIn=1h50m52.999899041s refreshBuffer=0s secret_path=database/static-creds/pg-dbuser1
2 info  | 11:00:29.446979 | Published Vault secret         logger=vault_credentials caller=creds.go:245 secret_path=database/creds/pg-dyn-dbuser expiresAt="2026-01-15 12:15:29.446969 +0100 CET m=+900.050791918"
0 info  | 11:00:29.446989 | credential                     caller=main.go:220 secret_engine=database credential_type=dynamic secret_path=/creds/pg-dyn-dbuser username=v-jwt-ript-pg-dyn-d-QKRDQydUME1zlQtgdyY6-1768474829 password=t7gZd5h-7BwZr2lB0iFO
1 info  | 11:00:29.447002 | Scheduling credential refresh  logger=vault_credentials caller=creds.go:260 refreshIn=11m57.937258345s refreshBuffer=3m2.06274128s secret_path=database/creds/pg-dyn-dbuser

What we see in the output:

For the static PostgreSQL user dbuser1, the password is managed and rotated by the OpenBAO database secrets engine. The user was originally created with the password pwd1. OpenBAO rotates this password only when the rotation time is reached, at expiresAt="2026-01-15 13:51:17.428782 +0100 CET".

Because this is a static role, tokenex cannot retrieve a new password before the rotation occurs. It must wait until OpenBAO performs the rotation.

Once the password has been rotated, Tokenex re-fetches and publishes the updated credentials shortly after, at refreshOn="2026-01-15 13:51:22.428782 +0100 CET".

For the dynamic PostgreSQL user v-jwt-ript-pg-dyn-d-QKRDQydUME1zlQtgdyY6-1768474829, OpenBAO creates a brand-new database user with a unique password. This credential is short-lived and expires in approximately 15 minutes.

Unlike static credentials, tokenex can proactively request a new dynamic credential before the current one expires.

In this example, a refresh is scheduled at refreshIn=11m57.937258345s with a refreshBuffer=3m2.06274128s, ensuring continuous access without relying on password rotation.

Example use cases

1. Zero-Trust service & database access

Workloads authenticate using a JWT and exchange it for secrets at runtime:

Short-lived database credentials (e.g. PostgreSQL)
Service-specific API keys or tokens
Automatically rotated by Vault/OpenBao
Fully auditable and identity-scoped

No secrets in config files, CI pipelines, or environment variables.
No shared credentials between services.

2. Trusted secret orchestrators

A trusted orchestrator (Kubernetes controller, job runner, workflow engine) can:

Authenticate using its own workload identity
Use Tokenex to fetch secrets on behalf of workloads
Enforce centralized policy, intent, and approval flows
Act as a controlled trust boundary in regulated environments

Final thoughts

By combining:

Identity-based authentication
Centralized secrets management
Short-lived credentials
Explicit, auditable token exchange

you end up with systems that are:

Easier to reason about
Harder to misuse
Safer by default

tokenex doesn’t replace Vault or OpenBao — it connects them seamlessly to modern identity systems, allowing secrets to be accessed only when and where identity has been verified.

If you enjoyed this post, follow us on LinkedIn and X for more updates.

If you’d like to see Riptides in action, get in touch with us for a demo.