23

Let's say I'm using an GCE ingress to handle traffic from outside the cluster and terminate TLS (https://example.com/api/items), from here the request gets routed to one of two services that are only available inside the cluster. So far so good.

What if I have to call service B from service A, should I go all the way and use the cluster's external IP/domain and use HTTPS (https://example.com/api/user/1) to call the service or could I use the internal IP of the service and use HTTP (http://serviceb/api/user/1)? Do I have to encrypt the data or is it "safe" as long as it isn't leaving the private k8s network?

What if I want to have "internal" endpoints that should only be accessible from within the cluster - when I'm always using the external https-url those endpoints would be reachable for everyone. Calling the service directly, I could just do a http://serviceb/internal/info/abc.

Philipp Kyeck
  • 18,402
  • 15
  • 86
  • 123
  • 1
    The question is can you guarantee that " it isn't leaving the private k8s network" for all future changes? That a rouge user will not add a path/hardware that comprises the private network? I would not bet on that having been a rogue a few of times to get around security restrictions. – zaph Jan 09 '18 at 12:27

1 Answers1

28

What if I have to call service B from service A, should I go all the way and use the cluster's external IP/domain and use HTTPS (https://example.com/api/user/1) to call the service or could I use the internal IP of the service and use HTTP (http://serviceb/api/user/1)?

If you need to use the features that you API Gateway is offering (authentication, cache, high availability, load balancing) then YES, otherwise DON'T. The External facing API should contain only endpoints that are used by external clients (from outside the cluster).

Do I have to encrypt the data or is it "safe" as long as it isn't leaving the private k8s network?

"safe" is a very relative word and I believe that there are no 100% safe networks. You should put in the balance the probability of "somebody" or "something" sniffing data from the network and the impact that it has on your business if that happens.

If this helps you: for any project that I've worked for (or I heard from somebody I know), the private network between containers/services was more than sufficient.

What if I want to have "internal" endpoints that should only be accessible from within the cluster - when I'm always using the external https-url those endpoints would be reachable for everyone.

Exactly what I was saying on top of the answer. Keeping those endpoints inside the cluster makes them inaccessible by design from outside.

One last thing, managing a lot of SSL certificates for a lot of internal services is a pain that one should avoid if not necessary.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • Are you aware of a simple way to setup https traffic beetwen two local systems? Meaning the call would be https://localservicaA to https:localserviceB – Astronaut Dec 04 '20 at 16:52
  • 1
    @Astronaut Simple? No. Complicated: you could take a look at Service Meshes. – Constantin Galbenu Dec 08 '20 at 09:27
  • In the end we will try to go Service Mesh route, its hard since we do not have admin rights on the cluster, lets see how far we can go. thxs for your reply – Astronaut Dec 08 '20 at 23:17