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.
Related
Cloud Run is providing a domain *.run.app to access the service deployed. I am wondering how Google Cloud Run handling requests from one to another Cloud Run service. Is all the service to service communication internal even we have a custom domain instead of *.run.app?
The definition of "internal" is not clear.
Your request stay in the Google Network. Is it internal or external?
To resolve the Custom Domain, a DNS resolution request (port 53) is performed on the public network, but the content of the request stays in the Google Network and forwarded after the resolution. Is it internal or external?
So, as long as you use Google Services (in premium network option), you don't go out of the Google Network and thus you can consider this as highly secured.
I assume, my answer isn't very clear, in fact all depend if you trust or not the Google Cloud network.
Should I be able to setup secure gateway to be able to connect to my on-prem SQL server DB, using SQL Server Management Studio on my laptop from home (not on prem)?
You don't "have to" use the secure gateway in order for your application on the cloud to see your local db. You could simply give your application the public ip (and port) of the local machine and they should work fine.
It is however a good practise to use the Secure Gateway service as it can ensure the security of the local-to-cloud communication. Make sure to have a look at the documentation to learn how the service works - https://console.ng.bluemix.net/docs/services/SecureGateway/secure_gateway.html
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.)
I am going to use Secure Gateway service in Bluemix and I have some questions about how I should make it work.
Systems in my data center's intranet access the Internet through a proxy (with no authentication). Can Secure Gateway connect to Bluemix via a proxy?
Does it connect to Bluemix via HTTPS protocol?
The network admins asked me: What are the IPs (or the IP range) of Bluemix, any idea?
Thank you very much.
A Secure Gateway instance runs in two parts, as shown in "Reaching enterprise backend with Bluemix Secure Gateway via console": the gateway and the gateway client. The gateway runs in Bluemix, the gateway client runs in the data center containing one or more systems of record to connect to. The gateway client needs network access to the Bluemix data center (typically via the Internet) and to the systems of record (via the data center's internal network). The gateway client initiates the connection, so it needs to know Bluemix's address, but Bluemix doesn't need to know the gateway client's address.
To answer your questions specifically:
A proxy isn't supported. The gateway and its client need direct access to each other.
The connection uses HTTPS for SSL encryption. The transport level security (TLS) options can be used to add authentication.
Bluemix's IP addresses aren't published.
For point 3:
The client connects outbound to the cloud services. Once the SecGW is connected, all additional Destination connects flow through that connection, no additional firewall or iptables rules are needed. If they have a rule in-place so that the on-premises machine where the SecureGateway client is installed can use the outbound port 443 (HTTPS) to make connections, that is all they need.
I have created an API via basic secure connector (SOAP). The API works but I am wondering why I can't retrieve the endpoint URL from VCAP_SERVICES. Anything I miss here?
Are you using the secure connector portion of the Cloud Integration service in Bluemix? You might want to try the Secure Gateway service, which is newer and is basically just the secure connector as a standalone service without the rest of Cloud Integration.
"Reaching enterprise backend with Bluemix Secure Gateway via console" explains how to set up a Secure Gateway instance. When you create a destination, that creates an integration.ibmcloud.com URL that your app can then use to connect to your destination via the gateway. The gateway is a proxy, preserving the interface, so the cloud host URL has the same API as the destination host.