Machine identity management in the cloud is significantly more complicated than it is on-premises. Putting aside the sheer number of machines that need to be protected, every machine must interact with hundreds, if not thousands, of other containers, services, machines and platforms, many of which may belong to third parties—and all of these machines have wildly varying lifespans and integration methods.
Despite the added complexities involved, many of the largest, most security-conscious organizations have already successfully migrated their IT infrastructures to AWS, Azure and GCP—while ensuring a foundation of trust for their machine identities. These customers recognized from the get-go that in order to use use the cloud to deliver business objectives, they needed to have an effective machine identity management strategy in place.
Read the cloud tale below to learn how an information services company used machine identity management to successfully migrate to AWS.
A fast-growing information services company saw that their services business had great growth potential, but they were reluctant to purchase more data center hardware and related capital expenditures because of the costs involved.
They wanted to be able to scale easily in either direction, depending on the success of their rollout of one of their more popular video services. Moving that part of their environment to AWS seemed like the ideal solution, giving them the flexibility they needed to test—and ideally grow—this portion of their business.
In order to do this, however, they needed to rearchitect their traditional applications into microservices to spin up the service and then decommission them once it was over.
They were using Kubernetes for the on-demand containers that would be used to deploy the applications. But they were running into problems requesting and automating the lifecycle of the TLS certificates they needed to secure the machine identities of a multitude of containers.
Developers had been requesting certificates directly from Amazon, but the InfoSec team quickly realized that this would create complications, given that, according to company policy, Amazon was not an authorized CA. The InfoSec team needed a way to make it easy for developers to easily request certificates from authorized CAs without affecting speed or efficiency. And the InfoSec team also needed this to happen in a way that didn’t force every member of the InfoSec team to learn the APIs of every approved CA in order to manage these processes in a secure fashion.
By offering one CA-agnostic platform, Venafi enabled the InfoSec team to configure one set of APIs that would work with every CA they wanted to use—including Amazon’s internal CA should they decide to include them in their authorized CA list in the future. The developers were able to procure and renew TLS machine identities as easily as they did before without putting the organization at risk—no additional steps needed.
Even better: The InfoSec team now had visibility into what the developers were doing with certificates, so they could monitor their machine identity inventory without interfering in DevOps processes. In fact, they were so pleased with the Venafi machine identity management solution that the InfoSec team referred to Venafi as “the connective tissue holding everything together!”
Want to learn more? Check out our eBook “Tale of 3 Clouds” to learn how other enterprises leveraged Venafi to manage their machine identities in each of the top three public clouds: Azure and GCP.
- Certificate Management for Multi-Cloud Environments
- Open-Source Community: CNCF Sandbox Accepts Cert-Manager
- 5 Cloud Catastrophes and How to Avoid Them
- Are You Doing Multicloud Safely?