Skip to content

Latest commit

 

History

History
48 lines (26 loc) · 2.94 KB

13-validation.md

File metadata and controls

48 lines (26 loc) · 2.94 KB
Raw

End-to-End Validation

Now that you have a simulated regulated workload deployed, you can start validating and exploring this reference implementation of the AKS Baseline Cluster for Regulated Workloads.

Validate the workload is deployed

This section will help you to validate the workload is exposed correctly and responding to HTTPS requests.

Steps

  1. Get the public IP of Azure Application Gateway.

    APPGW_PUBLIC_IP=$(az deployment group show -g rg-enterprise-networking-spokes-centralus -n spoke-BU0001A0005-01 --query properties.outputs.appGwPublicIpAddress.value -o tsv)

  2. Create a DNS A Record 🛑

    💡 You can simulate this via a local hosts file modification.

    Map the Azure Application Gateway public IP address to the application domain name. To do that, edit your hosts file (C:\Windows\System32\drivers\etc\hosts or /etc/hosts) and add the following record to the end: ${APPGW_PUBLIC_IP} bicycle.contoso.com

  3. Browse to the site (https://bicycle.contoso.com).

    💡 A TLS warning will be present due to using a self-signed certificate.

    💡 Your first hit might result in a upstream request timeout response. There is a relatively low timeout on the workloads, and the request chain suffers from a "cold start" perspective. If you do get that, just refresh the page.

  4. Review the emitted page details.

    This page shows a series of attempted network traffic attempts in your cluster. Due to Azure Firewall, NSGs, service mesh rules, and Kuberentes Network Policies, only a select number of requests will be successful, the rest will be blocked. Generally speaking, the allowed network flow is Ingress -> web-frontend -> microservice-a -> microservice-b -> microservice-c. All other attempted connections are denied. Likewise, most Internet-bound traffic was denied, and only microservice-a was able to make the public request.

Validate Web Application Firewall functionality

Your workload is placed behind a Web Application Firewall (WAF), which has rules designed to stop intentionally malicious activity. You can test this by triggering one of the built-in rules with a request that looks malicious.

💡 This reference implementation enables the built-in OWASP 3.2 ruleset, in Prevention mode.

Steps

  1. Browse to the site with the following appended to the URL: ?sql=DELETE%20FROM (such as https://bicycle.contoso.com/?sql=DELETE%20FROM).
  2. Observe that your request was blocked by Application Gateway's WAF rules and your workload never saw this potentially dangerous request.

For a more exhaustive WAF test and validation experience, try the Azure Web Applicationg Firewall Security Protection and Detection Lab.

Next step

▶️ Access resource logs & Microsoft Defender for Cloud data