Here is the fourth blog of #securityweek. This time it's from Hashicorp's Kevin Fishner. Enjoy!
The growing popularity of microservices, datacenter automation, containers, and dynamic cloud environments has made it difficult for security teams to organize, distribute, and secure secrets. These trends increase the number of secrets required to connect services and as a result expand the surface area for an attack, both in terms of potential infiltration points and internal damage in the event of a compromise. The dynamic nature of microservices and cloud environments forces key storage and distribution into the center of these systems, as the frequently moving services require secrets to communicate with each other. This set of problems is often referred to as “secret sprawl”.
Vault was built to solve the secret sprawl problem in a user-friendly and auditable way. Just as immutable infrastructure gives operations certainty in server configurations and eliminates drift, Vault gives security certainty in when, where, and how secrets are being used across a system. It is the central source of security truth for modern architectures.
Specific goals and features of Vault include:
- Reduce the period of time an attacker has to infiltrate the infrastructure in the event of a security breach.
This is accomplished with Vault’s dynamic secrets and leasing features. Dynamic secrets enables Vault to generate secrets on-demand for supported backend systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up. Thus, even if the system is breached, the attacker only has a short window of opportunity before the secret gets re-generated and access is revoked.
- Limit the internal surface area of a breach to a single application instance.
Fine-grained ACLs lets Vault grants specific, limited communication permissions for each secret. If a secret is compromised, it only provides access to a single service and not the entire infrastructure. In many existing security managers, obtaining one key will let an attacker have free reign throughout the system.
- Generate an audit trail of service communication
Each time a secret is generated it creates an audit log which can be used to determine the specific compromised resource in the datacenter. For example, if an application that does not have access to a database attempts to make a connection, it is clear that there has been a compromise. The audit log can be used by operators and security teams to pinpoint tainted servers and take the proper steps to restore the security of the system as a whole. It is important to note that secrets are generated after the log is stored, meaning that all access actions are guaranteed to be logged. If for some reason the log cannot be written, the secret will not be generated.
- Simplify security for large operations and infrastructures
Often the biggest hurdle to proper security is the complexity of the implementing the security solution. With simple installation and setup, Vault lowers the barrier to entry for organizations to use responsible secret management to secure their distributed infrastructure. Secrets can be written from the command line or the complete HTTP API.
Additional features of Vault for deploying in large-scale infrastructures:
- In-transit data encryption
Vault can encrypt and decrypt data without storing it. Security teams can define encryption parameters and store encrypted data in a location such as a SQL database without having to design a custom encryption method. You can read more about how HashiCorp’s Atlas uses Vault to encrypt GitHub OAuth tokens.
- High-availability
High-availability is a requirement for large-scale infrastructures to protect against service outages. Vault can run in multi-server mode when using a backend that supports it, such as Consul or etcd.
- Authentication methods
Vault includes multiple methods for authentication so organizations can select the option that fits best with their setup. Vault currently supports tokens, username/password, GitHub, certificates, and more.
Comparison to Other Secret Managers
In the current state of the world secrets are often manually updated in service configurations, distributed with configuration management, or managed with a custom solution. These options often have a massive attack surface, have no method for auditing secret usage across a distributed system, have no revocation procedure, or even store secrets in plaintext. You can learn more about how Vault compares to specific solutions on the project’s website.
Conclusion: Security as a First-Class Citizen in Distributed Systems
It is an unfortunate truth that security is often an afterthought in designing an architecture. Custom solutions require expertise within a company and large resource commitments. Existing commercial offerings are often expensive or difficult to implement. Both options result in security taking a backseat to just getting the system running.
With Vault, the design is dogmatically user-friendly to ensure that security is no longer an afterthought, but instead a first-class citizen. Vault simplifies secret management with a set of powerful, flexible features to build security into every modern enterprise architecture.
Previous article
