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.
Related
Maybe this is a dumb question, but I really don't know if I have to secure applications with tokens etc. within a kubernetes cluster.
So for example I make a grpc-call from a client within the cluster to a server within the cluster.
I thought this should be secure without authenticating the client with a token or something like that, because (if I understood it right) kubernetes pods and services work within a VPN which won't be exposed as long as it's not told to.
But is this really secure, should I somehow build an authorization system within my cluster?
Also how can I use a service to load balance the grpc-calls over the server pods without exposing the server outside the cluster?
If you have a service, it already has built-in load balancer when you have more than one replica out of the box.
Also Kubernetes traffic is internal within the cluster out of the box, unless you explicitly expose traffic using LoadBalancer, Ingress or NodePort.
Does it mean traffic is safe? No.
By default, everything is allowed within Kubernetes cluster so every service can reach every service or pod in StatefulSet apps.
You can use NetworkPolicy to allow traffic from one service to another service and nothing else. That would increase security.
Does it mean traffic is safe now? It depends.
Authentication would add an additional security layer in case container is hacked. There could be more scenarios, but I can't think of for now.
So internal authentication is usually used to improve security in production systems.
I hope it answers the question.
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.
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/*.
Azure VM, Cloud service or Web job?
I have a configurable console application which runs continuosly. Currently it is running on a VM and consumes lot of memory (it is basically doing data mining).
The current requirement is to have multiple instances of this application with different set of configuration which can be changed by specific users.
So where should I host this application such that the configuration can be modified using some front end which provides access managements(like Sharepoint),ability to stop it/restart (like WCF service) without logging on the VM?
I am open to any suggestions/ideas. Thanks
I don't think there's any sold answer to this question as there is the preference variable but for what it's worth, if it were up to me I would deploy it against individual azure VM's for each specific set of users. That way if the server resources went up because of config changes the user group made it is isolated to that group, and with azure, will scale automatically to meet the resource demand. Then just build a little .net web app to allow user to authenticate and change configuration settings.
You could expose an "admin" endpoint for your service (obviously you need authentication here!) that:
1. can return the current configuration
2. accept new configuration
3. restart the service (if needed). Stopping the service will be harder, since that leaves the question on how to start it again.
Then you need to write your own (or use a 3-party (like sharepoint or a CMS)) application that will handle your users and under the hood consume your "admin" endpoint.
Edit: The hosting part: If I understand you correctly your app is just an console application today, and you don't know how to host it? Well, there are many answers to that question. If you have a operations department go talk to them, if you are on your own play around and see what fits you and your environment best!
My tip: go for a http/https protocol/interface - just because there are many web host out there, and you can easy find tools for that protocol. if you are on the .NET platform check out Web.API or OWASP
Azure now has Machine learning to process data mining.
You should check if it's suit to you.
Otherwise, you can use Webjob:
Allow you to have multiple instances of your long time running job (Webjon scaling out).
AppSettings can be change from the Azure Portal or using the Azure Management API
We have developed a cloud based POS system which running on more that 75 outlets and all the transaction data need to be posted every 5 minutes to the relevant database which sits on our head office (POS System is connecting to its own local database). For this we are using windows application which is directly connecting to our head office database through a VPN. But recently one of our clients raised a concern that our head office database is exposed because if anyone sneak to the network (obviously inside the VPN) he could see all CRUD Operations. So by this way he could do anything to head office database.
So we have decided to go for a WCF solution with encrypted JSON Call. If we use a web service can we eliminate this issueccompletely. Is it the best practice? Please advice.
There are several aspects of security to consider in your situation. If your current network topology doesn't limit the VPN client's visibility to just your database server, then yes, I agree that moving to publishing a web service endpoint and using HTTPS would improve security by blocking clients access to other servers on your internal network. However, the web service solution introduces some other considerations. Will you use firewall rules to limit which clients can access the web service? How are you authenticating clients, and how are you protecting those credentials from unauthorized users?