Microsoft Azure
https://www.azurecitadel.com/cli/jmespath/
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
!
Object ID
object_id
correspond est id unique à chaque compte d'authentication: SPN, user account, clientID etc.
User account az ad signed-in-user show --query objectId --output tsv