Protect: Secrets Management

This blog post deals with the topic of Secrets Management. It is intended to serve as a brief introduction to the topic and describe the core features and benefits of Secrets Management.

But, first of all, we should perhaps start with the definition of the term “Secret”. What is a secret anyway? The Cambridge Dictionary defines a secret as:

a piece of information that is only known by one person or a few people and should not be told to others

So a piece of information that is only known to one person or a small group of people and that should not be passed on. This is the definition of the word secret as a whole, but it can still be very well applied directly to the IT industry.

Secrets are usually information such as cryptographic keys, passwords or configuration files that are necessary for the operation of applications. All these examples have one thing in common: their loss or theft can have serious consequences for a company. In the best case, in the event of a loss, the affected applications must be equipped with new secrets, in the worst case, a cyber attack follows, resulting in high penalties, damage to reputation and insolvency.

Now that we have clarified what a secret is, we should look at how secrets are used in practice. In modern companies, applications are constantly being further developed and automatically rolled out via Continuous Integration (CI) and Continuous Deployment (CD) processes. In both cases, this means that the software and the tools in the background have access to the secrets of the respective application. For example, if an application requires access to a database for a complete deployment, then this access data must find its way into the configuration of the application.

In the past, the necessary access data was often stored directly in version control, without any control over who could ultimately access it, in plain text and statically. Fortunately, this practice is largely a thing of the past, but the developers of CI/CD software recognized the need and implemented ways to store secrets in the respective tools.

Until a few years ago, the number of secrets in software was manageable. Encryption of http web traffic using Transport Layer Security, for example, has only really been the prevailing standard for a few years. However, due to the rapidly increasing need for security in recent years, the limitations of these implementations are now becoming apparent. Storing secrets in CI/CD tools often leads to a wide variety of configurations being distributed across numerous servers, especially when working with different acceptance and test systems. There is also a lack of a common standard and central management to change lost secrets if necessary.

This is where Secrets Management comes into play. Secrets Management describes a category of software, as well as a practice of handling sensitive data. Instead of storing secrets directly in the systems that consume them, as has been the case up to now, a centralized approach is chosen. A platform to manage all secrets in a collected manner. With uniform interfaces for all consumers. The advantages are manifold. If all secret consumers obtain secrets from one and the same source, then this means that changes only have to be carried out once. Where in the past the same password for a deployment server was distributed across three different tools, there is now only a reference to the Secrets Management platform on these tools. Where in the past TLS certificates had to be provided via an often self-developed solution, there is now a central, open interface via which this is clearly controlled and undeniably recorded.

But Secrets Management can do more than just store sensitive data centrally.

Modern Secrets Management solutions offer interface integrations for databases, cloud or identity providers to dynamically generate access as required. This means that an application that needs to access a database is no longer statically rolled out with the same password, but receives a new password each time – an enormous security gain.

Likewise, temporary access can be generated in supported clouds for deployments, which can prevent hackers from stealing access data that is actually intended for deployments in order to then cause high cloud costs for affected companies.

The advantages of Secrets Management are therefore great as described, but now the question arises, is it not a risk to have all secrets in one place? What happens if I get hacked after all?

A legitimate question, no piece of software is perfect and security in the IT industry only works via a so-called “Defense-in-Depth” approach. Defense in Depth means combining several security mechanisms to cover the widest possible range of security requirements. If the same secret is distributed across three systems, it is only as secure as the weakest system. While Secrets Management platforms have exactly one task and are rigorously tested, CI/CD systems often take on several tasks at once (including Secrets Management) in order to cover the widest possible range of applications. Unfortunately, the past has shown that security is often not the highest priority here.

The current frontrunner in the field of Secrets Management is HashiCorp Vault, which is therefore also the clear recommendation of FullStackS. Vault combines all the features mentioned above: Secure software, a variety of interface integrations, both in Vault itself and on external platforms, as well as a high degree of automation through tools such as Terraform.

In addition, Vault is able to support even large multi-cloud architectures and cloud-native systems by, for example, synchronizing Vault Secrets into the respective native hyper-scaler key and secrets management systems. So all in all a complete package, which has established itself as an industry and sector standard in the field of Secrets Management.