View a markdown version of this page

Modifier les contrôles d'origine des packages - CodeArtifact
Scénarios courants de contrôle d'accès aux packagesParamètres de contrôle de l'origine des colisParamètres de contrôle de l'origine des packages par défautComment les contrôles d'origine des packages interagissent avec les contrôles d'origine des groupes de packagesModifier les contrôles d'origine des packagesPublication et référentiels en amont

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.

Modifier les contrôles d'origine des packages

Dans AWS CodeArtifact, les versions de packages peuvent être ajoutées à un référentiel en les publiant directement, en les extrayant d'un référentiel en amont ou en les ingérant depuis un référentiel public externe. Le fait d'autoriser l'ajout de versions d'un package à la fois par publication directe et par ingestion à partir de référentiels publics vous rend vulnérable à une attaque de substitution de dépendances. Pour de plus amples informations, veuillez consulter Attaques de substitution de la dépendance. Pour vous protéger contre une attaque de substitution de dépendances, vous pouvez configurer les contrôles d'origine des packages sur un package d'un référentiel afin de limiter la manière dont les versions de ce package peuvent être ajoutées au référentiel.

La configuration des contrôles d'origine des packages doit être envisagée par toute équipe souhaitant autoriser les nouvelles versions de différents packages à provenir à la fois de sources internes, telles que la publication directe, et de sources externes, telles que des référentiels publics. Par défaut, les contrôles d'origine des packages seront configurés en fonction de la manière dont la première version d'un package est ajoutée au référentiel. Pour plus d'informations sur les paramètres de contrôle de l'origine des packages et leurs valeurs par défaut, consultezParamètres de contrôle de l'origine des colis.

Pour supprimer l'enregistrement du package après avoir utilisé l'opération d'put-package-origin-configurationAPI, utilisez delete-package (voirSupprimer un package ou une version de package).

Scénarios courants de contrôle d'accès aux packages

Cette section inclut certains scénarios courants lorsqu'une version de package est ajoutée à un CodeArtifact référentiel. Les paramètres de contrôle de l'origine des packages seront définis pour les nouveaux packages en fonction de la manière dont la première version du package est ajoutée.

Dans les scénarios suivants, un package interne est un package publié directement par un gestionnaire de packages dans votre référentiel, tel qu'un package que vous ou votre équipe créez et gérez. Un package externe est un package qui existe dans un référentiel public et qui peut être ingéré dans votre référentiel via une connexion externe.

Une version de package externe est publiée pour un package interne existant

Dans ce scénario, considérez un package interne, PackageA. Votre équipe publie la première version du package pour PackageA dans un CodeArtifact référentiel. Comme il s'agit de la première version de package pour ce package, les paramètres de contrôle de l'origine du package sont automatiquement définis sur Publier : Autoriser et En amont : Bloquer. Une fois que le package existe dans votre référentiel, un package portant le même nom est publié dans un référentiel public connecté à votre CodeArtifact référentiel. Il peut s'agir d'une tentative d'attaque de substitution de dépendances contre le package interne, ou simplement d'une coïncidence. Quoi qu'il en soit, les contrôles d'origine des packages sont configurés pour bloquer l'ingestion de la nouvelle version externe afin de se protéger contre une attaque potentielle.

Dans l'image suivante, RePoa est votre CodeArtifact dépôt avec une connexion externe à un référentiel public. Votre dépôt contient les versions 1.1 et 2.1 de PackageA, mais la version 3.0 est publiée dans le référentiel public. Normalement, RePoa ingère la version 3.0 une fois que le package a été demandé par un gestionnaire de packages. L'ingestion de packages étant définie sur Bloquer, la version 3.0 n'est pas ingérée dans votre CodeArtifact référentiel et n'est pas disponible pour les gestionnaires de packages qui y sont connectés.

Graphique simple montrant une nouvelle version d'un package externe bloquée depuis un référentiel public.

Une version de package interne est publiée pour un package externe existant

Dans ce scénario, un package, PackageB, existe en externe dans un référentiel public que vous avez connecté à votre référentiel. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande PackageB, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de PackageB ajoutée à votre référentiel, les paramètres d'origine du package sont configurés pour Publier : BLOQUER et En amont : AUTORISER. Plus tard, vous tenterez de publier une version portant le même nom de package dans le référentiel. Soit vous n'êtes pas au courant de l'existence du package public et vous essayez de publier un package indépendant sous le même nom, soit vous essayez de publier une version corrigée, soit vous essayez de publier directement la version exacte du package qui existe déjà en externe. CodeArtifact rejettera la version que vous essayez de publier, mais vous permettra d'annuler explicitement le rejet et de publier la version si nécessaire.

Dans l'image suivante, RePoa est votre CodeArtifact dépôt avec une connexion externe à un référentiel public. Votre dépôt contient la version 3.0 qu'il a ingérée depuis le dépôt public. Vous souhaitez publier la version 1.1 dans votre référentiel. Normalement, vous pouvez publier la version 1.2 sur RePoa, mais comme la publication est définie sur Bloquer, la version 1.2 ne peut pas être publiée.

