Configurer les capacités du compte

Utilisez les capacités et les politiques de compatibilité pour adapter les commandes et les requêtes de S3Client aux fonctions acceptées par votre service S3.

Les capacités indiquent les fonctions S3 prises en charge par le service. Les politiques précisent les requêtes et les valeurs acceptées selon le bucket, sa région ou son endpoint. Ces réglages indiquent à S3Client ce qu’il peut proposer ; ils ne donnent aucune permission et n’activent aucune fonctionnalité sur le service.

Le préréglage de fournisseur renseigne les valeurs initiales du compte. Amazon S3 renseigne les fonctions prises en charge par Amazon S3. S3-compatible storage désactive les capacités optionnelles et fournit une configuration de base à compléter selon votre service. Les préréglages personnalisés utilisent les valeurs de leur fichier. Vérifiez ces réglages : S3Client ne détecte pas automatiquement les fonctions disponibles. Vous pouvez aussi appliquer explicitement un préréglage aux comptes existants pour remplacer leurs réglages de service.

Les actions de base communes, comme lire et envoyer un objet, n’ont pas toutes une case de capacité. Désactiver une option peut masquer ou limiter les commandes qui en dépendent, mais ne retire pas les données ni la configuration déjà présentes sur S3.

Ouvrir et enregistrer les réglages#

1. Dans la fenêtre principale, choisissez File > Accounts….
2. Sélectionnez le compte et cliquez sur Edit….
3. Dans Account, ouvrez Capabilities.
4. Sélectionnez la catégorie dans la liste de gauche.
5. Cochez les capacités prises en charge ou modifiez la politique concernée. Une case décochée déclare la fonction indisponible ; survolez ou sélectionnez une ligne pour consulter son explication.
6. Cliquez sur OK dans Account pour enregistrer, ou sur Cancel pour abandonner toutes les modifications.
7. Rouvrez les propriétés ou la commande concernées pour vérifier les options proposées dans le contexte du bucket.

Un réglage incompatible peut être refusé avec des détails. Invalid ACL policy: rend OK et Test connection indisponibles. Un test de connexion ne valide pas toutes les capacités : il ne vérifie qu’une requête de lecture. Voir Ajouter et gérer les comptes.

General#

Transfers#

Un compte existant sans Copy only if the source ETag matches et Copy parts only if the source ETag matches les conserve désactivées, y compris un compte Amazon S3. Installer ou remplacer un préréglage ne modifie pas ce compte ; activez les capacités dans sa configuration si le service les prend en charge, ou appliquez-lui explicitement un préréglage adapté.

Les conditions source sont évaluées d’après le compte destination, même si une copie utilise les identifiants de l’autre compte. Les désactiver conserve les vérifications préalables, mais autorise la copie d’une source modifiée ensuite ; une copie multipart peut mélanger des révisions. Cela concerne les déplacements et réécritures aussi. Les téléchargements et conditions de destination ou de suppression restent indépendants. Voir les conditions des copies S3.

Listing & deletion#

Désactiver Multipart upload, Object listing (ListObjectsV2), Delete multiple objects ou Object versions décoche et désactive automatiquement leurs capacités dépendantes. Les réactiver ne recoche pas automatiquement ces dépendances.

Data protection#

Les trois capacités de versionnement sont indépendantes : Object versions donne accès aux versions, Read bucket versioning permet de lire l’état du bucket et Change bucket versioning permet de le modifier. Activer une capacité ne modifie pas le bucket et ne donne aucune permission distante.

Les capacités Object Lock exigent Object versions. Toutes sauf Create buckets with Object Lock et Read bucket Object Lock exigent aussi Read bucket Object Lock. Change object retention exige Read object retention ; Change object legal hold exige Read object legal hold.

Pour Backblaze B2, activez Object versions et Read bucket versioning, mais laissez Change bucket versioning désactivé.

Existing-bucket activation token (only if required by the service): reste vide par défaut. Renseignez uniquement la valeur demandée par le service pour activer un bucket existant, par exemple 1 pour Backblaze B2. Ce paramètre n’est pas une clé d’accès ; il n’est pas envoyé pendant la création ni lors d’une modification de rétention par défaut.

Object tags#

Configurez séparément Read tags et Tag editing :

• Unavailable : la lecture ou la modification concernée est indisponible.
• Current object only : la fonction vise l’objet courant, sans versionId.
• Current object and specific versions : elle vise aussi une version choisie, avec versionId.

