major rework

This commit is contained in:
Yann Verry 2022-04-24 16:03:30 +02:00
parent c96aef4500
commit 79b935e5b0
Signed by: yann
GPG key ID: EB9E679A66B8C7A1
48 changed files with 41 additions and 209 deletions

View file

@ -0,0 +1,61 @@
+++
author = "Yann Verry"
categories = ["cloud"]
date = 2018-06-04T06:42:00Z
description = ""
draft = false
image = "__GHOST_URL__/content/images/2018/06/498544386_01f64e68dd_o.jpg"
slug = "s3-origin-de-cloudfront"
tags = ["cloud"]
title = "Les erreurs avec S3 + Cloudfront → Origin Access Identity"
+++
Le couple S3 && cloudfront est le serverless avant l'heure.C'est facile à setup, performant, éfficace.
Par défaut si un fichier n'éxiste pas dans un dossier alors cloudfront renvoie une erreur 403 au lieu d'une 404. C'est bien dommage surtout quand on se sers de cette feature pour faire des règles de réécriture.
## Comment remédier à cela ?
Par défaut lorsqu'on fait la liaison entre S3 et cloudfront il y a création d'une bucket policy du style:
```
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <ID>"
},
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::<bucketName>/*"
]
}]
}
```
Ceci donne l'accès à cloudfront à votre bucket S3. Il y a comme action _s3:GetObject_, il manque donc juste une action pour lister le contenu ? Oui mais non si AWS était intuitif ça se serais. Il faut faire un [OAI](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html).
Récupérer le *S3CanonicalUserId* via
```
aws cloudfront list-cloud-front-origin-access-identities
```
Une fois celui-ci obtenu il faut donc ajouter l'option `--grant-read` avec le S3CanonicalUserId récupéré à l'instant.
```
aws s3api put-bucket-acl --bucket <bucketName> --grant-read id=<S3CanonicalUserId>
```
**--grant-read (string) Allows grantee to list the objects in the bucket.**

View file

@ -0,0 +1,32 @@
+++
author = "Yann Verry"
categories = ["s3", "scaleway", "cloud"]
date = 2018-10-20T20:26:48Z
description = ""
draft = false
image = "__GHOST_URL__/content/images/2018/10/599820538_2871b1a5e9_b.jpg"
slug = "stockage-scaleway-s3"
tags = ["s3", "scaleway", "cloud"]
title = "Stockage Scaleway"
+++
Online.net via sa filiale "cloud" scaleway viens (enfin) de lancer sa beta public pour son [stockage objet](https://www.scaleway.com/object-storage/) compatible S3, le standard de facto (un peu comme le frigo).
Le choix technique est d'être compatible S3 ce qui de facto le rend compatible avec un nombre impressionnant d'outils, le filesystem POSIX est de moins en moins utile.
Côté pricing, il est simple 500Go de stockage avec dedans 500Go de transfert, tout cela pour 5€/mois. Si vous êtes dans le réseau online/scaleway, pas de limitations sur le transfert. Il y a d'autre subtilité mais si vous avez un usage classique ce n'est pas votre [problème](https://www.scaleway.com/faq/object-storage/#-Is-there-a-limitation-in-number-of-HTTP-requests).
Et en exemple d'utilisation, car c'est bien beau mais dans la vrai vie ? Par exemple sur une instance nextcloud avec un stockage S3 externe :
{{< figure src="__GHOST_URL__/content/images/2018/10/sc_s3_nextcloud.jpg" >}}
**Et c'est tout !**
## Un autre exemple ?
J'utilise comme outil de backup restic, il est lui aussi compatible s3-like.Plus simplement chercher un outil S3 compatible mais non AWS. L'exemple que je trouve le plus souvent est "voici comment faire sous minio", suivé le tutorial et ça fonctionnera
Conclusion, c'est une super nouvelle il faut une gestion plus fine des droits sans tomber dans l'enfer des IAM, plus de détail