Graphique simple montrant une nouvelle version d'un package externe bloquée depuis un référentiel public.

Publication d'une version corrigée d'un package externe existant

Dans ce scénario, un package, PackageB, existe en externe dans un référentiel public que vous avez connecté à votre référentiel. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande PackageB, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de PackageB ajoutée à votre référentiel, les paramètres d'origine du package sont configurés pour Publier : BLOQUER et En amont : AUTORISER. Votre équipe décide qu'elle doit publier des versions corrigées de ce package dans le référentiel. Pour pouvoir publier directement les versions des packages, votre équipe modifie les paramètres de contrôle de l'origine des packages sur Publier : AUTORISER et En amont : BLOQUER. Les versions de ce package peuvent désormais être publiées directement dans votre référentiel et ingérées à partir de référentiels publics. Une fois que votre équipe a publié les versions corrigées du package, elle rétablit les paramètres d'origine du package sur Publier : BLOQUER et En amont : AUTORISER.

Paramètres de contrôle de l'origine des colis

Les contrôles d'origine des packages vous permettent de configurer la manière dont les versions des packages peuvent être ajoutées à un référentiel. Les listes suivantes incluent les paramètres et valeurs de contrôle de l'origine des packages disponibles.

Note

Les paramètres et valeurs disponibles sont différents lors de la configuration des contrôles d'origine sur les groupes de packages. Pour de plus amples informations, veuillez consulter Contrôles de l’origine des groupes de packages.

Publish

Ce paramètre permet de configurer si les versions des packages peuvent être publiées directement dans le référentiel à l'aide de gestionnaires de packages ou d'outils similaires.

  • AUTORISER  : Les versions des packages peuvent être publiées directement.

  • BLOCAGE  : Les versions des packages ne peuvent pas être publiées directement.

En amont

Ce paramètre permet de configurer si les versions des packages peuvent être ingérées depuis des référentiels publics externes ou conservées depuis des référentiels en amont à la demande d'un gestionnaire de packages.

  • AUTORISER  : Toute version de package peut être conservée à partir d'autres CodeArtifact référentiels configurés en tant que référentiels en amont ou ingérée depuis une source publique via une connexion externe.

  • BLOCAGE  : Les versions des packages ne peuvent pas être conservées à partir d'autres CodeArtifact référentiels configurés en tant que référentiels en amont ou ingérées depuis une source publique via une connexion externe.

Paramètres de contrôle de l'origine des packages par défaut

Les paramètres de contrôle d'origine des packages par défaut sont configurés en fonction des paramètres de contrôle d'origine du groupe de packages associé au package. Pour plus d'informations sur les groupes de packages et les contrôles d'origine des groupes de packages, consultez Utilisation de groupes de packages dans CodeArtifact etContrôles de l’origine des groupes de packages.

Si un package est associé à un groupe de packages dont les paramètres de restriction sont définis ALLOW pour chaque type de restriction, les contrôles d'origine du package par défaut pour un package seront basés sur la manière dont la première version de ce package est ajoutée au référentiel.

  • Si la première version du package est publiée directement par un gestionnaire de packages, les paramètres seront Publier : AUTORISER et En amont : BLOQUER.

  • Si la première version du package est ingérée depuis une source publique, les paramètres seront Publish : BLOCK et Upstream : ALLOW.

Note

Les packages qui existaient dans CodeArtifact les référentiels avant mai 2022 auront un contrôle d'origine de package par défaut de type Publish : ALLOW et Upstream : ALLOW. Les contrôles d'origine des packages doivent être définis manuellement pour ces packages. Les valeurs par défaut actuelles ont été définies pour les nouveaux packages depuis lors et ont commencé à être appliquées lorsque la fonctionnalité a été lancée le 14 juillet 2022. Pour plus d'informations sur la définition des contrôles d'origine des packages, consultezModifier les contrôles d'origine des packages.

Sinon, si un package est associé à un groupe de packages dont au moins un paramètre de restriction est égal à BLOCK ouALLOW_SPECIFIC_REPOSITORIES, les paramètres de contrôle d'origine par défaut pour ce package seront définis sur Publish : ALLOW et Upstream : ALLOW.

Comment les contrôles d'origine des packages interagissent avec les contrôles d'origine des groupes de packages

Étant donné que les packages ont des paramètres de contrôle d'origine et que leurs groupes de packages associés ont des paramètres de contrôle d'origine, il est important de comprendre comment ces deux paramètres différents interagissent entre eux.

L'interaction entre les deux paramètres est qu'un réglage de l'emporte BLOCK toujours sur un paramètre deALLOW. Le tableau suivant répertorie quelques exemples de configurations et leurs paramètres de contrôle d'origine effectifs.

Paramètre de contrôle de l'origine des colis Paramètre de contrôle de l'origine des groupes de packages Paramètre de contrôle d'origine efficace

