Skip to content

Latest commit

 

History

History
61 lines (37 loc) · 4.8 KB

01-prerequisites.md

File metadata and controls

61 lines (37 loc) · 4.8 KB
Raw

Prerequisites

This is the starting point for the end-to-end instructions on deploying the AKS Baseline for Regulated Workloads 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 and subscription ready to proceed with the AKS cluster creation.

Throughout this walkthrough, take note of the following symbol.

🛑 - Manual Modification Required. When this symbol appears on a step, you will need to modify the commands as indicated prior to running them.

Steps

  1. An Azure subscription. If you don't have an Azure subscription, you can create a free account.

    💡 The user initiating the following 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, create & assign policy, and perform deployments at both the subscription and resource group level.
    • 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. An Azure AD 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 Azure AD permissions assigned:

    • Azure AD User Administrator is required to create a "break glass" AKS admin Active Directory Security Group and User. Alternatively, you could get your Azure AD admin to create this for you when instructed to do so. If you are not assigned the User Administrator permission in the tenant associated to your Azure subscription, consider creating a new tenant to use while evaluating this implementation.

    The Azure AD tenant backing your Cluster's API RBAC does NOT need to be the same tenant associated with your Azure subscription. Your organization may have dedicated Azure AD tenants used specifically as a separation between Azure resource management, and Kubernetes control plane access. Ensure you're following your organization's practices when it comes to separation of identity stores to ensure limited "blast radius" on any compromised accounts.

  3. Latest Azure CLI installed or you can perform this from Azure Cloud Shell by clicking below.

    Launch Azure Cloud Shell

    Ensure you're logged into the subscription in which you plan on deploying this reference to.

  4. While the following feature(s) are still in preview, please enable them in your target subscription.

    • Follow the instructions to enable Azure AD Pod Identity. You do not need to install the preview CLI extension or follow other instructions on this page.
    az feature register --namespace "Microsoft.ContainerService" -n "EnablePodIdentityPreview"

# Keep running until all say "Registered." (This may take up to 20 minutes.)
az feature list -o table --query "[?name=='Microsoft.ContainerService/EnablePodIdentityPreview'].{Name:name,State:properties.state}"

# When all say "Registered" then re-register the AKS resource provider
az provider register --namespace Microsoft.ContainerService

  5. Fork this repository and clone it locally. 🛑

    GITHUB_ACCOUNT_NAME=YOUR-GITHUB-ACCOUNT-NAME-GOES-HERE

git clone https://github.com/${GITHUB_ACCOUNT_NAME}/aks-baseline-regulated.git
cd aks-baseline-regulated

    💡 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.

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

Next step

▶️ Generate TLS Certificates.