Remove content that is now in AAC and cross-link (#37)

README.md

@@ -4,7 +4,7 @@ This reference implementation demonstrates the _recommended starting (baseline)
 
 | 🎓 Foundational Understanding |
 |:------------------------------|
-| **If you haven't familiarized yourself with the general-purpose [AKS baseline cluster](https://github.com/mspnp/aks-secure-baseline) architecture, you should start there before continuing here.** This architecture rationalizes and is constructed from the AKS baseline, which is the foundation for this body of work. This reference implementation avoids rearticulating points that are already addressed in the AKS baseline cluster. |
+| **If you haven't familiarized yourself with the general-purpose [AKS baseline cluster](https://github.com/mspnp/aks-secure-baseline) architecture, you should start there before continuing here.** This architecture is constructed from the AKS baseline, which is the foundation for this body of work. This reference implementation avoids rearticulating points that are already addressed in the AKS baseline cluster. |
 
 ## Compliance
 
@@ -17,15 +17,15 @@ Even if you are not in a regulated environment, this infrastructure demonstrates
 
 ## Azure Architecture Center guidance
 
-This project has a companion set of articles that describe challenges, design patterns, and best practices for a AKS cluster designed to host workloads that fall in **PCI-DSS 3.2.1** scope. You can find this article on the Azure Architecture Center at [Azure Kubernetes Service (AKS) regulated cluster for PCI-DSS 3.2.1](https://aka.ms/architecture/aks-baseline-regulated). If you haven't reviewed it, we suggest you read it; as it will give added context to the considerations applied in this implementation.
+This project has a companion set of articles that describe challenges, design patterns, and best practices for a AKS cluster designed to host workloads that fall in **PCI-DSS 3.2.1** scope. You can find this article on the Azure Architecture Center at [Azure Kubernetes Service (AKS) regulated cluster for PCI-DSS 3.2.1](https://aka.ms/architecture/aks-baseline-regulated). If you haven't reviewed it, we suggest you read it; as it will give added context to the considerations applied in this implementation. This repo primarly focuses on _deployment concerns_, while _compliance concerns_ are mostly addressed in the linked article series above.
 
 ## Architecture
 
-**This reference implementation is _infrastructure focused, more so than workload_.** It concentrates on compliance concerns dealing with the AKS cluster itself. This implementation will touch on workload concerns, but does not contain end-to-end guidance on in-scope workload architecture, container security, or isolation. There are some good practices demonstrated and others talked about, but it is not exhaustive.
+**This reference implementation is _infrastructure focused, more so than workload_.** It concentrates on dealing with the AKS cluster itself. This implementation will touch on workload concerns, but does not contain end-to-end guidance on in-scope workload architecture, container security, or isolation. There are some good practices demonstrated and others talked about, but it is not exhaustive.
 
 The implementation presented here is the _minimum starting point for most AKS clusters falling into a compliance scope_. This implementation integrates with Azure services that will deliver observability, provide a network topology that will support public traffic isolation, and keep the in-cluster traffic secure as well. This architecture should be considered your architectural starting point for pre-production and production stages of clusters hosting regulated workloads.
 
-The material here is relatively dense. We strongly encourage you to dedicate _at least four hours_ to walk through these instructions, with a mind to learning. You will not find any "one click" deployment here. However, once you've understood the components involved and identified the shared responsibilities between your team and your greater IT organization, it is encouraged that you build auditable deployment processes around your final infrastructure.
+The material here is relatively dense. We strongly encourage you to start by reading the Azure Architecture Center guidance linked above and then dedicate _at least four hours_ to walk through these instructions, with a mind to learning. You will not find any "one click" deployment here. However, once you've understood the components involved and identified the shared responsibilities between your team and your greater IT organization, it is encouraged that you build auditable deployment processes around your final infrastructure.
 
 Finally, this implementation uses a small, custom application as an example workload. This workload is minimally interesting, as it is here exclusively to help you experience the infrastructure and illustrate network and security controls in place. The workload, and its deployment, does not represent any sort of "best practices" for regulated workloads.
 
@@ -44,8 +44,8 @@ Finally, this implementation uses a small, custom application as an example work
 * Azure Virtual Networks (hub-spoke)
   * Azure Firewall managed egress
   * Hub-proxied DNS
-  * BYO Private DNS Zone for AKS
-* Azure Application Gateway (WAF - OWASP 3.1)
+  * BYO Private DNS Zone for AKS with no public DNS representation
+* Azure Application Gateway (WAF - OWASP 3.2)
 * AKS-managed Internal Load Balancers
 * Azure Bastion for maintenance access
 * Private Link enabled Key Vault and Azure Container Registry
@@ -137,19 +137,21 @@ Most of the Azure resources deployed in the prior steps will have ongoing billin
 
 All workloads that find themselves in compliance scope usually require a documented separation of duties/concern implementation plan. Kubernetes poses an interesting challenge in that it involves a significant number of roles typically found across an IT organization. Networking, identity, SecOps, governance, workload teams, cluster operations, deployment pipelines, any many more. If you're looking for a starting point on how you might consider breaking up the roles that are adjacent to the AKS cluster, consider **reviewing our [Azure AD role guide](./docs/rbac-suggestions.md)** shipped as part of this reference implementation.
 
+> :notebook: See [Azure Architecture Center guidance for PCI-DSS 3.2.1 Requirement 7, 8, and 9 in AKS](https://docs.microsoft.com/azure/architecture/reference-architectures/containers/aks-pci/aks-pci-identity).
+
 ## Is that all, what about … !?
 
 Yes, there are concerns that do extend beyond what this implementation could reasonably demonstrate for a general audience. This reference implementation strived to be accessible for most people without putting undo burdens on the subscription brought to this walkthrough. This means SKU choices with relatively large default quotas, not using features that have very limited regional availability, not asking for learners to be overwhelmed with "Bring your own encryption key" options for services, and similar. All in hopes that more people can complete this walkthrough without disruption or excessive coordination with subscription or management group owners.
 
-For your implementation, take this starting point and please add on additional security measures talked about throughout the walkthrough that were not directly implemented. For example, enable JIT and Conditional Access Policies, leverage Encryption-at-Host features if applicable to your workload, etc.
+For your implementation, take this _starting point_ and please add on additional security measures talked about throughout the walkthrough and the Azure Architecture Center guidance that were not directly implemented. For example, enable JIT and Conditional Access Policies, leverage Encryption-at-Host features if applicable to your workload, etc.
 
 **For a list of additional considerations for your architecture, please see our [Additional Considerations](./docs/additional-considerations.md) document.**
 
 ## Cost
 
 This reference implementation runs idle around $95 (US Dollars) per day within the first 30 days; and you can expect it to increase over time as some Security Center tooling has free-trial period and logs will continue to accrue. The largest contributors to the starting cost are Azure Firewall, the AKS nodepools (VM Scale Sets), and Log Analytics. While some costs are usually cluster operator costs, such as nodepool VMSS, log analytics, incremental Azure Defender costs; others will likely be amortized across multiple business units and/or applications, such as Azure Firewall.
 
-While some customers will amortize cluster costs across workloads by hosting a multi-tenant cluster within their organization, maximizing density with workload diversity, doing so with regulated workloads is not advised. Regulated environments will generally prioritize compliance and security (isolation) over cost (diverse density).
+Some customers will opt to amortize cluster costs across workloads by hosting a multi-tenant cluster within their organization, maximizing density with workload diversity. Doing so with regulated workloads is not advised. Regulated environments will generally prioritize compliance and security (isolation) over cost (diverse density).
 
 ## Final thoughts
 

cluster-stamp.json

@@ -611,7 +611,7 @@
                     "enabled": true,
                     "firewallMode": "Prevention",
                     "ruleSetType": "OWASP",
-                    "ruleSetVersion": "3.1",
+                    "ruleSetVersion": "3.2",
                     "disabledRuleGroups": [],
                     "requestBodyCheck": true,
                     "maxRequestBodySizeInKb": 128,

cluster-stamp.v2.json

@@ -611,7 +611,7 @@
                     "enabled": true,
                     "firewallMode": "Prevention",
                     "ruleSetType": "OWASP",
-                    "ruleSetVersion": "3.1",
+                    "ruleSetVersion": "3.2",
                     "disabledRuleGroups": [],
                     "requestBodyCheck": true,
                     "maxRequestBodySizeInKb": 128,