Je parle beaucoup de cloud public, que ça soit US ou EU et pour le coup s’il y a bien une chose qui me manque énormément quand j’utilise les solutions clouds EU c’est bien le service IAM. Je ne pense pas que ce service soit anodin, il est la pierre angulaire de la sécurité dans le cloud aujourd’hui. La bonne nouvelle, c’est que Scaleway a sorti sa solution IAM pour son offre cloud ! Une bonne occasion de tester ça.

IAM c’est quoi ?

Avant tout, définissons un peu IAM, à quoi ça sert et les fonctionnalités qu’on peut y retrouver. Si on définit de manière large, IAM pour Identity and Access Management sert tout simplement à gérer les identités et les accès à la plateforme. Le tout en permettant d’associer des sets de droits spécifiques pour des utilisateurs ou groupes d’utilisateurs au travers de policy.

Par exemple, si vous avez besoin d’un utilisateur qui doit pouvoir récupérer des images de conteneur dans un registry du cloud provider vous allez passer par IAM. Dans l’idéal vous allez même lui limiter les droits en lecture sur les images spécifiques.

C’est ici le domaine principal de l’IAM, ce qui en fait la serrure sur la porte d’entrée qu’est l’API du fournisseur cloud.

À cela, peut s’ajouter plusieurs fonctionnalités plus avancées, comme la lecture des logs des appels APIs sur vos comptes, ce qui est très important du point de vue auditabilité et souvent négligé. Ou encore l’intégration des solutions hébergées dans IAM, ainsi vous pouvez utiliser IAM pour vous connecter à l’API d’un Kubernetes hébergé, une centralisation bienvenue.

L’offre de Scaleway

IAM était promis et attendu depuis longtemps par les utilisateurs de Scaleway. Actuellement il n’existait qu’une seule vraie limite au sein d’une organisation, c’était la notion de projet avec des clés scopes à celui-ci.

C’est chose corrigée avec l’IAM, aujourd’hui. Quand on regarde la page de présentation, on note les points suivants :

• On a la possibilité de gérer des utilisateurs et de leurs attacher des règles
• Les règles (policy) sont personnalisables
• On peut créer des utilisateurs applicatifs
• La solution est décrite comme simple, quand on connaît AWS IAM c’est une grosse promesse
• C’est intégré dès le premier jour à Terraform et à la CLI Scaleway

Sur le papier c’est clairement une offre intéressante et surtout qui surpasse déjà les solutions concurrentes des autres fournisseurs français.

À l’usage ça donne quoi ?

Sur la console web

À l’arrivée sur la console de gestion, on retrouve dans le menu utilisateur en haut à droite le service IAM. Celui-ci rejoint ce menu qui regroupait déjà les précédentes options de gestion comme pour l’organisation.

On nous demande ensuite de l’activer si on le souhaite, on nous précise que l’opération va migrer les droits et clés existantes.

Je précise que je n’ai eu aucun problème de compatibilité, ou d’anciennes clés qui ont été révoquées lors de cette migration.

Dans ce test nous créons le moins de ressource possible côté console, je vais néanmoins l’utiliser pour créer un utilisateur pour mon outil d’infrastructure as code Terraform.

Je note que les menus d’IAM sont plutôt clairs et permettent une vue globale sur les utilisateurs avec notamment un récapitulatif sur l’activation du 2FA, ce qui est agréable.

Pour cela je créé une application et j’y adjoins un set de règle que je créer dans la foulé.

J’arrive rapidement à une des parties que j’attends le plus: la conception des règles. C’est le vrai enjeu de l’IAM de pouvoir gérer des droits fins, le tout en étant accessible. Trouver un équilibre là-dessus n’est pas un exercice simple. Si je prends l’exemple d’AWS, leurs systèmes sont top au niveau personnalisation et finesse, mais d’une assez grosse complexité qui finit par pousser les entreprises les moins contentieuses à utiliser des droits très larges.

Globalement ici, ça se passe en 2 étapes :

• On choisit le scope (un projet, tous les projets ou toute l’organisation)
• On assigne ensuite un pré-set d’autorisations en fonction du service (lecture seule sur les instances, full accès sur les instances, etc.)

Dans mon cas, vu que le Terraform va gérer l’IAM, je dois passer par le scope organisation.

Je peux ensuite ajouter d’autres règles, dans mon cas il ne me suffit que d’une règle.

Je note quand même que j’ai dû recréer ma policy à plusieurs reprises, tombant plusieurs fois sur des messages d’erreur ne précisant pas le problème à date du test (le 4 janvier 2023).

Dans l’Infrastructure As Code

Maintenant, lançons-nous dans l’iac. Comme tous mes tests, je vous encourage à vous faire votre propre avis dans cette optique le code source du poc est disponible sur : github.com

Je vais créer :

• Trois applications
• Deux groupes avec chacun des set de règles
• Ajouter mon utilisateur à un des groupes

