Case Study
Property Firm Enhances Multi-Cloud Security Without Secrets Managers
Relied on secrets for workload access across clouds and services.
Faced VPN limitations for microservices communication.
Challenges in managing secrets, leading to security and governance issues.
7 month ROI via simplified workload access management, enhancing security across clouds.
No-code implementation and no stored client credentials simplified development.
Improved operational visibility and troubleshooting with Aembit logs.
The Environment
The company has a complex operation that includes roughly 5,000 locations in the United States, as well as early expansion into Europe. It provides various specialized software for its locations, as well as apps for its customers to use. At the same time, the software it uses is licensed to other operators, which increases the need for reliable, secure, and auditable operations.
The company uses the cloud – both AWS and Azure – as well as SaaS services for specific needs. As the company has grown, it has also merged with other operators, which means that its stack is highly variable. The company actively built its software on Kubernetes (K8s), but also leverages serverless architecture where it can and virtual machines where it is required.
The Problem
Like many other businesses, this property management company relied heavily on secrets to enable workload-to-workload access. This could include services within the same cloud – or even across AWS and Azure – and SaaS services that stored critical property data or customer information.
In the Kubernetes environment, the company used a private VPN, which provided perimeter-based security, to control microservice communication. This was helpful but broke down when the company had to connect to a third-party service (like a payment provider) or even to its own services that were on another cloud or outside the protected K8s environment.
To support good secrets management practices among its developers, the company had integrated components of the Spring Framework, focusing on simplifying the configuration of secrets. This initiative was part of a broader framework that emphasized the essential best practice of keeping secrets out of the code. However, they realized that relying solely on these established practices and the Spring framework was not adequate to meet growing security and compliance requirements. This recognition highlighted the need for more sophisticated solution to accommodate their evolving and intricate software environment.
The Solution
The firm considered secrets managers – and even had this technology implemented in pockets of its acquired software – but wanted something that would be more scalable and drive more benefits.
“Secrets managers mean you still have secrets running around,” the lead DevOps engineer said. “ If I could get away from managing secrets altogether, I knew that would be more secure, and it would be easier for us.”
The company decided to implement Aembit in a set of its core systems to test its capabilities, and then expand from there. The security benefits were almost immediately obvious.
Typically you’d have a secret stored in the memory of a running pod, but because of Aembit’s approach and its sidecar, credentials are injected into requests, without the application ever seeing them. That means Aembit took a possible hole and made it a virtual impossibility.
– Lead DevOps Engineer
Aembit Edge, the platform’s transparent proxy that you deploy alongside each of your applications, made implementation of workload identity simple. Instead of requiring developers to modify code in their application, the Edge intercepts authorization requests and injects credentials into validated requests. All other requests flow through the Edge without delay or modification on to their intended destination. In Kubernetes, Aembit Edge is deployed as a sidecar, on a VM as an agent.
“Even if a bad actor got into our network, infiltrated a pod, they still wouldn’t have access to credentials,” the engineer observed. “Typically you’d have a secret stored in the memory of a running pod, but because of Aembit’s approach and its sidecar, credentials are injected into requests, without the application ever seeing them. That means Aembit took a possible hole and made it a virtual impossibility.”
The additional benefit, in the event of an incident, is the ability to instantly shut off access to a resource via policy. A simple click to make a policy inactive means that your sensitive resource is protected until it is deemed safe to use again.
Aembit also simplified ongoing operations. First, the no-code auth approach meant the company didn’t need to have developers modify code or do any specific integration with Aembit. Next, with no credentials stored in client applications or in third party tools, credential rotation is dramatically simplified. It only requires a change in the service account and confirming the change with Aembit.
Finally, visibility was another strong benefit of Aembit.
“We were having a connectivity problem and it was going to potentially impact production,” the engineer recalled. “I ship all our logs to an ELK stack, and I did that with the Aembit logs too. They were incredibly helpful because I could see access requests based on the workload identities. That made it really easy to see where the problem was. Aembit isn’t a troubleshooting tool, but its data helped us solve a problem anyway.”
Concrete Business Benefits
The firm saw a 7 month ROI upon implementing Aembit. The benefits were driven by the ability to offload development teams from thinking about auth, and instead providing that as-a-service via the simple inclusion of Aembit in workloads.
Further, ongoing DevOps works was greatly reduced, in terms of managing credential lifecycle from issue, to rotate, to audit. Troubleshooting was simplified by having a new source of high quality, identity-based access logs.
While not included in the ROI, the organization significantly improved its security posture by hardening access to sensitive resources and services as well.
Rollout and Futures
The firm’s objective for Workload IAM is to use Aembit across all services, APIs, and SaaS products that are integrated into its production stack, as well as run the same environment in dev.
“We’ve now got about 12 different databases that Aembit controls access to across our clusters,” the engineer said. “And I’m implementing it across our external API calls to external services. And while I still have those secrets vaults around, I’ll secure them too, using Aembit.”
Next up, the team hopes to implement Aembit in VMs, as it handles some particularly sensitive systems. Finally, serverless functions that do data processing and reporting can take advantage of the same functionality.
At each step of implementation, Aembit has allowed the company to better secure its workloads while reducing the operational burden on the organization.
“Working with Aembit has just made my life a lot easier.”
Related Content
