In Appgate SDP it is normal to handle http(s) traffic using the TCP up protocol type which would <ALLOW> or <BLOCK> the traffic at the firewall in the Gateway in the usual way; the hostnames being resolved using the dns:// or *.domain.com host definitions. However, Appgate SDP offers an alternative to this approach called URL access which uses a reverse proxy to filter the traffic (in a very different way from the usual firewall operation). To use this you chose the protocol type HTTP up and define the host using the http(s):// prefix. Even though the protocol type is called HTTP up it is able to restrict access for standard http(s)// connections and websockets based on the URLs; i.e. https://app1.company.com.
Using URL Access
The URL access feature operates as a reverse proxy when handling Client traffic. This means that the Appliance requires a PKCS#12 file to terminate any http(s) connections, decrypt, URL filter and then re-establish an onward https connection to the protected hosts. URL access can support multiple PKCS#12 files, each containing a certificate (for the protected host) signed by a trusted CA and the private key. An alternative to the use of multiple certs is a wild-card cert - but this should be limited in scope because of the security implications in the event of its loss.
NOTE
The PKCS#12 file for connection termination is configured under Tunneling options in each Site. Configure this first, as you won’t be allowed to save your Entitlement with an https:// host defined.
Once set up correctly, the reverse proxy controls access to separate applications (by hostname) that are sharing the same IP and port. This is therefore the perfect way of controlling ingress to containerized applications such as would be found in a k8s environment. With Appgate SDP acting as an external reverse proxy, the k8s cluster should be configured to accept connections from ONLY the Appgate SDP Gateways. The Gateways do not replace the k8s ingress controls - which are still required to route application traffic to the correct services (and pods). The Gateways need no knowledge of the internal services within the k8s cluster, only the external URLs used to access them. The Gateways role is to filter the traffic (by user) that is allowed TO the k8s cluster thus allowing user1 to access only https://app1.web.my.co.
NOTE
To control access FROM pods in a k8s environment you should use the k8s service Client.
Filter operation
There are some basic rules that need to be followed:
Uses simple left to right string matching - so allow https://application.web.my.co would allow https://application.web.my.co/whatever but would not allow https://web.my.co.
Looks for an exact allow match first, so a request to https://application.web.my.co/whatever/thing would look for a rule for https://application.web.my.co/whatever/thing. If this is not found then it will check other rules to see if there are any back towards the root which would allow a match such as https://application.web.my.co/whatever.
Does not support wildcards - so you cannot use https://application.web.my.co/*/thing or https://application*.web.my.co.
Treats upper and lower case differently - so if only https://application.web.my.co was allowed; then https://Application.web.my.co would be blocked.
Does not support http:// and https:// in the same Action - so instead include them as separate Actions in the same Entitlement.
Method filtering
It is also possible to filter by allowed methods when using the HTTP up protocol. Multiple methods can be selected in one Action.
Use cases
Controlling access to containerized applications such as would be found in a k8s environment:
app1 to app10 are all hosted at 172.17.1.6:443 (so you cannot use a TCP up rule to control app by app access). A user with allow HTTP up to https://app1.company.com and https://app7.company.com will be able to access app1 and app7 but will be denied access to all other apps hosted at 172.17.1.6.
When specifying the Action be careful to explicitly allow every subdomain used by the app (since URL access matches from left and wildcards are not supported):
Allowing access to a Github Enterprise server may require that the following hosts are included: https://github.company.com, https://statics.github.company.com, https://gist.github.company.com, https://binary.github.company.com.
URL access uses a simple URL string filter which is not application aware. It is therefore not possible to restrict access to specific parts of a web-based application - so you should not expect to be able to filter down to just one page in a application:
In theory, a user with a HTTP up rule to <ALLOW> access to https://app1.company.com and a HTTP up rule to <BLOCK> access to https://app1.company.com/admin can access any path under app1.company.com except /admin. This setup can work technically; however, it’s not recommended as virtually all web applications have multiple entry points, such as REST API.
Additionally an explicit HTTP up rule to <ALLOW> access to app1.company.com/admin can work technically; however, it’s not recommended as virtually all web applications make calls to countless other pages to load content so will almost always appear broken!
NOTE
When a <BLOCK> rule is encountered then NGX_HTTP_FORBIDDEN 403 will be returned. When a conditional <ALLOW> rule is encountered then NGX_HTTP_UNAUTHORIZED 401 will be returned until the user meets the condition.
URL access override
Because the traffic has to be inspected this process has a significant overhead. This in turn means the performance (throughput and concurrency) is very limited when compared to TCP up. For situations where the Gateways are unable to handle the amount of HTTP up traffic it is possible to configure individual Gateways to use TCP up even when HTTP up has been specified in the Action. These gateways should be configured with a lower weighting (so they are only used when the others don't respond). This feature is only available from the command line using cz-config commands.
Disable Source NAT on Gateways
When the destination in Appgate SDP is being configured as a URL (HTTP up access rule), the Gateway will act as a man in the middle, so even when SNAT is disabled on the Site, the Gateway IP address will always be used on the protected network behind the Gateway. The Gateway acts as a reverse proxy, decrypting and filtering the traffic, before encrypting it again and making a new onward connection to the protected host. The IP Access logs within Appgate SDP contain all the details about the user and the device that is connecting to the application. And the original client tun IP will be added to the HTTP request header, so the source IP of the user can also be traced by the application this way.