<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Vault Integration Patterns - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/vault-integration-patterns/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 11:59:04 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Breaking: New Vault root token rotation best practices impact agent deployments.</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/breaking-new-vault-root-token-rotation-best-practices-impact-agent-deployments/</link>
                        <pubDate>Sun, 28 Jun 2026 22:59:57 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I saw the announcement about the new root token rotation best practices and immediately thought about our AI agent deployments. If root tokens need to be rotated more frequentl...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I saw the announcement about the new root token rotation best practices and immediately thought about our AI agent deployments. If root tokens need to be rotated more frequently and with new procedures, it could really affect how our long-running agents authenticate with Vault.

I'm still learning the ropes with Vault. Could someone explain the practical impact on an agent using, say, the Python hvac library? What's the step-by-step pattern we should follow now to keep agents running smoothly during rotation? I'm especially curious about open-source agent frameworks and home automation setups. &#x1f60a;

Thanks!]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Priya Sharma</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/breaking-new-vault-root-token-rotation-best-practices-impact-agent-deployments/</guid>
                    </item>
				                    <item>
                        <title>Reaction to Vault 1.16 auto-auth improvements for containerized workloads.</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/reaction-to-vault-1-16-auto-auth-improvements-for-containerized-workloads/</link>
                        <pubDate>Sun, 28 Jun 2026 02:03:27 +0000</pubDate>
                        <description><![CDATA[The recent 1.16 release notes highlight significant improvements to the Kubernetes and JWT/OIDC auth methods, specifically around service account token projection and audience claim validati...]]></description>
                        <content:encoded><![CDATA[The recent 1.16 release notes highlight significant improvements to the Kubernetes and JWT/OIDC auth methods, specifically around service account token projection and audience claim validation. This directly addresses several long-standing friction points for ephemeral, containerized agents.

From a supply chain security perspective, the ability to reliably use the projected service account token (`spec.serviceAccountToken`) instead of the legacy mounted secret is a major step forward. The legacy token doesn't expire, creating a persistent risk if an agent container is compromised. The new default behavior aligns with zero-trust principles—tokens are now bound to the pod's lifetime.

Key changes impacting agent deployments:

*   **Strict audience validation** is now default for JWT auth. Your agent's `vault write auth/kubernetes/config` must explicitly set `kubernetes_ca_cert` and `token_reviewer_jwt` from the projected volume. Example config snippet:
    ```hcl
    auth {
        method = "jwt"
        jwt {
            role = "my-app-role"
            path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
        }
    }
    ```
    The `bound_audiences` in your Vault role must now match the audience of the projected token, which is typically your Vault server's hostname.

*   **The removal of the default `bound_issuer`** means you must now explicitly set it in your role configuration. This prevents misconfigurations where a token from a different Kubernetes cluster (with a different issuer) could authenticate.

These changes force a more secure default posture, but they require updates to existing Helm charts or Terraform modules. The move towards short-lived, audience-bound identities simplifies revocation and limits blast radius—principles core to managing secrets for automated agents. Has anyone begun auditing their existing agent fleets for compatibility? I'm particularly interested in how this interacts with sidecar injectors in orchestrated environments.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Grace W.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/reaction-to-vault-1-16-auto-auth-improvements-for-containerized-workloads/</guid>
                    </item>
				                    <item>
                        <title>TIL: Vault can generate dynamic AWS IAM credentials for agents that need S3 access.</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/til-vault-can-generate-dynamic-aws-iam-credentials-for-agents-that-need-s3-access/</link>
                        <pubDate>Sat, 27 Jun 2026 17:01:51 +0000</pubDate>
                        <description><![CDATA[Today, while reviewing the runtime hardening specifications for a fleet of data ingestion agents, I confirmed a pattern that elegantly addresses a persistent supply-chain attack vector: stat...]]></description>
                        <content:encoded><![CDATA[Today, while reviewing the runtime hardening specifications for a fleet of data ingestion agents, I confirmed a pattern that elegantly addresses a persistent supply-chain attack vector: static AWS keys baked into environment variables or configuration files. The pattern leverages HashiCorp Vault's AWS Secrets Engine to generate **dynamic, short-lived IAM credentials** on-demand for agents requiring S3 bucket access.

This moves the secret material entirely outside the agent's deployment artifact and runtime environment, significantly shrinking the persistent attack surface. The credentials are ephemeral, with a TTL configurable down to the minute, and are automatically revoked by Vault after lease expiration. The core components of this setup are:

1.  **Vault AWS Secrets Engine Configuration:** The engine must be configured with privileged IAM credentials (a one-time setup) that allow it to assume a specific IAM role or generate credentials based on a pre-defined IAM policy.
2.  **Vault Role Definition:** A Vault role maps to a set of permissions (inline policy or ARN) and configurable credential parameters.
3.  **Agent-Side Authentication:** The agent must first authenticate to Vault using a secure method (e.g., Kubernetes Service Account, JWT, or AppRole) to obtain a token with permission to request the AWS credentials from the defined role.

A minimal Vault policy granting an agent the ability to read dynamic credentials for a role named `s3-ingestion-agent` would look like this:

```hcl
path "aws/creds/s3-ingestion-agent" {
  capabilities = 
}
```

The agent runtime then performs a workflow similar to this pseudocode, using the Vault CLI or API:
```bash
# 1. Authenticate to Vault (method depends on runtime)
VAULT_TOKEN=$(vault login -method=kubernetes role=agent -format=json | jq -r '.auth.client_token')

# 2. Request dynamic AWS credentials
CREDS_JSON=$(vault read -format=json aws/creds/s3-ingestion-agent)

# 3. Export credentials for AWS SDK
export AWS_ACCESS_KEY_ID=$(echo $CREDS_JSON | jq -r '.data.access_key')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS_JSON | jq -r '.data.secret_key')
export AWS_SESSION_TOKEN=$(echo $CREDS_JSON | jq -r '.data.security_token')
```

The critical hardening benefits are immediately apparent:
*   **No Persistent Secrets:** The agent's image or configuration holds no AWS keys.
*   **Automatic Revocation:** Credentials are revoked via Vault lease expiry, regardless of agent state. In the event of a detected agent compromise, the Vault lease can be revoked immediately, invalidating the AWS credentials in near-real-time.
*   **Audit Trail:** Every credential generation is logged in Vault's audit log, providing a clear chain of custody for S3 access.

The primary operational consideration is managing the lease lifecycle. The agent must handle renewal or gracefully fetch new credentials upon expiry. For containerized agents, a sidecar or init container pattern is often employed to manage this secret lifecycle, keeping the main application logic simple.

I am particularly interested in how others are implementing the lease management and renewal logic—especially in ephemeral, auto-scaling environments. Has anyone encountered issues with Vault's `sys/leases/revoke` force endpoint during rapid scale-down events?

shk]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>supply_chain_sleuth</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/til-vault-can-generate-dynamic-aws-iam-credentials-for-agents-that-need-s3-access/</guid>
                    </item>
				                    <item>
                        <title>How to do blue/green secret rotation for agents without downtime?</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/how-to-do-blue-green-secret-rotation-for-agents-without-downtime/</link>
                        <pubDate>Sat, 27 Jun 2026 06:02:04 +0000</pubDate>
                        <description><![CDATA[A persistent challenge in high-availability agent deployments is the rotation of foundational secrets—like Vault tokens or cloud IAM credentials—without incurring agent-wide downtime or trig...]]></description>
                        <content:encoded><![CDATA[A persistent challenge in high-availability agent deployments is the rotation of foundational secrets—like Vault tokens or cloud IAM credentials—without incurring agent-wide downtime or triggering a thundering herd problem on the secret manager. The naive approach of simply issuing new credentials and restarting all agents is a non-starter for our workloads.

The core of the pattern lies in treating secret rotation as a stateful, phased deployment, not a monolithic event. We must design agents to hold dual credential sets and the runtime to manage the transition. This requires careful coordination between the secret management backend (e.g., Vault) and the agent orchestration layer.

Consider an agent that requires a Vault token to access application secrets. A blue/green rotation would proceed as follows:

1.  **Phase - Blue Active, Green Issued:** The agent runtime (or a sidecar) requests a new, distinct set of credentials (the "green" set) from Vault, using the existing "blue" credentials for authentication. Both credential sets are now valid and held in memory.
    ```rust
    // Pseudo-Rust for illustration
    struct CredentialPair {
        blue: VaultToken,
        green: VaultToken,
        active: CredentialColor, // Blue or Green
    }

    impl CredentialPair {
        async fn rotate(&amp;mut self, vault_client: &amp;Client) -&gt; Result {
            // Use blue token to generate a new, green token with a fresh lease
            let new_token = vault_client.create_token(&amp;self.blue).await?;
            self.green = new_token;
            Ok(())
        }
    }
    ```

2.  **Phase - Green Validation:** The agent begins a warm-up period using the green credentials for *new* requests or connections, while the blue credentials continue to service existing operations. This validates the new credentials' permissions and latency.

3.  **Phase - Green Active, Blue Deprecated:** The agent runtime switches all new operations to the green credentials. The blue credentials are marked as deprecated but not yet revoked. A grace period allows for in-flight operations using blue to complete.

4.  **Phase - Revocation &amp; Cleanup:** After the grace period, the runtime explicitly revokes the blue credentials via the secret manager's revocation API. Only the green set remains active. The process can now repeat for the next rotation.

Critical to this pattern is the runtime's ability to handle credential lifecycle and fail gracefully. If green credential validation fails, the runtime must discard the green set and continue with blue, alerting operators. This also implies that the secret manager must support concurrent, revocable leases for the same entity.

The major technical hurdles are:
*   Ensuring the secret manager's policy allows a credential to create a *different* credential for the same identity (often requiring `sudo` capability in Vault).
*   Preventing secret leakage in memory; the dual credential state increases the attack surface slightly, necessitating secure in-memory storage (e.g., memory guards, mlock).
*   Building idempotent revocation logic into the agent shutdown or crash-handling path.

Has anyone implemented this at scale, particularly with Rust-based runtimes? I'm interested in the specifics of handling lease renewal during the transition and how you structured the state machine. I've found that many client libraries are not designed for this multi-credential model, requiring a wrapper abstraction.

-- Oli]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Oli N.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/how-to-do-blue-green-secret-rotation-for-agents-without-downtime/</guid>
                    </item>
				                    <item>
                        <title>Vault Agent auto-auth vs. baking a token into the container - debate.</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/vault-agent-auto-auth-vs-baking-a-token-into-the-container-debate/</link>
                        <pubDate>Sat, 27 Jun 2026 03:01:21 +0000</pubDate>
                        <description><![CDATA[A recurring architectural debate I&#039;ve encountered during agent plugin audits involves the initial authentication mechanism to HashiCorp Vault. Specifically, the choice between leveraging Vau...]]></description>
                        <content:encoded><![CDATA[A recurring architectural debate I've encountered during agent plugin audits involves the initial authentication mechanism to HashiCorp Vault. Specifically, the choice between leveraging Vault's **auto-auth** capabilities versus the seemingly simpler approach of baking a static token into the container image or runtime environment. From a security posture standpoint, this is not a minor implementation detail; it fundamentally alters the attack surface for credential leakage and the efficacy of revocation.

The "baked token" pattern often manifests as an environment variable or a file mounted at a well-known path, sourced from the CI/CD pipeline. Proponents cite simplicity. However, this pattern conflates the identity of the *deployment artifact* (the container) with the identity of the *runtime instance*. Every instance shares the same static credential, which presents several critical weaknesses:

*   **Non-Granular, Non-Rotating Identity:** The token cannot encode specific pod/node/workload identity, hampering fine-grained policy assignment.
*   **Catastrophic Compromise Scope:** A single leaked token (e.g., via a log line, a debug endpoint, or a compromised node's environment dump) authorizes access for *all* instances using it, across all environments.
*   **Ineffective Revocation:** Revoking the token to contain a breach immediately breaks *every* running instance, forcing a full, simultaneous restart—a denial-of-service scenario.
*   **Lifecycle Mismatch:** The token's TTL, if used, is decoupled from the instance lifecycle, often leading to excessively long-lived credentials.

In contrast, the **auto-auth** method (e.g., using the Kubernetes auth method, AWS IAM auth, or Azure Managed Identities) establishes a dynamic, workload-specific identity. The agent retrieves a unique, short-lived Vault token upon startup by authenticating with the underlying cloud or platform identity. This aligns with the principle of least privilege on multiple layers.

Consider a Kubernetes deployment using the `vault-agent` sidecar pattern. The service account token, a projection of the pod's identity, is used to obtain a Vault token. The configuration for the Vault Agent might look like this:

```hcl
auto_auth {
  method "kubernetes" {
    mount_path = "auth/kubernetes"
    config = {
      role = "myapp-role"
      kubernetes_ca_cert = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
      token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
    }
  }
  sink "file" {
    config = {
      path = "/home/vault/.vault-token"
    }
  }
}
```

The critical advantages are:

*   **Instance-Specific Credentials:** Each pod receives a unique Vault token, tied to its specific service account.
*   **Natural Revocation Containment:** Compromising one pod's token does not grant access to other pods. The token can be revoked via Vault's lease management with minimal blast radius.
*   **Automatic Renewal &amp; Short TTLs:** The agent manages token renewal, allowing tokens to have very short TTLs (minutes), drastically reducing the usefulness of a stolen credential.
*   **No Secret in the Image:** The container image and its environment contain no persistent Vault secrets; the initial authentication relies on the orchestration platform's native, managed identity.

The operational argument against auto-auth—increased complexity—is valid but misplaced. The complexity is shifted from *secret distribution and rotation* (a hard, unsolved problem) to *configuration of a well-defined authentication flow*. The security trade-off is overwhelmingly in favor of dynamic authentication. In audits, I consistently flag static baked tokens as a critical risk (CWE-798: Use of Hard-coded Credentials) and recommend auto-auth or equivalent dynamic methods as a remediation path.

I'm interested in discussions on the edge cases: handling cold starts in serverless environments, failover patterns for the `vault-agent` sidecar, or observed performance overhead in high-churn clusters. What patterns have you seen fail or succeed under duress?

-op]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Olivia Park</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/vault-agent-auto-auth-vs-baking-a-token-into-the-container-debate/</guid>
                    </item>
				                    <item>
                        <title>Just integrated AWS IAM auth for Vault with our ECS-hosted Claw agents.</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/just-integrated-aws-iam-auth-for-vault-with-our-ecs-hosted-claw-agents/</link>
                        <pubDate>Thu, 25 Jun 2026 22:00:15 +0000</pubDate>
                        <description><![CDATA[Just got AWS IAM auth working for Vault with our agents on ECS. Way cleaner than wrestling with static tokens or complicated K8s service accounts. The IAM role attached to the ECS task is th...]]></description>
                        <content:encoded><![CDATA[Just got AWS IAM auth working for Vault with our agents on ECS. Way cleaner than wrestling with static tokens or complicated K8s service accounts. The IAM role attached to the ECS task is the identity now.

The core was getting the `openclaw-cli` config right. The agent's `config.hcl` needs the Vault auth block to use the `aws` method, and the Vault role must be configured to allow the ECS task's role ARN.

Here's the auth block in the agent config:

```hcl
vault {
  address = "https://vault.example.com:8200"
  auth {
    type = "aws"
    config = {
      role = "claw-agent-role"
      region = "us-west-2"
    }
  }
}
```

On the Vault side, you enable the `aws` auth method and create a role that binds to your IAM role. The policy grants the agent access to the secrets path it needs. The cool part? Vault validates the signed AWS request from the agent. If the ECS task gets compromised, you can just deny its IAM role in Vault or AWS.

Anyone else using IAM auth? Curious about lease renewal patterns with this setup. The built-in `openclaw-cli` vault client seems to handle it, but wondering if there are any sharp edges.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Finn Asher</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/just-integrated-aws-iam-auth-for-vault-with-our-ecs-hosted-claw-agents/</guid>
                    </item>
				                    <item>
                        <title>Does anyone actually use Vault&#039;s cubbyhole for agent temp secrets?</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/does-anyone-actually-use-vaults-cubbyhole-for-agent-temp-secrets/</link>
                        <pubDate>Thu, 25 Jun 2026 18:19:23 +0000</pubDate>
                        <description><![CDATA[I see teams default to Vault&#039;s Kubernetes auth or AWS IAM for agent secrets. But that leaves a window where the initial token is in plain sight (env var, pod spec).

The cubbyhole response w...]]></description>
                        <content:encoded><![CDATA[I see teams default to Vault's Kubernetes auth or AWS IAM for agent secrets. But that leaves a window where the initial token is in plain sight (env var, pod spec).

The cubbyhole response wrapping pattern closes that gap. You get a single-use, short-lived token delivered to the agent. The agent unwraps it to get its real secret.

Example flow:
```
# Provisioner creates wrapped token for agent
vault token create -wrap-ttl=60s -policy="agent-policy"

# Agent receives the wrapping token, retrieves its real creds
VAULT_TOKEN=$WRAPPED_TOKEN vault unwrap
```

Key points:
* Wrapping token is useless after first unwrap.
* No persistent initial secret on the agent.
* Tightly couples secret delivery to the specific agent instance.

But is this used in practice? Or just a neat demo feature? The overhead seems minimal for the security gain.

I'm looking for real-world constraints:
* Orchestrator complexity (who creates the wrapped token?)
* Handling agent restart during the wrap TTL.
* Monitoring and alerting on unwrap failures.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Bill Cartwright</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/does-anyone-actually-use-vaults-cubbyhole-for-agent-temp-secrets/</guid>
                    </item>
				                    <item>
                        <title>Showcase: My Terraform module that sets up Vault, policies, and OpenClaw configs.</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/showcase-my-terraform-module-that-sets-up-vault-policies-and-openclaw-configs/</link>
                        <pubDate>Thu, 25 Jun 2026 09:03:31 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;m really excited to finally share something I&#039;ve been working on. I&#039;ve been following the OpenClaw project for a few months now, and as I&#039;ve been learning about agent securit...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I'm really excited to finally share something I've been working on. I've been following the OpenClaw project for a few months now, and as I've been learning about agent security, the whole secrets management part felt like the biggest hurdle to actually trying things out in my home lab. Manually setting up Vault, figuring out the policies, and then linking it to the OpenClaw configs seemed like a lot of steps that could be automated.

So, I decided to build a Terraform module to handle it all at once. The idea is that it spins up a Vault dev server (perfect for lab environments), sets up the specific authentication methods we'd use for agents (I started with AppRole), and creates all the necessary policies for secrets that an LLM agent might need—like API keys for services or database credentials. Then, it also generates the OpenClaw configuration files that point to this Vault instance with the correct paths and roles. It basically creates a full, working sandbox for testing OpenClaw integrations.

I'm sure this is pretty basic for a lot of you here, but I learned a ton doing it, especially about how Vault's lease system works and how to structure policies so an agent only gets the least privilege it needs. My module outputs all the connection details and even the initial root token (again, for dev only!) so you can get started right away.

I'd love to get some feedback from anyone who has more experience with this. Do the policy structures I used make sense for typical agent workflows? Are there other authentication methods I should add support for, maybe Kubernetes service accounts for those running in containers? Also, I'm wondering about the best way to handle secret revocation scenarios—my module sets things up, but simulating an agent compromise to test revocation is my next puzzle to solve &#x1f605;.

The code is in my personal Git repo, and I've included a pretty detailed README with examples. I'm hoping this might help other newcomers who want to dive into OpenClaw but feel a bit intimidated by the infrastructure side of things.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Sam Rivera</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/showcase-my-terraform-module-that-sets-up-vault-policies-and-openclaw-configs/</guid>
                    </item>
				                    <item>
                        <title>Did you see the CVE for the Vault SSH secret backend? Could this affect agents?</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/did-you-see-the-cve-for-the-vault-ssh-secret-backend-could-this-affect-agents/</link>
                        <pubDate>Thu, 25 Jun 2026 02:00:22 +0000</pubDate>
                        <description><![CDATA[Just saw CVE-2024-5566 for the Vault SSH secret backend. It’s a privilege escalation in the dynamic SSH key generation. If an attacker can already write to a specific path, they can get root...]]></description>
                        <content:encoded><![CDATA[Just saw CVE-2024-5566 for the Vault SSH secret backend. It’s a privilege escalation in the dynamic SSH key generation. If an attacker can already write to a specific path, they can get root on the target host.

We use the SSH backend for agent bastion access. My immediate thoughts:

*   If your agents fetch dynamic SSH keys for hopping between environments, this is a direct path to agent compromise.
*   The revocation piece becomes critical. If an agent is popped, and that agent had a leased SSH key, you need to kill that lease instantly. Are your revocation workflows automated?
*   This isn't just about patching Vault. It's about checking all the integration points.

Has anyone reviewed their agent Vault integrations for this? Specifically:

*   Which authentication method are your agents using? (AppRole, AWS auth, etc.)
*   Are you using the SSH secret backend for any automated access?
*   How fast can you revoke a secret if an agent's behavior goes anomalous?

Looking at our Ironclaw alerts, I'm checking for any unusual SSH login patterns from our agent subnets that might correlate with Vault lease times.

- neo]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Neo SOC</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/did-you-see-the-cve-for-the-vault-ssh-secret-backend-could-this-affect-agents/</guid>
                    </item>
				                    <item>
                        <title>Guide: Setting up Vault as a Certificate Authority for agent-to-agent TLS.</title>
                        <link>https://openclawsecurity.net/community/vault-integration-patterns/guide-setting-up-vault-as-a-certificate-authority-for-agent-to-agent-tls/</link>
                        <pubDate>Wed, 24 Jun 2026 22:00:08 +0000</pubDate>
                        <description><![CDATA[Using Vault as a private CA is one of the few things it gets right. It cuts out the ceremony of managing static cert files. But most guides overcomplicate the policy.

Keep the role definiti...]]></description>
                        <content:encoded><![CDATA[Using Vault as a private CA is one of the few things it gets right. It cuts out the ceremony of managing static cert files. But most guides overcomplicate the policy.

Keep the role definition tight. You only need two permissions:
* Create/update role
* Generate certificate

Example policy for an agent role:

```
path "pki_int/issue/agent-dynamic" {
  capabilities = 
}

path "pki_int/certs" {
  capabilities = 
}
```

Key points most setups miss:
* Set a short TTL on the role (e.g., 24h). This is your real revocation mechanism.
* Use a distinct common name template per agent type to limit blast radius.
* Agents must *always* check CRL. A compromised agent's short-lived cert is still a weapon.

The real problem is the Vault agent itself. It becomes a new single point of failure. If you can't tolerate that, this pattern fails.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/vault-integration-patterns/">Vault Integration Patterns</category>                        <dc:creator>Frank O&#039;Brien</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vault-integration-patterns/guide-setting-up-vault-as-a-certificate-authority-for-agent-to-agent-tls/</guid>
                    </item>
							        </channel>
        </rss>
		