Introducing Application Shielding
Application Shielding is an opt-in product feature for all Webscale customers. This feature allows a controlled isolation of the application servers in a customer’s cloud account, against traffic from the Internet. A handful of Webscale customers have requested to configure their application servers so the only HTTP/HTTPS traffic that reaches is through the Webscale proxy servers, and this feature was developed in response to that. Application Shielding makes it possible to completely eliminate direct HTTP/HTTPS traffic to the application servers from the Internet, unless they are explicitly allowed by special settings of the firewalls or via whitelists. It forces all other traffic to be routed through the Webscale proxies, thereby making it more insulated against malicious attacks.
Webscale’s application shielding implementation utilizes the underlying cloud provider capabilities to control the traffic hitting the application servers. It is a fully integrated solution that assimilates the differences in cloud providers and presents a simple, unified control to the end user and makes it very easy for them to enable this extra layer of protection for their servers.
While the control of this feature is indeed simple, any user attempting to enable or disable application shielding for one or more applications, is expected to have a basic understanding of networking and firewall concepts. This feature is currently only supported for the AWS and the Google cloud providers, so to make use of this security feature, the application servers must be hosted in one of those two cloud provider accounts.
Firewalls and Security Groups
Firewalls in Google and security groups in AWS are fundamental networking resources in the cloud provider account, that enable Webscale to offer the Application Shielding feature. This section talks about what the user needs to know about the server environment in their cloud provider account, before attempting to deploy application shielding. Fundamentally, both firewalls and security groups provide a way for the user to configure and control access to their application servers.
Application Server Blueprints
Most of the Webscale customers rely on us to orchestrate any auto-scaling of their application servers as dictated by the demands placed on the website by the Internet users. One of the fundamental aspects of this auto-scaling is what is referred to as server blueprints in the Webscale documents. Server blueprints allow a Webscale customer to specify the precise configuration that may be used to create additional application servers when needed.
Prior to the release of the application shielding feature, the server blueprints allowed one to specify the server image (operating system and software), server placement (cloud provider region/zone) and the instance type (machine capabilities). This feature release enhances these capabilities to include additional cloud provider resources in the server blueprints. This include things like network/VPC, subnet for both Google and AWS, network tags (Google only) and security groups (AWS only).
These new attributes make it possible for a user to create precise blueprints with networking attributes that allow access control to the servers created by the Webscale auto-scaling solution.
AWS Security Groups
Security groups allow users to create a set of ingress and egress rules to control traffic to servers that are associated with the security group. Each VPC (network) in AWS is associated with a security group that determines the flow of traffic to and from the servers in the network and all subnets of the network. For more about Security Groups, please visit here.
The application shielding feature manipulates the ingress rules on a user identified security group to add/remove IP addresses and address blocks, to put access rules into effect. Any rules added by the Webscale product to this security group are annotated with a specific description string “webscale-app-shielding-<n>”, where n is a integer that grows with every new rule added by the system. When the application shielding is disabled, all the ingress rules with such a description is removed by the system automatically.
Things to note:
- The security group that is configured for use via application shielding, must already exist in the cloud provider account and the Webscale product must have access to modify the rules in the group.
- It is responsibility of the user to make sure that the security group rules actually impact traffic to the application servers by ensuring that the server blueprints are created in accordance with that.
- Any rules existing in the security group that include the substring “webscale-app-shielding-<n>”, are liable to be deleted by the Webscale product, rules that are not meant to be edited by the Webscale product, must not include such a description.
Google firewalls, much like the AWS security groups, provide a similar capability of allowing/restricting access to the application servers hosted in the Google cloud account. Google firewalls are always associated with a network and the firewall specification allows a user to specify what servers in the network are impacted by the firewall rules. This is accomplished by setting a target property on the firewall. One of the ways that targets can be specified is by specifying network tags (arbitrary strings), and when servers in the network are created with the same tags, the firewall rules apply to them. For more about Firewalls, please visit here.
The application shielding feature requires that a firewall be identified and selected by the user to shield their application servers running in the Google cloud infrastructure. The firewall priority must be set by the user such that any other firewalls that must be applied irrespective to whether the shielding is enabled, are set to a higher priority. The specific firewall identified for application shielding is manipulated by the Webscale product and the rules are updated as needed by the product.
Things to note:
- The firewall designated for application shielding must not be edited by the user for application shielding to work as expected. Any updates are liable to be overwritten.
- The user has the responsibility to ensure firewall defines its targets appropriately so the application servers desired to be protected are indeed affected by the rules in the firewall.