DevOps Secrets Vault and Dynamic Secrets in the Cloud

This article is based on content originally published by Thycotic on Security Boulevard. Product details reflect the state of Thycotic DevOps Secrets Vault as of early 2020.

The Problem with Static Credentials in DevOps Pipelines

Modern DevOps pipelines rely on dozens of interconnected tools — Jenkins, Terraform, Ansible, Chef, Puppet, Kubernetes — each requiring credentials to authenticate to infrastructure and services. The traditional approach of hardcoding passwords or storing them in disparate, tool-specific vaults creates serious security and operational risks.

A centralized secrets vault solves the sprawl problem by replacing hardcoded credentials with a single API call to an encrypted, access-controlled, audited location. Tools request a secret when they need it and use it only for their specific task. However, even this model carries residual risk: what if the tool itself leaks the secret through improper memory storage, logging, or a misconfigured plugin?

This is the problem dynamic secrets are designed to solve.

What Are Dynamic Secrets?

Dynamic secrets — also called dynamic passwords or ephemeral secrets — are credentials that are generated on demand and automatically expire after a defined time-to-live (TTL). Unlike static secrets, they do not exist until a tool requests them, and they become worthless as soon as their TTL elapses.

Key properties of dynamic secrets:

• Created on demand: A new credential is generated each time a tool authenticates and requests access.
• Short-lived: The TTL is configured in advance; the secret expires automatically without manual rotation or revocation.
• Scoped by policy: Each dynamic secret is tied to a cloud IAM policy that limits what the credential can actually do — for example, only launching an EC2 instance, or only deploying code.
• Low attacker value: Even if a dynamic secret is intercepted or leaked, it is usable only within a narrow authorization scope and for a short window of time.

How Dynamic Secrets Work: An Ansible and AWS Example

The following walkthrough illustrates dynamic secrets in a real DevOps workflow involving Ansible, AWS, and a centralized secrets vault.

Pre-Configuration

Before any automation runs, an administrator configures the secrets vault with two items:

1. A base secret — a long-lived credential that gives the vault itself the authority to request new credentials from AWS on behalf of callers.
2. A dynamic secret definition — a template that specifies an AWS IAM policy (for example, ec2:RunInstances only) and a TTL. At this stage, no actual secret values exist.

Runtime Flow

1. Ansible needs to build an EC2 instance. It authenticates to the secrets vault.
2. The vault receives the request, calls AWS using its base secret, and asks AWS to issue a new ephemeral credential scoped to the pre-defined IAM policy.
3. AWS generates the ephemeral credential and returns it to the vault.
4. The vault passes the ephemeral credential to Ansible.
5. Ansible uses the credential to create the EC2 instance.
6. The TTL expires. The credential is automatically invalid — no rotation job or manual revocation required.

Fine-Grained Scoping Across Tasks

The same base secret can back multiple dynamic secret definitions, each with a different policy and TTL. For example:

• Dynamic secret A — policy: ec2:RunInstances, TTL: 10 minutes. Used by Ansible to build the server.
• Dynamic secret B — policy: deploy code, TTL: 5 minutes. Used by Ansible to push an application to the server it just built.

Breaking a pipeline into discrete secrets with narrow scopes means that compromising one secret gives an attacker only a tiny, time-limited capability — not broad access to the environment.

Cross-Account Access in AWS

Dynamic secrets also support cross-account access patterns. An administrator in a production AWS account can configure an IAM role with appropriate policies and link it to a developer’s account. When the developer’s automation requests the dynamic secret, the vault generates a credential scoped to the production account via that role — without permanently granting the developer account production access.

Why Dynamic Secrets Matter for Cloud Security

Infrastructure-as-a-service platforms — AWS, Microsoft Azure, and Google Cloud Platform — are high-value targets. Stolen or leaked cloud credentials can cause disruptions ranging from service outages to catastrophic data loss. DevOps tools introduce multiple potential leak vectors:

• Secrets written to disk or held in memory longer than necessary
• Secrets captured by logging systems (stdout, debug logs, CI/CD job logs)
• Secrets exposed through plugin vulnerabilities or misconfigurations
• Open-source library dependencies with unknown security posture

Because dynamic secrets are short-lived and narrowly scoped, they significantly reduce the blast radius of any single leak. An attacker who captures an ephemeral credential gains little: the credential expires quickly and cannot be used for actions beyond what the IAM policy permits.

Authentication Methods for a Cloud-Native Secrets Vault

A DevOps secrets vault deployed in the cloud should support the native identity mechanisms of each cloud platform so that tools and services can authenticate without requiring a separate static credential. Thycotic DevOps Secrets Vault, as described in the original source, supported authentication via:

• AWS IAM — authenticate using AWS instance roles or IAM credentials
• Microsoft Azure — authenticate using Azure managed identities
• Google Cloud Platform — authenticate via GCP service accounts, user accounts, Google Compute Engine (GCE) instance metadata, or Google Kubernetes Engine (GKE) service accounts
• Thycotic One — single sign-on with two-factor authentication via TOTP or SMS

Integrations, SDKs, and Certificate Issuance

For a secrets vault to be genuinely useful in a DevOps environment, it must integrate natively with the tools teams already use. As of early 2020, Thycotic DevOps Secrets Vault included integrations and SDKs for:

• CI/CD and orchestration: Jenkins, Kubernetes, Terraform, Ansible
• Configuration management: Chef, Puppet
• SDKs: Java, Go, Python, .NET, Ruby

The vault also supported X.509 certificate issuance. Once a customer’s root or intermediate certificate authority was imported into the vault, the vault could issue signed leaf certificates on demand — extending the same secrets-management model to PKI.

Key Takeaways

• Centralizing secrets management behind a single API-driven vault eliminates hardcoded credentials and credential sprawl across DevOps tools.
• Dynamic secrets add a second layer of protection: credentials that do not exist until needed and expire automatically reduce the value of any leak to near zero.
• Scoping dynamic secrets to narrow IAM policies per pipeline task limits the blast radius of a compromise.
• Cloud-native authentication (AWS IAM, Azure managed identity, GCP service accounts, GKE) removes the need for a separate static credential just to authenticate to the vault itself.
• SDK and integration coverage for common DevOps tools is essential for adoption — secrets management only works if every tool in the pipeline uses it.