Posted by Oded Hareven
January 5, 2021
Available solutions for secrets and keys management mostly fail in hybrid and multi-cloud environments. That should, and can, be changed.
DevOps teams are moving their secrets and keys from on-prem to the cloud and at very high rates. It makes sense; everything else is being moved to a cloud environment. Cloud service providers, chiefly AWS, Azure and GCP, offer their own secrets management solutions, and many organizations are forced to opt-in for this because they have no other better solution and because again, it makes sense – what can be safer than a provider’s own native solution?
But with hybrid cloud architecture, most DevOps teams find themselves dealing with multiple environments and thousands of containers and microservices. Since many more machine-to-machine components need to communicate with one another, and since these components require access management by administrators, a significantly higher number of secrets is accumulating. Especially since the scale has tipped – more and more machines – secrets and keys have become a serious operational burden and a security vulnerability that should be addressed.
What Are Secrets and How They Are Used
Secrets are data items of authentication and authorization, such as passwords, API Tokens, TLS Certificates, SSH Keys, Encryption Keys, Signing Keys, and others. Both machines and humans use secrets to authenticate and communicate.
Managing and protecting the increasing amount of secrets has become a glaring pain point. The reason for that lies in the sprawling nature that secrets are placed for ‘safekeeping’; in code, scripts, various infrastructures, and development stages, thus posing a real risk if mismanaged and unprotected.
There’s more: Secrets kept in cloud platforms that perform CI/CD are required, by their nature, to manage other machines and need to store secrets to allow access. And, more often than not, signing keys (used for sealing code and software updates) are kept in a non-secure location, such as the programmer’s station or build servers.
Note that most of the ‘safekeeping’ places mentioned above are actually not secure in any way. And as a wide range of secret types is placed in multiple cloud infrastructures, private and public, the threat intensifies.
How Secrets Management is Managed Today
Basically, secrets are managed in two ways – either using a self-deployed solution, on-prem or in the cloud, or using the cloud provider’s in-house solution. Both pose their own operational challenges and security risks.
Deploying a secrets management solution is a rigorous and costly effort for any organization. It might be a suitable solution for new or smaller-scale companies that operate in a single, narrow environment, but it gets immediately more complex to manage and maintain when organizations reach their second environment, either on the cloud or a hybrid one, not to mention across various geographical locations; troubles begin with replications and synchronizations.
A very special skill set is required to support a complex environment, especially when the aim is to provide a comprehensive solution for all the various secret types, of machines and humans since it requires operating various products. Also, unique knowledge is needed for the fast implementation, deployment and maintenance of such a complex architecture that might include a credentials valuation solution that supports multiple connectors for many types of platforms, such as SSH and privileged access control, PKI certificates automation solution and encryption keys’ management platform.
The other available way to deal with secrets management today is to go with the cloud service provider’s own in-house solution. Before getting into the operational limitations and challenges that a CSP solution poses, the Closed Garden issue should be addressed. Cloud provides, quite intentionally, offers excellent services and support for their own infrastructure but fails to offer adequate solutions for cross-cloud operations; AWS’s secrets management solution would prove problematic working across Azure or even on-prem.
For a small-to-medium, cloud-born company that works with a single cloud provider in a single region and conducts all its operations in that cloud, this would be a reasonable solution. Moving on to the vast majority of companies and larger organizations that operate in multi-cloud and/or multi-region and/or hybrid environments, these aren’t fully supported by individual cloud providers. On top of that, not all services and features of the mega cloud providers are supported in every region. A patchwork of workarounds and compromises are needed to be put in place in order to continue using a CSP secrets management solution in non-native environments.
Above all, when using a CSP-native secrets management solution, organizations are compromising their security in one significant way – cloud providers have access to their secrets. This security flaw is often overlooked but shouldn’t be. This is not to say that Amazon or Microsoft are plotting to steal your secrets, but rather that your organization’s most sensitive data is exposed to insider threats and malicious attacks through an additional entry point. More than that, according to cloud providers’ declared Shared Responsibility Model, they are responsible for infrastructure security while you, the user, are required to take measures to secure your own data stored on the cloud, including your secrets and encryption keys.
The Ideal Solution for Secrets Management
An ideal secrets management solution would be one that solves all the faults of self-deployed solutions and cloud providers’ native solutions.
A solution that can manage any secret in any environment and allows for dynamic scaling. It should be a single solution that centralizes the decentralized business of managing secrets and keys. It should work, seamlessly and simply, in multi-cloud and hybrid environments and be able to handle endless infrastructures of semi services and containers, no matter in what architecture they are sprawled, all while supporting every use case to unify all secrets and keys management components, used by either machines or humans.
Additionally, it should provide Zero-Trust Encryption to the organization; for managing its most sensitive data, nothing less should be acceptable. What is the most sensitive data? Encryption keys, so it is essential to ensure that no one but you has visibility or access to them.
Is it at all possible to achieve Zero-Trust Encryption when it comes to encryption keys? In order to achieve Zero-Trust Encryption when keeping your keys at a third-party vendor (and maintain complete ownership over them), a solution is required where the provider is unable to see or access the keys cryptographically.
Fragmented keys are a common practice. A key isn’t kept in a single location but broken to pieces, making it more difficult to obtain the entire key. But, at the moment of encryption, or decryption, the key is assembled in order to lock or unlock. And at that moment, the key in its entirety is visible and accessible to malicious attacks by proxy of the cloud provider.
Zero-Trust Encryption in secrets and keys management seems to be unattainable and indeed it was, until now. A new technology, DFC – Distributed Fragments Cryptography – by Akeyless, is enabling the use of fragmented encryption keys without ever needing to assemble them. More than that, DFC places key fragments in various locations, constantly refreshed mathematically and lets the user keep one fragment of the key in his own environment. True Zero-Trust Encryption is achieved – the Encryption Key never exists as a whole AND even Akeyless, the service provider, can’t see or access the key as a whole.
Akeyless Secrets Management Platform is the Solution
Simply put, Akeyless answers all these needs as it:
- Provides a unified, centralized solution that supports all types of secrets: encryption keys, API-keys, tokens, passwords (SQL, LDAP), SSH keys, x.509 certificates, signing Keys
- Seamlessly supports any configuration, in both hybrid and multi-cloud environments in all regions
- Ensures exclusive ownership of organizations over their security by denying its own access to their secrets and keys.
- Requires no installation and enables deployment within minutes
- Plugs into every common cloud platform such as Kubernetes, Docker, Jenkins, Terraform, Ansible, and others
- Offers flexible pay-per-use pricing which makes it completely scalable and affordable
- Uses patented, Zero-Trust Encryption DFCTM – Distributed Fragments Cryptography – which enables unique protection to any secret, giving only its owner the exclusive ability to access, encrypt and decrypt it
- Is FIPS 140-2 certified, recognized worldwide as one of the highest standards for cryptography validation
Akeyless offers a singular solution to a growing problem – managing secrets and keys across hybrid and multi-cloud environments, solving the challenge of keeping track and rotating passwords for developers and DevOps.
With Akeyless, organizations finally need not compromise on scalability nor security when moving to multi-cloud or hybrid environments.
DevOps SecurityThe Akeyless gateway serves as protection between your private network and the cloud. Equipped with caching and zero-knowledge encryption capabilities, the Akeyless gateway is the powerhouse of the Akeyless SaaS platform.
Using GitHub Securely: Best Practices & What to Watch Out ForDevelopers on public GitHub leak over 5,000 API keys or credentials every day. Learn best practices to avoid credential breaches on GitHub.
What’s in a Secret? Best Practices for Static, Rotated and Dynamic SecretsSecrets are ranked as the leading cause of data breaches. Combat this by learning how to best use static, rotated, and dynamic secrets.