I'd like to implement micro service architecture on CF (run.pivotal.io) and have problems with creating my private backend services.
As I see I have to options at deployment: with and without route.
With route my services becomes public which is ok for my public site and my public REST API, but I don't want it for my backend services.
Without route I don't see how should I do service discovery.
What I found already:
Use VCAP_APPLICATION env variable and create my own service discovery (or use something like Eureka) based on that. Does this give me always a valid IP:PORT? No matter what DEA my app is running it is reachable on this IP:PORT by other apps on other DEAs?
Register my backend app as a service and bind it, than use VCAP_SERVICES. I'd like to do this but only found documentation about registering services outside CF. Is there a simple way to bind my own app as a service?
So what would be really nice is to be able to mark an app as private but still assign a host and domain to it, so (only) my other apps could call it though CF load balancers but it would be protected from the public.
Answers inline...
As I see I have to options at deployment: with and without route.
This depends on the Cloud Foundry installation and how it's configured. On PWS, you cannot talk directly between application instances. It's a security restriction. You have to go through the router.
With route my services becomes public which is ok for my public site and my public REST API, but I don't want it for my backend services.
The best you can do here is to add application level (or container level, if you prefer) security to prevent unauthorized access.
If you don't want to do password based authentication, you could do IP based filtering. On PWS, we just added a service with Statica. You can use that to send your outbound traffic through a proxy which will assign a static IP to that traffic. You could then restrict access to your app to only the Statica IPs.
Without route I don't see how should I do service discovery.
If you remove the route, you can't sent traffic to the app.
Use VCAP_APPLICATION env variable and create my own service discovery (or use something like Eureka) based on that. Does this give me always a valid IP:PORT? No matter what DEA my app is running it is reachable on this IP:PORT by other apps on other DEAs?
You'd probably need to use this enhancement. It was added to support this type of deployment. However this will only work on Cloud Foundry installation where the networking restrictions between application instances have been relaxed. Normally you cannot talk directly between instances.
Register my backend app as a service and bind it, than use VCAP_SERVICES. I'd like to do this but only found documentation about registering services outside CF. Is there a simple way to bind my own app as a service?
You can create a "user provided" service. Look at the cf cups command. It lets you create a service with an arbitrary set of parameters and data. This could contain the URLs for your services. Once you create the service, you can bind it to any number of apps.
Related
I successfully created the Azure Container App named my-app-name to host the Python Flask App.
The hostname for my app uses FQDN, so it looks like my-app-name.grayocean-1r2fd430h.centralus.azurecontainerapps.io.
I would like the hostname to be more user-friendly, for example my-app-name.azurecontainerapps.io (similar to the App Service, where it's named my-app-name.azurewebsites.net by default)
What should I do to make my custom hostname point to the Container App?
Unlike app service, in container apps there is a concept of an environment that groups all your apps that might need to communicate together whether it's for microservices or other designs you might have. the grayocean-1r2fd430h.centralus part is the unique part for your particular environment in this case.
However, From Container Apps you have 2 options here to give your app a custom domain:
1- You can use a different suffix for all the apps on your environment. i.e: replacing .grayocean-1r2fd430h.centralus.azurecontainerapps.io with some domain you might have, like .cornisto.io for example See https://learn.microsoft.com/en-us/azure/container-apps/environment-custom-dns-suffix for how to configure that.
2- You can assign custom domains per container app where each application can have its own set of custom domains that route to it. See this doc for how to set that up https://learn.microsoft.com/en-us/azure/container-apps/custom-domains-certificates
You could also use a service like Azure Front Door or API Management to proxy traffic to your application and the configuration of a custom domain would be on that end instead.
I have an Azure Static Web App developed using Angular (let's say my company homepage) which needs to be publicly accessible w/o authentication. If I wanted some dynamic content on the home page which comes from a database (i.e. news items or a product list), are there any ways to "secure" an Azure Function endpoint that supplies this data to the front end.
"secure" == I'd like to limit access of the endpoint to just my Azure Static Web App.
I'd also like to set up a function that listens for IPN requests from PayPal and so I'd like to configure that function to only be accessible from PayPal.
I see that I can configure CORS to only allow specific domains access to a function -- is this my best option?
There are two ways to look at it,
(i) Azure has APIM Service which allows to secure certain endpoints and is probably the best way how to handle Azure Functions endpoints for public.
(ii) You can also secure the functions by adding application gateway and whitelist the IP address of the Application gateway in the function or you can build functions inside a vnet using the azure environment service.
You can read more about Securing Azure Functions here
I have Azure App Services behind the Azure Application Gateway/Firewall. There are few application that talks between them. Does that applications talk internally(using xxx.azurewebsites.net) or they talk with public domain(mydomain.com)?
Also, how to check these things in logs.
Current configuration:
HTTPSettings: Pick hostname from the backend address has checked.
Probes: pick hostname from backend https settings has checked.
To answer your question, No if your applications are inside azure's network, it usually wont go through the public domain. But it will go through the firewall/gateways and follow the same networking restriction you have defined.
What logs you want to check? if you want to see the application event logs you can do it using scm. You can access it via Diagnostics/Advanced Tools in your azure app services.
You can enable Access Logs in the Application gateway to see all the request that hits Application Gateway. It has the hostname field where you can check how the site is being accessed.
Let me know if you have any further questions.
I have two services running in my Service Fabric cluster. Let's assume they are Service A and Service B, both of them are Stateless Services. I am using the dns service method to communicate between A and B and the entry point in B is an api which has a route. Now this route is also publicly accessible since I have exposed port 80 publicly for that service. And even though someone who is trying to access this api will have to send the appropriate Auth tokens, I still don't want to be able to anyone outside the cluster to access this api. Is there any other way I can achieve what I am trying to do? I know another way is to use the service proxy pattern but for some reason that did not work for me.
Is there any way to secure an HTTP endpoint of an Azure Logic App ?
For example if I'm using my Logic App's HTTP request endpoint to be triggered as a webhook from a payment gateway, I'd want to restrict only certain static IP Addresses to access it and enable HTTPS.
I didn't find any firewall options like those present in Azure SQL for IP base restrictions.
You can put the manual trigger endpoint behind Azure API Management, using its "Restrict caller IPs" policy should help you accomplish what you need.
See https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-securing-a-logic-app
Restrict incoming IP addresses
In addition to the Shared Access Signature, you may wish to restrict calling a logic app only from specific clients. For example, if you manage your endpoint through Azure API Management, you can restrict the logic app to only accept the request when the request comes from the API Management instance IP address.
This setting can be configured within the logic app settings:
In the Azure portal, open the logic app you want to add IP address restrictions
Click the Access control configuration menu item under Settings
Specify the list of IP address ranges to be accepted by the trigger
A valid IP range takes the format 192.168.1.1/255. If you want the logic app to only fire as a nested logic app, select the Only other logic apps option. This option writes an empty array to the resource, meaning only calls from the service itself (parent logic apps) fire successfully.
I could be wrong but all App Services (Web Apps, Logic Apps, API Apps) are, by default, publically accessible and, by default, do not enable IP Filtering via Azure resource configuration (meaning, a setting on the Logic App). Options I can think of enabling this would be:
If you have access to a Web.config, use an element to restrict traffic to only a specific set of address (see MSDN)
Consider putting the Logic App behind an API Management resource and enforce a IP restriction policy (see Azure API Management Documentation); I'm guessing this may not apply for Logic Apps but including it anyway
Scale to a Premium App Service Plan, deploy Logic App to an App Service Environment which gives you the ability to specify whether there is a Public IP (VIP) used for load balancing requests or internal load balancer (which would be used for cross-premise connectivity between your LAN and Azure); you can also deploy a virtual Web Application Firewall (WAF) which would allow you to place explicit IP filters as well
Not knowing your requirements, I'd lean more towards option 3 simply because there is documentation supporting that scenario (at least for Web, Mobile and API Apps -- Logic Apps are not mentioned). Otherwise, if you're not able to modify the web.config to include the filters and cannot put an API Management instance in front of the logic app, I'm not sure what other options you may have.
Hope this helps and if you find a solution, I'd be interested in learning it as well.