La modification exige la lecture des mêmes cibles. Augmenter Tag editing augmente si nécessaire Read tags ; réduire Read tags réduit si nécessaire Tag editing. Une lecture disponible avec Tag editing > Unavailable permet de consulter les balises sans les modifier.

Remove tags choisit la requête utilisée pour vider les balises : DeleteObjectTagging ou PutObjectTagging with an empty TagSet. Le choix est fixé avant l’opération ; S3Client ne tente pas une autre méthode après un refus.

Current object verification choisit comment vérifier que les balises lues correspondent à l’objet courant :

• Response version header utilise l’identité de version renvoyée avec les balises, sans contrôle HEAD supplémentaire. C’est le réglage Amazon S3.
• Versioned read and HEAD check exige Read tags > Current object and specific versions. Lorsqu’une observation de l’objet courant identifie une version, S3Client lit ses balises avec versionId, puis ajoute un HEAD pour vérifier qu’elle est toujours courante. Cela demande la lecture versionnée des balises et les permissions de HEAD, notamment s3:GetObjectVersionTagging et s3:GetObject sur Amazon S3. Une contradiction ou une disparition bloque l’opération.

Choisir Versioned read and HEAD check règle automatiquement Read tags sur Current object and specific versions. Réduire ensuite cette portée rétablit Response version header. Versioned read and HEAD check conserve la cible logique : une modification de l’objet courant reste sans versionId. Une version exacte immuable n’ajoute pas ce HEAD ; une version null mutable doit aussi conserver la même identité de contenu. Ces contrôles ne rendent pas atomique la lecture suivie d’une écriture.

Send tags with PutObject et Send tags with CreateMultipartUpload déclarent séparément l’envoi de balises avec le contenu, notamment pour les copies relayées et multipart. Ces cases n’activent pas Multipart upload et ne nécessitent pas l’édition des balises existantes.

CopyObject tags propose :

• Unavailable : l’envoi de balises avec CopyObject est indisponible.
• Independent metadata and tagging directives : les directives de métadonnées et de balises peuvent être choisies séparément.
• Tagging directive must match the metadata directive : les directives doivent correspondre. Si les métadonnées sont remplacées, S3Client lit les balises source avant la copie pour les renvoyer et les préserver. Leur lecture et les permissions correspondantes sont nécessaires ; l’édition des balises source ne l’est pas.

Une copie simple conservant à la fois métadonnées et balises côté serveur n’exige pas cette lecture supplémentaire. Consultez les propriétés conservées lors des copies.

Bucket tags#

Tag editing API propose :

• Unavailable : aucune lecture ou modification des balises de buckets.
• S3 bucket tagging API : GetBucketTagging, PutBucketTagging et DeleteBucketTagging, pour les buckets à usage général.
• S3 Control resource tagging : ListTagsForResource, TagResource et UntagResource. Renseignez Account ID et les routes S3 Control dans les connexions du compte. Sans configuration complète, la lecture et la modification des balises restent indisponibles.

Bucket creation#

Object Ownership#

Ces réglages sont distincts de ACL policy. Une politique déclarant les ACL disponibles ne les rend pas modifiables dans un bucket où BucketOwnerEnforced les désactive. Voir ACL et propriété des objets.

Politiques par contexte#

Encryption policies, Storage classes, Lifecycle et Static website hosting permettent plusieurs politiques. Policy sélectionne celle que vous éditez ; Account default policy choisit celle utilisée quand aucune affectation plus précise ne correspond. Changer Policy seul ne change pas la politique par défaut.

Les boutons d’ajout, duplication lorsqu’elle est proposée, et suppression se trouvent à côté de Policy. Les politiques sont limitées à 32 par famille et leurs identifiants doivent être uniques. Conservez au moins une politique. Pour retirer une politique utilisée dans Assignments, supprimez ou modifiez d’abord ses affectations. Dans Storage classes et Encryption policies, choisissez aussi une autre politique par défaut avant de retirer celle-ci ; dans Lifecycle et Static website hosting, la première politique restante devient la politique par défaut si vous retirez l’ancienne.

Pour créer une politique dans Storage classes, cliquez sur le bouton d’ajout à côté de Policy, saisissez Policy identifier dans Add storage class policy, puis cliquez sur OK. La nouvelle politique contient initialement une classe STANDARD. Dans les trois autres catégories, Add génère l’identifiant : configurez Features avant de sélectionner la politique comme défaut ou de l’affecter. Les options y sont initialement décochées, sauf les deux états de règle et les trois états de versionnement sous Lifecycle > Rule constraints ; ajustez-les au service. Duplicate, proposé dans Encryption policies, Lifecycle et Static website hosting, copie les réglages de la politique sélectionnée sous une nouvelle identité.

