Microsoft Azure¶

The best approach to backup Kubernetes clusters running in Azure platform is to give the Afi backup agent access to manage volume snapshots directly via Azure API instead of generic CSI API. With this integration Afi uses changes block tracking API provided by AWS to perform fast and lightweight incremental backups.

An Azure Kubernetes Service (AKS) cluster requires an identity to access Azure resources like managed disks and snapshots. This identity can be one of the following:

managed identity - A managed identity is the type of identity managed by the Azure platform and doesn't require the user to provision or rotate any secrets. For more information about managed identities in Azure AD, see Managed Identities.
service principal - A service principal is a security identity used by user-created apps, services, and automation tools to access Azure resources. Think of it as a 'user identity' (login and password or certificate) with a specific role, and tightly controlled permissions to access your resources. For more information about service principal in Azure AD, see Service Principal.

Managed identities are essentially a wrapper around service principals and make their management simpler. The same permission requirements apply for both service principals and managed identities.

To proceed with the configuration, locate the resource group associated with your AKS cluster, configure a managed identity or a service principal which will be able to manage snapshots and disks in your AKS cluster and share its credentials with the Afi backup agent.

Locate a resource group associated with your AKS cluster¶

When an AKS cluster is created in a specific resource group, AKS creates one more resource group associated with this cluster, where its aks-nodepool, disks and snapshots are located. To use AKS API directly for snapshot management, Afi Kubernetes Backup needs access to this resource group. The resource group name format is mc_{resource-group}_{cluster}_{zone}.

For example, if you have an AKS cluster in the k8s resource group and eastus Azure location, the corresponding resource group should be mc_k8s_kn-0_eastus.

Set up Azure API access through a managed identity¶

Prerequisites¶

An AKS cluster should support managed identities to use this setup option. The following Azure documentation articles describe how to create an AKS cluster which supports managed identities or upgrade an existing AKS cluster to use managed identities:

Create a custom role¶

Below is the JSON description of a Azure custom role k8sbackup required for snapshot management (replace ${SubscriptionId} with an identifier of your Azure subscription). Save it to a file named role.json:

{
  "Name": "k8sbackup",
  "IsCustom": true,
  "Description": "",
  "Actions": [
    "Microsoft.Compute/snapshots/write",
    "Microsoft.Compute/snapshots/read",
    "Microsoft.Compute/snapshots/delete",
    "Microsoft.Compute/snapshots/beginGetAccess/action",
    "Microsoft.Compute/snapshots/endGetAccess/action",
    "Microsoft.Compute/disks/write",
    "Microsoft.Compute/disks/read",
    "Microsoft.Compute/disks/delete",
    "Microsoft.Compute/disks/beginGetAccess/action",
    "Microsoft.Authorization/*/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/${SubscriptionId}"
  ]
}

Create a custom role:

az role definition create --role-definition "role.json"

The new custom role is now available and can be assigned to users, groups, or service principals just like built-in roles. For more information, see Create a custom role article in Azure documentation.

Create a managed identity¶

Create a managed identity myIdentity by running the following az identity command:

az identity create --name myIdentity --resource-group myResourceGroup

The command output should look the following way:

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "eastus",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Save clientId value for later use.

Add role assignment for control plane identity¶

Assign the k8sbackup role to a managed identity myIdentity created in the previous step. This way myIdentity will be able to manage Azure disks and snapshots in the resource group associated with your AKS cluster (myResourceGroup).

az role assignment create --assignee ${clientId} --role "k8sbackup" \
    --scope subscriptions/${SubscriptionId}/resourceGroups/myResourceGroup

Assign the managed identity to the virtual machine scale set¶

Assign the managed identity myIdentity to the existing virtual machine scale set associated with the AKS cluster and update instances.

az vmss identity assign -g myResourceGroup -n aks-nodepool-name \
    --identities myIdentity

az vmss update-instances -g myResourceGroup -n aks-nodepool-name \
    --instance-ids "*"

Create azure-api-key Secret and restart the backup agent¶

Create a Kubernetes Secret named azure-api-key in the namespace where the Afi backup agent is installed:

kubectl -n backup-agent create secret generic azure-api-key \
    --from-literal=client-id=${clientId}

Restart a daemonset that makes snapshots of persistent volumes:

kubectl -n backup-agent rollout restart ds/pvsnapshotter

Set up Azure API access through a service principal¶

Create a custom role¶

Below is the JSON description of a Azure custom role k8sbackup required for snapshot management (replace ${SubscriptionId} with an identifier of your Azure subscription). Save it to a file named role.json:

{
  "Name": "k8sbackup",
  "IsCustom": true,
  "Description": "",
  "Actions": [
    "Microsoft.Compute/snapshots/write",
    "Microsoft.Compute/snapshots/read",
    "Microsoft.Compute/snapshots/delete",
    "Microsoft.Compute/snapshots/beginGetAccess/action",
    "Microsoft.Compute/snapshots/endGetAccess/action",
    "Microsoft.Compute/disks/write",
    "Microsoft.Compute/disks/read",
    "Microsoft.Compute/disks/delete",
    "Microsoft.Compute/disks/beginGetAccess/action",
    "Microsoft.Authorization/*/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/${SubscriptionId}"
  ]
}

Create a custom role:

az role definition create --role-definition "role.json"

The new custom role k8sbackup is now available and can be assigned to users, groups, or service principals just like built-in roles. For more information, see Create a custom role article in Azure documentation.

Create a service principal¶

Create a service principal myServicePrincipal and configure its access to the Azure resource group myResourceGroup:

az ad sp create-for-rbac --name myServicePrincipal \
    --role k8sbackup \
    --scopes subscriptions/${SubscriptionId}/resourceGroups/myResourceGroup

The command output should look the following way:

{
  "appId": "<appId>",
  "displayName": "myServicePrincipal",
  "password": "<password>",
  "tenant": "<tenant>"
}

Save appId, password and tenant values to later use.

Create azure-api-key Secret and restart the backup agent¶

Create a Kubernetes Secret named azure-api-key in the namespace where the Afi backup agent is installed:

kubectl -n backup-agent create secret generic azure-api-key \
    --from-literal=client-id=${appId} \
    --from-literal=client-secret=${passport} \
    --from-literal=tenant-id=${tenant}

Restart a daemonset that makes snapshots of persistent volumes:

kubectl -n k8sbackup rollout restart ds/pvsnapshotter