I have an app that is deployed in k8s cluster and the frontend and the backend of the app are exposed, is there a way to not expose the backend ? i thought about the api gateway is it going to fulfills my requests if yes how ? and if not what's the alternatives ??
Thank you in advance
I tried the gateway kong and it did not work out very well
Your question requires more detail for me to be certain, however I will take a stab at pointing you in the right direction.
Typically, most apps have a frontend which serves the HTML, and any static assets such as images, css and javascript (like a single page app such as ReactJS)
If you have some SPA, then you will likely have a backend API written in something like Node / Python / PHP / Java to serve your frontend app with dynamic data.
If your frontend and backend are exposed to the internet, this is OK and expected.
If your backend was not exposed to the internet, then it would be impossible for your frontend to load dynamic data.
That said, you mentioned that you are using or at least tried to use an API Gateway. Typically, you would not expose your backend directly to the internet. Rather, you would expose your API Gateway to the internet, with the API Gateway acting as a reverse proxy to your backend.
In order to achieve this (in Kubernetes), you would typically create a Service type Load Balancer for your API Gateway. And configure a Service type Cluster IP for your backend.
ClusterIP: Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default that is used if you don't explicitly specify a type for a Service. You can expose the service to the public with an Ingress or the Gateway API.
Related
I am using azure kubernetes for backend deployment. I have 2 URLs one is API URL(api.project.com) and other one is BFF URL(bff.project.com).
From Web application, instead of calling API URL(api.project.com) they use BFF URL(bff.project.com) which internally calls the API URL(api.project.com) and sends the response.
I now want to restrict direct usage of API URL(api.project.com) even from any REST API Clients(like postman, insomnia, ...) it should only work when triggered from BFF URL(bff.project.com).
We have used nginx-ingress for subdomain creation and both the URLs(BFF and API) are in same cluster.
Is there any firewall or inbuilt azure services to resolve the above mentioned problem ?
Thanks in Advance :)
You want to keep your api private, only accessible from another K8S service, so don't expose it using your ingress controller and it simply won't be accessible outside K8S to any client.
This means that you lose the api.project.com address (although you can get that back if you really want to, it seems unnecessary). The BFF would then access the API via the URL: http://<service-name>.<namespace>.svc.cluster.local:<service-port>, which in your case might be:
http://api.api_ns.svc.cluster.local
Assuming you haven't used TLS (http rather than https), the service is called api, it's running on port 80 (which it should be) and the namespace is called api_ns.
Should you need to provide temporary access to the API for developers to use, say, postman, then they can use port-forwarding to provide that in a dev environment without allowing external access all the time.
However, this won't restrict access to BFF alone. Any service running in K8S could access the API. If you need/want to restrict things further, then you have a lot of options.
If we have two service for example
Front-end (which is consul-connect enabled)
Back-end (which is not consul-connect enabled).
Is it possible to restrict communication between then through intention. Provided we use Consul-Sync from to moved k8s service into consul catalog. Then back-end which is not consul-connect enabled will show in intention. I tried setting deny between Front-end -> Back-end. If not working Front-end is hitting Back-end. I am missing something Or its like Authorization can only happen between two consul-connect enabled service
This question was recently answered in https://stackoverflow.com/a/68432317/12384224.
Consul intentions are authorization polices that allow you to control access between applications within a service mesh. You must use a sidecar proxy, or natively integrate your application with the mesh, in order to use intentions. They are not applicable if you are only using Consul for service discovery, or your application is not part of the service mesh.
I have a small application comprising three services:
A single page application (SPA) served from nginx
A simple nodejs HTTP API used by the SPA
An MQtt broker exposing ports 1883 and 9001
Ideally I'd like the all to be served from the same subdomain and static IP address and have been trying to configure this in Kubernetes on the Google Cloud Platform.
I've created deployments for each of the services, with the SPA exposing port 80, the API 3000 and the MQTT broker 1883/9001. I've then followed the instructions here to set up a static IP and a Service to route to the SPA, then created similar services for the API and the MQTT app. (I've initally adapted these from deployments and services generated from a docker-compose file and Kompose).
The SPA and API seem to work fine but the MQTT service does not. When I run kubetl get events I see:
Error creating load balancer (will retry): failed to ensure load balancer for service default/mqtt-broker: failed to create forwarding rule for load balancer (a5529f2a9bdaf11e8b35d42010a84005(default/mqtt-broker)): googleapi: Error 400: Invalid value for field 'resource.IPAddress': '35.190.221.113'. Specified IP address is in-use and would result in a conflict., invalid
So I'm wondering if I should be creating a single service to route to the three deployments but can't find any documentation or examples that explain how to do this for a non http service.
I guess I could put the mqtt service on a separate IP address but this seems to be hacking around the problem rather than solving it.
Thanks in advance for any advice.
I eventually found an almost identical use case to my own on this github repository.
In essence, they are creating the MQTT broker on a separate static IP and using Kubernetes API calls to expose the details to the front end, which they explain in the following comment at the top of the web.yaml file:
This needs a bit of trickery
as it needs to expose the LB ip address for the MQTT server. That
requires kubernetes API calls to look it up, and the ability to
store it somewhere (we put it in a secret). To be secure this is
done with a dedicated service account and an init container.
https://github.com/IBM/ny-power
My backend and frontend is deployed on Google Kubernetes Engine (GKE). And lets consider these steps -
User opens up browser and points to yyy.yyy.yyy:8080.
Browser loads the login page.
User enters username/password and presses "login" button.
Browser (ReactJS App) sends request to REST backend xxx.xxx.xxx:7070 to do the validation.
Now my question is, how can we inject the backend (in this case xxx.xxx.xxx) ip frontend pod? Because this ip is not static (i dont want to make it static), and will be provided by GKE. I don't want to proxy my backend call through frontend either. Neither I want to use nginx, the reason is, one more POD, and config to maintain. Just don't want to have nginx for only this reason.
Should I create ingress? I mean something like-
`/` <-- serves ReactJS app
`/api` <--- serves REST api
Or there is a way to inject the ip of backend POD?
What is the best approach?
Thanks in advance.
You can't access the pods directly from the outside. The only way in is through a service of type LoadBalancer. External IP you get for such a service is static for GKE (AWS gives a DNS name instead)
For every service of type LoadBalancer the cloud provider will spin up a load balancer that you have to pay for. You can funnel all http traffic through a single ingress service that would fan out your requests based on host DNS or URI path and other options. Which is what pretty much everyone does. If you want to setup something like that google for ingress
Here is usecase:
I have two apps in Bluemix: app1 and app2
app1 is accessible through the internet using its route (e.g. app1.mybluemix.net)
app2 doesn't have any route to prevent from being accessible through the internet.
app2 may expose a REST API.
How do I call app2 from app1 inside Bluemix?
An example of communicating to an application without a route is implemented in this Microservice Shipping sample.
This is an EJB Liberty application that runs on Bluemix without a route and subscribes to the Bluemix MQ Light service. The sender of the messages is the Microservice Orders sample application, which binds to the same MQ Light service.
Going the REST API route will mean you must have an externally accessible route. However, you could secure it using keys and tokens.
It would be easier to use one of the services in Bluemix as an "RPC" layer between the two applications. You could use one of the queue services (MQLight, RabbitMQ) or Redis to pass messages between the applications to execute commands.
These service bindings are internal and won't be exposed externally unlike the REST API.
Alternatively, you could expose the REST API from App2 and use authentication to control access.
There are two ways you can prevent access.
Put your microservice inside a Bluemix Container and utilize private IPs https://new-console.ng.bluemix.net/docs/containers/container_security_network.html#container_cli_ips_byoip
Use API Connect as a API Gateway/proxy to the private IP being in your container microservice.
Use Bluemix Dedicated to deploy app2. Bluemix dedicated provides firewall capabilities and you could set it up so that it only accepts requests from app1's IP address.
Use Bluemix Local when it becomes available with the same approach where you use your corporate firewall to only accept requests that come from your App1 IP Address. This is an expensive alternative compared to a public PAAS.
Use the API Connect Service which replaced the API Management Service to:
Specify what users can access your apis
Specify the number of requests per day or other unit of time
Provides a API Gateway to securely call the other service App2.
I expect at some point a software network defined solution will be considered as part of the offering.