Quoi ? Comment ? Quand ? Pourquoi ? …. Quoi ?!

Un service principal est très utile pour donner une identité à une application et définir ses autorisations. À l’aide d’un service principal, nous pouvons, par exemple, restreindre l’accès d’une application à d’autres ressources (comme une base de données) et contrôler ce qu’elle peut faire sur cette base de données de manière plus granulaire.

Un service principal est également très utile lors de la définition d’une connexion de point de terminaison dans Azure DevOps par exemple, afin que tu puisses déployer et/ou configurer tes ressources Azure à partir de tes pipelines à l’aide d’ARM.

Cependant, lorsqu’on crée un service principal, ses informations d’identification (son mot de passe) ne sont par défaut valides que pour un an. Ceci est pour des raisons de sécurité afin d’éviter d’oublier un service principal et de le laisser traîner indéfiniment, ce qui peut causer une faille de sécurité dans notre infrastructure.

Pourquoi devrais-je m’en soucier?

Tu devrais ! Parce que si tu ne le fais pas, tes services qui reposent sur des service principals pour l’authentification et les permissions pourraient cesser de fonctionner.

Dans le scénario évoqué plus haut par rapport au point de terminaison dans Azure DevOps, l’exécution de tes pipelines échoueront due à l’absence des autorisations requises.

Comment puis-je vérifier la date d’expiration des informations d’identification de mon service principal ?

En utilisant ces deux commandes:

$sp = Get-AzADServicePrincipal -DisplayName $myServiceprincipalName
Get-AzADSpCredential -ObjectId $sp.Id

Comment gérer ça?

Selon que ton service principal soit déjà créé ou non, la procédure est légèrement différente.

Définir la date d’expiration lors de la création du service principal

Si tu n’as pas encore créé ton service principal, voici comment définir une date d’expiration personnalisée pour celui-ci lors de sa création.

Ici, nous créons un principal de service nommé totoSP ayant le rôle Reader et nous nous assurons que le mot de passe soit valide durant 150 ans. Cela semble bizarre (et ça l’est !) mais c’est juste pour les besoins de la démo 😉

$start = get-date
$end = $start.AddYears(150)

New-AzADServicePrincipal -DisplayName 'totoSP' -Role Reader -StartDate $start -EndDate $end

Prolonger la date d’expiration d’un service principal existant

Si ton service principal existe déjà (que ses informations d’identification aient expiré ou pas encore), tu peux définir une date d’expiration personnalisée à l’aide des commandes suivantes.

Encore une fois, nous nous assurons que le mot de passe soit valide durant 150 ans, ce qui peut sembler étrange (et ça l’est !) mais c’est juste pour les besoins de la démo 😉

# Obtenir l’ID du service principal
$sp = Get-AzADServicePrincipal -DisplayName $myServiceprincipalName

# Définir le nouveau mot de passe avec une date d’expiration étendue
$start = get-date
$end = $start.AddYears(150)

$credentials = New-AzADSpCredential -ObjectId $sp.Id -StartDate $start -EndDate $end

Dans le cas où tu aurais besoin du nouveau mot de passe (par exemple, pour mettre à jour les informations du point de terminaison de service dans Azure DevOps), tu peux utiliser les commandes suivantes.

Attention cependant, tu ne pourras les utiliser que dans le contexte de la même session PowerShell dans laquelle tu as créé ce mot de passe:

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($credentials.Secret)

$UnsecureSecret = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

Write-Host $UnsecureSecret

Le script précédent génère un mot de passe aléatoire et l’utilise pour la mise à jour des informations d’identification.

Si tu souhaites spécifier ton propre mot de passe, tu peux le faire en utilisant plutôt ces commandes:

$SecureStringPassword = ConvertTo-SecureString -String "@zuR3_R0ck$!!!!" -AsPlainText -Force

New-AzADSpCredential -ObjectId $sp.Id -StartDate $start -EndDate $end -Password $SecureStringPassword

En conclusion…

Aujourd’hui, nous avons appris que les informations d’identification d’un service principal Azure ont une date d’expiration. Nous avons également vu comment adresser ce problème.

J’espère que cela te sera utile.

Continuons la discussion

N’oublie pas que tu peux me joindre sur Twitter ou LinkedIn.

À la prochaine !