Migrare una service connection a workload identity federation in Azure DevOps

di Matteo Tumiati, in DevOps,

Quando da Azure DevOps vogliamo comunicare con Azure per, ad esempio, fare il deploy di un'applicazione web all'interno di un App Service o di un container in AKS, abbiamo bisogno di creare un service endpoint, anche conosciuto come "Service Connection", ovvero una connessione pre-autorizzata tramite un service principal nei confronti della nostra istanza cloud.

Il problema è che viene richiesto, per l'appunto, un service principal. Questo significa che dobbiamo creare un'entità di sicurezza all'interno del nostro tenant Azure, con un ID e una chiave segreta, che va ruotata periodicamente e che può essere persa o sfruttata in malo modo per accedere ai nostri sistemi interni, vanificandone la sicurezza.

Oggi, Azure DevOps, fornisce un nuovo strumento per creare un service endpoint con Azure che sfrutta la Workload Identity Federation, ovvero un meccanismo che permette di delegare l'autenticazione e l'autorizzazione a un servizio di Azure, senza dover creare un service principal. Questo meccanismo è molto più sicuro e non richiede la gestione di secret. La creazione di nuove service connection verrà proposta in automatico con la federation, mentre quelle esistenti possono essere convertite manualmente, vediamo come.

Il primo passaggio è quello di collegarsi al nostro tenant di Azure:

$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

A questo punto recupero tutte le service connection di tipo "AzureRM" che sono visibili nel mio progetto:

$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=7.1"

az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug

Per ogni service connection trovata effettuo la conversione da ServicePrincipal a WorkloadIdentityFederation:

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    # Get the state of the service connection
    if (!$updatedServiceEndpoint) {
      Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
      exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

Completato con successo l'esecuzione dello script, non dovremo più preoccuparci di dover gestire e rinnovare le secret delle service connection o dei service principal associati, rendendo l'autenticazione molto più sicura, semplice e facile da manutenere.

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

I più letti di oggi