Google Auth — Démystifier la magie

https://www.googleapis.com/auth/compute.readonly

import google.auth
creds, project = google.auth.default()

gcloud compute instances create instance-1 ... \
    --scopes=cloud-platform,

gcloud compute ssh instance-1 -- python3
>>> import google.auth
>>> creds, project = google.auth.default()
>>> from google.auth.transport import requests
>>> creds.refresh(requests.Request())
>>> creds.scopes
['\
```\
\
[https://www.googleapis.com/auth/cloud-platform'](https://www.googleapis.com/auth/cloud-platform%27)\
\
```\
, '\
```\
\
[https://www.googleapis.com/auth/drive'](https://www.googleapis.com/auth/drive%27)\
\
```\
]
````

Je dis " relativement de chance " avec GCE et GKE car les scopes ne peuvent être spécifiés qu'à la création. C'est un moindre mal pour une VM unique, mais cela peut devenir pénible avec GKE, où vous risquez de devoir redéployer tout le node pool juste pour ajouter un scope.

Au final, votre code ne change pas, mais vous devez anticiper côté DevOps.

Cela dit, il existe un moyen d'obtenir des identifiants avec des scopes qui _n'ont pas été_ autorisés à l'avance pour la VM, que je décris vers la fin.

#### Google App Engine

App Engine est l'un des plus anciens services GCP et un véritable framework serverless qui, à bien des égards, était en avance sur son temps. Mais qui dit grand héritage dit aussi nombreuses contraintes héritées du passé. L'une d'elles : toutes les applications App Engine ont leurs scopes figés à `cloud-platform`, sans moyen simple de s'en affranchir.

Une solution de contournement consiste à faire usurper l'identité du compte de service par défaut d'App Engine vers un autre compte de service, voire vers lui-même, en demandant de nouveaux scopes au passage. [**Voici**](https://cloud.google.com/iam/docs/understanding-service-accounts#acting_as_a_service_account) la documentation officielle de Google Cloud sur le sujet. Voyons ce que cela donne en Python :

````
SCOPES = ["\
```\
\
[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/spreadsheets.readonly)\
\
```\
"]
svcacc = "test
````

[@my-project-id.iam.gserviceaccount.com](mailto:[email protected])

Attention à l'argument `cache_discovery=False` : il est nécessaire à cause d'un [bug](https://github.com/googleapis/google-api-python-client/issues/299). Pour que ce qui précède fonctionne, vous devez aussi accorder le rôle Token Creator au compte de service par défaut d'AppEngine sur votre compte de service cible :

[appspot.gserviceaccount.com](https://console.cloud.google.com/iam-admin/serviceaccounts/details/108759703281763060579?authuser=1&project=zaar-playground)

**À noter** **: cette approche soulève une question de sécurité importante** — tous les services App Engine d'un projet donné s'exécutent sous _le même compte de service_. Par conséquent, _tous_ pourront usurper l'identité, ce qui peut poser problème.

Il n'y a malheureusement pas de parade simple, mais je présente une solution plus loin dans cet article.

**Mise à jour de novembre 2021 :** App Engine permet désormais de [spécifier](https://cloud.google.com/appengine/docs/standard/python3/user-managed-service-accounts) un compte de service personnalisé par service.

#### Cloud Run / Functions

Lors du déploiement d'un service Cloud Run ou d'une Cloud Function, plus de question de scopes : enfin ! Pourquoi se compliquer la vie quand on peut tout simplement demander les scopes voulus à la volée, comme ceci :

````
import google.auth
SCOPES = ["\
```\
\
[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/spreadsheets.readonly)\
\
```\
"]
creds, _ = google.auth.default(scopes=SCOPES)
````

Procédez ensuite comme d'habitude avec l'API de votre choix. Voir l'exemple complet [ici](https://medium.com/@guillaume.blaquiere/yes-my-experience-isnt-the-same-63ac3c783864).

À mon sens, c'est ainsi que cela aurait dû fonctionner aussi dans GKE/GCE/GAE.

Au cas où vous vous poseriez la question : non, faire la même chose dans GCE/GKE ne donnera pas l'effet escompté. Sur GCE/GKE, les scopes demandés dans votre application sont ignorés et réinitialisés à ceux configurés pour la VM ou le node pool.

#### **Développement local**

Quand j'ai commencé à travailler avec l'API Google Directory, j'ai été surpris de constater que pour invoquer cette API, il **fallait** obligatoirement passer par un compte de service GCP, et donc disposer d'un projet GCP correctement configuré avec l'API souhaitée activée.

Comme les identifiants ADC obtenus dans l'environnement de dev local (sur votre laptop, donc) appartiennent généralement à votre utilisateur, ils sont en pratique inutilisables avec de nombreuses APIs non-GCP (l'API Directory, par exemple).

La seule voie reste, là encore, l'usurpation d'identité ; le code de la section GAE ci-dessus fonctionne ici tel quel.

## Que sont les subjects ?

Les subjects sont souvent un petit détail qui complique encore le code d'amorçage de l'authentification. Le fait est que pour accéder à _Directory API_ (par exemple pour lister les utilisateurs de votre domaine G Suite), vous agissez au nom d'un certain utilisateur de l'annuaire qui doit être spécifié comme _subject_ de l'identifiant.

Du coup, on peut se retrouver dans une usurpation en boucle lors de l'exécution depuis un environnement de dev local : un `[email protected]` authentifié localement usurpe l'identité d'un compte de service afin de dialoguer avec l'API Directory de son propre domaine ; puis ce compte de service agit au nom d'`[email protected]` dans l'annuaire.

Quoi qu'il en soit, il faut spécifier cet e-mail " act as " comme subject des identifiants, ce qui fait exploser notre code de configuration de l'authentification :

[https://accounts.google.com/o/oauth2/token](https://accounts.google.com/o/oauth2/token)

````
"
SCOPES = ["\
```\
\
[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/spreadsheets.readonly)\
\
```\
"]
svcacc = "test
````

[@my-project-id.iam.gserviceaccount.com](mailto:[email protected])

Cela fonctionne aussi pour tous les cas décrits plus haut : il suffit de passer `subject=None` si vous n'utilisez pas l'API Directory, et de bien attribuer les rôles Token Creator.

**On a donc une solution, youpi !** Seul bémol : en passant cette approche en production et en y injectant les tokens d'_identité_, on se retrouve avec près de 200 lignes de [code](https://gist.github.com/haizaar/fcf8ee4b98b2452c618582bca632a338) juste pour obtenir des identifiants d'authentification — dont la moitié sont des commentaires, signe habituel de complexité.

## Une meilleure approche ?

Nous avons une solution qui fonctionne partout (mis à part le risque de sécurité potentiel avec App Engine), mais elle paraît désormais bien tarabiscotée comparée au simple appel `google.auth.default()` que nous utilisions auparavant. Existe-t-il une autre voie ?

J'ai une suggestion qui paraîtra peut-être plus simple à certains. Au moins, elle répond au problème de sécurité d'App Engine lié à l'usurpation d'identité. La voici :

-   Créer un fichier de clé pour le compte de service dont vous voulez usurper l'identité. Oui, le bon vieux fichier de clé " disgracieux ".
-   Chiffrer ce fichier avec [Mozilla sops](https://github.com/mozilla/sops) + GCP KMS et le stocker avec votre code.
-   Accorder à votre compte de service opérationnel un rôle de déchiffrement sur la clé GCP KMS utilisée pour chiffrer le fichier de clé du compte de service.

Votre code d'amorçage ressemblera désormais à ceci :

L'objet `creds` obtenu dispose de deux méthodes pratiques, `with_scopes()` et `with_subject()`, qui retournent un nouvel objet d'identifiants avec les scopes/subject mis à jour.

Bien que cela demande davantage de configuration, notamment l'intégration du binaire `sops` de 30 Mio dans vos Cloud Functions et images de conteneurs, le flux est très facile à comprendre (contrairement à l'approche précédente).

Cette solution résout aussi le problème d'App Engine : il reste vrai que le compte de service par défaut d'App Engine peut potentiellement déchiffrer tous les fichiers de clé, mais des services GAE déployés depuis des dépôts git différents n'auront pas accès aux fichiers de clé chiffrés des autres — d'où une vraie isolation des secrets !

#### Traçabilité de l'authentification

Voici une partie bonus — merci d'être arrivé jusqu'ici.

L'un des avantages de l'usurpation d'identité par rapport aux disgracieux fichiers de clé de compte de service, c'est que l'on peut retracer le principal d'origine ayant effectué l'usurpation jusqu'au compte de service.

Voici l'aide-mémoire d'audit :

-   [Activez](https://cloud.google.com/iam/docs/audit-logging#enabling_audit_logging) les audit logs Data Access pour le service IAM.
-   Effectuez l'usurpation, par exemple `gcloud --impersonate-service-account=<email> projects list`.
-   Ouvrez l'[Explorateur de logs](https://console.cloud.google.com/logs) et sélectionnez " Service Account " dans le menu déroulant " Resource " et " data\_access " dans le menu déroulant " Log name ".

Ou saisissez tout simplement la requête ci-dessous :