Secrets Management: New Series

By Adrian Lane

This week we are starting a new research series on Secrets Management. What is secrets management and why do you care? A good number of you in security will be asking these questions. Secrets Management platforms do exactly what the name implies; they store, manage and provide secrets. This technology addresses several problems most security folks don’t yet know they have. As development teams leverage automation and orchestration techniques, they are creating new security issues to be tackled. Let’s jump into some of the back story, and then outline what we will accomplish in this research effort.

It sounds cliche, sure, but IT and application environments are genuinely undergoing radical change. New ways of deploying applications as microservices or into containers is improving our ability to cost-effectively scale services and large systems. Software defined IT stacks and granular control over services through API provide tremendous advantages in agility. Modern operational models such as Continuous Integration and DevOps amplify these advantages, bringing applications and infrastructure to market faster and more reliably.

Perhaps the largest change currently affecting software development and IT is cloud computing: on-demand and elastic services offers huge advantages, but predicated on automated infrastructure defined as software. While cloud is not a necessary component to these other advancements, it’s makes them all the more powerful. Leveraging all these advancements together, a few lines of code can launch – or shut down – an entire (virtual) data center in minutes, with minimal human involvement or effort.

Alongside their benefits, automation and orchestration raise new security concerns. The major issue today is secure sharing of secret information. Development teams need to share data, configurations, and access keys across teams to cooperate on application development and testing. Automated build servers need access to source code control, API gateways, and user roles to accomplish their tasks. Servers need access to encrypted disks, applications need to access databases, and containers must be provisioned with privileges as they start up. Automated services cannot wait around for users to type in passwords or provide credentials! So we need new agile and automated techniques to provision data, identity, and access rights.

Obtaining these secrets is essential for automation scripts to function, but many organizations cling to the classic (simple) mode of operation: place secrets in files, or embed them into scripts, so tasks can complete without human intervention. Developers understand this is problematic, but it’s a technical problem most sweep under the rug. And they certainly do not go out of their way to tell security about how they provision secrets, so most CISOs and security architects are unaware of this emerging security issue.

This problem is not new. No administrator wants to be called into work in the middle of the night to enter a password so an application can restart. So IT administrators routinely store encryption keys in files so an OS or application can access them when needed. Database administrators place encryption keys and passwords in files to facilitate automated reboots. Or they did until corporate networks came under even more attack; then we saw a shift to keys, certificates, and passwords. Since then we have relied upon everything from manual intervention, key management servers, and even hardware dongles to provide a root of trust to establish identity and provision systems. But those models not only break the automation we rely upon to reduce costs and speed up deployments, lack also the programmatic interfaces needed to integrate with cloud services.

To address the changes described above, new utilities and platforms have been created to rapidly provide information across groups and applications. The term for this new class of product is “Secrets Management”; it is changing how we deliver identity, secrets, and tokens; as well as changing the way we validate systems for automated establishment of trust. In this research we will explore why this is an issue for many organizations, what sort of problems these new platforms tackle, and how they work in these newer environments. Specifically, we will cover:

  • Use Cases: We will start by considering specific problems which make secret sharing so difficult: such as moving passwords in clear text, providing keys to encryption engines, secure disk storage, knowing which processes are trustworthy, and mutual (bidirectional) authentication. Then we will discus specific use cases driving secrets management. We will cover issues such as provisioning containers and servers, software build environments, database access, and encrypted disk & file stores; we will continue to examine sharing secrets across groups and controlling who can launch which resources in private and public cloud environments.
  • Components and Features: This section will discuss the core features of a secrets management platform. We will discuss the vault/repository concept, the use of ephemeral non-vault systems, identity management for vault access, role-based authorization, network security, and replication for both resiliency and remote access. We will cover common interfaces such as CLI, API, and HTTP. We’ll contrast open source personal productivity tools with newer commercial products; we will also consider advanced features such as administration, logging, identity store integration, ability to provide secure connections, and policy enforcement.
  • Deployment Considerations: Next we will discuss what is stored in a repository, and how secrets are shared or integrated with dependent services or applications. We will discuss both deployment models; as well as the secrets to be shared: passwords, encryption keys, access tokens, API keys, identity certificates, IoT key pairs, secure configuration data, and even text files. We will also offer some advice on product selection criteria and what to look for.

As we leverage cloud services and rely more heavily on automation to provision applications and IT resources, we find more and more need to get secrets to applications and scripts securely. So our next post will start with use cases driving this market.

No Related Posts

This is certainly not a “NEW” problem and has been there since decades. I agreed that, with the new Dev/Ops and “on-demand”, “one-click” software delivery will end-up creating the islands of the secrets/passwords/tokens (whatever you call it).
I hope these secrets are not stored in an excel sheet which is protected with another secret..
It is same as centralizing the cryptographic keys and avoiding the silos of encryption keys.

Great Article Adrian Lane!!

By Ajay Chauhan

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.