Replace starter github workflow with dedicated repo reference (#348)

* commit to see how intro table looks

* add newlines instead

* remove github workflow and add two more links to automation repo

* Apply suggestions from code review

Co-authored-by: Rick Hallihan <1796255+hallihan@users.noreply.github.com>

* Update 12-cleanup.md

Co-authored-by: Rick Hallihan <1796255+hallihan@users.noreply.github.com>

Co-authored-by: Rick Hallihan <1796255+hallihan@users.noreply.github.com>

.gitignore

@@ -3,5 +3,4 @@
 *.key
 *.pfx
 *.pem
-sp.json
 aks_baseline.env

01-prerequisites.md

@@ -2,6 +2,9 @@
 
 This is the starting point for the instructions on deploying the [AKS Baseline reference implementation](./README.md). There is required access and tooling you'll need in order to accomplish this. Follow the instructions below and on the subsequent pages so that you can get your environment ready to proceed with the AKS cluster creation.
 
+| :clock10: | These steps are intentionally verbose, intermixed with context, narrative, and guidance. The deployments are all conducted via [Bicep templates](https://learn.microsoft.com/azure/azure-resource-manager/bicep/overview), but they are executed manually via `az cli` commands. We strongly encourage you to dedicate time to walk through these instructions, with a focus on learning. We do not provide any "one click" method to complete all deployments.<br><br>Once you understand the components involved and have identified the shared responsibilities between your team and your greater organization, you are encouraged to build suitable, repeatable deployment processes around your final infrastructure and cluster bootstrapping. The [AKS baseline automation guidance](https://github.com/Azure/aks-baseline-automation#aks-baseline-automation) is a great place to learn how to build your own automation pipelines. That guidance is based on the same architecture foundations presented here in the AKS baseline, and illustrates GitHub Actions based deployments for all components, including workloads. |
+|-----------|:--------------------------|
+
 ## Steps
 
 1. An Azure subscription.

06-aks-cluster.md

@@ -19,107 +19,13 @@ Now that your [ACR instance is deployed and ready to support cluster bootstrappi
 1. Deploy the cluster ARM template.
   :exclamation: By default, this deployment will allow unrestricted access to your cluster's API Server. You can limit access to the API Server to a set of well-known IP addresses (i.,e. a jump box subnet (connected to by Azure Bastion), build agents, or any other networks you'll administer the cluster from) by setting the `clusterAuthorizedIPRanges` parameter in all deployment options. This setting will also impact traffic originating from within the cluster trying to use the API server, so you will also need to include _all_ of the public IPs used by your egress Azure Firewall. For more information, see [Secure access to the API server using authorized IP address ranges](https://learn.microsoft.com/azure/aks/api-server-authorized-ip-ranges#create-an-aks-cluster-with-api-server-authorized-ip-ranges-enabled).
 
-    **Option 1 - Deploy from the command line**
-
    ```bash
    # [This takes about 18 minutes.]
    az deployment group create -g rg-bu0001a0008 -f cluster-stamp.bicep -p targetVnetResourceId=${RESOURCEID_VNET_CLUSTERSPOKE_AKS_BASELINE} clusterAdminAadGroupObjectId=${AADOBJECTID_GROUP_CLUSTERADMIN_AKS_BASELINE} a0008NamespaceReaderAadGroupObjectId=${AADOBJECTID_GROUP_A0008_READER_AKS_BASELINE} k8sControlPlaneAuthorizationTenantId=${TENANTID_K8SRBAC_AKS_BASELINE} appGatewayListenerCertificate=${APP_GATEWAY_LISTENER_CERTIFICATE_AKS_BASELINE} aksIngressControllerCertificate=${AKS_INGRESS_CONTROLLER_CERTIFICATE_BASE64_AKS_BASELINE} domainName=${DOMAIN_NAME_AKS_BASELINE} gitOpsBootstrappingRepoHttpsUrl=${GITOPS_REPOURL} gitOpsBootstrappingRepoBranch=${GITOPS_CURRENT_BRANCH_NAME} location=eastus2
    ```
 
    > Alteratively, you could have updated the [`azuredeploy.parameters.prod.json`](./azuredeploy.parameters.prod.json) file and deployed as above, using `-p "@azuredeploy.parameters.prod.json"` instead of providing the individual key-value pairs.
 
-    **Option 2 - Automated deploy using GitHub Actions (fork is required)**
-
-    1. Create the Azure Credentials for the GitHub CD workflow.
-
-       ```bash
-       # Create an Azure Service Principal
-       #
-       # This command will generate a sp.json file in the format expected by GitHub Actions for Azure.
-       # This is accomplished by using the deprecated --sdk-auth flag. For alternatives, including using
-       # Federated Identity, see https://github.com/Azure/login#configure-deployment-credentials.
-       az ad sp create-for-rbac --name "github-workflow-aks-cluster" --sdk-auth --skip-assignment > sp.json
-       export APP_ID=$(grep -oP '(?<="clientId": ").*?[^\\](?=",)' sp.json)
-       echo APP_ID: $APP_ID
-
-       # Wait for propagation
-       until az ad sp show --id ${APP_ID} &> /dev/null ; do echo "Waiting for Azure AD propagation" && sleep 5; done
-
-       # Assign built-in Contributor RBAC role for creating resource groups and performing deployments at subscription level
-       az role assignment create --assignee $APP_ID --role 'Contributor'
-
-       # Assign built-in User Access Administrator RBAC role since granting RBAC access to other resources during the cluster creation will be required at subscription level (e.g. AKS-managed Internal Load Balancer, ACR, Managed Identities, etc.)
-       az role assignment create --assignee $APP_ID --role 'User Access Administrator'
-       ```
-
-    1. Create `AZURE_CREDENTIALS` secret in your GitHub repository. For more
-       information, please take a look at [Creating encrypted secrets for a repository](https://docs.github.com/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository).
-
-       > :bulb: Use the content from the `sp.json` file.
-
-       ```bash
-       cat sp.json
-       ```
-
-    1. Create `APP_GATEWAY_LISTENER_CERTIFICATE_BASE64` secret in your GitHub repository. For more
-       information, please take a look at [Creating encrypted secrets for a repository](https://docs.github.com/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository).
-
-       > :bulb:
-       >
-       >  * Use the env var value of `APP_GATEWAY_LISTENER_CERTIFICATE`
-       >  * Ideally fetching this secret from a platform-managed secret store such as [Azure KeyVault](https://github.com/marketplace/actions/azure-key-vault-get-secrets)
-
-       ```bash
-       echo $APP_GATEWAY_LISTENER_CERTIFICATE_AKS_BASELINE
-       ```
-
-    1. Create `AKS_INGRESS_CONTROLLER_CERTIFICATE_BASE64` secret in your GitHub repository. For more information, please take a look at [Creating encrypted secrets for a repository](https://docs.github.com/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository).
-
-       > :bulb:
-       >
-       >  * Use the env var value of `AKS_INGRESS_CONTROLLER_CERTIFICATE_BASE64`
-       >  * Ideally fetching this secret from a platform-managed secret store such as [Azure Key Vault](https://github.com/marketplace/actions/azure-key-vault-get-secrets)
-
-       ```bash
-       echo $AKS_INGRESS_CONTROLLER_CERTIFICATE_BASE64_AKS_BASELINE
-       ```
-
-    1. Copy the GitHub workflow file into the expected directory and update the placeholders in it.
-
-       ```bash
-       mkdir -p .github/workflows
-       cat github-workflow/aks-deploy.yaml | \
-           sed "s#<resource-group-location>#eastus2#g" | \
-           sed "s#<resource-group-name>#rg-bu0001a0008#g" | \
-           sed "s#<geo-redundancy-location>#centralus#g" | \
-           sed "s#<cluster-spoke-vnet-resource-id>#${RESOURCEID_VNET_CLUSTERSPOKE_AKS_BASELINE}#g" | \
-           sed "s#<tenant-id-with-user-admin-permissions>#${TENANTID_K8SRBAC_AKS_BASELINE}#g" | \
-           sed "s#<azure-ad-aks-admin-group-object-id>#${AADOBJECTID_GROUP_CLUSTERADMIN_AKS_BASELINE}#g" | \
-           sed "s#<azure-ad-aks-a0008-group-object-id>#${AADOBJECTID_GROUP_A0008_READER_AKS_BASELINE}#g" | \
-           sed "s#<domain-name>#${DOMAIN_NAME_AKS_BASELINE}#g" | \
-           sed "s#<bootstrapping-repo-https-url>#${GITOPS_REPOURL}#g" \
-           > .github/workflows/aks-deploy.yaml
-       ```
-
-    1. Push the changes to your forked repo.
-
-       > :book: The DevOps team wants to automate their infrastructure deployments. In this case, they decided to use GitHub Actions. They are going to create a workflow for every AKS cluster instance they have to take care of.
-
-       ```bash
-       git add .github/workflows/aks-deploy.yaml && git commit -m "setup GitHub CD workflow"
-       git push origin HEAD:kick-off-workflow
-       ```
-
-       > :bulb: You might want to convert this GitHub workflow into a template since your organization or team might need to handle multiple AKS clusters. For more information, please take a look at [Sharing Workflow Templates within your organization](https://docs.github.com/actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization).
-
-    1. Navigate to your GitHub forked repository and open a PR against `main` using the recently pushed changes to the remote branch `kick-off-workflow`.
-
-       > :book: The DevOps team configured the GitHub Workflow to preview the changes that will happen when a PR is opened. This will allow them to evaluate the changes before they get deployed. After the PR reviewers see how resources will change if the AKS cluster ARM template gets deployed, it is possible to merge or discard the pull request. If the decision is made to merge, it will trigger a push event that will kick off the actual deployment process.
-
-    1. Once the GitHub Workflow validation finished successfully, please proceed by merging this PR into `main`.
-
-       > :book: The DevOps team monitors this Workflow execution instance. In this instance it will impact a critical piece of infrastructure as well as the management. This flow works for both new or an existing AKS cluster.
-
 ## Container registry note
 
 :warning: To aid in ease of deployment of this cluster and your experimentation with workloads, Azure Policy and Azure Firewall are currently configured to allow your cluster to pull images from _public container registries_ such as Docker Hub. For a production system, you'll want to update Azure Policy parameter named `allowedContainerImagesRegex` in your `cluster-stamp.bicep` file to only list those container registries that you are willing to take a dependency on and what namespaces those policies apply to, and make Azure Firewall allowances for the same. This will protect your cluster from unapproved registries being used, which may prevent issues while trying to pull images from a registry which doesn't provide SLA guarantees for your deployment.

12-cleanup.md

@@ -28,6 +28,14 @@ After you are done exploring your deployed [AKS Baseline cluster](./), you'll wa
 
 1. [Remove the Azure Policy assignments](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyMenuBlade/Compliance) scoped to the cluster's resource group. To identify those created by this implementation, look for ones that are prefixed with `[your-cluster-name] `.
 
+## Automation
+
+Before you can automate a process, it's important to experience the process in a bit more raw form as was presented here. That experience allows you to understand the various steps, inner- & cross-team dependencies, and failure points along the way. However, the steps provided in this walkthrough are not specifically designed with automation in mind. It does present a perspective on some common seperation of duties often encountered in organizations, but that might not align with your organization.
+
+Now that you understand the components involved and have identified the shared responsibilities between your team and your greater organization, you are encouraged to build repeatable deployment processes around your final infrastructure and cluster bootstrapping. Please refer to the [AKS baseline automation guidance](https://github.com/Azure/aks-baseline-automation#aks-baseline-automation) to learn how GitHub Actions combined with Infrastructure as Code can be used to facilitate this automation. That guidance is based on the same architecture foundations you've walked through here.
+
+> Note: The [AKS baseline automation guidance](https://github.com/Azure/aks-baseline-automation#aks-baseline-automation) implementation strives to stay in sync with this repo, but may slightly deviate in various decisions made, may introduce new features, or not yet have a feature that is used in this repo. The are functionally aligned by design, but not necessarily identical. Use that repo to explore the automation potential, while this repo is used for the core architectural guidance.
+
 ### Next step
 
 :arrow_forward: [Review additional information in the main README](./README.md#broom-clean-up-resources)

README.md

@@ -74,7 +74,7 @@ This is the heart of the guidance in this reference implementation; paired with
 - [ ] [Deploy the AKS cluster and supporting services](./06-aks-cluster.md)
 - [ ] [Validate cluster bootsrapping](./07-bootstrap-validation.md)
 
-We perform the prior steps manually here for you to understand the involved components, but we advocate for an automated DevOps process. Therefore, incorporate the prior steps into your CI/CD pipeline, as you would any infrastructure as code (IaC). We have included [a starter GitHub workflow](./github-workflow/aks-deploy.yaml) that demonstrates this.
+We perform the prior steps manually here for you to understand the involved components, but we advocate for an automated DevOps process. Therefore, incorporate the prior steps into your CI/CD pipeline, as you would any infrastructure as code (IaC). See the dedicated [AKS baseline automation guidance](https://github.com/Azure/aks-baseline-automation#aks-baseline-automation) for additional details.
 
 ### 4. Deploy your workload