Pour affecter une politique :

1. Dans la catégorie concernée, ouvrez Assignments.
2. Cliquez sur Add ou Add…, selon la catégorie.
3. Dans Policy assignment, choisissez Applies to et Policy.
4. Renseignez les champs affichés selon le critère ci-dessous.
5. Cliquez sur OK pour ajouter l’affectation, puis sur OK dans Account pour sauvegarder.

S3Client applique uniquement la politique de l’affectation qui correspond au bucket avec la priorité la plus élevée dans ce tableau. Sans correspondance, la politique par défaut s’applique. Utilisez le code de région, pas son nom local ; l’endpoint est un hôte sans protocole ni chemin. Bucket kind propose General purpose, Directory et Outposts. Choisir un type de bucket indique où appliquer la politique ; cela ne suffit pas pour que S3Client puisse parcourir ce type de bucket.

Deux affectations ne peuvent pas reprendre exactement les mêmes critères. Chaque famille accepte au plus 1 000 affectations. Sélectionnez une ligne et utilisez Edit ou Edit…, selon la catégorie, pour la modifier, Remove pour la retirer.

Encryption#

Dans la liste Object encryption modes, les cases SSE-S3, SSE-KMS, DSSE-KMS et SSE-C déclarent les modes de chiffrement d’objets disponibles. Dans la liste Encryption API operations, Read bucket encryption, Set bucket encryption et Remove bucket encryption configuration déclarent séparément les API de configuration du chiffrement par défaut du bucket. Update object encryption without copying déclare UpdateObjectEncryption, qui modifie le chiffrement sans recopier les données.

Encryption policies#

Dans cette rubrique, ouvrez Features et choisissez la politique à modifier dans Policy. Les options précisent les requêtes et paramètres admis pour cette politique. Ces cases ne remplacent pas les capacités générales ni les permissions KMS nécessaires :

SSE-C exige de fournir la clé lors des opérations concernées ; ce réglage ne stocke pas cette clé. Choisissez la politique par défaut ou les affectations adaptées au bucket avant d’enregistrer.

Storage classes#

Une politique décrit les noms de classes réellement acceptés par le service, les opérations qui les proposent, l’accès aux objets archivés et les transitions de cycle de vie autorisées. Ajouter une classe dans S3Client ne crée pas de classe sur le service.

Dans Classes, choisissez Default class, puis utilisez Add…, Edit… ou Remove sur la liste. Pour ajouter ou modifier une classe, renseignez Storage class name dans Storage class, configurez les champs suivants et cliquez sur OK :

Les noms de classe sont uniques dans la politique. La classe par défaut ne peut être retirée avant d’en choisir une autre ; une classe référencée par une transition doit d’abord être retirée de cette transition. Chaque politique est limitée à 100 classes et à 1 000 transitions.

Saisissez le nom exact accepté par le service, en ASCII et sans espace, avec au plus 256 caractères. Une nouvelle classe commence avec le nom provisoire NEW_CLASS, un accès Always direct, aucune opération de sélection cochée, Change storage class on the same object décoché et une restauration Unsupported. Remplacez ce nom et configurez les opérations avant d’enregistrer. Renommer une classe met à jour ses références dans la classe par défaut et les transitions de cette politique ; cela ne change pas les objets distants.

Choisir Unsupported efface les réglages de durée, de niveau de récupération et de version. Choisir Forbidden pour un paramètre efface ses valeurs dépendantes. Si vous réactivez ensuite ces options, configurez-les à nouveau.

Change storage class on the same object est évalué pour chaque classe de destination. Le chemin d’écriture réellement utilisé doit être disponible et autorisé pour cette classe : Copy object pour une copie simple côté serveur, Single-request upload pour un relais simple par S3Client, ou Start multipart upload pour un transfert multipart. Ce dernier exige Multipart upload dans Transfers ; Multipart server-side copy est nécessaire uniquement pour une copie multipart côté serveur. Les propriétés et les modifications récursives proposent uniquement les destinations autorisées. Décocher cette option ne bloque pas une réécriture qui conserve la classe existante.

