I have an Azure SQL Managed instance with public endpoint disabled (we store sensitive data and do not want an exposed endpoint on the DB). We have a VNET and when we need to access our SQL managed instance from an administrator's machine, we use a VPN. How do I connect Power BI to my SQL Managed instance for reporting? I've been digging and am surprised that the only way I can see is to either:
Create a virtual machine and host a data gateway
Expose the public endpoint on the SQL Managed instance.
I may accept 2 if I can limit access to Power BI itself but I'm not convinced that's possible.
Any suggestions are welcome!
You can also secure the public endpoint allowing access to powerBI only using Azure Service Tags. Documentation can be found here https://learn.microsoft.com/en-us/power-bi/admin/service-premium-service-tags
I'm confused with some of these supposed solutions since I'm looking at PowerBI.com and it only has 4 options and managed instance is not one of them....
See: Create Dataset - Databases & More option and there's only 4 options for connecting to a database... That's it folks.
Sure you can connect from desktop but that won't do you any good once you publish it to powerbi.com unless that site supports connecting to the source.
Yes you can create a gateway which I believe is currently the only solution. Why oh why isn't Managed Instance one of the options for databases when you create a dataset on powerbi.com? That tells me they do not support it, regardless of whether you've enabled public endpoint. As far as I know you still would have to use a gateway to access it if it's not one of these options. Or...something silly like create Azure REST services just to talk to your database.
Related
I want to ask a conceptional question and take advices about possible system design if possible.
The plan is basically authenticating specific Gmail users to use my serverless backend application. I'm thinking about either forwarding users directly to my VPC or I can authenticate them in my host-provider server and then after forward them to the VPC (or directly Cloud Run service?).
I'd be really glad if someone experienced can lead me about concepts and suggest design ideas about this.
As commented by#John Hanley, your question has concepts that do not exist.
To invoke Cloud Run authentication to specific users to use your serverless backend application, go through below required possible systems designs :
1)Initially design how to describe IAM roles that are associated with Cloud Run, and list the permissions that are contained in each role.
2)Design how to secure and Configure Cloud Run to limit access to Cloud Run service with Identity aware Proxy(IAP).
3)Design how to create a Serverless VPC Access connector and also know how to use IAP for TCP forwarding within a VPC Service Controls perimeter.
4)Step by step implementation of how to use IAP to secure portal access without using a Virtual Private Network (VPN). IAP simplifies implementing a zero-trust access model and takes less time than a VPN for remote workers both on-premises and in cloud environments with a single point of control for managing access to your apps.
Solution to the what I had in mind was could be accomplished by Identity-Aware Proxy.
I have a Web App (Azure App Service) and I have an Azure SQL Database that this Web App talks to. I have two questions regarding communication between the two.
When connecting from the Web App to the Database (using the connection string), does the communication go out to the internet and then back into Azure or does Azure know to keep the traffic locally in Azure?
I have been looking into V-Net Service Endpoints as a possible way to improve speed of communication between the two. It is said that when connecting from a VM on V-Net with Service Endpoints enabled to a SQL Database, that Azure knows to keep the traffic internal to the Azure network and not go out to the internet, is this the same for Azure App Services?
Is it possible to keep traffic between an App Service and SQL Database internal to Azure? If so, how do I go about doing this? Any guidance on this is greatly appreciated.
It knows to keep it local on the "Azure backbone" (as per Azure doco). It doesn't go out to the public internet
Yes
Yes. It is already internal to the "Azure Backbone"
Having said that.... networks are really complicated.
As I understand it the main benefit of V-Net is that you can define your own network and add things to it like firewalls, security groups, subnets, peering between networks. Also it helps when setting up a hybrid network - i.e. connecting Azure resources to an on-premises network. When you can set up the same kind of structures as on premise, it's easier to 'transparently' make it part of the on-premises network. Lastly (rereading the doco), you can remove any incoming public IP firewall rules. These are "Azure backbone" IP addresses but they are also "public internet" addresses
There may be a performance improvement if the App Service and Azure SQL are on the same V-Net.
Azure SQL service endpoints are a bit mysterious. They "connect" to the VNET but you still need to connect to a public address. They don't actually take a up a local IP adress.
Depending on what you are really doing, you might want to look into private endpoint, which actually assigns a private IP to your Azure SQL.
Yes, communication between Azure App Service and Azure SQL Database is "local" within the Azure Virtual Network and does not go out to the public internet.
Scenario :: we want to enable communication between on-premise SQL Server and Azure SQL MI which should be super secure and fast.
After researching a lot, we have found two solutions::
Public endpoint
Site to Site (VPN)
Question :: now we are confused about which way we should go-ahead and Why?
Requirement :: have connectivity between on-prem SQL server and Azure MI so that we can push data to Azure SQL MI via a custom-built application.
The VPN option is difficult to configure if you are not a network expert. You need to have good knowledge of VNet, ExpressRoute and VPN P2S and understand new notions of Azure networking. The VPN option does not provide separation of duties. The VPN option has also some known issues in terms of throughput so the endpoint gives you better performance.
The public endpoint option is easier to configure and allows for separation of duties. Your database administrator will enable the endpoint and the network administrator will make accesible the endpoint by opening port 3342 and provide a UDR route. Your DBA will need RBAC permissions on scope Microsoft.Sql/managedInstances/* while your administrator will need permissions on Microsoft.Network/*.
We have a SQL Azure database and enabled VNET service endpoint. The service endpoint is listed in our VNET and the Azure SQL lists our VNET. According to documentation found here, connections applications inside our VNET should use the Azure backbone and not travel through the public internet.
There was another stack overflow article asking a similar question but I still didn't see an answer (maybe I missed it). That article is here
This is great, but I don't see how to build the connection string to utilize this internal network path since the only name available is the public DNS name (which we can still use with SSMS to manage the server from our on-premise location).
Is Azure smart enough to know that this public DNS name is routed differently when used inside the VNET versus when its used from our on-premise site?
Is Azure smart enough to know that this public DNS name is routed differently when used inside the VNET versus when its used from our on-premise site?
Yes. And that doesn't even require a VNET service endpoint. Connections within Azure, even across Regions never leave Microsoft private networks.
A Virtual Network Service Endpoint is mostly just a firewall rule on your SQL Instance, so you can cut off all public IP access if you want.
I have an Azure VM with SSAS Tabular Model.
I understand that using Virtual Network it can be accessed from On-Premise.
But is it possible to access it using DAX queries without creating Virtual Network?
Short answer: No - you need a Virtual Network in this scenario (link)
Long answer: Maybe. It might be possible to use HTTP Access to SSAS via IIS but I've never tried it nor have I come across any blogs/whitepapers where it has been tried.
Is there a specific reason why you want to avoid setting one up? It really does make things much easier in Azure.
we use an HTTP proxy
Just set up as normal but remember to configure an endpoint on the TCP and SSAS ports in AZURE