Skip to content

Latest commit

 

History

History
72 lines (46 loc) · 4.67 KB

01-prerequisites.md

File metadata and controls

72 lines (46 loc) · 4.67 KB
Raw

Prerequisites

This is the starting point for the instructions on deploying the AKS baseline multicluster reference implementation. 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 creation of the AKS clusters.

Steps

💡 The steps shown here and elsewhere in the reference implementation use Bash shell commands. On Windows, you can use the Windows Subsystem for Linux to run Bash.

  1. An Azure subscription.

    The subscription used in this deployment cannot be a free account; it must be a standard EA, pay-as-you-go, or Visual Studio benefit subscription. This is because the resources deployed here are beyond the quotas of free subscriptions.

    ⚠️ The user or service principal initiating the deployment process must have the following minimal set of Azure role-based access control (RBAC) roles:

    • Contributor role is required at the subscription level to have the ability to create resource groups and perform deployments.
    • User Access Administrator role is required at the subscription level since you'll be performing role assignments to managed identities across various resource groups.

  2. A Microsoft Entra tenant to associate your Kubernetes RBAC Cluster API authentication to.

    ⚠️ The user or service principal initiating the deployment process must have the following minimal set of Microsoft Entra permissions assigned:

    • Microsoft Entra User Administrator is required to create a "break glass" AKS admin Microsoft Entra security group and user. Alternatively, you could get your Microsoft Entra admin to create this for you when instructed to do so.
      • If you are not part of the User Administrator group in the tenant associated to your Azure subscription, consider creating a new tenant to use while evaluating this implementation. The Microsoft Entra tenant backing your cluster's API RBAC does NOT need to be the same tenant associated with your Azure subscription.

  3. Latest Azure CLI installed (must be at least 2.37), or you can perform this from Azure Cloud Shell by clicking below.

    Launch Azure Cloud Shell

  4. Latest GitHub CLI. OpenSSL is already installed in Azure Cloud Shell.

  5. Install Certbot

    Certbot is a open-source software tool for automatically using Let's Encrypt certificates on manually-administrated websites to enable HTTPS. It'll be used to generate a non self-signed TLS cert for your Azure Application Gateway instances, a requirement for Azure Front Door.

  6. Ensure OpenSSL is installed in order to generate the remaining self-signed certs used in this implementation. OpenSSL is already installed in Azure Cloud Shell.

    ⚠️ Some shells may have the openssl command aliased for LibreSSL. LibreSSL will not work with the instructions found here. You can check this by running openssl version and you should see output that says OpenSSL <version> and not LibreSSL <version>.

  7. Login with the GitHub CLI

    gh auth login -s "repo,admin:org"

  8. Fork the repository and clone it

    gh repo fork mspnp/aks-baseline-multi-region --clone=true --remote=false
cd aks-baseline-multi-region
git remote remove upstream

  9. Get your GitHub username

    export GITHUB_USERNAME_AKS_MRB=$(gh api user -q '.login')
echo GITHUB_USERNAME_AKS_MRB: $GITHUB_USERNAME_AKS_MRB

Save your work in-progress

# run the saveenv.sh script at any time to save environment variables created above to aks_baseline.env
./saveenv.sh

# if your terminal session gets reset, you can source the file to reload the environment variables
# source aks_baseline.env

Next step

▶️ Prep for Microsoft Entra integration