Our customer is planning for APIC on Bluemix cloud to On-premise connectivity for IIB APIs.
For secure connection we are planning to use Secure gateway service on Bluemix and creating secure gateway client on customer existing DataPower .
At present there is an internet connectivity via eth0 of DataPower at customer datacenter where a service is running on 443.
We want to seggregate traffic comming from Bluemix and the existing non-bluemix traffic.
So We are planning to create a new eth1 dedicated for Bluemix calls, that will also talk to internet on port 443 and 9000 (as required by secure gateway service) .
How do we make sure Bluemix traffic cames to Gateway via Eth1
The Secure Gateway Client initiates the connection to the SG Servers in Bluemix with the combination of requests across 443 and 9000. Once that connection has been initiated, it will remain open and all traffic from Secure Gateway will travel across it.
Related
I'm trying to setup Identity Aware Proxy for my backend services parts of which resides in GCP and other on on-prem,according to the instruction given in the following link
Enabling IAP for on-premises apps and
Overview of IAP for on-premises apps
After, following the guide I ended up in a partial state where services running on GCP serving at https endpoint is perfectly accessible via IAP. However, the app which is running on on-prem is not reachable through pods* and external loadbalancer*.
Current Architecture followed:
Steps Followed
On GCP project
Created a VPC network in any region with one subnet in my case (asia-southeast1)
Used IAP connector https://github.com/GoogleCloudPlatform/iap-connector
Configured the mapping for 2 domains.
For app in GCP
source: gcp.domain.com
destination: app1.domain.com (serving at https endpoint)
For app in on-prem(Another GCP project)
source: onprem.domain.com
destination: app2.domain.com (serving at https endpoint but not exposed to internet)
Configured VPN Tunnel between both the project so the network gets peered
Enabled IAP for the loadbalancer which is created by the deployment.
Added corresponding accounts to allow access to the services with IAP web-user role.
On-prem
Created VPC network in a region with one subnet (asia-southeast1)
Created VM on VPC in that region
Assigned that VM to an instance group
Created Internal Https loadbalancer and chose instance group as backend
Secured load balancer http with ssl
Setup VPN tunnel to the first project
What I have tried?
logged in to pods and pinged different pods. All pods were reachable.
logged in to nodes and pinged the remote VM on port 80 and 443 both are reachable.
pinged remote VM from inside the pods. Not reachable.
Expected Behaviour:
User requests to loadbalancer on the app1.domain.com which IAP authenticates and authorizes user with OAuth and grant access to the webapp.
User requests to loadbalancer on the app2.domain.com which IAP authenticates and authorizes user with OAuth and grant access to the webapp running on on-prem.
Actual Behaviour
Request to the app1.domain.com prompts OAuth screen after authenticating the website is returned to the user.
Request to the app2.domain.com prompts OAuth screen after authenticating the browser returns 503 - "No healthy upstream"
Note:
I am using a separate GCP project to simulate on-premise.
Both projects are peered via VPN tunnel.
Both peering projects have subnets in the same region.
I have used internal https loadbalancer in my on-prem project to make my VM visible in my host project so that the external loadbalancer can route request to the VM's https endpoint.
** I'm suspecting that if pod could able to reach the remote VM the problem might as well be resolved. It's just a wild guess.
Thank you so much guys. I'm looking forward for your responses.
Is it ok to have a microservice exposing a public REST API to a gateway but also communicate with other services through messaging?
At least add some kind of identifier which is known only by the gateway or check the IP address if it is dedicated to the gateway. I hope you are using an encrypted communication protocol. Can't you do this via VPN, SSH tunnel or something more secure?
I want to consider using a Bluemix to run my application? For a firewall problem, I want to use a secure gateway of IBM that is one service in Bluemix. It uses a web socket. I customized a web socket of jetty in the past. So I am wondering if a web socket client makes a permanent connection with a web socket server. Does the server giving data back to the client? If the connection is disconnected for some reason, how can the web socket handle this exception?
If you're wondering about how Bluemix Secure Gateway handles these situations, then yes, the Secure Gateway Client creates a persistent secure websocket connection to the Secure Gateway Servers which allows for the necessary communication between your application and your resource(s) behind the firewall. If the websocket connection goes down, the Secure Gateway Client will attempt to establish a new websocket connection with the Secure Gateway Servers.
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.
Does the Datapower Secure Connection in Bluemix require the Datapower to be internet facing ?
If Bluemix starts the connection, the answer is maybe yes.
But as the Basic Secure Connection (Software), if that one initiates the connection, the server running the Basic Secure Connection only needs to have internet access (behind a firewall/gateway/etc...), but doesn't need to be internet facing : IP# on internet.
I have set up a Bluemix DataPower Secure Connection (in the Bluemix Cloud Integration Service) towards my on-premise DataPower appliance. The DataPower Secure Connection are pointing to an Internet IP, and my on-premise firewall maps this to the DataPower appliances "DMZ" ethernet interface.
On the DataPower appliance, the Cloud Gateway Service is configured to receive connections from the Bluemix DataPower Secure Connections. This seems to work well for endpoints I have added to the Cloud Gateway Service. Right now I am working on adding (1-way and 2-way) TLS in the Bluemix DataPower Secure Connection.
To my knowledge the DataPower connector and the Basic Secure connector must be able to connect to your DataPower. This is usually initiated by the on-premises side, either your DataPower or the Basic Connector client running on-premises.
Also, DataPower v7.2 now supports Secure Gateway connectivity which is the preferred way to securely connect your cloud applications to your on-premises DataPower resources. The UI for DataPower has been updated to provide the ability to configure for these connections.