Building a stellar application that users will love consists of many different decisions, from UI design and color palettes to functionality and feature sets. Writing code that works is a creative process, but it’s only one part of the entire development process. Your app also needs to be secure—not just for the sake of your users, but also for the integrity of your business. Typical security measures when designing your software architecture include:
- Safe and well-tested authentication and authorization schemes
- The ability to control network traffic through firewalls and port monitoring
- Service and resource isolation, so that one server cannot access another
- Securing connections between services via SSL/HTTPS
Together, these practices form a philosophy known as Zero Trust. A Zero Trust architecture is hyper-focused on locking down your application from any and all access. Services are inaccessible to one another by default. Then, over time, and based on need, services are granted access to communicate with one another. In short, services accept outside connections only when it’s necessary. Since the network of your application infrastructure is “closed” by default, this mitigates malicious access and unexpected events.
Zero Trust doesn’t make your infrastructure fool-proof from attack, but it does reduce the attack vectors for outsiders. Whether you’re a massive enterprise company or a small startup, the security considerations are the same. You want your user data to be safe and secure as soon as it goes online.
Zero Trust architecture requires developers to consider how services interact. For example, let's say Service A handles fetching data and Service B handles requesting data. Service A would need to have a specific endpoint and port open and available for communication with Service B (and only Service B). Zero Trust planning can appear to hinder productivity, even more so if you’re adding a new service or are unfamiliar with the DevOps necessary to grant access.
However, no matter the perceived hassle of adopting this approach, the advantages far, far _outweigh the time spent planning. It is _impossible to undo a security incident, and an incident results in reduced user confidence and stress on your teams to address the issue. We often hear stories of hackers gaining access to an outdated and unmanaged service, reaching production systems, or misconfigured databases for public access.
If you configured your application as a group of microservices, you might feel a little overwhelmed with adopting network and policy settings consistent with a Zero Trust philosophy. To develop a set of consistent policies, you’ll want to make use of a service mesh like Kuma. A service mesh is a system that controls how different services share data. It’s responsible for handling network traffic, network policies, and observability for your microservices.
For communicating with the outside world (such as your users), you’ll want to set up an API gateway like Kong Gateway. Kong acts as a frontend service provider for access to all of your internal services. Kong routes HTTP requests made to an endpoint to a specific service.
Some of the policies and functionality Kong and Kuma support include the following:
You may know how important HTTPS is and how it’s an essential step to securing traffic from outside interference. Typically, you would set this up via an SSL certificate. That’s a great first step, but there are plenty of other configurations to bring more protection.
For example, with several lines of YAML, Kong can force all HTTP traffic to be encrypted as HTTPS. Doing so is important because it protects users from inadvertently making insecure requests. Furthermore, SSL certificates need to be renewed and kept up to date; the average certificate validity ranges from 90 days to a year. Kong also comes with a certificate manager, which will automatically renew certificates so that they never expire. To go even further, Kong also supports encrypting outbound TLS/TCP traffic. These protocols exist outside the well-known HTTP/S system and are responsible for handling email, file transfers, SSH, and more.
Kuma, for its part, supports Mutual TLS (mTLS), a policy that verifies the validity of a service through sharing private keys. mTLS is used to ensure the legitimate identity of users, devices, and servers. Kuma’s documentation on securing service communication with Kuma provides more details on mTLS and other security policies.
Observability is a critical practice. Tracking and visualizing the behaviors of your application can help you get a better understanding of how your application performs in production. In a Zero Trust context, observability is often considered the foundation of services and networks. At a minimum, you would need to make sure that you are collecting traffic logs to verify and test your assumptions about the security of your network. You also need to make sure that the data you collect is stored securely, like any other piece of critical information.
To help with this, Kong has several plugins that support analytics and monitoring. Many of these come with their own API endpoints, so you can potentially automate their behaviors.
More specifically, Kuma provides a Traffic Log policy. This policy allows you to define how logs are collected and allows for routing different sources of traffic data to different destinations. You can create a unified data capturing system that’s still flexible enough to accommodate any variances. For example, you might want your internal application logs to be aggregated in some long-term archive database while your external user-facing service logs are sent to somewhere more readily accessible.
Zero Trust architecture isn’t about mandating a “one-size-fits-all” approach to security solutions. Rather, it starts with simple statements. For example, “All traffic should be captured, stored, and able to be queried.” It then implements solutions that meet those needs.
Isolating services from one another is critical for ensuring that security issues on one server do not affect another. You may have some degree of isolation in place, even if you call it redundancy. If a service fails and cannot handle requests, you should have a plan for either queuing work or load balancing to another healthy service. Service isolation in a Zero Trust architecture is not quite the same concept. Still, the important takeaway is that a security incident on one machine should not grant access to any other machine on your network. Think of it like the flu: You want to isolate the compromised service to mitigate the spread.
Kong's Ingress controller provides granular traffic management. It builds on top of Kubernetes’ own Ingress policies, with a lot of syntactic sugar and automation provided. It requires little to no extra configuration. Similarly, Kuma offers Traffic Permissions policies to define permissible traffic. You can think of this as a souped-up firewall: You can restrict traffic sources that come from a specific service (based on its name, not IP address or ports). You can also route requests to specific endpoint destinations. Any unknown source or destination is not allowed.
Building a Zero Trust architecture is about more than just protecting yourself; it’s also a global issue. For example, in the United States, the Cybersecurity mandate is a recent executive order that advocates for increased infrastructure protection from hacking and other unauthorized access. It shows that the philosophies of a Zero Trust design extend far beyond tech and have broader concerns.
If you’d like to try out Kong and Kuma, they have a quick start guide. For more on Zero Trust architecture, check out Kong's recent virtual event, Destination: Zero-Trust. The sessions are online for your convenient viewing.
You may also be interested in learning how Kong and Kuma can help you remove complex and expensive load balancers with their new ZeroLB architecture pattern.