NGINX Full Version

Six Ways to Secure Kubernetes Using Traffic Management Tools

Editor – This post is part of a 10-part series:

  1. Reduce Complexity with Production-Grade Kubernetes
  2. How to Improve Resilience in Kubernetes with Advanced Traffic Management
  3. How to Improve Visibility in Kubernetes
  4. Six Ways to Secure Kubernetes Using Traffic Management Tools (this post)
  5. A Guide to Choosing an Ingress Controller, Part 1: Identify Your Requirements
  6. A Guide to Choosing an Ingress Controller, Part 2: Risks and Future-Proofing
  7. A Guide to Choosing an Ingress Controller, Part 3: Open Source vs. Default vs. Commercial
  8. A Guide to Choosing an Ingress Controller, Part 4: NGINX Ingress Controller Options
  9. How to Choose a Service Mesh
  10. Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment

You can also download the complete set of blogs as a free eBook – Taking Kubernetes from Test to Production.

As discussed in Secure Cloud‑Native Apps Without Losing Speed, we have observed three factors that make cloud‑native apps more difficult to secure than traditional apps:

  1. Cloud‑native app delivery causes tool sprawl and offers inconsistent enterprise‑grade services
  2. Cloud‑native app delivery costs can be unpredictable and high
  3. SecOps teams struggle to protect cloud‑native apps and are at odds with DevOps

While all three factors can equally impact security, the third factor can be the most difficult problem to solve, perhaps because it’s the most “human”. When SecOps isn’t able or empowered to protect cloud‑native apps, some of the consequences are obvious (vulnerabilities and breaches), but others are hidden, including slowed agility and stalled digital transformation.

Let’s dig deeper into those hidden costs. Organizations choose Kubernetes for its promise of agility and cost savings. But when there are security incidents in a Kubernetes environment, most organizations pull their Kubernetes deployments out of production. That slows down digital transformation initiatives that are essential for the future of the organization – never mind the wasted engineering efforts and money. The logical conclusion is: if you’re going to try to get Kubernetes from test to production, then security must be considered a strategic component that is owned by everyone in the organization.

In this post, we cover six security use cases that you can solve with Kubernetes traffic‑management tools, enabling SecOps to collaborate with DevOps and NetOps to better protect your cloud‑native apps and APIs. A combination of these techniques is often used to create a comprehensive security strategy designed to keep apps and APIs safe while minimizing the impact to customers.

  1. Resolve CVEs quickly to avoid cyberattacks
  2. Stop OWASP Top 10 and denial-of-service attacks
  3. Offload authentication and authorization from apps
  4. Set up self‑service with guardrails
  5. Implement end-to-end encryption
  6. Ensure clients are using a strong cipher with a trusted implementation

Security and Identity Terminology

Before we jump into the use cases, here’s a quick overview of some security and identity terms you’ll encounter throughout this post.

Use Case: Resolve CVEs Quickly to Avoid Cyberattacks

Solution: Use tools with timely and proactive patch notifications

According to a study by the Ponemon Institute, in 2019 there was an average “grace period” of 43 days between the release of a patch for a critical or high‑priority vulnerability and organizations seeing attacks that tried to exploit the vulnerability. At F5 NGINX, we’ve seen that window narrow significantly in the following years (even down to day zero in the case of Apple iOS 15 in 2021), which is why we recommend patching as soon as possible. But what if patches for your traffic management tools aren’t available for weeks, or even months, after a CVE is announced?

Tools that are developed and maintained by community contributors (rather than a dedicated engineering team) have the potential to lag weeks or months behind CVE announcements, making it unlikely that organizations can patch within that 43-day window. In one case, it took OpenResty four months to apply an NGINX‑related security patch. That left anyone using an OpenResty‑based Ingress controller vulnerable for at least four months, but realistically there’s usually additional delay before patches are available for software that depends on an open source project.

To get the fastest CVE patching, look for two characteristics when selecting traffic management tools:

For more on CVE patching, read Mitigating Security Vulnerabilities Quickly and Easily with NGINX Plus.

Use Case: Stop OWASP Top 10 and DoS Attacks

Solution: Deploy flexible, Kubernetes‑friendly WAF and DoS protection

Choosing the right WAF and DoS protection for Kubernetes apps depends on two factors (in addition to features):

While a tool that consolidates WAF and DoS protection may seem more efficient, it’s actually expected to have issues around both CPU usage (due to a larger footprint) and flexibility. You’re forced to deploy the WAF and DoS protection together, even when you don’t need both. Ultimately, both issues can drive up the total cost of ownership for your Kubernetes deployments while creating budget challenges for other essential tools and services.

Once you’ve chosen the right security tools for your organization, it’s time to decide where to deploy those tools. There are four locations where application services can typically be deployed to protect Kubernetes apps:

So, out of the four options, which is best? Well…that depends!

Where to Deploy a WAF

First, we’ll look at WAF deployment options since that tends to be a more nuanced choice.

Where to Deploy DoS Protection

Protection against DoS attacks is more straightforward since it’s only needed at one location – either at the front door or at the Ingress controller. If you deploy a WAF both at the front door and the edge, then we recommend that you deploy DoS protection in front of the front‑door WAF, as it’s the most global. That way, unwanted traffic can be thinned out before hitting the WAF, allowing you to make more efficient use of compute resources.

For more details on each of these deployment scenarios, read Deploying Application Services in Kubernetes, Part 2.

Use Case: Offload Authentication and Authorization from Apps

Solution: Centralize authentication and authorization at the point of ingress

A common non‑functional requirement that gets built into apps and services is authentication and authorization. On a small scale, this practice adds a manageable amount of complexity that’s acceptable when the app doesn’t require frequent updates. But with faster release velocities at larger scale, integrating authentication and authorization into your apps becomes untenable. Ensuring that each app maintains the appropriate access protocols can distract from the business logic of the app, or worse, can get overlooked and lead to an information breach. While use of SSO technologies can improve security by eliminating separate usernames and passwords in favor of one set of credentials, developers still have to include code in their apps to interface with the SSO system.

There’s a better way: offload authentication and authorization to an Ingress controller.

Because the Ingress controller is already scrutinizing all traffic entering the cluster and routing it to the appropriate services, it’s an efficient choice for centralized authentication and authorization. This removes the burden from developers of building, maintaining, and replicating the logic in the application code; instead, they can quickly leverage SSO technologies at the ingress layer using the native Kubernetes API.

For more on this topic, read Implementing OpenID Connect Authentication for Kubernetes with Okta and NGINX Ingress Controller.

Use Case: Set Up Self-Service with Guardrails

Solution: Implement role‑based access control (RBAC)

Kubernetes uses RBAC to control the resources and operations available to different types of users. This is a valuable security measure as it allows an administrator or superuser to determine how users, or groups of users, can interact with any Kubernetes object or specific namespace in the cluster.

While Kubernetes RBAC is enabled by default, you need to take care that your Kubernetes traffic management tools are also RBAC‑enabled and can align with your organization’s security needs. With RBAC in place, users get gated access to the functionality they need to do their jobs without waiting around for a ticket to be fulfilled. But without RBAC configured, users can gain permissions they don’t need or aren’t entitled to, which can lead to vulnerabilities if the permissions are misused.

An Ingress controller is a prime example of a tool that can serve numerous people and teams when configured with RBAC. When the Ingress controller allows for fine‑grained access management – even down to a single namespace – you can use RBAC to enable efficient use of resources through multi‑tenancy.

As an example, multiple teams might use the Ingress controller as follows:

To learn how to leverage RBAC in NGINX Ingress Controller, watch Advanced Kubernetes Deployments with NGINX Ingress Controller. Starting at 13:50, our experts explain how to leverage RBAC and resource allocation for security, self‑service, and multi‑tenancy.

