Comme beaucoup de fournisseurs de cloud, tout est facile à mettre en place sur OVH Cloud. Pour créer un bucket S3, il vous suffit de :
- cliquer deux fois
- de saisir un nom de bucket
- de créer un utilisateur
- de l’associer au bucket avec les droits d’accès que vous souhaitez lui attribuer
et le tour est joué!
Vous êtes maintenant prêt à mettre des données dans le bucket et à les utiliser pour vos services, votre site web, etc.
Que se passe-t-il lorsque vous avez de nombreux buckets, des dizaines de comptes différents et que vous devez vérifier qui a accès à quoi et les droits associés ?
Eh bien, vous commencez par regarder l’interface utilisateur et vous êtes désespéré car vous voyez qu’il y a beaucoup d’informations, mais qu’il n’est pas si simple d’obtenir tout ce que vous cherchez.
Bien sûr, vous pouvez contacter le support et, selon le niveau de support auquel vous avez accès, vous aurez une des deux bonnes vieille réponse « lisez notre documentation sur cette page » ou alors « vous devriez utiliser l’API ».
Je vais vous faciliter la tâche : commencez ici avant de lire documentation sur leur page 😉
Consulter le tableau de bord d’OVH Link to heading
Comme illustré par l’image ci-dessous, la page bucket sur OVH Cloud vous donne la liste des buckets créés dans votre projet cloud.
Sur la page des utilisateurs S3, vous obtenez une liste d’utilisateurs créés comme illustré ci-dessous
Maintenant, la question est : comment relier les deux et vérifier à quoi l’administrateur du stockage a accès, et qu’en est-il des utilisateurs de podcasts et de vidéos ?
Eh bien, sur le site Web, vous êtes assez limité. Sur l’entrée du conteneur S3, vous pouvez uniquement y ajouter un utilisateur, voir ses objets et le supprimer.
Sur l’entrée utilisateur S3, vous pouvez obtenir la politique S3 au format JSON qui vous fournira des informations sur ce à quoi l’utilisateur a accès et ce qu’il peut en faire.
Lorsque vous téléchargez la politique S3, vous obtenez un fichier au format JSON.
Si le contenu du fichier est le suivant, cela signifie que l’utilisateur n’a pas accès
{
"Statement":[]
}
Si le contenu du fichier est le suivant, cela signifie que l’utilisateur dispose de droits d’accès personnalisés à tous les buckets
{
"Statement":[
{
"Action":[
"s3:CreateBucket",
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket",
"s3:ListMultipartUploadParts",
"s3:ListBucketMultipartUploads",
"s3:AbortMultipartUpload",
"s3:GetBucketLocation"
],
"Effect":"Allow",
"Resource":[
"arn:aws:s3:::*",
"arn:aws:s3:::*/*"
],
"Sid":"RWContainer"
}
]
}
Si le contenu du fichier est le suivant, cela signifie que l’utilisateur dispose de droits d’accès personnalisés à l’élément spécifié buckets
{
"Statement":[
{
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket",
"s3:ListMultipartUploadParts",
"s3:ListBucketMultipartUploads",
"s3:AbortMultipartUpload",
"s3:GetBucketLocation"
],
"Effect":"Allow",
"Resource":[
"arn:aws:s3:::video-data",
"arn:aws:s3:::video-data/*"
],
"Sid":"RWContainer"
},
{
"Action":["s3:*"],
"Effect":"Allow",
"Resource":[
"arn:aws:s3:::podcast-data",
"arn:aws:s3:::podcast-data/*"
],
"Sid":"AdminContainer"
}
]
}
Vous trouverez des informations complémentaires sur le détail des droits d’action dans les guides généraux Object Storage d’OVH pour commencer
Vérification de l’API d’OVH Link to heading
Gardez à l’esprit que la plupart, voire la totalité, de ce qui se trouve sur le tableau de bord d’OVH provient de leurs propres API. Cela signifie que tout ce que vous obtenez sur leur site Web est disponible dans leur API, et bien plus encore.
Je commencerai par vous donner les trois liens les plus importants concernant les API d’OVH :
- Premiers pas avec les API OVHcloud –https://help.ovhcloud.com/csm/fr-fr-api-commencer-avec-l-api-ovhcloud?id=kb_article_view&sysparm_article=KB0042784
- OVH API Discover – https://eu.api.ovh.com/
- Création de tokens API OVH : https://eu.api.ovh.com/createToken/
Le premier lien est une documentation sur la façon d’interagir avec l’API d’OVH. Le second est une sorte de site d’interaction API (vous n’aurez pas encore besoin de Postman) où vous pourrez tester tous les appels API, et où je passe beaucoup de temps ici avant de coder. Le troisième est l’endroit où vous pourrez créer des jetons API à utiliser dans votre propre code.
A la découverte des API d’OVH Link to heading
Comme je l’ai déjà dit, je passe la plupart de mon temps sur le site Web Discover de l’API d’OVH avant de coder. Cela me permet d’analyser tous les appels d’API, de vérifier les paramètres nécessaires et de comparer le résultat avec ce qui est vu sur leur site Web (ou ce que j’attends).
L’un des meilleurs aspects de ce site Web est qu’il fournit une classe de réponse (qui vous donnera les paramètres de sortie attendus), ainsi que des exemples de code PHP et Python pour vous aider à commencer vos scripts.
Il existe tellement d’appels API que vous pouvez utiliser qu’il n’est pas toujours facile de trouver ce dont vous avez besoin.
Comment réaliser un audit à l’aide de l’API Link to heading
OVH travaille avec des projets cloud, où chacun peut-être soit un projet différent, soit un client différent, etc. Cela signifie que chaque utilisateur est créé dans un projet cloud spécifique.
Tous les noms d’utilisateur et mots de passe sont générés du côté d’OVH, et vous pouvez attribuer une description à cet utilisateur et les droits d’accès à un ou plusieurs buckets. Je ne vais pas détailler comment faire, car il existe des guides disponibles pour cela.
Pour auditer l’accès des utilisateurs aux buckets S3, vous avez besoin des éléments suivants :
- l’ID du projet
- la liste des utilisateurs
- puis listez les droits d’accès pour chaque utilisateur
Obtenir l’ID du projet Link to heading
Obtenir l’ID du projet est le plus simple, soit vous allez sur votre Dashboard OVH et vous le récupérez sous son nom comme suit :
Ou vous utilisez l’appel API /cloud/project comme suit :
Une fois que vous avez obtenu l’ID du projet, qui est « yntasafv7bji02ks3uw2ot6ntwzf76l6 » pour cet exemple, conservez-le en sécurité, car vous en aurez besoin pour le reste des appels d’API.
Obtenir la liste des utilisateurs Link to heading
Obtenir la liste des utilisateurs est à la fois simple et compliqué.
En effet, la liste des utilisateurs contiendra tous les utilisateurs du projet cloud, et pas nécessairement ceux liés au stockage S3.
Ainsi, pour répertorier les utilisateurs, vous utilisez l’appel d’API /cloud/project/{serviceName}/user et dans le champ « serviceName », vous saisissez l’ID de projet que vous avez obtenu dans la section précédente.
Voici un exemple de résultat :
[
-{
id: 522131
username: "user-SDFiushdflUH"
creationDate: "2022-10-07T10:45:40.076781+02:00"
description: "storage admin"
openstackId: "BjfzK1iPyR2y2RbaT55HLSnMZYTxWmOm"
status: "ok"
-roles: [
-{
id: "2543e89a-eb48-4aee-8ec7-z01e33223b16"
name: "objectstore_operator"
description: "ObjectStore operator"
-permissions: [
"objectstore_all"
]
}
]
}
-{
id: 551723
username: "user-1xhkG5VdhWi1"
creationDate: "2022-09-26T17:05:58.281961+02:00"
description: "podcast"
openstackId: "fE27detNiQi8TIo17IxErFnBiALsw62r"
status: "ok"
-roles: [
-{
id: "2563c33a-eb48-4eff-1ec7-z21a00213m96"
name: "objectstore_operator"
description: "ObjectStore operator"
-permissions: [
"objectstore_all"
]
}
]
}
-{
id: 752284
username: "user-hlum5xBgU9FA"
creationDate: "2022-09-26T16:40:33.124552+02:00"
description: "video"
openstackId: "4vehYINQEQCiVlgT34mFaZriZfqZyVHX"
status: "ok"
-roles: [
-{
id: "2943d34c-zb15-4aee-8bh7-c01c81120b51"
name: "objectstore_operator"
description: "ObjectStore operator"
-permissions:[
"objectstore_all"
]
}
]
}
]
Comme vous pouvez le voir ici, nous obtenons trois comptes différents (tels qu’ils apparaissent sur l’interface Web) qui sont :
- user-SDFiushdflUH
- user-1xhkG5VdhWi1
- user-hlum5xBgU9FA
Maintenant que nous avons les trois utilisateurs, nous devons obtenir les droits associés à ces comptes.
Liste des droits d’accès pour chaque utilisateur Link to heading
Comme nous l’avons vu dans une section précédente, les droits d’accès dans les buckets S3 sont appelés politiques (policy). Cela signifie que nous devons utiliser l’API et rechercher un tel appel.
Celui que nous recherchons est « user storage policy » disponible dans « /cloud/project/{serviceName}/user/{userId}/policy ». Il est actuellement en mode bêta, mais il fonctionne très bien.
Comme vous pouvez le voir, l’interface ne demande pas de nom d’utilisateur, mais un « userId ». Si vous regardez attentivement la sortie de l’appel d’API précédent, vous verrez un champ appelé « Id » pour chaque entrée. C’est ce que vous devez saisir dans l’appel d’API.
{
policy: "{
"
{
"Statement":[
{
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket",
"s3:ListMultipartUploadParts",
"s3:ListBucketMultipartUploads",
"s3:AbortMultipartUpload",
"s3:GetBucketLocation"
],
"Effect":"Allow",
"Resource":[
"arn:aws:s3:::video-data",
"arn:aws:s3:::video-data/*"
],
"Sid":"RWContainer"
},
{
"Action":[
"s3:*"
],
"Effect":"Allow",
"Resource":[
"arn:aws:s3:::podcast-data",
"arn:aws:s3:::podcast-data/*"
],
"Sid":"AdminContainer"
}
]
}
"
}"
}
Vous voyez maintenant que vous obtenez la politique pour chaque compte. Plus besoin de télécharger manuellement et de lire les fichiers pour vérifier.
Rassembler les pièces ensemble Link to heading
Maintenant, en rassemblant les pièces du puzzle, j’ai écrit un script qui fait ce qui suit :
- Boucle sur tous les projets cloud
- Appel d’API : /cloud/project
- Entrée : Aucune
- Sortie à conserver: ServiceName
- Pour chaque projet cloud, listez tous les utilisateurs
- Appel d’API : /cloud/project/{serviceName}/user
- Entrée : ServiceName
- Sortie à conserver : id, username, description
- Pour chaque utilisateur, récupérez la politique qui lui est associée
- Appel d’API : /cloud/project/{serviceName}/user/{userId}/policy
- Entrée : ServiceName, id (as userId)
- Sortie à conserver : all
Cela me donne la sortie suivante au format CSV :
project_description;cloud_identifier;username;rights;permission;bucket_path
"Project Alpha";"yntasafv7bji02ks3uw2ot6ntwzf76l6";"user-1xhkG5VdhWi1";"['s3:*']";"Allow";"arn:aws:s3:::podcast-data"
"Project Alpha";"yntasafv7bji02ks3uw2ot6ntwzf76l6";"user-1xhkG5VdhWi1";"['s3:*']";"Allow";"arn:aws:s3::: podcast-data/*"
"Project Alpha";"yntasafv7bji02ks3uw2ot6ntwzf76l6";"user-hlum5xBgU9FA";"['s3:*']";"Allow";"arn:aws:s3:::video-data"
"Project Alpha";"yntasafv7bji02ks3uw2ot6ntwzf76l6";"user-hlum5xBgU9FA";"['s3:*']";"Allow";"arn:aws:s3::: video-data/*"
"Project Alpha";"yntasafv7bji02ks3uw2ot6ntwzf76l6";"user-SDFiushdflUH";"['s3:*']";"Allow";"arn:aws:s3:::*"
"Project Alpha";"yntasafv7bji02ks3uw2ot6ntwzf76l6";"user-SDFiushdflUH";"['s3:*']";"Allow";"arn:aws:s3:::/*"
Vous pouvez ensuite vérifier manuellement et archiver cela, ou vous pouvez importer dans une base de données et avoir un script qui vérifiera périodiquement les changements de droits d’accès, les nouveaux comptes, etc.
C’est à présent à votre tour de mettre cela en place et de choisir comment vous souhaitez encadrer la vérification de ces changements.