Securing any environment requires multiple lines of defense. Azure Container Registry recently announced general availability of features like Azure Private Link, customer-managed keys, dedicated data-endpoints and Azure Policy definitions.
L’équipe Azure Container Registry partage la préversion des clés gérées par le client pour le chiffrement des données au repos. Azure Container Registry chiffre déjà les données au repos à l’aide de clés gérées par le service.
L’équipe Azure Container Registry (ACR) est en train de déployer la préversion des autorisations de contrôle d’accès en fonction du rôle (RBAC) délimitées par le dépôt, l’élément le plus plébiscité sur UserVoice.
L’équipe Azure Container Registry (ACR) est en train de déployer la préversion des autorisations de contrôle d’accès en fonction du rôle (RBAC) délimitées par le dépôt, l’élément le plus plébiscité sur UserVoice. Dans cette mise en production, nous vous proposons une expérience d’interface de ligne de commande (CLI) que vous pouvez essayer pour fournir des commentaires.
Azure Container Registry prend en charge plusieurs options d’authentification utilisant des identités disposant d’un accès en fonction du rôle à un registre entier. Toutefois, pour des scénarios avec plusieurs équipes, vous pouvez consolider plusieurs équipes dans un seul registre, en limitant l’accès de chaque équipe à des dépôts spécifiques. Le RBAC étendu au dépôt permet désormais l’utilisation de cette fonctionnalité.
Voici des scénarios dans lesquels des autorisations étendues au dépôt peuvent s’avérer utiles :
Limiter l’accès au référentiel à des groupes d’utilisateurs spécifiques au sein de votre organisation. Par exemple, fournir un accès en écriture aux développeurs qui génèrent des images ciblant des dépôts spécifiques, et un accès en lecture aux équipes qui déploient à partir de ces dépôts.
Fournir à des millions d’appareils IoT un accès individuel pour extraire des images de dépôts spécifiques.
Fournir à une organisation externe des autorisations sur des dépôts spécifiques.
Dans cette mise en production, nous avons introduit des jetons en tant que mécanisme pour implémenter des autorisations RBAC étendues au dépôt. Un jeton est une information d’identification utilisée pour s’authentifier auprès du registre. Il peut être adossé à un nom d’utilisateur et un mot de passe, ou à des objets Azure Active Directory (AAD) tels que des utilisateurs, principaux de service et identités managées Azure Active Directory. Pour cette version, nous avons fourni des jetons adossés à un nom d’utilisateur et un mot de passe. Les futures mises en production prendront en charge les jetons adossés à des objets Azure Active Directory (AAD) tels que des utilisateurs, principaux de service et identités managées Azure Active Directory. Voir la Figure 1.
*La prise en charge de jeton adossé à Azure Active Directory (AAD) sera disponible dans une version ultérieure.
Figure 1
La Figure 2 ci-dessous décrit la relation entre les jetons et les mappages d’étendue.
Un jeton est une information d’identification utilisée pour s’authentifier auprès du registre. Il est associé à un ensemble autorisé d’actions qui sont étendues à un ou plusieurs dépôts. Une fois que vous avez généré un jeton, vous pouvez l’utiliser pour vous authentifier auprès de votre registre. Vous pouvez établir une connexion de Docker à l’aide de la commande suivante :
docker login --username mytoken --password-stdin myregistry.azurecr.io.
Un mappage d’étendue est un objet de registre qui regroupe des autorisations de dépôt que vous appliquez à un jeton. Il fournit un graphique d’accès à un ou plusieurs référentiels. Vous pouvez appliquer des autorisations de dépôt délimité à un jeton ou les réappliquer à d’autres jetons. Si vous n’appliquez pas de mappage d’étendue lors de la création d’un jeton, un mappage d’étendue est automatiquement créé pour vous, afin d’enregistrer les paramètres d’autorisation.
Un mappage d’étendue vous aide à configurer plusieurs utilisateurs avec un accès identique à un ensemble de référentiels.
Figure 2
Les clients utilisant des conteneurs et d’autres artefacts pour leur déploiement IoT, le nombre d’appareils peut atteindre plusieurs millions. Pour prendre en charge l’échelle de l’IoT, Azure Container Registry a implémenté un contrôle d’accès en fonction du rôle (RBAC) basé sur le dépôt, utilisant des jetons (figure 3). Les jetons ne remplacent pas les principaux de service ou les identités managées. Vous pouvez ajouter des jetons en tant qu’option supplémentaire pour l’extensibilité des scénarios de déploiement IoT.
Cet article montre comment créer un jeton avec des autorisations limitées à un dépôt spécifique au sein d’un registre. Avec l’introduction d’autorisations de dépôt basées sur des jetons, vous pouvez désormais fournir aux utilisateurs ou aux services un accès délimité et limité dans le temps aux référentiels sans exiger d’identité Azure Active Directory. À l’avenir, nous prendrons en charge les jetons adossés à des objets Azure Active Directory. Découvrez cette nouvelle fonctionnalité et faites-nous part de vos commentaires sur GitHub.
Figure 3
L’expérience Azure CLI est désormais en préversion. Comme toujours, nous apprécions de lire vos commentaires sur des fonctionnalités existantes, ainsi que vos idées pour orienter la feuille de route de notre produit.
Feuille de route : Pour la visibilité de notre travail planifié.
UserVoice : Pour voter en faveur de demandes existantes ou créer des demandes.
Problèmes : Pour examiner des bogues et problèmes existants, et en consigner de nouveaux.
Documents ACR : Pour des didacticiels et de la documentation sur ACR.