Je commence par créer mes trois applications et mes deux groupes :

resource "scaleway_iam_application" "app" {
  count				= length(var.apps)
  name				= "poc-application-${var.apps[count.index]}"
  description = "A simple application to create"
}

resource "scaleway_iam_group" "dev" {
  name						= "dev_group"
  application_ids = [scaleway_iam_application.app[0].id, scaleway_iam_application.app[1].id]
}

resource "scaleway_iam_group" "ops" {
  name						= "ops_group"
  application_ids = [scaleway_iam_application.app[2].id]
  user_ids				= [data.scaleway_iam_user.moi.id]
}

Pas de soucis par ici, les groupes peuvent tout à fait regrouper utilisateur classique et applicatif.

Je vous conseille d’ailleurs de toujours utiliser des groupes pour attacher les droits, cela simplifiera votre gestion.

Vient ensuite la création de deux set de règles :

• dev_policy : qui va venir autoriser sur le compte de prod en readonly sur kapsules, les buckets et en write sur le staging.
• ops_policy : qui aura les droits en lecture et écriture sur le même set de service.

Ce qui nous donne ce résultat sous Terraform :

resource "scaleway_iam_policy" "dev" {
  name     = "developers permissions"
  group_id = scaleway_iam_group.dev.id
  rule {
    project_ids					 = [data.scaleway_account_project.staging.id, data.scaleway_account_project.prod.id]
    permission_set_names = ["InstancesReadOnly", "KubernetesReadOnly", "ObjectStorageBucketsRead"]
  }
  rule {
    project_ids					 = [data.scaleway_account_project.staging.id]
    permission_set_names = ["ObjectStorageObjectsWrite"]
  }
}

resource "scaleway_iam_policy" "ops" {
  name     = "SRE permissions"
  group_id = scaleway_iam_group.ops.id
  rule {
    project_ids			 		 = [data.scaleway_account_project.staging.id, data.scaleway_account_project.prod.id]
    permission_set_names = ["KubernetesFullAccess", "InstancesFullAccess", "ObjectStorageBucketsRead", "ObjectStorageObjectsWrite"]
  }
}

Pour information, les set de règles sont disponibles avec la commande scw iam permission-set list.

Je note qu’il existe aussi la ressource scaleway_iam_api_key, je ne l’utiliserai pas et je déconseille fortement son utilisation comme sur AWS d’ailleurs. Tout simplement, car celle-ci stocke les tokens en clair dans les states Terraform.

Si je tente de créer une ressource hors des droits, le code d’erreur est bon et explicite aussi bien avec la cli qu’avec Terraform :

scaleway_instance_ip.test: Creating...
╷
│ Error: scaleway-sdk-go: http error 403 Forbidden: insufficient permissions
│
│   with scaleway_instance_ip.test,
│   on test.tf line 1, in resource "scaleway_instance_ip" "test":
│    1: resource "scaleway_instance_ip" "test" {}
│
╵

À partir de là, on peut créer nos clés et effectuer nos tests. De là on peut continuer normalement à utiliser l’ensemble des services.

J’ai testé à l’utilisation notamment le cloisonnement entre projets et je n’ai pas rencontré de problème hormis quelques erreurs sporadiques à la création de policy avec la console web.

Une base solide, mais quelques limites

Le service fonctionne comme promis, vous pouvez créer, gérer les droits et les accès aux services Scaleway de votre organisation. Et je dois avouer que l’intégration notamment sur Terraform et la documentation le premier jour est un très bon point.

Cela n’empêche pas d’y voir déjà quelques limites. Tout d’abord, les règles prédéfinies sont tout de même assez limitées. Alors oui, pour beaucoup ça sera suffisant, mais j’avoue rester sur ma faim sur cette partie. De même il s’agit uniquement d’additionner des droits pas de système de deny ou autre, d’un côté cela permet de garder une simplicité, mais ça réduit aussi les possibilités. L’offre manque aussi de flexibilité, il n’est pas possible de déléguer la gestion IAM d’un projet spécifique à un utilisateur.

Au niveau global, j’attends maintenant les fonctionnalités annexes à IAM, qui reposent dessus. Comme par exemple, l’authentification keyless entre service ou encore pouvoir me connecter à Kapsule ou une base managée avec un utilisateur IAM Scaleway, sans oublier l’accès aux logs d’API sur une organisation.

Il faut tout de même noter que techniquement, le plus difficile est fait, la couche IAM est intégrée aux API Scaleway, mine de rien c’est souvent le point de blocage.

Malgré ces quelques ombres au tableau, ça reste un très gros pas en avant et je félicite les équipes de Scaleway sur ce travail. Je vais surveiller de près ce produit et surtout son évolution.

Si je sujet vous intéresses j’ai eu la chance, d’échanger avec des membres de l’équipe IAM Scaleway lors du podcast DevObs disponible par ici : Dev’Obs #30 / IAM @ Scaleway.