Bypass kong by using cluster ip

Kubernetes
1

Hi,

Since a service is not mandatory on Kubernetes, it’s possible to bypass any kong plugin by accessing a pod directly by it’s clusterIP.
-> the security is then only perimeter and not within the cluster

How can we prevent such situation ? Using network policies to enforce the network for a service to come from Kong?

Another solution would be using sidecar but its more a service mesh architecture.

It’s an open question :blush:

2

As you’ve mentioned, there are multiple options to handle this. There’s no single recommendation that works best everywhere, since there are many options for enforcing networking policy in Kubernetes, including network-level segmentation, mesh sidecars, or application-layer restrictions in upstream applications. Which you choose will depend on your preferences, organization policy, and security requirements.

We can’t provide much information about network-level restrictions, as they’re implemented and enforced at a layer lower than where our products operates, but we can provide information about the others:

  • If you want to use a mesh architecture, our mesh offering, Kuma provides mutual TLS authentication and Service-based permissions.
  • If you do not, and your upstream applications provide a means to require TLS client certificates themselves, the controller can instruct the Kong proxy to send a client certificate using an annotation. We provide a guide that goes over this in more depth.
  • There are many HTTP-level options for authentication, but you may need to use different ones for different upstream services depending on what authentication protocols they support. For example, however, you can add very basic security by having the request-transformer plugin add or replace an HTTP basic auth header, or if you have Kong Enterprise and your application can verify JWTs, you can use the jwt-signer plugin to re-sign a client’s JWT with a key only Kong knows.