I'm currently deploying on cloud foundry, Now I have a frontend server and a backend server.
Both deployed as micro services with the Cloud Foundry nodejs build pack.
I would like to hide the backend server from the outside world, that only my frontend server can access it. How do I do that?
If I remove the route to the backend server the server is hidden from the outside but then I do not know how to access it from my frontend.
I'm new to Cloud Foundry maybe there is an easy way.
Thanks
Andreas
Thanks for the information so far.
I do however not understand how I could now hide my backend instance from being accessed from the outside, but allow for access of the frontrontend?
Basically what roule would I need to set in my space in order to allow only port 80 to be accessed of my frontend instance (lets say the frontend ip is 168.192.0.5).
could you make an example?
If you are using OSS Cloud Foundry, you can put the backend services into their own space, and then set the security group rules for that space so that they will not respond to outside IP addresses:
https://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html
If you are using Pivotal Cloud Foundry, you can use Spring Cloud Service Discovery, as Amit said.
What about using "cf push myjavaapp --no-route"?
The no-route option tell Bluemix that your backend is not a web application.
Another solution to hide the back-end microservice from the public is to use containers (also available on Bluemix, based on Docker, see https://www.ng.bluemix.net/docs/containers/container_gettingstarted.html). Containers have a private IP by default and can access other containers in the same space. You can assign the front-end microservice a public IP using e.g. following command
cf ic ip bind {public_ip} {container_name}
but don't assign a public address to your back-end microservices.
(A few weeks ago I've created a simple example for a microservice in a container, you can find the code at
https://hub.jazz.net/project/matthiashub/bluemix-unistuttgart-container/overview I admit that this was done in Java and not in nodejs but I think you get the idea.)
Related
we are migrating from IBM Cloud Foundry Orgs (as they are depreciated) to ibm cloud engine.
but what seems impossible is the "routes" option that was available in CF (cloud foundry). With CF we could just CNAME the custom domain to eu-de.cf.appdomain.cloud and add it to the routes of the application.
With cloud engine, the only way we can setup a custom domain is explained here, but this requires an extra service from cloudflare.
Is there a way to migrate the CF setup to IBM cloud engine without the Cloudflare worker?
At the moment that is not possible. That being said the Code Engine team is working on a solution to enable this without requiring requiring an extra service (although the proposed cloudflare service in the blog is free AFAIK)
Another option is to deploy a proxy on your own and use it to handle the domains. I have used Traefik for it, but nginx and others should work, too. I deployed the proxy to a Kubernetes cluster which worked well.
I am new to Cloud Foundry.
Is there any way that only specific users can view and update an app deployed in Cloud Foundry?
1.I deployed an app in Cloud Foundry using “cf push”command.
2.After entering “cf push “command I’ve got an message below.
Using manifest file /home/stevemar/node-hello-world/manifest.yml
enter Creating app node-hello-world-example...
name: node-hello-world-example
requested state: started
routes: {route-information}
last uploaded: Mon 14 Sep 13:46:54 UTC 2020
stack: cflinuxfs3
buildpacks: sdk-for-nodejs
type: web
instances: 1/1
memory usage: 256M
3.Using the {route-information} above,I can see the app deployed via browser entering below URL.
https://{route-information}
By this way ,anyone can see app from browser, but I don’t want that to be seen by everyone and limit access to specific user.
I heard that this global IP will be allocated to {route-information} by default.
Is there any way to limit access to only between specific users?
(For example,is there any function like “private registry” at Kubernetes in Cloud Foundry which is not open to public)
Since I am using Cloud Foundry in IBM Cloud it would be better if there is solution using IBM Cloud.
I’ve already granted cloud foundry role to the other user.
Thank you.
The CloudFoundry platform itself does not provide any access controls for applications. If you assign a public route to your application, where the DNS is publicly resolvable and the foundation is on the public Internet, like IBM Bluemix, then anyone can access your app.
There's a number of things you can do to limit access, but they do require some work on your part.
Use a private DNS. You can add any domain you want to Cloud Foundry, even ones that don't resolve. That means you could add my-cool-domain.local which does not resolve anywhere. You could then add a record to /etc/hosts for this domain or perhaps run DNS on your local network to resolve this DNS domain and direct traffic to the CloudFoundry.
With this setup, most people cannot access your application because the DNS domain for the route to your application does not resolve anywhere. It's important to understand that this isn't really security, but obscurity. It would stop most traffic from making it to your app, but if someone knew the domain, they could add their own /etc/hosts header or send fake Host headers to access your application.
This type of setup can work well if you have light security requirements like you just want to hide something while you work on it, or it can work well paired with other options below.
You can set up access controls in your application. Many application servers & frameworks can do things like restrict access by IP address or require user access (Basic auth is easy and it is OK, if you're only allowing HTTPS traffic to your app which you should always do anyway).
You can use OAuth2 to secure apps too. Again, many app servers & frameworks have support for this and make it relatively simple to secure your apps. If you don't have a corporate OAuth2 solution, there are public providers you can use. Exactly how you do OAuth2 in your app is beyond the scope of this question, but there's plenty of material out there on how to do this. Google information for your application language/framework of choice.
You could set up an access Gateway. This would be an application that's job is to proxy traffic to other applications on the foundation. The Gateway could be something like Nginx, Apache HTTPD, or Spring Cloud Gateway. The idea is that the gateway would be publicly accessible, and would almost certainly apply access controls/restrictions (see #2, many of these proxies have access control options that only take a few lines of config). Your actual applications would not be deployed publicly though. When you deploy your actual applications, they would only be on the internal Cloud Foundry domain.
CloudFoundry has local domains, often apps.internal (run cf domains to see if that shows up), which you can use to easily route traffic across the internal container-to-container network. Using this domain and the C2C network, you can have apps deployed to CF that are not accessible to the public Internet, except through your Gateway.
Again, how you configure this exactly is outside the scope of this question, but check out the docs I linked to for info on using the C2C network & internal routes. Then check out your proxy server of choice's documentation.
I created in SAP Logon OData Service and Registed it.
I cheked it and it works good. Now, I want to create cloud connector using the link which I got when tested my Odata Service. It looks like:
http://mylink.com:1234/sap/opu/odata/sap/***_SRV/.
In cloud connector setting I put:
Internal host:mylink.com
Internal port:1234.
But, everytime when I try to check my connection in Cloud Connector it show to me Not Reachable.
Can anybody advice to me something about that and explain to me the reasons of it?
Thanks a lot.
Cloud connector requires two different addresses:
Internal Host and port: this should be the real network address of your on premise system. Typically the SAP Netweaver Gateway where the service URL is in. The address must be reachable from the Cloud Connector server
Virtual Host and port: this should be a non real (virtual) address. It’s a must that this address match the URL address of a destination configured in SAP Cloud Platform.
Moreover, apart from the on premise configuration you must enable which URL paths are allowed to be accessed from the cloud
Check whether your cloud connector and SAP LogOn OData service are in the same network. Then only the SAP cloud connector can reach your on-premise system through a secure channel.
I have multiple Service Fabric APIs. Both services are hosted in the same cluster using Kestrel. Currently each service is assigned to a specific port so they show up as
http://service1:123 and
http://service2:456
I would like to access the services using default port 80 for both. Is there a way to do this without having to use Azure API Management?
Sure, Kestrel doesn't support port sharing, but you can:
run on IIS, inside containers.
use the built in reverse proxy
use a (containerized) reverse proxy like Traefik
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.