PUBLIER : AUTORISER

EN AMONT : AUTORISER

PUBLIER : AUTORISER

EN AMONT : AUTORISER

PUBLIER : AUTORISER

EN AMONT : AUTORISER

PUBLIER : BLOQUER

EN AMONT : AUTORISER

PUBLIER : AUTORISER

EN AMONT : AUTORISER

PUBLIER : BLOQUER

EN AMONT : AUTORISER

PUBLIER : AUTORISER

EN AMONT : AUTORISER

PUBLIER : AUTORISER

EN AMONT : BLOC

PUBLIER : AUTORISER

EN AMONT : BLOC

Cela signifie que si les paramètres d'origine d'un package sont Publish : ALLOW et Upstream : ALLOW, il s'en remet effectivement aux paramètres de contrôle d'origine du groupe de packages associé.

Modifier les contrôles d'origine des packages

Les contrôles d'origine des packages sont configurés automatiquement en fonction de la manière dont la première version d'un package est ajoutée au référentiel. Pour plus d'informations, consultezParamètres de contrôle de l'origine des packages par défaut. Pour ajouter ou modifier des contrôles d'origine de package pour un package dans un CodeArtifact référentiel, effectuez les étapes de la procédure suivante.

Pour ajouter ou modifier des commandes relatives à l'origine des packages (console)

  1. Ouvrez la AWS CodeArtifact console à l'adresse https://console.aws.amazon.com/codesuite/codeartifact/home.

  2. Dans le volet de navigation, choisissez Repositories, puis choisissez le référentiel qui contient le package que vous souhaitez modifier.

  3. Dans le tableau Packages, recherchez et sélectionnez le package que vous souhaitez modifier.

  4. Sur la page récapitulative du package, dans les contrôles Origin, choisissez Modifier.

  5. Dans Modifier les contrôles d'origine, choisissez les contrôles d'origine du package que vous souhaitez définir pour ce package. Les deux paramètres de contrôle de l'origine des packages, Publish et Upstream, doivent être définis en même temps.

    • Pour autoriser la publication directe des versions des packages, dans Publier, choisissez Autoriser. Pour bloquer la publication des versions des packages, choisissez Bloquer.

    • Pour autoriser l'ingestion de packages depuis des référentiels externes et l'extraction de packages depuis des référentiels en amont, dans Sources en amont, choisissez Autoriser. Pour bloquer toute ingestion et extraction de versions de packages depuis des référentiels externes et en amont, choisissez Bloquer.

Pour ajouter ou modifier des contrôles d'origine des packages (AWS CLI)

  1. Si ce n'est pas le cas, configurez-le AWS CLI en suivant les étapes décrites dansConfiguration avec AWS CodeArtifact.

  2. Utilisez la put-package-origin-configuration commande pour ajouter ou modifier des contrôles d'origine du package. Remplacez les champs suivants :

    • my_domainRemplacez-le par le CodeArtifact domaine qui contient le package que vous souhaitez mettre à jour.

    • my_repoRemplacez-le par le CodeArtifact référentiel qui contient le package que vous souhaitez mettre à jour.

    • npmRemplacez-le par le format du package que vous souhaitez mettre à jour.

    • my_packageRemplacez-le par le nom du package que vous souhaitez mettre à jour.

    • Remplacez ALLOW et BLOCK par les paramètres de contrôle de l'origine des colis souhaités.

    aws codeartifact put-package-origin-configuration --domain my_domain \
--repository my_repo --format npm --package my_package \ 
--restrictions publish=ALLOW,upstream=BLOCK

Publication et référentiels en amont

CodeArtifact n'autorise pas la publication de versions de packages présentes dans des référentiels en amont accessibles ou des référentiels publics. Supposons, par exemple, que vous souhaitiez publier un package com.mycompany.mypackage:1.0 Maven dans un référentiel et que vous myrepo disposiez myrepo d'un référentiel en amont avec une connexion externe à Maven Central. Envisagez les scénarios suivants.

  1. Les paramètres de contrôle de l'origine des packages com.mycompany.mypackage sont Publish : ALLOW et Upstream : ALLOW. S'il com.mycompany.mypackage:1.0 est présent dans le référentiel en amont ou dans Maven Central, CodeArtifact rejette toute tentative de publication dans ce référentiel myrepo avec une erreur de conflit 409. Vous pouvez toujours publier une version différente, telle quecom.mycompany.mypackage:1.1.

  2. Les paramètres de contrôle de l'origine des packages com.mycompany.mypackage sont Publish : ALLOW et Upstream : BLOCK. Vous pouvez publier dans votre référentiel n'importe quelle version de com.mycompany.mypackage qui n'existe pas encore car les versions des packages ne sont pas accessibles.

  3. Les paramètres de contrôle de l'origine des packages com.mycompany.mypackage sont Publish : BLOCK et Upstream : ALLOW. Vous ne pouvez publier aucune version de package directement dans votre référentiel.