Default class décrit la classe utilisée lorsque S3Client laisse le service choisir la classe de destination, sans en-tête x-amz-storage-class. Il sert aussi à interpréter un HeadObject réussi qui ne fournit aucun en-tête de classe. Une classe absente d’un listing reste inconnue : S3Client lit les métadonnées avec HeadObject avant une lecture ou une réécriture qui dépend de cette information. L’absence dans le listing ne signifie donc pas STANDARD. Une valeur par défaut incorrecte peut fausser le placement attendu ou l’interprétation après HEAD ; adaptez la politique et ses affectations au bucket.

Dans Transitions, cliquez sur Add… ou Edit…. Le dialogue Storage class transition demande deux classes distinctes sous Source class et Target class, au moins une portée (Current versions, Noncurrent versions) et au moins un état de versionnement compatible (Never enabled, Suspended, Enabled).

Vous pouvez cocher Minimum days since object creation, Minimum days since version became noncurrent et Minimum time in source class pour déclarer les délais minimaux, en jours à partir de 0. Les deux premiers dépendent de la portée sélectionnée ; la décocher efface le délai correspondant. Default minimum object size indique une taille minimale en octets, à partir de 0 ; An S3 size filter may override the default déclare qu’un filtre de taille explicite peut la remplacer et n’est disponible que si cette taille minimale est cochée. Ces champs déclarent les contraintes acceptées ; ils ne créent pas de règle de transition dans un bucket.

Dans Supported operations, déclarez séparément :

• Restore status in ListObjects, Restore status in ListObjectsV2 et Restore status in ListObjectVersions, pour demander l’attribut optionnel RestoreStatus dans ces listes.
• Read Intelligent-Tiering configuration, Create or update Intelligent-Tiering configuration, List Intelligent-Tiering configurations et Delete Intelligent-Tiering configuration, pour les API correspondantes.

Lifecycle#

Les cases Read bucket lifecycle rules, Create or replace bucket lifecycle rules et Remove all bucket lifecycle rules déclarent les API de lecture, remplacement de toutes les règles et suppression de la configuration. Retirer la configuration arrête les futures actions ; cette requête ne supprime pas elle-même les objets.

La politique choisie précise dans Features les éléments de règle admis :

Dans Features > Rule constraints, choisissez les états de règle autorisés (Enabled rules, Disabled rules) et les états de bucket compatibles (Buckets never versioned, Buckets with suspended versioning, Buckets with enabled versioning). Require paired expiration rules exige After a number of days et Remove delete markers with no remaining versions : cochez d’abord ces deux options. Elle impose deux règles au même filtre et au même état : expiration après un nombre de jours et nettoyage des marqueurs de suppression expirés. Les identifiants des règles ne déterminent pas leur association.

Pour Backblaze B2, la politique de cycle de vie autorise seulement les règles actives sur un bucket au versionnement actif et exige Require paired expiration rules.

Dans Limits, cochez Maximum tag conditions per rule pour fixer une limite de 1 à 10 et Maximum actions per rule pour fixer une limite positive. Une limite décochée n’impose pas de borne supplémentaire dans cette politique ; les limites du service et du format S3 restent applicables.

Les dépendances sont ajustées automatiquement. Maximum tag conditions per rule exige Tags ; Retain newer noncurrent versions from deletion exige Expiration ; Keep newer noncurrent versions in their storage class et Multiple noncurrent transitions exigent Noncurrent version after days ; Multiple current transitions exige Current version after days ou Current version at a date. Décocher le prérequis efface les réglages dépendants, qu’il faudra rétablir si vous le réactivez.

Ces déclarations ne programment aucune expiration. La création de règles distantes se fait dans les propriétés du bucket et peut supprimer définitivement des données ; consultez les règles de cycle de vie avant de les appliquer.

Static website hosting#

Dans Features de la politique, déclarez GetBucketWebsite pour lire, PutBucketWebsite pour créer ou remplacer et DeleteBucketWebsite pour retirer la configuration. RedirectAllRequestsTo permet la redirection globale vers un autre hôte ; RoutingRules permet des redirections conditionnelles.

L’éditeur de propriétés exige une lecture réussie avant toute écriture ou suppression. Cocher seulement PutBucketWebsite ne suffit donc pas pour modifier le site dans l’interface. Ces options ne publient pas de site et ne rendent pas les objets publics. Utilisez les propriétés du bucket pour la configuration distante.

Bucket access logging#

Les deux dernières options complètent la configuration d’écriture, sans activer seules la journalisation. Les permissions sur le bucket destination et son état d’ACL restent nécessaires. Voir Journaliser les accès.

