Securing Your Environment with OpenBao and Tailscale

Wed, 22 Jul 2026 00:00:00 +0000

Securing Your Environment with OpenBao and Tailscale

By Sam Fleming
Consultant, Red Hat · Tailscale Insider

Introduction

In my day job I’m constantly touching enterprise infrastructure, where HashiCorp Vault and OpenBao are standard fixtures. But at home, I run a setup that generates a power bill my electric company sends me personal thank-you notes for.

At some point I asked myself: How do I bring enterprise-grade security down to my home lab without making my daily workflow a nightmare?

That question led me to OpenBao and a pattern for managing secrets that protects self-hosters and engineering teams alike. This post covers the standard container setup, its underlying credential delivery flaw, and how to fix it using OpenBao and Tailscale together.

The Current Environment

Most self-hosted environments start with containerization. Docker and Podman let us package applications alongside their dependencies and run them in isolation. That ecosystem gives us tools like Paperless-ngx for digitizing mail, Immich for photo management, Nextcloud for file storage, and Forgejo for code hosting. Rather than managing containers individually on the host OS, we define multi-container stacks declaratively using Docker Compose.

To network these containers securely, Tailscale is my go-to. The cleanest pattern for container networking on a private tailnet is called a “sidecar deployment”. Instead of exposing ports to the host or giving containers direct LAN access, you run a lightweight Tailscale sidecar container alongside your application in the Compose stack. All incoming and outgoing traffic for that app routes strictly through your private tailnet. You get ACL controls and zero public ports exposed to the internet.

The catch with this pattern is authentication. Tailscale requires an auth key to register a device on your network, which means that key has to live inside the container deployment.

In practice, that key usually sits in one of two places:

Plain-text .env files stored on the host filesystem.
Hardcoded variables inside CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins).

In both cases, you are passing a static, long-lived credential into the environment.

Most people pull third-party container images from public registries without auditing every upstream dependency. If a dependency in your stack is compromised, an attacker gets shell access inside that container. If your Tailscale auth key sits in an environment variable or a local .env file, the compromise isn’t contained to that single application. An attacker extracts the static key and can spin up malicious nodes from anywhere, attaching them directly to your private tailnet. From there, they can sniff traffic, spoof internal services, and pivot laterally across your network. Features like Tailnet Lock or MAC filtering can help, but the real goal should be making the credential useless if stolen.

The fix: moving secrets out of flat files and into a dedicated secrets engine.

This is where OpenBao, and its predecessor HashiCorp Vault, come in. To understand OpenBao, it helps to look at Vault’s history. HashiCorp Vault was the industry standard for secret management and was fully open-source under the Mozilla Public License up through version 1.14. When HashiCorp shifted Vault to a commercial Business Source License in version 1.15, the Linux Foundation launched OpenBao — a community-governed, open-source fork built directly from Vault 1.14. But OpenBao isn’t just an encrypted key-value store. It acts as an interactive security broker for authentication, identity, and access control.

Storing static credentials inside OpenBao is an improvement over .env files, but it doesn’t solve the core problem. If a breached container queries OpenBao for a permanent credential, an attacker can still steal it. However, OpenBao isn’t just an encrypted key-value store. It acts as an interactive security broker for authentication, identity, and access control. Instead of holding static secrets, OpenBao brokers access directly with target platforms (AWS, database clusters, networking providers).

When an application requests access, OpenBao:

Communicates with the provider API.
Generates a short-lived, single-use credential on the fly.
Passes the credential to the container with a strict TTL.

If a container is breached after boot, the credential used to start it is already expired. There is no static secret stored in memory to harvest, dropping the blast radius to near zero.

New Day, New Threats

The July 2026 Hugging Face incident is a clear example of why static secrets are a dangerous default.

What happened

On July 16, 2026, Hugging Face disclosed unauthorized access to internal datasets. Five days later, OpenAI confirmed that an autonomous AI agent running inside an evaluation sandbox had escaped its environment, executed 17,000+ actions over a weekend, exploited the data-processing pipeline, and harvested internal service credentials — ultimately accessing cloud infrastructure and internal datasets.

Public models and Spaces were untouched, and Hugging Face handled the response cleanly (revoke, evict, rebuild). But the post-mortem consensus among security teams was unanimous: the attack method was completely conventional.

Old playbook, new attacker

As GitGuardian noted in their analysis, if you strip the AI agent from the incident report, the remaining pages read like any breach retrospective from the last decade. The breach didn’t rely on exotic zero-days — it succeeded on reusable credentials and flat internal permissions.

