Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Container-based exigences relatives aux produits pour AWS Marketplace
AWS Marketplace applique les exigences suivantes pour tous les produits et offres à base de contenants sur. AWS Marketplace Ces exigences contribuent à promouvoir un catalogue sûr, sécurisé et fiable pour nos clients. Nous encourageons également les vendeurs à revoir la mise en œuvre de contrôles et de protocoles supplémentaires, le cas échéant, pour répondre aux besoins de leurs produits spécifiques.
Tous les produits et leurs métadonnées associées sont révisés lorsqu'ils sont soumis pour s'assurer qu'ils respectent ou dépassent AWS Marketplace les politiques en vigueur. Ces politiques sont régulièrement mises à jour pour s'aligner sur l'évolution des directives de sécurité. AWS Marketplace analyse en permanence les produits pour vérifier que les offres existantes continuent de répondre à toute modification de ces exigences. Si un produit n'est pas conforme, nous AWS Marketplace contacterons le vendeur pour le mettre à jour afin qu'il réponde aux nouvelles normes. Dans certains cas, les produits peuvent être temporairement indisponibles pour les nouveaux abonnés jusqu'à ce que les problèmes soient résolus. Ce processus permet de maintenir la sécurité et la fiabilité de la AWS Marketplace plateforme pour tous les utilisateurs.
**Topics**
+ [Politiques relatives aux vendeurs de produits contenant](#container-product-seller-policies)
+ [Stratégies de sécurité](#container-security-requirements)
+ [Exigences en matière d'information du client](#container-customer-info-requirements)
+ [Exigences relatives à l'utilisation du produit](#container-usage-requirements)
+ [Exigences relatives à l'architecture](#container-architecture-requirements)
+ [Exigences relatives à la structure de l'organigramme](#helm-chart-structure-requirements)
+ [Instructions d'utilisation du produit en contenant](#container-product-usage-instructions)
+ [Exigences relatives aux produits complémentaires Amazon EKS](#publishing-eks-add-on)
## Politiques relatives aux vendeurs de produits contenant
En tant que vendeur de produits en conteneur, vous devez respecter les politiques suivantes :
+ Par défaut, vous êtes limité à un maximum de 20 listes de produits dans des conteneurs publics. Si vous dépassez cette limite, les performances de votre compte sont soumises à des évaluations périodiques et il se peut que vous deviez restreindre les annonces peu performantes. Nous accordons ou annulons les augmentations de cette limite à notre seule discrétion.
## Stratégies de sécurité
Tous les produits à base de contenants doivent respecter les exigences de sécurité suivantes :
+ Les images de conteneurs ne doivent pas contenir de vulnérabilités connues, de programmes malveillants ou de progiciels End-of-Life (EoL) et de systèmes d'exploitation.
+ Les conteneurs ne doivent pas demander AWS d'informations d'identification pour accéder aux AWS services. Lorsque votre produit doit accéder à AWS des services, vous devez utiliser l'une des options suivantes :
+ Rôles IAM pour les comptes de service, pour les charges de travail Amazon Elastic Kubernetes Service (Amazon EKS).
+ Rôles IAM pour les tâches, pour les charges de travail Amazon Elastic Container Service (Amazon ECS).
+ Container-based les produits ne doivent nécessiter que les privilèges minimaux pour fonctionner. Pour plus d'informations, consultez les [ rubriques Sécurité dans Amazon Elastic Container Service ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security.html) et [ Sécurité dans Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/security.html).
+ Les images de conteneur doivent être configurées pour s'exécuter avec des privilèges autres que root par défaut.
+ Les conteneurs ne doivent contenir aucun secret codé en dur, tel que des mots de passe (même hachés) pour les utilisateurs et les services du système, des clés privées, des informations d'identification, etc.
+ L'authentification dans tous les services exécutés à l'intérieur du conteneur ne doit pas utiliser l'authentification par mot de passe, même si le mot de passe est généré, réinitialisé ou défini par l'utilisateur au lancement. Les mots de passe nuls et vides ne sont pas non plus autorisés.
+ Les images de conteneur ne doivent pas inclure de couches dont les architectures ne sont pas prises en charge (par exemple, des métadonnées in-toto Attestation Framework).
## Exigences en matière d'information du client
Tous les produits à base de contenants doivent respecter les exigences suivantes en matière d'information des clients :
+ Le logiciel ne doit pas collecter ou exporter les données des clients à l'insu du client et sans son consentement exprès, sauf si la BYOL (Bring Your Own License) l'exige. Les applications qui collectent ou exportent des données clients doivent suivre les directives suivantes :
+ La collecte des données clients doit être en libre-service, automatisée et sécurisée. Les acheteurs ne doivent pas avoir à attendre l'approbation des vendeurs pour déployer le logiciel.
+ La collecte des données clients doit être conforme à vos contrats avec AWS, mais sans s'y limiter, les conditions générales de la [AWS place de marché](https://aws.amazon.com/legal/seller-terms/), les conditions de [AWS service](https://aws.amazon.com/service-terms/), la déclaration de [AWS confidentialité ](https://aws.amazon.com/privacy/) et [AWS le contrat client](https://aws.amazon.com/agreement/).
+ Les informations de paiement ne doivent pas être collectées.
## Exigences relatives à l'utilisation du produit
Tous les produits à base de contenants doivent respecter les exigences d'utilisation suivantes :
+ Les vendeurs peuvent uniquement mettre en vente des produits entièrement fonctionnels. Les produits en version bêta ou en version préliminaire à des fins d'essai ou d'évaluation ne sont pas autorisés. Les éditions pour développeurs, communautaires et BYOL de logiciels commerciaux sont prises en charge si le vendeur fournit une version payante équivalente AWS Marketplace dans les 90 jours suivant la fourniture de l'édition gratuite.
+ Toutes les instructions d'utilisation d'un produit à base de conteneurs doivent inclure toutes les étapes de déploiement de produits à base de conteneurs. Les instructions d'utilisation doivent fournir des commandes et des ressources de déploiement pointant vers les images de conteneur correspondantes sur AWS Marketplace.
+ Container-based les produits doivent inclure toutes les images de conteneurs dont un abonné a besoin pour utiliser le logiciel. En outre, les produits à base de conteneurs ne doivent pas obliger l'utilisateur à lancer le produit en utilisant des images provenant de l'extérieur AWS Marketplace (par exemple, des images de conteneurs provenant de référentiels tiers).
+ Les conteneurs et leurs logiciels doivent être déployables en libre-service et ne doivent pas nécessiter de méthodes de paiement ni de coûts supplémentaires. Les applications qui nécessitent des dépendances externes lors du déploiement doivent suivre les directives suivantes :
+ L'exigence doit être indiquée dans la description ou les instructions d'utilisation de la liste. Par exemple, * ce produit nécessite une connexion Internet pour se déployer correctement. Les packages suivants sont téléchargés lors du déploiement :. *
+ Les vendeurs sont responsables de l'utilisation et de la garantie de la disponibilité et de la sécurité de toutes les dépendances externes.
+ Si les dépendances externes ne sont plus disponibles, le produit doit AWS Marketplace également être supprimé.
+ Les dépendances externes ne doivent pas nécessiter de méthodes de paiement ou de frais supplémentaires.
+ Les conteneurs qui nécessitent une connexion continue à des ressources externes ne relevant pas du contrôle direct de l'acheteur, par exemple des API externes ou Services AWS gérées par le vendeur ou un tiers, doivent suivre les directives suivantes :
+ L'exigence doit être indiquée dans la description ou les instructions d'utilisation de la liste. Par exemple, * ce produit nécessite une connexion Internet permanente. Les services externes continus suivants sont nécessaires pour fonctionner correctement :. *
+ Les vendeurs sont responsables de l'utilisation et de la garantie de la disponibilité et de la sécurité de toutes les ressources externes.
+ Si les ressources externes ne sont plus disponibles, le produit doit AWS Marketplace également être supprimé.
+ Les ressources externes ne doivent pas nécessiter de méthodes de paiement ou de coûts supplémentaires et la configuration de la connexion doit être automatisée.
+ Le logiciel et les métadonnées du produit ne doivent pas contenir de langage redirigeant les utilisateurs vers d'autres plateformes cloud, des produits supplémentaires ou des services de vente incitative qui ne sont pas disponibles sur. AWS Marketplace
+ Si votre produit est un ajout à un autre produit ou à un produit d'un autre ISV, la description de votre produit doit indiquer qu'il étend les fonctionnalités de l'autre produit et que, sans lui, votre produit n'a qu'une utilité très limitée. Par exemple, * ce produit étend les fonctionnalités de et sans lui, ce produit a une utilité très limitée. Veuillez noter que cette liste peut nécessiter sa propre licence pour bénéficier de toutes les fonctionnalités. *
## Exigences relatives à l'architecture
Tous les produits à base de conteneurs doivent respecter les exigences d'architecture suivantes :
+ Les images de conteneur source pour AWS Marketplace doivent être transférées vers le référentiel Amazon Elastic Container Registry (Amazon ECR) appartenant AWS Marketplaceà. Vous pouvez créer ces référentiels dans les produits du Portail de gestion AWS Marketplace sous-serveur pour chacune de vos listes de produits en conteneur.
+ Les images de conteneurs doivent être basées sur Linux.
+ Les produits payants basés sur des conteneurs doivent pouvoir être déployés sur [ Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html), [ Amazon EKS ou](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html). [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html)
+ Les produits payants basés sur des conteneurs assortis d'une tarification contractuelle et d'une intégration avec AWS License Manager devraient être déployés sur Amazon EKS, Amazon ECS AWS Fargate, Amazon EKS Anywhere, Amazon ECS Anywhere, Red Hat OpenShift Service on AWS (ROSA), des clusters Kubernetes autogérés sur site ou sur Amazon Elastic Compute Cloud.
+ Pour les produits Helm Chart, les références d'images de conteneurs doivent être structurées en fonction de la prise [Exigences relatives à la structure de l'organigramme](#helm-chart-structure-requirements) en charge du déploiement interrégional.
+ Si votre produit basé sur un conteneur nécessite que l'acheteur déploie une Amazon Machine Image (AMI), il doit s'agir d'une AMI AWS gérée ou d'une AMI distincte publiée dans. AWS Marketplace Si vous publiez votre propre AMI dans AWS Marketplace, elle doit être conforme au [AMI-based exigences relatives aux produits pour AWS Marketplace](product-and-ami-policies.md) et vous devez indiquer qu'il s'agit d'un produit complémentaire, comme l'exige le[Politiques d'utilisation des produits](product-and-ami-policies.md#product-usage). Vous pouvez fixer le prix de votre AMI-based produit au BYOL, car il s'agit d'une extension de votre offre basée sur des conteneurs. AWS Marketplace analyse les AMI-based produits pour détecter les vulnérabilités et expositions courantes (CVE) non corrigées et les exigences de sécurité. Vos acheteurs doivent également souscrire à votre AMI-based produit avant de le déployer.
## Exigences relatives à la structure de l'organigramme
Tous les produits Helm Chart soumis AWS Marketplace doivent respecter les exigences de structure suivantes afin de garantir une régionalisation et un déploiement appropriés dans toutes AWS les régions :
+ Les références aux images de conteneurs doivent être définies exclusivement dans le `values.yaml` fichier et ne doivent pas être codées en dur dans aucun autre fichier du graphique Helm. Cela permet AWS Marketplace de remplacer automatiquement ces références lors de la réplication de votre produit dans différentes régions.
+ Le `values.yaml` fichier doit utiliser des variables pour toutes les références d'images de conteneur.
+ Si vous le souhaitez, vous pouvez diviser les champs en champs distincts au même niveau que le référentiel pour créer votre référence d'image. `registry` `tag`
+ Les modèles Helm doivent référencer ces variables à l'aide de la syntaxe de modélisation Helm standard (par exemple,`{{ .Values.image.repository }}:{{ .Values.image.tag }}`).
+ Évitez d'utiliser une logique conditionnelle dans les modèles qui contournerait les références d'image définies dans`values.yaml`.
+ Lorsque vous testez votre carte Helm avec différentes AWS régions, assurez-vous que la modification `values.yaml` correcte de la région met à jour toutes les références d'image dans les ressources déployées.
AWS Marketplace valide que toutes les références d'images du conteneur sont correctement définies dans le `values.yaml` fichier lors du processus de soumission du produit. Les produits ne répondant pas à ces exigences seront rejetés.
### Exigences relatives aux références d'images de conteneurs dans les cartes Helm
Vous trouverez ci-dessous des approches permettant de structurer les références d'images de conteneurs dans les diagrammes Helm :
**`values.yaml`(format recommandé) : **
```
image:
registry: "709825985650.dkr.ecr.us-east-1.amazonaws.com"
repository: "accuknox/kubearmor"
tag: "v1.1.1"
```
**Note**
Nous recommandons l'approche ci-dessus pour la structure de votre structure`values.yaml`, mais les méthodes alternatives ci-dessous sont également valables.
**`values.yaml`(format alternatif) : **
```
image:
repository: "709825985650.dkr.ecr.us-east-1.amazonaws.com/guance/datakit"
tag: "1.0"
```
**`values.yaml`(format alternatif) : **
```
image:
repository: "709825985650.dkr.ecr.us-east-1.amazonaws.com/guance/datakit:1.0"
```
**Note**
Pour le modèle de déploiement, le format ci-dessous est le seul format valide disponible.
**Modèle de déploiement : **
```
containers:
- name: kubearmor
image: "{{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}"
```
**Approche incorrecte (ne pas utiliser) : **
```
containers:
- name: kubearmor
image: "709825985650.dkr.ecr.us-east-1.amazonaws.com/accuknox/kubearmor:v1.1.1"
```
### Erreurs possibles de validation du diagramme Helm
Au cours du processus de soumission des produits, AWS Marketplace effectue des contrôles de validation sur les produits Helm Chart afin de garantir la conformité aux exigences de référence des images des conteneurs. Si votre carte Helm ne répond pas à ces exigences, vous pouvez rencontrer les erreurs de validation suivantes :
| Erreur | Explication |
| --- | --- |
| INCOMPATIBLE\_HELM\_OBJECTS | Les objets Helm spécifiés ne sont pas pris en charge pour les modules complémentaires EKS. Consultez [Exigences relatives aux produits complémentaires Amazon EKS](#publishing-eks-add-on). |
| INVALID\_DEPENDENT\_HELM\_CHARTS | Les graphiques Helm dépendants doivent être contenus dans le répertoire des graphiques parent et ne pas provenir de sources externes. |
| INVALID\_HELM\_SENSITIVE\_CONFIG | Le schéma de configuration ne peut pas contenir de champs qui collectent des informations sensibles. Les schémas de configuration ne doivent pas accepter de mots de passe, de clés d'API, de certificats ou de secrets. Fournissez plutôt des champs pour les noms secrets Kubernetes que les clients créeront séparément. |
| INVALID\_HELM\_CHART\_IMAGES | Toutes les images, y compris les dépendances open source, doivent être transférées vers les référentiels AWS Marketplace Amazon ECR créés via la demande [ Ajouter un référentiel. ](container-add-version.md#add-repositories) |
| INVALID\_HELM\_UNDECLARED\_IMAGES | Toutes les références aux images de conteneurs doivent être explicitement répertoriées dans la [** demande d'**](container-add-version.md#add-new-version)ajout de version. |
| INVALID\_HELM\_LINT | La helm lint validation de la carte Helm a échoué. Exécutez helm lint localement pour identifier et résoudre les problèmes structurels ou syntaxiques. Utilisez la version Helm 3.19.0 ou une version ultérieure. |
| INVALID\_HELM\_TEMPLATE | La helm template validation de la carte Helm a échoué. Le graphique ne peut pas être rendu dans des manifestes Kubernetes valides. Testez localement helm template pour identifier les erreurs de syntaxe ou de logique du modèle. Utilisez la version Helm 3.19.0 ou une version ultérieure. |
| MISSING\_HELM\_DEPLOYMENT\_CONFIG | Le Helm chart d'un module complémentaire Amazon EKS doit contenir un déploiement ou une DaemonSet ressource. Amazon EKS nécessite au moins l'un de ces types de charge de travail pour la gestion du cycle de vie des modules complémentaires. Consultez [Exigences relatives aux produits complémentaires Amazon EKS](#publishing-eks-add-on). |
| INCOMPATIBLE\_CONFIGURATION\_SCHEMA\_VERSION | La version du schéma JSON dans n'aws\_mp\_configuration\_schema.jsonest pas prise en charge. Consultez [Exigences relatives au schéma](#schema-requirements) les versions de schéma prises en charge. |
| INVALID\_IMAGE\_REFERENCE | Toutes les images doivent être définies en tant que variables values.yaml et référencées à l'aide de la syntaxe du modèle Helm, comme décrit dans[Exigences relatives à la structure de l'organigramme](#helm-chart-structure-requirements). |
| MISSING\_VALUES\_IMAGE\_REFERENCE | Chaque référence d'image de conteneur doit avoir une entrée correspondante dansvalues.yaml. |
| MISSING\_IMAGE\_TAG | Les références aux images de conteneurs values.yaml doivent inclure des valeurs de balise explicites ou utiliser par défaut la version du graphique d'origineChart.yaml. |
## Instructions d'utilisation du produit en contenant
Lorsque vous créez des instructions d'utilisation pour votre produit en contenant, suivez les étapes et les conseils figurant dans[Création d'instructions d'utilisation de l'AMI et du produit conteneur pour AWS Marketplace](ami-container-product-usage-instructions.md).
### Instructions d'utilisation du Helm Chart
Lorsque vous créez des instructions d'utilisation pour les produits Helm Chart :
+ Documentez clairement tous les paramètres configurables de votre `values.yaml` fichier, y compris le référentiel d'images, les balises et les paramètres de registre.
+ Fournissez des exemples montrant comment modifier ces paramètres lors de l'installation de la carte Helm.
+ Ne demandez pas aux utilisateurs de modifier des fichiers autres que `values.yaml` ou d'utiliser des `--set` paramètres lors de l'installation du graphique.
+ Incluez des informations sur la manière dont votre produit gère la régionalisation des images de conteneurs.
## Exigences relatives aux produits complémentaires Amazon EKS
Un module complémentaire Amazon EKS est un logiciel qui fournit des fonctionnalités opérationnelles aux Kubernetes applications mais qui n'est pas spécifique à celles-ci. Par exemple, un module complémentaire Amazon EKS inclut des agents ou des Kubernetes pilotes d'observabilité qui permettent au cluster d'interagir avec les AWS ressources sous-jacentes pour la mise en réseau, le calcul et le stockage.
En tant que vendeur de produits en conteneurs, vous pouvez choisir parmi plusieurs options de déploiement, notamment Amazon EKS. Vous pouvez publier une version de votre produit en tant que AWS Marketplace module complémentaire dans le catalogue de modules complémentaires Amazon EKS. Votre module complémentaire apparaît dans la console Amazon EKS à côté des modules complémentaires gérés par AWS et par d'autres fournisseurs. Vos acheteurs peuvent déployer votre logiciel en tant que module complémentaire tout aussi facilement que les autres modules complémentaires.
Pour plus d'informations, veuillez consulter [Modules complémentaires Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html) dans le *Guide de l'utilisateur Amazon EKS*.
### Préparation de votre produit en conteneur en tant que AWS Marketplace module complémentaire
Pour publier votre produit en conteneur en tant que AWS Marketplace module complémentaire, il doit répondre aux exigences suivantes :
+ Votre produit en conteneur doit être publié dans AWS Marketplace.
+ Votre produit conteneur doit être conçu pour être compatible avec les architectures AMD64 et ARM64.
+ Votre produit en conteneur ne doit pas utiliser le modèle [ de ](https://docs.aws.amazon.com/marketplace/latest/userguide/pricing-container-products.html) tarification BYOL (Bring Your Own License).
**Note**
Le BYOL n'est pas pris en charge pour la livraison du module complémentaire Amazon EKS.
+ Vous devez respecter toutes les exigences relatives aux produits liés aux [ conteneurs, ](https://docs.aws.amazon.com/marketplace/latest/userguide/container-product-policies.html) y compris le transfert de toutes les images et de tous les Helm graphiques des conteneurs vers des référentiels Amazon ECR AWS Marketplace gérés. Cette exigence inclut les images open source, `nginx` par exemple. Les images et les graphiques ne peuvent pas être hébergés dans d'autres référentiels externes, y compris, mais sans s'y limiter, [ Amazon ECR Public Gallery ](https://docs.aws.amazon.com/AmazonECR/latest/public/public-repositories.html)Docker Hub, et. Quay
+ **Helmgraphiques ** : préparez et empaquetez votre logiciel sous forme de Helm graphique. Le framework complémentaire Amazon EKS convertit un Helm graphique en manifeste Kubernetes. Certaines Helm fonctionnalités ne sont pas prises en charge dans les systèmes Amazon EKS. La liste suivante décrit les exigences qui doivent être remplies avant d'intégrer votre logiciel en tant que module complémentaire Amazon EKS. Dans cette liste, toutes les Helm commandes utilisent Helm la version 3.19.0 :
+ Tous les `Capabilities` objets sont pris en charge, à l'exception de`.APIVersions`. `.APIVersions`n'est pas pris en charge pour les Kubernetes API personnalisées non intégrées.
+ Seuls les `Release.Namespace` objets `` `Release.Name` et sont pris en charge.
+ Helmles crochets et la `lookup` fonction ne sont pas pris en charge.
+ Tous les graphiques dépendants doivent être situés dans le Helm graphique principal (spécifié avec le chemin du référentiel file ://...).
+ Le Helm graphique doit passer avec succès Helm Lint et Helm Template sans erreur. Les commandes sont les suivantes :
+ HelmPeluche — `helm lint {{helm-chart}}`
Parmi les problèmes courants, citons les graphiques non déclarés dans les métadonnées du graphique parent. Par exemple, `chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed`
+ HelmModèle — `helm template {{chart-name}} {{chart-location}} --set k8version={{Kubernetes-version}} --kube-version {{Kubernetes-version}} --namespace {{addon-namespace}} --include-crds --no-hooks -f {{any-overriden-values}}`
Passez toutes les configurations annulées à l'aide du `-f` drapeau.
+ Stockez tous les fichiers binaires des conteneurs dans les AWS Marketplace dépôts Amazon ECR. Pour créer un manifeste, utilisez la commande Helm modèle présentée précédemment. Recherchez dans le manifeste toutes les références d'images externes, telles que `busybox` des `gcr` images. Téléchargez toutes les images de conteneurs ainsi que leurs dépendances dans les dépôts AWS Marketplace Amazon ECR créés à l'aide de l'**option ** Ajouter un référentiel dans la liste déroulante des demandes.
+ **Configuration personnalisée ** : vous pouvez ajouter des variables personnalisées pendant le déploiement. Pour plus d'informations sur la manière d'identifier l'expérience de l'utilisateur final, de nommer le logiciel `aws_mp_configuration_schema.json` et de le regrouper dans un wrapper avec le Helm graphique, consultez la section Modules complémentaires [ Amazon EKS : Configuration ](https://aws.amazon.com/blogs/containers/amazon-eks-add-ons-advanced-configuration/) avancée.
Selon [ le mot clé « $schema »](https://json-schema.org/draft/2020-12/json-schema-core#name-the-schema-keyword), `$schema` il doit s'agir d'un URI qui pointe vers une `application/schema+json` ressource valide.
Ce fichier ne doit accepter aucune information sensible telle que les mots de passe, les clés de licence et les certificats.
Pour gérer les installations secrètes et les certificats, vous pouvez fournir aux utilisateurs finaux des étapes de Add-on post-installation ou de pré-installation. Le produit ne doit pas reposer sur des licences externes. Le produit doit fonctionner en fonction des AWS Marketplace droits.
Pour plus d'informations sur les limites de`aws_mp_configuration_schema.json`, consultez[Add-on exigences de configuration et meilleures pratiques pour les fournisseurs de modules complémentaires](#eks-addon-configuration).
+ **Identifiez et créez l'espace de noms dans lequel le logiciel sera déployé ** — Dans la première version de votre produit, vous devez identifier l'espace de noms dans lequel le logiciel sera déployé en ajoutant un espace de noms modélisé.
+ **Définitions de ressources personnalisées (CRD) ** : le framework complémentaire Amazon EKS ne prend pas en charge l'installation de CRD et les déclarations de ressources personnalisées basées sur les CRD appliqués avec le même module complémentaire. Si votre module complémentaire dispose de ressources personnalisées et s'appuie sur des CRD, vous pouvez soit :
+ **Publiez deux modules complémentaires : ** divisez la définition du CRD dans un module complémentaire distinct (organigramme distinct) et l'[installation réelle des ressources ](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) personnalisées dans un module complémentaire distinct.
+ **Publiez un module complémentaire unique avec des instructions manuelles supplémentaires : ** publiez un module complémentaire unique qui installe les CRD sur le cluster. Fournissez des instructions d'utilisation ainsi que des fichiers manifestes Kubernetes aux utilisateurs finaux afin de configurer des ressources personnalisées qui dépendent de ces CRD.
+ **Créez le `serviceAccount` cas échéant ** : si le logiciel est payant AWS Marketplace ou doit être connecté à un autre logiciel Services AWS, assurez-vous que le Helm graphique est créé `serviceAccount` par défaut. Si la `serviceAccount` création est gérée par un paramètre dans un `values.yaml` fichier, définissez la valeur du paramètre sur`true`. Par exemple, `serviceAccount.create = true`. Cela est nécessaire car le client peut choisir d'installer le module complémentaire en héritant des autorisations de l'instance de nœud sous-jacente qui possède déjà les autorisations requises. Si le graphique Helm ne crée pas le`serviceAccount`, les autorisations ne peuvent pas être liées au`serviceAccount`.
+ **Déploiements ou ensembles de démons traçables ** : assurez-vous que votre diagramme Helm comporte un daemonset ou un déploiement. Le framework complémentaire Amazon EKS permet de suivre le déploiement de vos ressources Amazon EKS à l'aide de celles-ci. Sans déploiement ni daemonset traçables, votre addon sera confronté à une erreur de déploiement. Si votre module complémentaire ne possède pas de déploiement ni de daemonset, par exemple, si votre module déploie un ensemble de ressources personnalisées ou une tâche Kubernetes qui ne sont pas traçables, ajoutez un déploiement ou un objet daemonset factice.
+ **Prise en charge des architectures AMD et ARM ** — De nombreux clients Amazon EKS utilisent ARM64 aujourd'hui pour utiliser les instances AWS Graviton. Third-party le logiciel doit prendre en charge les deux architectures.
+ **Intégrez les API de licences ou de comptage à partir de AWS Marketplace** : AWS Marketplace prend en charge plusieurs modèles de facturation. Pour de plus amples informations, veuillez consulter [Intégrations relatives à la facturation, au mesurage et aux licences des produits conteneurisés](container-products-billing-integration.md). Si vous souhaitez vendre votre produit via les mécanismes PAYG, consultez[Configuration du comptage personnalisé pour les produits conteneurisés avec AWS Marketplace Metering Service](container-metering-meterusage.md). Si vous souhaitez vendre votre produit selon un modèle initial ou contractuel, consultez[Tarification contractuelle pour les produits en conteneur avec AWS License Manager](container-license-manager-integration.md).
+ **Téléchargez le logiciel et tous les artefacts et dépendances ** — Le graphique Helm doit être autonome et ne doit pas nécessiter de dépendances provenant de sources externes, GitHub par exemple. Si le logiciel nécessite des dépendances externes, celles-ci doivent être transférées vers des référentiels Amazon ECR AWS Marketplace privés sous la même AWS Marketplace liste.
+ **Fournissez des instructions de déploiement sur votre site Web ** — Nous vous demandons d'héberger un guide de déploiement destiné aux clients afin d'identifier comment déployer votre logiciel via la commande [ create-addon](https://docs.aws.amazon.com/cli/latest/reference/eks/create-addon.html).
+ **Add-on permissions/IAM rôles ** : si votre module complémentaire publié AWS Marketplace nécessite l'accès à un AWS service, votre logiciel doit disposer d'un compte de service Kubernetes annoté avec des politiques IAM pour accéder aux services. AWS Vous pouvez choisir entre deux options pour que votre compte de service envoie des demandes d'API aux AWS services :
+ Informations d'identification via IRSA : cette option permet à votre logiciel d'obtenir des informations d'identification supposées auprès du service de rôle IRSA (Identity and Access Management). Pour plus d'informations, consultez la section Rôles [ IAM pour les comptes de service. ](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)
+ Identité du pod Amazon EKS : cette option permet à votre logiciel d'utiliser l'identité du pod du pod Amazon EKS pour envoyer des demandes d'API aux AWS services. Pour plus d'informations, voir [ Découvrez comment EKS Pod Identity accorde aux pods l'accès aux AWS services ](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)
Votre module complémentaire doit disposer d'un fichier de configuration supplémentaire nommé `aws_mp_addon_parameters.json` au niveau supérieur du graphique Helm, dans le même répertoire que le schéma de configuration personnalisé actuel (`aws_mp_configuration_schema.json`). Actuellement, ce fichier ne gère que les autorisations compatibles avec l'identité des pods. Le format de fichier est le suivant :
```
{
"permissions": {
"isPodIdentityCompatible" : true,
"permissionsList": [
{
"serviceAccount" : "String",
"managedPolicies" : ["Policy Arn"],
}
]
}
}
```
**Nom du fichier : `aws_mp_addon_parameters.json` **
**Note**
Le `aws_mp_addon_parameters.json` fichier active la ** section ** Add-on d'accès de la ** page des paramètres de ** Add-on configuration de la console Amazon EKS.
[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/marketplace/latest/userguide/container-product-policies.html)
**Note**
Pay-as-you-go Les produits complémentaires (PAYG) de ne AWS Marketplace peuvent pas utiliser Amazon EKS Pod Identity et doivent utiliser IAM Roles for Service Accounts (IRSA) pour le contrôle d'accès.
+ **Mises à jour des versions ** : Amazon EKS publie de nouvelles versions de Kubernetes quelques semaines après la publication en amont. Les nouvelles versions du cluster Amazon EKS étant généralement disponibles, les fournisseurs disposent de 45 jours pour certifier ou mettre à jour leur logiciel afin qu'il soit compatible avec la nouvelle version du cluster Amazon EKS. Si vos versions actuelles du module complémentaire prennent en charge la nouvelle version de Kubernetes, validez et certifiez-la afin que nous puissions mettre à jour la matrice de compatibilité des versions. Si une nouvelle version complémentaire est nécessaire pour prendre en charge la nouvelle version de Kubernetes, veuillez soumettre la nouvelle version pour intégration.
+ Le logiciel du partenaire doit appartenir à l'un des types suivants ou être un logiciel opérationnel destiné à améliorer Kubernetes ou Amazon EKS : Gitops \| surveillance \| journalisation \| gestion des certificats \| gestion des politiques \| gestion des coûts \| autoscaling \| stockage \| kubernetes-management \| service-mesh \| etcd-backup \| ingress-service-type \| load-balancer \| registre local \| réseau \| sécurité \| sauvegarde \| contrôleur d'entrée \| observabilité
+ Le logiciel ne peut pas être une interface réseau de [ conteneurs (CNI). ](https://github.com/containernetworking/cni)
+ Les logiciels doivent être vendus AWS Marketplace et intégrés aux API de licences et de comptage pour les produits payants. Les produits BYOL ne sont pas acceptés.
### Add-on exigences de configuration et meilleures pratiques pour les fournisseurs de modules complémentaires
Amazon EKS nécessite une configuration en tant que [ chaîne de schéma ](https://helm.sh/docs/topics/charts/#schema-files) Helm JSON de la part des fournisseurs de modules complémentaires. Add-ons qui nécessitent les configurations requises ou autorisent des configurations facultatives doivent inclure un `aws_mp_configuration_schema.json` fichier contenant le Helm Chart soumis à AWS Marketplace. Amazon EKS utilisera ce schéma pour valider les entrées de configuration des clients et rejeter les appels d'API dont les valeurs d'entrée ne sont pas conformes au schéma. Add-on les configurations se répartissent généralement en deux catégories :
+ Configuration des propriétés générales de Kubernetes telles que les étiquettes, les tolérations, NodeSelector, etc.
+ Configurations spécifiques aux modules complémentaires, telles que la clé de licence, l'activation des fonctionnalités, les URL, etc.
Cette section se concentre sur la première catégorie relative aux propriétés générales de Kubernetes.
Amazon EKS recommande de suivre les meilleures pratiques en matière de configuration des modules complémentaires Amazon EKS.
+ [Exigences relatives au schéma](#schema-requirements)
+ [Paramètres courants autorisés pour la configuration](#parameters-allowed)
+ [Paramètres courants qui ne sont pas autorisés pour la configuration](#parameters-not-available)
#### Exigences relatives au schéma
Lorsque vous définissez le schéma json, assurez-vous d'utiliser une version de jsonschema prise en charge par les modules complémentaires Amazon EKS.
La liste des schémas pris en charge :
+ https://json-schema.org/draft-04/schema
+ https://json-schema.org/draft-06/schema
+ https://json-schema.org/draft-07/schema
+ https://json-schema.org/draft/2019-09/schema
L'utilisation d'une autre version de schéma json est incompatible avec les modules complémentaires Amazon EKS et ne pourra pas être publié tant que ce problème ne sera pas résolu.
**Exemple de fichier de schéma Helm **
```
{
"$schema": "http://json-schema.org/schema#",
"type": "object",
"properties": {
"podAnnotations": {
"description": "Pod Annotations"
"type": "object"
},
"podLabels": {
"description": "Pod Labels"
"type": "string"
},
"resources": {
"type": "object"
"description": "Resources"
},
"logLevel": {
"description": "Logging Level"
"type": "string",
"enum": [
"info",
"debug"
]
},
"config": {
"description": "Custom Configuration"
"type": "object"
}
}
}
```
**Étui Camel**
Les paramètres de configuration doivent être CamelCase et seront rejetés s'ils ne respectent pas ce format.
**Les descriptions sont obligatoires**
Incluez toujours des descriptions pertinentes pour les propriétés du schéma. Cette description sera utilisée pour afficher les noms des étiquettes dans la console Amazon EKS pour chaque paramètre de configuration.
**Définition du RBAC**
Add-on les fournisseurs doivent définir et fournir les autorisations RBAC nécessaires pour installer correctement le module complémentaire en utilisant le principe du moindre privilège. Si les autorisations RBAC doivent être modifiées pour les nouvelles versions d'un module complémentaire ou pour tout correctif visant à résoudre un CVE, les fournisseurs de modules complémentaires devront informer l'équipe Amazon EKS de cette modification. Les autorisations requises pour chaque ressource Kubernetes doivent être limitées au nom de ressource de l'objet.
```
apiGroups: ["apps"]
resources: ["daemonsets"]
resourceNames: ["ebs-csi-node"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
```
**Gestion des secrets**
Cette section s'applique uniquement aux modules complémentaires qui nécessitent que les clients configurent des informations secrètes telles que la clé d'application, la clé API, le mot de passe, etc. Actuellement, les API Amazon EKS ne prennent pas en charge la transmission d'informations secrètes en texte brut pour des raisons de sécurité. Cependant, les clients peuvent utiliser la configuration pour transmettre le nom du secret Kubernetes qui contient les clés nécessaires au module complémentaire. Les clients devront créer des objets Kubernetes Secret contenant les clés avec le même espace de noms comme étape préalable, puis transmettre le nom du secret à l'aide du blob de configuration lors de la création du module complémentaire. Nous recommandons aux fournisseurs de modules complémentaires de nommer les propriétés du schéma afin que les clients ne le confondent pas accidentellement avec la clé réelle. Par exemple : applicationSecretName, connexionSecretName , etc.
En résumé, les fournisseurs de modules complémentaires peuvent utiliser le schéma pour permettre aux clients de transmettre le nom du secret, mais pas les clés qui contiendront réellement le secret lui-même.
**Exemples de valeurs de configuration**
Vous pouvez inclure des exemples de configuration dans votre schéma pour aider les clients à configurer les modules complémentaires. L'exemple suivant est tiré du schéma de AWS Distro for OpenTelemetry add-on.
```
"examples": [
{
"admissionWebhooks": {
"namespaceSelector": {},
"objectSelector": {}
},
"affinity": {},
"collector": {
"amp": {
"enabled": true,
"remoteWriteEndpoint": "https://aps-workspaces.us-west-2.amazonaws.com/workspaces/ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api/v1/remote_write"
},
"cloudwatch": {
"enabled": true
},
"mode": "deployment",
"replicas": 1,
"resources": {
"limits": {
"cpu": "256m",
"memory": "512Mi"
},
"requests": {
"cpu": "64m",
"memory": "128Mi"
}
},
"serviceAccount": {
"annotations": {},
"create": true,
"name": "adot-collector"
},
"xray": {
"enabled": true
}
},
"kubeRBACProxy": {
"enabled": true,
"resources": {
"limits": {
"cpu": "500m",
"memory": "128Mi"
},
"requests": {
"cpu": "5m",
"memory": "64Mi"
}
}
},
"manager": {
"env": {},
"resources": {
"limits": {
"cpu": "100m",
"memory": "128Mi"
},
"requests": {
"cpu": "100m",
"memory": "64Mi"
}
}
},
"nodeSelector": {},
"replicaCount": 1,
"tolerations": []
}
]
```
#### Paramètres courants autorisés pour la configuration
Les paramètres suivants sont recommandés dans un fichier de schéma Helm destiné au client.
| Paramètre | Description | Devrait-il y avoir une valeur par défaut ? |
| --- | --- | --- |
| Étiquettes supplémentaires | Ajoutez des étiquettes Kubernetes à tous les objets Kubernetes gérés par le module complémentaire. | Non |
| Annotations supplémentaires | Ajoutez des annotations Kubernetes à tous les objets Kubernetes gérés par le module complémentaire. | Non |
| Étiquettes pour POD | Ajoutez des étiquettes Kubernetes aux pods gérés par le module complémentaire. | Non |
| Annotations POD | Ajoutez des annotations Kubernetes aux pods gérés par le module complémentaire. | Non |
| logLevel | Niveau de journalisation pour les composants gérés par le module complémentaire. | Oui |
| nodeSelector | Forme recommandée la plus simple de contrainte de sélection de nœuds. Vous pouvez ajouter le champ NodeSelector à la spécification de votre pod et spécifier les étiquettes de nœud que vous souhaitez attribuer au nœud cible. | Potentiellement, par exemple, des nœuds Linux uniquement |
| tolérances | Des tolérances sont appliquées aux gousses. Les tolérances permettent au planificateur de planifier des pods avec les couleurs correspondantes. Les tolérances permettent la planification mais ne garantissent pas la planification. | Peut-être, plus courant avec les daemonsets |
| affinité | La fonction d'affinité comprend deux types d'affinité : l'affinité des nœuds fonctionne comme le champ NodeSelector mais est plus expressive et vous permet de spécifier des règles souples, Inter-pod affinity/anti -affinity vous permet de contraindre les Pods par rapport aux étiquettes des autres Pods. | Peut-être |
| topologie SpreadConstraints | Vous pouvez utiliser les contraintes de répartition de la topologie pour contrôler la répartition des pods dans votre cluster entre les domaines de défaillance tels que les régions, les zones, les nœuds et autres domaines de topologie définis par l'utilisateur. Cela peut contribuer à atteindre une haute disponibilité ainsi qu'une utilisation efficace des ressources. | Peut-être |
| ressource request/limits | Spécifiez la quantité dont cpu/memory chaque contenant a besoin. Il est fortement recommandé de définir les demandes. Les limites sont facultatives. | Oui |
| réplicas | Nombre de répliques des pods gérés par le module complémentaire. Ne s'applique pas aux daemonsets. | Oui |
**Note**
Pour les paramètres de configuration de la planification de la charge de travail, vous devrez peut-être séparer les composants de niveau supérieur dans le schéma si nécessaire. Par exemple, le pilote Amazon EBS CSI contient deux composants principaux, le contrôleur et l'agent de nœud. Les clients ont besoin d'un nœud différent selectors/tolerations pour chaque composant.
**Note**
Les valeurs par défaut définies dans le schéma JSON sont uniquement destinées à la documentation utilisateur et ne remplacent pas la nécessité d'avoir la valeur par défaut correcte dans le `values.yaml` fichier. Si vous utilisez la propriété par défaut, assurez-vous que la valeur par défaut `values.yaml` correspond à celle du schéma et des deux artefacts (`values.schema.json`et`values.yaml`) qu'elle reste synchronisée chaque fois que des modifications sont apportées au Helm Chart.
```
"affinity": {
"default": {
"affinity": {
"nodeAffinity": {
"preferredDuringSchedulingIgnoredDuringExecution": [
{
"preference": {
"matchExpressions": [
{
"key": "eks.amazonaws.com/compute-type",
"operator": "NotIn",
"values": [
"fargate"
]
}
]
},
"weight": 1
}
]
},
"podAntiAffinity": {
"preferredDuringSchedulingIgnoredDuringExecution": [
{
"podAffinityTerm": {
"labelSelector": {
"matchExpressions": [
{
"key": "app",
"operator": "In",
"values": [
"ebs-csi-controller"
]
}
]
},
"topologyKey": "kubernetes.io/hostname"
},
"weight": 100
}
]
}
}
},
"description": "Affinity of the controller pod",
"type": [
"object",
"null"
]
}
```
### Paramètres courants qui ne sont pas autorisés pour la configuration
Des paramètres de métadonnées de cluster tels que `clusterName` `region``vpcId`,,`accountId`, et d'autres peuvent être requis par divers modules complémentaires (par exemple, Elastic Load Balancing Controller). Tout paramètre similaire connu par le service Amazon EKS sera automatiquement injecté par les modules complémentaires Amazon EKS, et il n'incombe pas à l'utilisateur de le spécifier comme option de configuration. Ces paramètres incluent :
+ AWS région
+ Nom du cluster Amazon EKS
+ ID VPC du cluster
+ Registre de conteneurs, spécifiquement pour les comptes build-prod, utilisé par les modules complémentaires réseau
+ IP du cluster DNS, spécifiquement pour le module complémentaire Coredns
+ Point de terminaison d'API du cluster Amazon EKS
+ IPv4 activé sur le cluster
+ IPv6 activé sur le cluster
+ Délégation de préfixes pour IPv6 activée sur le cluster
Add-on les fournisseurs doivent s'assurer que vous avez défini des modèles pour ces paramètres applicables. Chacun des paramètres ci-dessus aura un `parameterType` attribut prédéfini défini par Amazon EKS. Les métadonnées de la version spécifieront le mappage entre le `parameterType` et le name/path du paramètre dans le modèle. De cette façon, les valeurs peuvent être transmises dynamiquement par Amazon EKS sans que les clients n'aient à les spécifier par le biais de configurations, ce qui donne également la flexibilité aux fournisseurs de modules complémentaires pour définir leur propre modèle. name/path Les paramètres tels que ceux ci-dessus qu'Amazon EKS doit injecter dynamiquement doivent être exclus du fichier de schéma.
**Exemple de mappage à partir des métadonnées de version **
```
"defaultConfiguration": [
{
"key": "image.containerRegistry",
"parameterType": "CONTAINER_REGISTRY"
}
]
```
Les paramètres suivants ne sont pas recommandés pour être configurés dans un fichier de schéma Helm destiné au client. Soit les paramètres doivent avoir des valeurs par défaut non modifiables, soit ne pas être inclus du tout dans le modèle du module complémentaire.
| Paramètre | Description | Devrait-il y avoir une valeur par défaut ? |
| --- | --- | --- |
| image | Image de conteneur qui sera déployée sur le cluster Kubernetes. | Non, géré via la définition du module complémentaire |
| image PullSecrets | Configuration d'un pod pour qu'il utilise un secret à extraire d'un registre privé. | N/A |
| Sonde Liveness | Le processus Kubelet utilise des sondes de vivacité pour savoir quand redémarrer un conteneur. Par exemple, les sondes de vivacité peuvent détecter une impasse, lorsqu'une application est en cours d'exécution mais ne parvient pas à progresser. Le redémarrage d'un conteneur dans un tel état peut contribuer à rendre l'application plus disponible malgré les bogues. | Oui |
| Sonde de préparation | Il est important que vous disposiez d'une sonde de préparation pour vos conteneurs. De cette façon, le processus Kubelet exécuté sur votre plan de données saura quand le conteneur est prêt à servir le trafic. Un pod est considéré comme prêt lorsque tous ses contenants sont prêts. L'une des utilisations de ce signal est de contrôler quels pods sont utilisés comme backends pour les services. Lorsqu'un Pod n'est pas prêt, il est retiré des équilibreurs de charge de service. | Oui |
| Sonde de démarrage | Le kubelet utilise des sondes de démarrage pour savoir quand une application conteneur a démarré. Si une telle sonde est configurée, elle désactive les contrôles de vivacité et de disponibilité jusqu'à ce qu'elle réussisse, en veillant à ce que ces sondes n'interfèrent pas avec le démarrage de l'application. Cela peut être utilisé pour adopter des contrôles de vivacité sur les conteneurs à démarrage lent, afin d'éviter qu'ils ne soient tués par la kubelet avant qu'ils ne soient opérationnels. | Facultatif |
| gousse DisruptionBudget | Définissez un budget de discrétion (PDB) pour garantir qu'un nombre minimum de PODS continuent de fonctionner pendant les interruptions volontaires. Un PDB limite le nombre de pods d'une application répliquée qui sont en panne simultanément en raison d'interruptions volontaires. Par exemple, une application basée sur le quorum souhaite s'assurer que le nombre de répliques en cours d'exécution n'est jamais inférieur au nombre requis pour atteindre un quorum. Une interface Web peut vouloir s'assurer que le nombre de répliques servant de la charge ne tombe jamais en dessous d'un certain pourcentage du total. | Oui, si la valeur par défaut est supérieure à deux répliques |
| ServiceAccount (nom) | Nom du compte de service sous lequel les pods seront exécutés. | Oui |
| ServiceAccount (annotations) | Annotations appliquées au compte de service. Généralement utilisé pour la fonctionnalité IAM Roles for Service Accounts | Non, l'ARN du rôle du compte de service IAM est défini dans l'API des modules complémentaires Amazon EKS de niveau supérieur. Il existe une exception à cette règle si votre module complémentaire en comporte plusieurs deployments/controllers (comme Flux) et nécessite des ARN de rôle IRSA distincts. |
| priorité ClassName | La priorité indique l'importance d'un Pod par rapport aux autres Pods. Si un Pod ne peut pas être programmé, le planificateur essaie de préempter (expulser) les Pods de priorité inférieure pour permettre la planification du Pod en attente. | Oui. La plupart des modules complémentaires sont essentiels à la fonctionnalité du cluster et doivent avoir une classe de priorité définie par défaut. |
| gousse SecurityContext | Un contexte de sécurité définit les paramètres de privilèges et de contrôle d'accès pour un pod ou un conteneur. Généralement utilisé pour définir FSGroup, qui était requis pour IRSA dans les clusters v1.19 et inférieurs. | Peu probable, étant donné qu'Amazon EKS ne prend plus en charge Kubernetes v1.19 |
| Contexte de sécurité | Un contexte de sécurité définit les paramètres de privilèges et de contrôle d'accès pour un pod ou un conteneur. | Oui |
| Stratégie de mise à jour | Spécifie la stratégie utilisée pour remplacer les anciens Pods par de nouveaux. | Oui |
| Nom Override | Remplacez le nom des pods. | Non |
| gousse SecurityPolicy | Appliquez des restrictions sur les paramètres. | Non, les PSP sont obsolètes |
| extraVolumeMounts/extraVolumes | Utilisé pour IRSA dans des clusters non Amazon EKS. | Non |