Aller au contenu

Microsoft Azure

Cloud Adoption Framework

Mostly cloud-agnostic methodology for adopting the cloud in various enterprise configurations.

Step 1: everyone must read and use the cloud concepts/vocabulary in: Azure Hosting Hierarchy

Step 2: set up governance document (a set of policies / practices with bullet point list format). Governance must cover 5 topics.

Step 3: Implement the landing zone(s).

RBAC

Authorization System (built on Azure Resource manager) that grants access to Azure resources.

Source: RBAC Overview

┌──────────────────────────┐        ┌───────────┐         ┌──────────┐
│                          │ assign │           │ scope   │          │
│         Security         │        │           │         │ Targeted │
│         Principal        ├────────►   Role    ├─────────► Resources│
│                          │        │           │         │          │
└────────────▲─────────────┘        └─────▲─────┘         └──────────┘
             │                            │
             │                            │
                                          │
     User, Group,                         │
   Managed Identity
 or Service Principal                multiple
                                     permissions

Security principal: who's asking for access to the resource. It can be an User / Group / Service Principal or Managed Identity (these 4 are identities from Azure AD)

Role definition: collection of permissions. There are built-in roles. Custom roles can also be added.

RBAC built-in role Description
Owner full rights on the resource + can give permissions to others
Contributor full rights on the resource, cannot give permissions
Reader read-only on the resource
User Access Administrator no access on the resource + can give permissions

Scope: which level of resources are allowed? Management group / subscription / resource group / resource.

Examples of scope:

  • sur un mgmt group: providers/Microsoft.Management/managementGroups/<mgmt_group_name>
  • sur une resource: subscriptions/<id>/resourcegroups/<rg_name>/providers/<provider_name>/<res_type>/<res_id>
  • sur un resource group: subscriptions/<id>/resourcegroups/<rg_name>

Azure vs AD

Azure RBAC and Azure AD RBAC are complimentary (source: What's the difference between Azure Roles and Azure AD Roles.

Azure AD has its own UNIQUE roles, but is only used for identity + billing management

Bonus - Azure AD PIM: Azure AD Priviledged Identity Management enables "temporary elevated access" for Azure (standard) roles. The temporary elevated access must be manually granted by another user with a "eligible" role.

Things

Service Principal: like a service user identity. Must be used for all automated tools! (documentation). Can be authentified by password or certificate but terraform seems to ony accept password (to be confirmed). Default role is Contributor.

Azure & Terraform

There are 2 main providers to use:

Provider Usage Resource examples Backend
azuread authentication & AD AD Users, Groups, Service pricnipals MS Graph API
azurerm everything else Azure Resource Manager API

Note: azurerm doesn't provide Azure Devops. It has its own provider

Linker un cluster AKS à kubectl

  • Créer son cluster en cliquant partout
  • Récuperer le resource group du cluster:
az resource list --name 'mon-super-cluster' | grep "\"resourceGroup\":"
  • Remplir le kubeconfig avec cette commande get:
az aks get-credentials --name <clusterName> --resource-group <resourceGroup>
  • On peut maintenant utiliser kubectl !