DevOps Secrets Vault and Dynamic Secrets in the Cloud

Source:-securityboulevard.com

Back in July of 2019, Thycotic released DevOps Secrets Vault, a high-velocity vault for high-speed password and secret creation, archiving, and retrieval. Each month we roll out improvements to this cloud-based tool. In 2020, we’ve been focused on adding dynamic secrets for key cloud platforms.

The foundational idea behind a vault specifically for DevOps tools is to replace hardcoded credentials, passwords and multiple disparate vaults with an API call to a centralized location where secrets are encrypted, access is controlled, and auditing provided. Of course, the DevOps tools only use the secrets to do what they need to, but can you trust them not to leak the secrets themselves? For infrastructure-as-a-service (IaaS) platforms, such as Amazon Web Services (AWS), Microsoft Azure (Azure) and Google Cloud Platform (GCP), dynamic secrets in DevOps Secrets Vault offer another layer of security.

Whether some or all your infrastructure is in the cloud, the impact of lost or stolen passwords or secrets could range from temporary disruptions to critical data loss. DevOps tools from Jenkins to Terraform to Ansible all have open-source and commercial pieces to them, numerous plug-ins to other tools, and library dependencies. All of this makes them very powerful, but along the way, there could be vulnerabilities or misconfigurations that leak secrets. This can happen when secrets are improperly stored in memory or on disk, sent to logging systems, or leaked to other tools or processes.

Dynamic secrets (aka dynamic passwords or ephemeral secrets) eliminate the problem with these potential leaks because they are created only when needed and then expire. When the DevOps tool needs to perform its function and accesses the secret, a new one is generated. Dynamic secrets also enable fine-grained authorization through cloud policies. Limiting the authorization scope and timeframe greatly reduces and even eliminates any value of the secret to an attacker.

Here is an illustration for how dynamic secrets work in an environment with Ansible, AWS, and DevOps Secrets Vault:

DevOps Dynamic Secrets Diagram

Let’s say it’s time for Ansible to build a server in AWS. DevOps Secrets Vault is pre-configured with a base secret that gives it access to AWS. A dynamic secret is also pre-configured with an AWS policy, that only allows the creation of an EC2 and a time-to-live (TTL) for the secret. However, the dynamic secret has no actual secret values to start with. When Ansible requests access to AWS to build an EC2, it authenticates to DevOps Secrets Vault and reads the dynamic secret.

At that time, DevOps Secrets Vault requests a new secret from AWS that enables only the authorization set in the policy and expires when the TTL has run out. That ephemeral secret is passed to Ansible. Ansible accesses AWS and builds the EC2. The dynamic secret does not have to be rotated or revoked because it will simply expire on its own.

The next step for Ansible could be to deploy code to the EC2 it just built. Another dynamic secret could be pre-configured in DevOps Secrets Vault and connected to the same base secret. This dynamic secret would have a policy “deploy code” and potentially different TTL. Breaking the processes in Ansible down and assigning different dynamic secrets further decreases the value of any given secret to an attacker.

We can take this a step further to enable cross-account access in AWS. If a developer needs to get access to the production account, which is normally not allowed, the admin in the production environment can set up a role (that in-turn has policies connected to it) and connect that role to the developer’s account. The process is the same as the example above, but now when the dynamic secret is read, the developer’s account gets the secrets from the production account.

Devops Diagram
Other DevOps Secrets Vault New Features

With each monthly DevOps Secrets Vault release, we add exciting new functionality to this powerful cloud DevOps tool. In addition to dynamic secrets, DevOps Secrets Vault now offers new authentication mechanisms, new integrations and software development kits (SDKs), and the ability to issue certificates.

Users can authenticate to DevOps Secrets Vault through AWS, Azure, GCP, and Thycotic One methods. GCP support includes the ability to authenticate via service and user accounts. Additionally, Google Compute Engines (GCE) metadata and Google Kubernetes Engines (GKE) can authenticate to DevOps Secrets Vault. Thycotic One enables single sign-on and two-factor authentication via both TOTP and SMS methods.

It’s important to have a centralized DevOps vault for the management of passwords and secrets

With the complexity and variety of tools within DevOps pipelines, it’s important to have a centralized vault that centralizes management of passwords and secrets to maintain security, unify privileged access management, and control costs. DevOps Secrets Vault now supports secrets access for Chef and Puppet and includes SDKs for .NET and Ruby. DevOps Secrets Vault also integrates with Jenkins, Kubernetes, Terraform, and Ansible, and includes SDKs for Java, Go, and Python.

DevOps Secrets Vault also supports certificate issuance. Once a customer root or intermediate certificate is imported into DevOps Secrets Vault, it can then issue signed X.509 leaf-certificates.