Anyone can tell me what kind of service fits on this use case below:
I want to expose a public IP that receive HTTPS/HTTP requests and forward the traffic to my services I have in on-prem.
Looking for Azure, AWS, etc, etc, are there some service that serve to my problem?
Regards...
If you are using using Azure and you want HTTPS based request to be sent to your backend APIs (which can be on prem or on any cloud) you can check for Azure API Management (APIM).
You can use the APIM with or without VNET.
APIM can be used in External Mode if you want to integrate a VNET to perform data plane operations which will expose a Public IP as well as a Gateway URL which you can be used to send HTTPS traffic.
Reference:
https://learn.microsoft.com/en-us/azure/api-management/api-management-using-with-vnet?tabs=stv2
https://learn.microsoft.com/en-us/azure/api-management/api-management-key-concepts#scenarios
Additionally, you can also check out Application Gateway
Reference:
https://learn.microsoft.com/en-us/azure/architecture/example-scenario/gateway/firewall-application-gateway
Related
I've created a SOAP Service in ABAP, which perfectly works inside the network.
Now I wan't it to be called from outside and I haven't really found any tutorial.
Most likely a SAP Web Dispatcher or a reverse proxy is required, but how to use them?
Or is there an easier way to make the endpoint "public" and callable from the "outside"?
Making it public not part of SAP system. You need to configure your network to allow incoming request. Generally you need to configure your firewall. You need to open a port on firewall and redirect it to your SAP server http/https port. It will also create a risk for opening http/https port to outside. You must sure about limit your your web service user authorizations and changing all default passwords and using update date SAP system for security patchs.
For more get security I prefer to use a proxy server like nginx/apache to just serve your SOAP service over it.
Usually it is done thourgh reverse-proxies, to minimize risk of attacks from public Internet.
The general schema looks the same, although there are multiple variations depending on the company
The oldest and the most traditional reverse-proxy for SAP systems is a Web Dispatcher
SAP Web Dispatcher it includes load balancing and HTTP filtering
https://informatik.rub.de/wp-content/uploads/2021/11/2_sap-secure-configuration.pdf
https://wiki.scn.sap.com/wiki/display/SI/FAQ+Web+Dispatcher
https://blogs.sap.com/2021/05/09/landscape-architecture-sap-web-dispatcher-deployment/
SAP Gateway is a framework for exposing functionality as REST/SOAP web-services
https://blogs.sap.com/2018/04/15/sap-odata-service-get-consume-rest-service/
The tutorial for configuring SAP Web Dispatcher + SAP Gateway together
https://help.sap.com/saphelp_uiaddon10/helpdata/en/ec/342f1809c94d2b817ba772fe69e43f/content.htm?no_cache=true
The other options for reverse-proxy for SAP:
nginx
Apache
...
You are free to choose any reverse proxy on the market depending on your environment.
I have an application deployed on Cloud Run and I want to apply IP filtering on it.
Can you please suggest me cheapest solution for both public and internal Cloud Run application.
For public IP, you can use an HTTPS Load Balancer with your Cloud Run service as serverless NEG as Backendservice, and add a Cloud Armor policy to filter the incoming IP
There is no built in solution for internal IP
You can also implement the IP filtering check directly in your Cloud Run service by reading the header of the request, especially the field X-Forwarded-For
Finally, filtering on IP is not a good idea. Google says: Don't trust the network, and that's why it's not so easy to implement what you want to achieve, because it's not a suitable design.
Base your security on the identity and OAuth2 protocol, instead of IP.
We have architecture pattern (Layered DMZ) where:
1. External facing applications are deployed in 3 layered DMZ (DMZ1 for Web Server, DMZ2 for App Server and DMZ3 for Database server)
2. We do not allow DMZ1 directly talking to LAN, however DMZ2, DMZ3 can talk to LAN
WSO2 API Manager will be installed in LAN, the issue is how do we expose services from LAN API store to external world. Which design pattern is best suited for this? I have couple of options
Option 1:
Deploy another instance of API Manager in DMZ1 which 3rd party can access
Deploy set of services in DMZ1 API Manager only for 3rd party access
Have reverse proxy in DMZ2 which talks to LAN server
Option2:
Single instance of API Manager deployed in LAN
Reverse proxy in DMZ1
Forward proxy in DMZ2 (which currently we do not have)
Forward proxy talks to LAN
I remember IBM has virtual/physical Datapower appliance which acts as ab external API gateway, how do we achieve similar design pattern with WSO2?
Many thanks in advance
WSO2 API Manager will be installed in LAN, the issue is how do we expose services from LAN API store to external world
WSO2 API Manager has a component API Gateway. Actually todays there are two ways to do that
Use API Gateway
API Gatway is an instance of API Manager with parameters specifying, that the instance is a gateway, so other modules (key manager, store, publisher) are disabled or not used
We use API Gateway in DMZ. This instace will authenticate and authorize the calling clients. However, the gateway still needs to call KeyManager web services for token validation and the publisher needs to call gateway for API deployment
(KeyManager and publisher are the services in the APIM in LAN)
Using API Micro Gateway
Needs to be deployed as individual modules and are able to validate client's tokens (jwt tokens) even without any connection to the LAN instance
Note: When not using static api keys, but OAuth authentication, then you need to expose a route to the token and revoke service
Resources:
https://docs.wso2.com/m/mobile.action#page/97564467
https://apim.docs.wso2.com/en/latest/Learn/APIGateway/overview-of-the-api-gateway/
https://wso2.com/api-management/api-microgateway/
There are several common deployment patterns recommended by WSO2 for API Manager which can be found below.
https://docs.wso2.com/display/AM260/Deployment+Patterns#DeploymentPatterns-WSO2APIManagerdeploymentpatterns
You can go for pattern #4 or #5. Pattern #5 will keep your total cost down in terms of license fee and infrastructure fee.
I can access the kubernetes api to get the deployments using Kubernetes proxy.
I get the list of deployments with:
127.0.0.1:8001/apis/apps/v1/deployments
This is getting the deployments locally. But what should I use the HOST and PORT to access the deployments from the cluster not locally but using the aws server.
I am new to Kubernetes, if the question is not understandable please let me know.
Any help is appreciated.
kubectl proxy forwards your traffic localy adding your authentication for you
Your public api endpoint can be exposed in different ways (or it can be completely inaccessible from public network) depending on your cluster setup.
In most cases it would be exposed on something like ie. https://api.my.cluster.fqdn or with custom port like https://api.my.cluster.fqdn:6443 and it would require authentication by ie. getting a baerer token or using client certificate. It is reasonable to use some client library to connect to API.
i created an android application that requires use of web service
i want it to be able to access the app everywhere therefore i need
my web services to be public with an external ip so i can access
what is the best way to do it?
I have an Amazon Web Services account i dont know if created an instance and run the web services there will be the best solution
My big problem with Amazon instance is that it takes a while to show in the app the result of the web service
Any ideas in how to make my web service public?
It appears that your requirement is:
Expose a public API endpoint for use by your Android application
Run some code when the API is called
There are two ways you could expose an API:
Use Amazon API Gateway, which that can publish, maintain, monitor, and secure APIs. It takes care of security and throttling. A DNS name is provided, which should be used for API calls. When a request is receive, API Gateway can pass the request to a web server or can trigger an AWS Lambda function to execute code without requiring a server.
Or, run an Amazon EC2 instance with your application. Assign an Elastic IP Address to the instance, which is a static IP address. Create an A record in Amazon Route 53 (or your own DNS server) that points a DNS name to that IP address.