La liste de compatibilité propose Strict S3 XML ou Preserve known logging additions. Le second choix permet de conserver les champs connus d’une configuration de journalisation standard, comme ObjectRollTime et RecordsBatchSize, lors d’une modification. La désactivation de la journalisation les supprime. Il ne propose pas de nouveaux réglages pour ces champs. Une extension inconnue reste non éditable. Voir la journalisation des accès.

ACL policy#

Enable ACL operations for this account active l’utilisation locale des ACL. Décocher cette option rend les onglets de politique indisponibles sans révoquer les autorisations distantes ; leurs valeurs sont conservées. Les réglages ci-dessous décrivent la compatibilité du service ; ils ne remplacent pas l’éditeur des ACL des ressources.

Lorsque cette option est décochée, les propriétés ne proposent plus d’onglet ACL. Les transferts ordinaires et les réécritures de propriétés utilisent le défaut de destination, sans requête ni en-tête ACL. Cela ne garantit pas la conservation des ACL existantes si le service les utilise encore. Une demande explicite d’ACL ou une exigence de conservation incompatible reste refusée. Voir les effets de la désactivation locale.

Set access log target grants reste indépendant de cette option : les TargetGrants appartiennent à la configuration de journalisation, pas aux opérations ACL sur les ressources. Le mode Bucket owner enforced de la destination conserve ses restrictions.

Les listes Operation de Request forms, Canned ACLs et Explicit grants proposent Replace bucket ACL, Single-request upload, Copy object, Start multipart upload et Replace object ACL. Pour le bucket, seules private, public-read, public-read-write et authenticated-read sont admises ; les trois autres ACL prédéfinies concernent les objets. La permission WRITE et le groupe http://acs.amazonaws.com/groups/s3/LogDelivery sont réservés aux opérations sur les buckets. Un choix incompatible bloque la validation au lieu d’être corrigé automatiquement.

Pour enregistrer une règle dans Error rules, respectez les conditions de son Action :

• Require Object Ownership check exige une opération d’écriture et Any write form / none.
• Mark operation as unsupported exige Any write form / none et refuse le code AccessDenied.
• Mark request form as unsupported exige une forme d’écriture précise compatible avec l’opération et refuse le code AccessDenied.

Deux règles pour la même opération et le même code d’erreur ne peuvent pas couvrir à la fois les mêmes statuts HTTP et les mêmes formes d’écriture. Any write form / none couvre toutes les formes. Un chevauchement bloque la validation.

Les limites ACL permettent au plus 1 000 valeurs par collection et 7 000 règles d’erreur. Configurez les codes exacts du service ; ne transformez pas une erreur d’accès en déclaration d’API indisponible. Les opérations d’envoi ou copie ont leurs propres réglages ACL, distincts du remplacement ultérieur d’une ACL. Pour modifier les autorisations des ressources, utilisez ACL et propriété des objets.

Une politique ACL activée exige au moins une API prise en charge. Les API d’objets exigent une portée de lecture ou d’écriture correspondante ; la portée est indépendante de Object ACL response, et une projection peut couvrir l’objet courant seul ou ses versions explicites. Les formes d’écriture doivent être cohérentes avec les ACL prédéfinies, permissions et Preferred encoding choisis. Try grant headers, then XML if unsupported exige à la fois Grant headers et AccessControlPolicy XML body. Une incohérence produit Invalid ACL policy: et bloque l’enregistrement tant qu’elle n’est pas corrigée.

La portée et la nature de la réponse ACL se règlent séparément. Pour consulter les permissions projetées du bucket sur les versions d’un objet, choisissez Current object and specific versions dans Object ACL read scope, et Object ACL derived from the bucket ACL dans Object ACL response, si le service le permet. Cette lecture reste sans édition ni garantie de préservation exacte d’une ACL propre à l’objet.

Limites générales des requêtes#

Depuis File > Accounts…, ouvrez le compte avec Edit…. Dans l’onglet Account, le groupe Connection contient Maximum PUT header bytes et Maximum POST header bytes. Ces valeurs limitent les en-têtes complets des requêtes correspondantes, même lorsque les ACL sont désactivées. 0, affiché No configured limit, ne fixe aucune limite. Une requête trop volumineuse est refusée avant l’envoi ; la limite intervient également dans le choix de l’encodage des ACL. Cliquez sur OK pour enregistrer.

À la création depuis Amazon S3, la limite PUT est de 8 192 octets et POST n’a pas de limite configurée. S3-compatible storage ne configure aucune de ces deux limites. Un préréglage personnalisé fournit ses propres valeurs ; appliquer un préréglage à un compte existant remplace aussi ces limites.