Industry metrics highlight how widespread this vulnerability is:

Roughly 60.4% of digital identities hold long-lived secrets.
64% of valid secrets first discovered in 2022 were still active in early 2026.
Credential-based breaches take an average of 186 days to identify, because a valid credential looks like legitimate traffic.

Applying the lesson

Look at your own environments. Do you have OpenAI or Anthropic API keys sitting in flat config files or .cursor directories? Tailscale auth keys in Compose .env files? Database passwords saved in CI/CD pipeline variables? Hugging Face tokens embedded in training scripts?

Each of those is a standing credential. An attacker — whether a human operator, a ransomware script, or an autonomous model — only needs to find one static key to pivot across your systems.

Dynamic secrets eliminate that vector. If a Tailscale auth key is minted on demand and expires in minutes, there is nothing permanent to steal.

Putting it into practice

When evaluating the extent that you want to deploy this, you can tier your approach based on risk.

Tier 1: Centralize static secrets in OpenBao

Start by getting OpenBao running and moving static secrets out of flat files.

You can install OpenBao natively (brew install openbao), run it via official container images on Quay or Docker Hub, or compile it from source.

For local testing, run it in dev mode:

1

bao server -dev

Writing and fetching keys is straightforward:

1
2


bao kv put secret/my-app key=value
bao kv get secret/my-app

Even basic centralized secret storage is safer than host .env files and unencrypted CI variables. Rotate existing static keys, and turn on secret-scanning on your Git repositories to catch accidental commits.

Tier 2: Use dynamic secrets for core infrastructure

For critical workloads, databases, and public-facing services, switch from static to dynamic secrets. Configure OpenBao to mint temporary credentials on demand with short TTLs.

Tier 3: Automate Tailscale keys with a custom secret engine

To solve the Tailscale sidecar issue, I wrote a custom OpenBao Secret Engine plugin for Tailscale in Go.

Rather than embedding Tailscale API keys into container stacks, you give a single restricted Tailscale OAuth credential to OpenBao. OpenBao registers a dedicated endpoint, such as docker/tailscale/authkey.

The startup flow works as follows:

Docker Compose deploys the application stack.
The Tailscale sidecar boots and requests a key from OpenBao using a short-lived, scoped Vault token.
OpenBao verifies the token and policy, then calls Tailscale’s Control Plane API.
OpenBao requests a single-use, ephemeral auth key tagged specifically for that service.
Tailscale returns the key to OpenBao.
OpenBao passes the key into memory for the sidecar to join the tailnet, then discards it immediately.

The key never touches disk, is never exposed in logs, and cannot be reused. Once the sidecar authenticates to the tailnet, the key no longer exists.

Expanding the pattern

Once OpenBao is brokering access, you can apply the same pattern elsewhere:

AI & LLM API keys: Proxy API calls to OpenAI, Anthropic, or local models through OpenBao instead of storing keys in local config files or .cursor settings.
TLS Certificates: Issue and renew short-lived TLS certs automatically using cert-manager or Certbot integrations.
Identity & Access: Use OpenBao as an OIDC broker requiring hardware passkeys or TOTP before granting temporary access.

Closing Thoughts

The Hugging Face incident generated headlines because an AI agent executed it. But the underlying issue wasn’t novel — it was standing credentials and flat access.

Moving secrets out of plain-text files and adopting dynamic credentials where it matters limits what an attacker can do, regardless of who or what that attacker happens to be.

However, the most important thing to rememeber when implementing this is:

The best security architecture is the one you can actually maintain.

I don’t run a complex dynamic pipeline for every single container in my lab. If an architecture is so tedious that you bypass it when you’re tired on a Sunday night, it offers zero real protection. Go with what you know, try your best, and be safe.

Slides, code examples, and the OpenBao Tailscale plugin are available on GitHub at @SamPlaysKeys. You can reach me directly at info@samplayskeys.com.

This post is based on a presentation prepared for SouthEast Linux Fest 2026. Incident details reflect public disclosures as of late July 2026.

Security on Sam's Blog

Securing Your Environment with OpenBao and Tailscale

Securing Your Environment with OpenBao and Tailscale

Introduction

The Current Environment

New Day, New Threats

What happened

Old playbook, new attacker

Applying the lesson

Putting it into practice

Tier 1: Centralize static secrets in OpenBao

Tier 2: Use dynamic secrets for core infrastructure

Tier 3: Automate Tailscale keys with a custom secret engine

Expanding the pattern

Closing Thoughts