Case Study - Child Rescue Coalition

The technology CRC develops is designed to monitor areas of the internet not owned by a corporate entity but primarily driven by computers that are connected to a network. Since there is no corporate ownership of this technology, there is no consistent or easy way to report abuse. CRC has trained more than 12,000 investigators across 98 countries on their technology which has led to the arrest of 14,000 individuals and the rescue of more than 3,200 children.

Image: One minute of illicit activity captured by Child Rescue Coalition technology

Child Rescue Coalition challenges

An organization with massive amounts of data operations and a small staff had several challenges before opting to use KrakenD as its API gateway solution. Here are some of them:

• Maintaining hundreds of internal microservices plus 38 (and growing!) public microservices, a reliable mechanism for securing entry, throttling calls, and validating requests was needed.
• In-house software had been handling security needs within the application code, thus replicating functionality, and increasing resource consumption, testing requirements, and staff time.
• Custom solutions integration required additional development to adapt.
• Tailoring output for certain partners, such as format and filtering, required adapting existing solutions or writing custom applications.
• With multiple legacy API calls and solutions reaching out to endpoints, an effective way to painlessly transition clients to new solutions was critical.
• Upon completing a full transition to a Kubernetes-based infrastructure, several API gateway solutions were tested, all of which required complex configuration and/or database storage. This would have placed an additional maintenance burden on our staff.

Implementing KrakenD

Child Rescue Coalition’s infrastructure is Kubernetes based, and the first line of entry into all API services is KrakenD. By using the Virtual Hosts and Wildcard routes plugins, inbound traffic is coordinated and directed to the appropriate load-balanced workload. In some cases, it functions as the actual ingress controller.

Due to KrakenD’s OAuth2 support and sharing of claims, it is possible to extract permissions from a JWT token before it even hits a workload. In addition, the usage of API keys with assigned roles facilitates service-to-service communications. This also prevents degraded service by rate limiting, based on an API key RBAC (Role Based Access Control).

By leveraging KrakenD’s endpoint customization options, converting calls made by legacy applications, and directing inbound traffic based on the revision stated in the path, it is possible to reroute workloads and keep backward compatibility. For example:

ourdomain.com/api/v1/sample
ourdomain.com/api/v2/sample

Each of the calls above is to the same API - but different versions. Both remain online, and our partners can continue to use the endpoint until they transition to the new. The code itself, and the testing and deployment process don’t change internally.

KrakenD logging, telemetry, and analytics are the tools and data that make it easy to make important infrastructure decisions.

What is next?

Ingesting partner data, with a diversity of formats and requirements, requires conversion processes. Async Agents and Event Driven Gateway solutions, together with custom plugins, may replace obsolete and less efficient workloads and processes.

About the author(s)

This case study has been written by the development team at Child Rescue Coalition and facilitated by Roberto Machorro, Software Programmer at CRC