I want to access the basic Bluemix CLI to do some infrastructure management (formerly softlayer) however the way I have configured my network is that all virtual machines are on a private VLAN with no access to the public internet, thus the Bluemix CLI tool is trying to access API endpoint:
https://api.softlayer.com/rest/v3.1
however it is failing:
Get https://api.softlayer.com/rest/v3.1/SoftLayer_Account/getCurrentUser.json: dial tcp 66.228.119.120:443 : i/o timeout
this is just trying to issue the preliminary bx sl init command with my username and API key I generated in the portal.
How does one access this from a private VLAN? Is is possible? or are all tools available to me useless?
Thanks-
Try by using the following endpoints for private networks
https://api.service.softlayer.com/rest/v3
or
https://api.service.softlayer.com/rest/v3.1
Reference:
https://softlayer.github.io/blog/klaude/its-time-bust-out-private-network/
Related
I'm currently tasked with setting up a secure, non-public connection between APIM and a Web API, and I've opted to use Private Endpoints for both services. The problem is that when Private Link is enabled on both, APIM can no longer connect to the Web API.
I've searched for similar questions online, but none of them seem to have Private Link enabled on APIM. Here's what I've done so far:
I created a virtual network called VNET1 with two subnets: PrivateLink-Subnet and VM-Subnet.
I deployed a simple Web API as a Web App, enabled private link, and used PrivateLink-Subnet.
Microsoft automatically created a private DNS zone for it. After this setup, the Web App is not accessible to the public, as expected.
To test VNET resources and Private Link, I used a Windows Virtual Machine, and from within the VM, I could access the Web API through "myapi.azurewebsites.net". So far, everything seems to be working well, as the app is only accessible from within the VNET.
For API Management, I selected "None" for the Virtual network settings, as per the documentation, and instead created a Private Endpoint. I chose the same VNET1 and PrivateLink-Subnet for the private endpoint and added a single API to the APIs, pointing to "myapi.azurewebsites.net".
The issue arises when I try to connect to the API through APIM gateway, as it returns a 403 error, saying that the APP has blocked my access. When I do an NSLOOKUP from within the VM, both APIM and the Web App are resolving to the same subnet, which is expected as both private links use the same subnet.
I believe for some reason APIM still try to resolve the API to the public IP address even though the Private DNS zone in Web APP and Private link has a records to sort that out!
I tried putting the private links on different subnets, but still no luck.
And if I go to the Networking section of the Web APP and enable public access, everything works like a charm, but that's not what we want. We need this to be accessible via VNET only and then later we'll add a VPN so people can access the APIs through APIM only when connected through the VPN.
FYI, if I choose Virtual Network type of External or Internal on APIM, everything works fine. But we're supposed to use Private Link for both the Web APP and APIM. no exposure to the internet!
We are getting below error on Azure devops pipeline via Self hosted agent release when Azure web app is on Private network. No Error seen when the web app on azure is on Public.
Error: Error: Failed to deploy web package to App Service. Error: tunneling socket could not be established, statusCode=503
Made Azure web app to private and error comes. Moved to public no error seen.
Seems that the self-hosted agent cannot connect to the Azure app service. It seems to be a network issue.
The agent needs a way to connect to the App service directly. To ensure the connectivity is ok, we need to make sure the self-hosted agent is not blocked by NSG rules or App Service networking Access Restrictions. Just whitelist the agent machine in your rules.
The task using Kudu REST API to deploy the application. We need to check the following App Service networking Access Restrictions to allow deployment from a specific agent:
Make sure the REST site “xxx.scm.azurewebsites.net” have Allow All, i.e. no restriction.
Also, the option “Same restrictions as ***.azurewebsites.net” should be unchecked.
If you are using Private Endpoints for Azure Web App, you must create two records in your Azure DNS private zone or your custom DNS server. Kindly check DNS for more details.
Besides, when the proxy is set up, Web API calls and SCM hosts are bypassed by the user. The same has to be configured in the Azure pipelines agent explicitly. To bypass specific hosts, follow the steps here and restart the agent.
1.Allow access to Public removed.
2.Created Pvt endpoints within same Vnet and Subnet of Target VM
3.Created new file .proxybypass in self hosted agent folder C:\Username\Agent
4.Added below entries in .proxybypass to allow and communicate bypassing corporate proxy
https://MyWebappname.azurewebsites.net
http://MyWebappname.azurewebsites.net
enter code here
Google has nice ways to connect to cloudsql from other google services but I cannot see how to connect from ai-platform jobs. As part of our training job, we need to update our cloudsql db with metrics but the only I could get it to work is by whitelisting all IPs (don't want that!) in the cloudsql and connecting via the public IP. I don't see an option to add cloud-sql-proxy to the trainer instance. Since the IP of the trainer instance is dynamic, we cannot reliably add specific IP address to whitelist. Any other ways to handle this?
It looks like AI Platform supports VPC peering, so you should be able to connect to Cloud SQL using private IP.
Since Cloud SQL also uses VPC peering, you'll likely need to do the following to get the resources to connect:
Create a VPC to share (or use the "default" VPC)
Follow the steps here to setup VPC peering for AI Platform in your VPC.
Follow the steps here to setup a private IP for your instance in your VPC.
Since the resources are technically in different networks, you may need to export custom routes (Step #2) to allow the AI platform access to your Cloud SQL instance.
Alternatively to using private IP, you could keep using public IP w/ an IP allowlist coupled with Authorizing with SSL/TLS certificates. This still isn't as secure as using the proxy or private IP (as users are technically able to connect to your instance), but they'll be unable to interact with the database engine without the correct certificates.
Can you publish a PubSub message from within your training job and have it trigger a cloud function that connects to the database? AI Platform training seems to have IAM restrictions that I too am curious how to control.
I have 2 GKE cluster both private and public and using cloudproxy as sidecar container for gke app to access cloudsql instance.
public cluster setup for development/testing
Cloud SQL is enabled with both private and public IP.
GKE app is using cloudproxy with default option of ip types (public,private) as below
Cloud SQL doesn't have any authorized network.
In this case, my app is able to connect CloudSQL and works smoothly. As far as I understand, here connection to cloudsql should be happening with private becuase there is no authorised network configured.
private cluster setup for production
Cloud SQL is enabled with both private and public IP.
GKE app is using cloudproxy with default option of ip types (public,private)
cloudsql-proxy setting in deployment file
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.11
command: ["/cloud_sql_proxy"]
args: ["-instances=$(REAL_DB_HOST)=tcp:$(REAL_DB_PORT)","-credential_file=/secrets/cloudsql/credentials.json"]
case 1
Cloud SQL doesn't have any authorized network.
Result: Application is not able to connect with Cloud SQL
case 2
Cloud SQL have private GKE NAT gateway as authorized network
Result: Application is not able to connect with Cloud SQL
May be removing cloudproxy from application will work (I am yet to test) but it discourages the usage of proxy during dev env as it will need changes in deployment file during production deployment.
I am not able to understand what is causing the connection failure with cloudproxy in gke private cluster. Should we not use cloudproxy in private cluster?
Update
The reason due to which cloud proxy not able to connect cloud sql was disabled Cloud SQL Admin API. I have updated my answer in answer section.
It looks like the question here is "Should we use the Cloud SQL proxy in a private cluster?" and that answer is "it depends". It's not required to connect, but it allows for more security because you can restrict unnecessary access to your Cloud SQL server.
The Cloud SQL proxy doesn't provide connectivity for you application - it only provides authentication. It has to be able to connect via the existing path, but then uses the Service Account's IAM roles to authenticate the connection. This also means that it doesn't have to come from a whitelisted network because it's been authenticated by a different means.
If you want to use the proxy to connect via Private IP (instead of defaulting to public), use the -ip_address_types=PRIVATE - this will tell the proxy to connect with the instance's Private IP instead. (Please note that if the proxy lacks a network path (eg, isn't on the VPC) that proxy will still be unable to connect.)
#kurtisvg has provided an informative answer to it.
However the real issue was SQL Admin API and enabling it fixed the issue. After looking into the logs I found below entry.
Error 403: Access Not Configured. Cloud SQL Admin API has not been used in project XXXXXX before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?
The issue for me was enabling Private cluster in GKE cluster :(
Because of private GKE cluster it wasn't having access to external IP addresses and fix was to create a NAT gateway with cloud router as per https://cloud.google.com/nat/docs/gke-example.
Hint if it's the issue is you won't be able to ping to google.com etc from the container after logging into it.
We have an Azure App Service Environment, which resides in a subnet in a vnet configured with both an expressroute gateway and a VPN gateway. When trying to connect an AppService outside of the ASE to the Vnet, as described here: https://learn.microsoft.com/nb-no/azure/app-service/web-sites-integrate-with-vnet, we are not able to connect, because it says the gateway is not a VPN gateway.
I suspect the GUI only picks the first gw in the list when it tries to figure out what type of gw it is.
Because, we do have a vpn gateway too:
I have a couple of questions:
Is there a way to get the Portal to use the correct gateway when
trying to connect from the AppService to the Vnet?
If not, is there a way to do this from Powershell with the AzureRm CmdLets?
Currently, it is not possible. It is a design behavior. Integrate web app with an Azure Virtual Network does not support Vnet that has an ExperssRoute Gateway. If ExperssRoute is in it, you will get the error log.
You could check the link you provided.
The VNet Integration feature does not integrate an app with a VNet
that has an ExpressRoute Gateway. Even if the ExpressRoute Gateway is
configured in coexistence mode the VNet Integration does not work. If
you need to access resources through an ExpressRoute connection, then
you can use an App Service Environment, which runs in your VNet.
Update:
If you need this function, you could vote up this feedback.