Cloud Service Providers (CSPs) such as Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP) have enabled the widespread move of organizations to the cloud. 

Using workloads in the cloud accelerates an organization’s key initiatives such as mobility, collaboration tools, scale-out apps, and business continuity.

These workloads need to communicate with other workloads, or (micro)services, and they use credentials, certificates, and keys—collectively known as secrets—to verify their identity and ensure secure communication channels. The surge of containerization and automation has created an urgent need to securely store and manage the use of such secrets.  

Secrets Management solutions orchestrate the secrets for human and machine identities that need them to connect to apps and services. They also manage a secret’s entire lifecycle: creating and securely storing secrets, but also ensuring that secrets are rotated frequently in order to comply with security policies and regulations. Finally, secrets need to be revoked when they are no longer necessary. 

When your DevOps teams run workloads on a cloud platform, it seemingly makes sense to use the included vault solution to secure and manage workload secrets. 

However, these cloud platform secret vaults come with significant limitations that should not be ignored. 

Walled Garden Isolation

While some organizations or individual teams may have locked into a single CSP for their automation projects, it is often a matter of time before they need to adopt other cloud and on-prem platforms, for example, to reduce dependency, increase redundancy, or scale efficiently. Often, organizations are forced to adopt other platforms through Mergers and Acquisitions (M&A). Therefore, growing organizations are likely to use at least some on-premise services, and have other cloud services as well—a hybrid multicloud environment. 

However, Cloud Vaults are largely proprietary and focus on supporting workloads that run within their own environment. This complicates workflows that involve on-premises workloads, or workflows on other platforms. In addition, cloud vaults provide poor connectivity to third-party platforms, such as self-deployed CI/CD tools, non-managed Kubernetes clusters, and similar workload elements.  

 Regardless of how many platforms an organization uses, there are multiple reasons why these limitations are detrimental to mission-critical systems.

• Keeping secrets locked inside a single cloud platform limits your agility, and ability to collaborate across platforms. This can create tremendous problems for DevOps teams who need to quickly develop applications that use multiple secrets on a minute-to-minute basis, with the ability to quickly inject secrets as needed. 
• Organizations are increasingly looking to create cross-cloud solutions and pursue a well-architected framework approach to balance aspects like reliability, performance, security, and cost optimization. This becomes impossible to do securely if operations are tied to a single cloud platform where secrets can be kept. 
• From a CISO perspective, storing secrets across on-premises and multiple clouds creates a solution sprawl that complicates visibility, increases the attack surface, and slows down the auditing process. 

Not Your Keys, Not Your Secrets

Storing secrets securely requires strong cryptography, but this encryption process creates another master key that must be kept safe. 

Typically, cloud vaults require their customers to relinquish their master encryption keys, giving up ownership and providing complete data access to the cloud provider. This makes the organization vulnerable, particularly to government mandates such as the CLOUD act, which compels CSPs to turn over both keys and data to the government if requested.

The Risk of Standing Permissions

The longer a secret is valid, the bigger the window is for an attacker to abuse a compromised secret. To minimize this risk, and to comply with various regulations,  secrets must be rotated frequently. These rotations must be automated to ensure this actually happens and to minimize complications in the auditing process. As an extra step,  as organizations seek to improve their security posture, they can create Just-In-Time (JIT) Access mechanisms that use dynamic secrets, which are created on-demand and expire and are revoked automatically. This destroys an attacker’s window of opportunity and reduces the risk of a successful attack. 

Unfortunately, cloud vaults do not provide either rotation or the ability to create dynamic JIT secrets.  Rotating secrets and creating dynamic secrets requires ongoing connectivity with services and resources outside of the cloud platform, or with third-party services within the platform, which presents a tremendous problem for CSPs.  

Akeyless Secrets Management for Hybrid Multicloud

Akeyless is designed from the ground up as a SaaS-based Secrets Orchestration platform to enable a  centralized, multi-tenant solution that is very simple to deploy across hybrid multicloud environments. With Akeyless, you can centrally manage and protect your workload secrets through all stages of the lifecycle, from creation to revocation, and securely stores the secrets using patented, FIPS 140-2 certified, Distributed Fragments Cryptography™ (DFC) technology. Akeyless DFC ensures secrets never exist as a whole, and enables

a Zero-Knowlege platform where customers retain exclusive ownershipof their secrets. Easily set up automated rotation schedules that do not disrupt your workflows, or use Akeyless to eliminate standing privileges with Just In Time Access. For more information, or to schedule a demo, visit https://www.akeyless.io