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, perhaps we should start with the definition of the term “secret”. What exactly is a secret? 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 - or secret - as a whole, but it can still be easily applied directly to the IT industry.
Secrets are usually information such as cryptographic keys, passwords or configuration files that are necessary to operate applications. All of 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 have to be equipped with new secrets; in the worst case, a cyber attack follows, followed by high fines, damage to the company's image and bankruptcy.
Now that we've clarified what a secret is, let's look at how secrets are used in practice. In modern companies, applications are constantly being further developed and rolled out automatically via Continuous Integration (CI) and Continuous Deployment (CD) processes. In both cases, this requires that the software tools have access to the secrets of the respective application in the background. For example, if an application requires access to a database for a complete deployment, then these access data must find their way into the application's configuration.
In the past, the necessary access data was often stored directly in version control, without any control over who could ultimately access it, readable in plain text and static. Fortunately, this practice is largely a thing of the past, but the developers of CI/CD software recognized the need and implemented options for storing 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 has only really been the prevailing standard for a few years. However, as the need for security has increased rapidly in recent years, the limitations of these implementations are now becoming apparent. Storing secrets in CI/CD tools often results in a wide variety of configurations being distributed across dozens of servers, especially when working with different acceptance and test systems. A common standard is missing, as is a central administration 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 dealing with sensitive data. Instead of storing secrets directly in the systems that consume them, as was previously the case, a centralized approach is chosen. A platform to manage all secrets collectively. With uniform interfaces for all consumers. The advantages are manifold. If all Secret consumers obtain Secrets from the same place, then this means that changes only have to be made once. Where in the past the same password for a deployment server was spread across three different tools, these tools now only contain a reference to the Secrets Management Platform. Where in the past TLS certificates had to be provided via a solution, often self-developed, there is now a central, open interface through which this is clearly controlled and indisputably 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 in order to dynamically generate access as required. This means that an application that needs to access a database is no longer rolled out statically with the same password, but gets a new password every time - an enormous security gain.
In the same way, temporary access can be generated in supported clouds for deployments, so that hackers can be prevented from stealing access data that is actually intended for deployments and then incurring high cloud costs for affected companies.
As described, the advantages of secrets management are great , but now the question arises: isn't it a risk to have all secrets in one place? What happens if I get hacked?
A legitimate question, no piece of software is perfect and security in the IT industry only works through a so-called “defense-in-depth” approach . Defense in Depth means combining multiple security mechanisms to cover the widest possible range of security requirements. If the same secret is spread 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 (e.g. secrets management) in order to cover the widest possible range of uses. Unfortunately, the past has shown that security is often not the highest priority here.
The current leader in the area of secrets management is HashiCorp Vault , which is also the clear recommendation of FullStackS. Vault combines all of 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, for example by synchronizing Vault Secrets into the native Hyper-Scaler key and secrets management systems. So an all-round complete package that has established itself as an industry standard in the area of secrets management.