G 2 Suite dans les idées: le retour du compte de service
Permettre à des applications d’accéder aux données et applications de G Suite c’est bien, mais l’inverse c’est encore mieux.
Le cas d’usage: Partager des documents
Par exemple: vous fabriquez des documents pour vos clients et vous souhaitez les mettre à leur disposition. Pour autant vous ne souhaitez pas leur fournir une licence G Suite et un accès au Drive.
La solution:
- Déposer vos fichiers dans un bucket de Google Cloud Storage (GCS)
- Créer des comptes d’accès dans Google Cloud Identity (GCI)
- Donner les liens d’accès
Avantages:
- Vous ne payez pas de licence G Suite pour les 50 premiers comptes d’accès (Google Cloud Identity)
- Le prix de stockage est moins cher que dans Drive (100 Go 1,99€ dans Drive vs 100 Go 1$ en NearLine Storage)
Développement: le nouveau Far West
Malheureusement, bénéficier de cette aubaine n’est pas donné à tout le monde. Il faut développer. Mais si vous faites cet effort un nouvel horizon s’offre à vous et le compte de service est votre ami.
Cependant il ne va plus servir comme porte d’entrée dans G Suite, mais l’inverse, c’est votre ambassadeur dans l’Eldorado du Google Cloud Platform (GCP).
Des rôles toujours plus de rôles
Nous avons déjà évoqué le modèle de rôles de GCP, mais finalement nous n’avions pas développé cette partie car la partie autorisation se trouvait dans G Suite Drive et il fallait seulement un scope (autorisation d’API). Avec le retournement du flux, il devient urgent de plonger dans la gestion des rôles et permissions de GCP.
Pour cela GCP fournit une gestion des identités et accès
Rappelez-vous vous pouvez organiser GCP par domaine / projet et dossier. Le compte de service est dans le projet PayPalipn et il dispose de rôles de très haut niveau Editor et Owner. Pour autant dans notre cas d’usage ce n’est pas suffisant. Afin d’avoir des droits dans la partie Storage, il faut donner des droits au compte.
Notre compte de service obtient des rôles spécifiques sur le bucket mais hérite aussi d’un rôle donné au niveau projet
(Storage Object Admin).
Nous voilà retourné dans l’enfer des héritages et des choix hasardeux 😉
Il faut ensuite consommer ce service dans un appel à l’API REST GCS comme suit :
Tout finit par du code
Chose promise chose dûe, donnons quelques éléments de code pour réussir ce mariage. En premier dans vos scripts côté G Suite vous allez appeler le compte et l’authentifier avec son certificat:
Pour conclure
Je n’ai pas fait la démonstration de l’utilisation des comptes d’accès GCI, ce sera pour une prochaine fois 😉
Le compte de service est un passeur entre les deux mondes G Suite et GCP. Le provisioning et la gestion des habilitations de ces comptes et ceux des utilisateurs est une belle gageure pour les gestionnaires d’identités qui vont mettre un certain temps à intégrer ce modèle. Tout en sachant que nous trouvons la même complexité chez Amazon AWS et Azure AD.
Stéphan.P
Sources
