Skip to content

Latest commit

 

History

History
141 lines (89 loc) · 7.8 KB

11-validation.md

File metadata and controls

141 lines (89 loc) · 7.8 KB
Raw

End-to-End Validation

Now that you have a workload deployed, the ASP.NET Core Docker sample web app, you can start validating and exploring this reference implementation of the AKS Baseline cluster. In addition to the workload, there are some observability validation you can perform as well.

Validate the Web App

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

Steps

  1. Get Public IP of Application Gateway

    📖 The app team conducts a final acceptance test to be sure that traffic is flowing end-to-end as expected, so they place a request against the Azure Application Gateway endpoint.

    # query the Azure Application Gateway Public Ip
APPGW_PUBLIC_IP=$(az deployment group show --resource-group $SPOKES_AKS_BASELINE -n spoke-BU0001A0008 --query properties.outputs.appGwPublicIpAddress.value -o tsv)
echo $APPGW_PUBLIC_IP

  2. Create A Record for DNS

    💡 You can simulate this via a local hosts file modification. You're welcome to add a real DNS entry for your specific deployment's application domain name, if you have access to do so.

    Map the Azure Application Gateway public IP address to the application domain name. To do that, please 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.${DOMAIN_NAME_AKS_BASELINE} (e.g. 50.140.130.120 bicycle.contoso.com)

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

    💡 A TLS warning will be present due to using a self-signed certificate. You can ignore it or import the self-signed cert (appgw.pfx) to your user's trusted root store.

Validate reader access to the a0008 namespace. Optional.

When setting up Azure AD security groups you created a group to be used as a "reader" for the namespace a0008. If you want to experience this RBAC example, you'll want to add a user to that group.

If Azure RBAC is your cluster's Kubernetes RBAC backing store, then that is all that is needed.

If instead Kubernetes RBAC is backed directly by Azure AD, then you'll need to ensure that you've updated and applied the rbac.yaml according to the instructions found at the end of the Azure AD configuration page.

No matter which backing store you use, the user assigned to the group will then be able to az aks get-credentials to the cluster and you can validate that user is limited to a read only view of the a0008 namespace.

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.0 ruleset, in Prevention mode.

Steps

  1. Browse to the site with the following appended to the URL: ?sql=DELETE%20FROM (e.g. 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.

  3. Blocked requests (along with other gateway data) will be visible in the attached Log Analytics workspace. Execute the following query to show WAF logs, for example.

    AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"

Validate Cluster Azure Monitor Insights and Logs

Monitoring your cluster is critical, especially when you're running a production cluster. Azure Monitor is configured to surface cluster logs, here you can see those logs as they are generated. Azure Monitor for containers is configured on this cluster for this purpose.

Steps

  1. In the Azure Portal, navigate to your AKS cluster resource.
  2. Click Insights to see see captured data.

You can also execute queries on the cluster logs captured.

  1. In the Azure Portal, navigate to your AKS cluster resource.
  2. Click Logs to see and query log data. :bulb: There are several examples on the Kubernetes Services category.

Validate Azure Monitor for containers (Prometheus Metrics)

Azure Monitor is configured to scrape Prometheus metrics in your cluster. This reference implementation is configured to collect Prometheus metrics from two namespaces, as configured in container-azm-ms-agentconfig.yaml. There are two pods configured to emit Prometheus metrics:

  • Traefik (in the a0008 namespace)
  • Kured (in the cluster-baseline-settings namespace)

Steps

  1. In the Azure Portal, navigate to your AKS cluster resource group (rg-bu0001a0008).

  2. Select your Log Analytic Workspace resource.

  3. Click Saved Searches.

    💡 This reference implementation ships with some saved queries as an example of how you can write your own and manage them via ARM templates.

  4. Type Prometheus in the filter.

  5. You are able to select and execute the saved query over the scraped metrics.

Validate Workload Logs

The example workload uses the standard dotnet logger interface, which are captured in ContainerLogs in Azure Monitor. You could also include additional logging and telemetry frameworks in your workload, such as Application Insights. Here are the steps to view the built-in application logs.

Steps

  1. In the Azure Portal, navigate to your AKS cluster resource group (rg-bu0001a0008).

  2. Select your Log Analytic Workspace resource.

  3. Execute the following query

    let podInventory = KubePodInventory
| where ContainerName endswith "aspnet-webapp-sample"
| distinct ContainerID, ContainerName
| project-rename Name=ContainerName;
ContainerLog
| project-away Name
| join kind=inner
    podInventory
on ContainerID
| project TimeGenerated, LogEntry, Computer, Name, ContainerID
| order by TimeGenerated desc

Validate Azure Alerts

Azure will generate alerts on the health of your cluster and adjacent resources. This reference implementation sets up multiple alerts that you can subscribe to.

Steps

An alert based on Azure Monitor for containers information using a Kusto query was configured in this reference implementation.

  1. In the Azure Portal, navigate to your AKS cluster resource group (rg-bu0001a0008).
  2. Select Alerts, then Manage Rule Alerts.
  3. There is an alert called "PodFailedScheduledQuery" that will be triggered based on the custom query response.

An Azure Advisor Alert was configured as well in this reference implementation.

  1. In the Azure Portal, navigate to your AKS cluster resource group (rg-bu0001a0008).
  2. Select Alerts, then Manage Rule Alerts.
  3. There is an alert called "AllAzureAdvisorAlert" that will be triggered based on new Azure Advisor alerts.

A series of metric alerts were configured as well in this reference implementation.

  1. In the Azure Portal, navigate to your AKS cluster resource group (rg-bu0001a0008).
  2. Select your cluster, then Insights.
  3. Select Recommended alerts to see those enabled. (Feel free to enable/disable as you see fit.)

Next step

▶️ Clean Up Azure Resources