ActBlue chooses RAD Security to secure billions in online transactions through Kubernetes

ActBlue’s Kubernetes journey

Reliability is critical to ActBlue’s business model, as any delay on the platform, even in seconds, could affect a donor’s decision on whether or not to continue with a transaction. ActBlue moved to Kubernetes for more reliability, supporting large-scale and unpredictable traffic spikes that could increase traffic by 100 times in a short period of time. ActBlue also migrated to Kubernetes to improve the developer experience and tooling, as well as future-proof the stack for future engineers living in a Kubernetes-first world of app development. As the team began the main part of its Kubernetes deployment, they started looking for a Kubernetes security tool.

Looking for a Native Kubernetes Security Tool 

At ActBlue, the Security team advises and partners with the infrastructure engineering teams that build out the Kubernetes platform and execute the migration. While the infrastructure team leads the deployment, as well as the architecture and collaboration model, the security team reviews those plans and suggests risk mitigation strategies; for example, on logging and alerting. When possible, the security team would lead the implementation of those strategies. 

Director of Security, Raj Umadas, describes the philosophy of his team, “Our security philosophy is ‘never say no’: figure out what teams want to happen, advise where we can to limit risk and then implement security mitigations to manage what can’t be limited, leaning toward secure defaults, accurate detections, and swift response. Supporting the adoption of Kubernetes is no different,” says Umadas. 

The security team knew that they would not be able to keep true to their philosophy of true partnership in the Kubernetes migration by using the same cloud security and EDR tools for their containerized environment in Kubernetes.  

“We were not interested in taking our existing cloud security solution, or detecting misconfiguration in terraform, and patching k8s security on top of this. We wanted a Kubernetes-native approach for our newly implemented Kubernetes environments. This focus on Kubernetes native tooling from day 1 ensured that our security engineers and our infrastructure engineers were speaking the same Kubernetes native language during design and implementation; building trust and security from day 1,” says Umadas.

The security team wanted a tool that would do Kubernetes security in a way that was native to Kubernetes, and that would allow them to ‘speak Kubernetes’ with engineering.