April 2025 Summaries

Ngrok's Kubernetes Operator aims to simplify and enhance Kubernetes ingress by transforming the complexities of network management into a streamlined process using a single interface. The Operator supports Ingress and Gateway API implementations, automatically converting them into ngrok resources that handle routing, authentication, transformation, and processing via a distributed network. Endpoints and a Traffic Policy engine are central to this approach, offering advanced traffic management capabilities and flexibility to match various use cases, from simple to complex. The Operator is designed to work seamlessly with Kubernetes standards, allowing users to deploy ingress quickly and manage services across clusters without exposing endpoints to the public internet. With ongoing updates, such as support for TCPRoute and TLSRoute, ngrok is preparing for a v1.0 release that promises improved documentation, usability, and integration with community tools, while encouraging user feedback to refine the project further.

The customer success team at ngrok has developed a testing framework for the ngrok Kubernetes Operator using GitHub Actions, which allows them to efficiently test multiple resources without the complexity of directly managing Kubernetes clusters. By collaborating with their infrastructure team, they created a streamlined process that involves setting up a Kubernetes cluster, installing Helm, and deploying the ngrok Operator, all within a version-controlled GitHub Action. This approach enables them to run comprehensive test plans, which include deploying Helm charts and validating endpoint availability and performance, while providing the flexibility to adapt to different Kubernetes APIs. The framework is designed to be scalable, allowing users to test various scenarios and configurations, and is shared publicly to help others enhance their CI pipelines for deploying applications and APIs to Kubernetes. Users are encouraged to explore the GitHub repository for more details and reach out for support if needed.

Kubernetes-bound endpoints offer a solution to the slow development loop often experienced by developers using Kubernetes, allowing app and API developers to instantly see how their services behave in remote clusters without the lengthy process of code commits, CI pipeline builds, and pod restarts. By utilizing ngrok's Kubernetes Operator and its bindings, developers can project local services to Kubernetes clusters securely and efficiently, bypassing the need for complex networking tools or exposing systems to the public internet. This approach not only speeds up the development process but also supports infrastructure and platform engineers in enabling self-service capabilities without expanding infrastructure demands. It facilitates seamless communication between clusters and allows testing in production-like environments without the need for constant rebuilds or redeployments, offering a simplified and secure way to manage Kubernetes networking.

Ngrok offers a simplified setup for mutual TLS (mTLS) through its terminate-tls Traffic Policy action, allowing users to control where and how TLS traffic is decrypted and client certificates are validated. This innovation centralizes TLS requirements into a single configuration engine, previously managed through a combination of agent configurations and edge modules. By default, ngrok handles TLS termination differently based on endpoint types, with the option to terminate at ngrok's cloud service, at the user's agent for end-to-end encryption, or at the upstream service. The system supports both the latest secure version of TLS, 1.3, and provides fallback for TLS 1.2, ensuring broader client compatibility and reduced latency. Users can also customize their setup with their own certificates, enhancing flexibility and security. Furthermore, ngrok simplifies mTLS setup, allowing users to enforce client certificate validation with minimal configuration and offering comprehensive documentation and support to guide users through the process.

A healthmed software company needed a secure, seamless method to connect their clinics' internal systems to cloud services without exposing them to the public internet or using VPNs. The solution involved deploying a single ngrok agent per clinic, which acts as a central gateway, providing secure access to services such as REST APIs, patient databases, and clinical web dashboards. This setup utilizes internal and cloud endpoints, allowing controlled, authenticated access via Google OAuth and mTLS, and supports dynamic access to web dashboards through the ngrok agent API. The architecture ensures secure, reliable connectivity and continuous uptime while minimizing complexity and security risks, making it adaptable for various industries beyond healthcare.

The blog post discusses leveraging ngrok's Kubernetes Operator to securely access Kubernetes APIs remotely without relying on traditional methods like VPC tunneling or VPNs. By setting up token-based RBAC and deploying ngrok's Kubernetes Operator, users can add ingress to their Kubernetes API using a single custom resource definition (CRD) while maintaining the ability to perform administrative tasks with kubectl. The setup enhances observability and traffic management by using ngrok's Traffic Inspector and Traffic Policy, which provide detailed API request insights and control over access attempts based on IP restrictions. Additionally, the post highlights the scalability and ease of deploying this setup across multiple clusters, emphasizing the added security layers and flexibility compared to built-in Kubernetes options, with usage-based pricing applicable across all plans.

Ngrok users can now create custom error pages to provide a seamless user experience if their agents or upstream services go offline, without needing to fill out forms or wait for support. This is achieved by utilizing ngrok's endpoints and Traffic Policy system, which includes setting up a "shape" with a Cloud Endpoint and internal Agent Endpoints, and using the forward-internal Traffic Policy action to direct traffic appropriately. By changing the on_error policy from "halt" to "continue," users can implement a custom-response action to display personalized error pages instead of the default ngrok-branded ones. This process involves creating a cloud endpoint, configuring traffic rules, and designing custom HTML error pages that can be enriched with user-specific information using CEL interpolation. The new system not only enhances user experience but also helps streamline infrastructure by eliminating the need for separate hosting solutions for error pages, while providing opportunities to integrate logging for better debugging and observability.