Use Case: Implement End-to-End Encryption

Solution: Use traffic management tools

End-to-end encryption (E2EE) is becoming an increasingly common requirement for organizations that handle sensitive or personal information. Whether it’s financial data or social media messaging, consumer privacy expectations combined with regulations like GDPR and HIPAA are driving demand for this type of protection. The first step in achieving E2EE is either to architect your backend apps to accept SSL/TLS traffic or to use a tool that offloads SSL/TLS management from your apps (the preferred option for separation of security function, performance, key management, etc.). Then, you configure your traffic management tools depending on the complexity of your environment.

Most Common Scenario: E2EE Using an Ingress Controller

When you have apps with just one endpoint (simple apps, or monolithic apps that you’ve “lifted and shifted” into Kubernetes) or there’s no service-to-service communication, then you can use an Ingress controller to implement E2EE within Kubernetes.

Step 1: Ensure your Ingress controller only allows encrypted SSL/TLS connections using either service‑side or mTLS certificates, ideally for both ingress and egress traffic.

Step 2: Address the typical default setting that requires the Ingress controller to decrypt and re‑encrypt traffic before sending it to the apps. This can be accomplished in a couple of ways – the method you choose depends on your Ingress controller and requirements:

Less Common Scenario: E2EE Using an Ingress Controller and Service Mesh

If there’s service-to-service communication within your cluster, you need to implement E2EE on two planes: ingress‑egress traffic with the Ingress controller and service-to-service traffic with a service mesh. In E2EE, a service mesh’s role is to ensure that only specific services are allowed to talk to each other and that they do so in a secure manner. When you’re setting up a service mesh for E2EE, you need to enable a zero‑trust environment through two factors: mTLS between services (set to require a certificate) and traffic access control between services (dictating which services are authorized to communicate). Ideally, you also implement mTLS between the applications (managed by a service mesh and the ingress‑egress controller) for true E2EE security throughout the Kubernetes cluster.

For more on encrypting data that’s been exposed on the wire, read The mTLS Architecture in NGINX Service Mesh.

Use Case: Ensure Clients Are Using a Strong Cipher with a Trusted Implementation

Solution: Comply with the Federal Information Processing Standards (FIPS)

In the software industry, FIPS usually refers to the publication specifically about cryptography, FIPS PUB 140-2 Security Requirements for Cryptographic Modules, which is a joint effort between the United States and Canada. It standardizes the testing and certification of cryptographic modules that are accepted by the federal agencies of both countries for the protection of sensitive information. “But wait!” you say. “I don’t care about FIPS because I don’t work with North American government entities.” Becoming FIPS‑compliant can be a smart move regardless of your industry or geography, because FIPS is also the de facto global cryptographic baseline.

Complying with FIPS doesn’t have to be difficult, but it does require that both your operating system and relevant traffic management tools can operate in FIPS mode. There’s a common misconception that FIPS compliance is achieved simply by running the operating system in FIPS mode. Even with the operating system in FIPS mode, it’s still possible that clients communicating with your Ingress controller aren’t using a strong cipher. When operating in FIPS mode, your operating system and Ingress controller may use only a subset of the typical SSL/TLS ciphers.

Setting up FIPS for your Kubernetes deployments is a four‑step process:

In the example below, when FIPS mode is enabled for both the operating system and the OpenSSL implementation used by NGINX Plus, all end‑user traffic to and from NGINX Plus is decrypted and encrypted using a validated, FIPS‑enabled crypto engine.

Read more about FIPS in Achieving FIPS Compliance with NGINX Plus.

Make Kubernetes More Secure with NGINX

If you’re ready to implement some (or all) of these security methods, you need to make sure your tools have the right features and capabilities to support your use cases. NGINX can help with our suite of production‑ready Kubernetes traffic management tools:

Get started by requesting your free 30-day trial of NGINX Ingress Controller with NGINX App Protect WAF and DoS, and download the always‑free NGINX Service Mesh.

Exit mobile version