• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la documentation Amazon CloudWatch Dashboard.
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.
Configuration Parameter Store
Avant de configurer les paramètres dansParameter Store, configurez des politiques Gestion des identités et des accès AWS (IAM) qui autorisent les administrateurs de votre compte à effectuer les actions que vous spécifiez.
Dans cette section, vous apprendrez à configurer manuellement ces politiques à l'aide de la console IAM et à les attribuer à des utilisateurs et à des groupes d'utilisateurs. Vous pouvez également créer et attribuer des politiques pour contrôler les actions de paramètres qui peuvent être exécutées sur un nœud géré.
Cette section explique également comment créer des EventBridge règles Amazon qui vous permettent de recevoir des notifications concernant les modifications apportées aux paramètres de Systems Manager. Vous pouvez utiliser des EventBridge règles pour invoquer d'autres actions en AWS fonction des modifications apportées àParameter Store.
Table des matières
Gestion de l'accès à Parameter Store paramètres utilisant des politiques IAM
Le principal IAM qui accède aux AWS Systems Manager paramètres doit être autorisé à effectuer les actions SSM requises. Le principal peut être un utilisateur IAM, un rôle IAM, un profil d'instance Amazon EC2, un rôle d'exécution Lambda, un rôle de tâche Amazon ECS, un rôle de CodeBuild service ou un autre rôle de service. AWS
Le tableau suivant décrit les autorisations IAM requises pour différentes Parameter Store actions.
| Action | Privilège IAM requis | Informations de référence |
|---|---|---|
| Création ou mise à jour d'un paramètre | ssm:PutParameter |
PutParameter |
| Récupérez un paramètre | ssm:GetParameter |
GetParameter |
| Récupérez plusieurs paramètres nommés | ssm:GetParameters |
GetParameters |
| Récupérer des paramètres sous un chemin | ssm:GetParametersByPath |
GetParametersByPath |
| Afficher les métadonnées des paramètres | ssm:DescribeParameters |
DescribeParameters |
| Afficher l'historique des versions des paramètres | ssm:GetParameterHistory |
GetParameterHistory |
| Supprimer un paramètre | ssm:DeleteParameter |
DeleteParameter |
| Supprimer plusieurs paramètres | ssm:DeleteParameters |
DeleteParameters |
Lorsque vous utilisez des politiques IAM pour accorder l'accès aux paramètres de Systems Manager, nous vous recommandons de créer et d'utiliser des politiques IAM restrictives. Par exemple, la politique suivante permet à un responsable d'appeler les opérations d'GetParametersAPI DescribeParameters et pour un ensemble limité de ressources. Le directeur peut obtenir des informations et utiliser tous les paramètres commençant parprod-*.
Important
Si un utilisateur a accès à un chemin, il peut accéder à tous les niveaux de ce chemin. Par exemple, si un utilisateur a l'autorisation d'accéder à un chemin /a, il peut également accéder à /a/b. Même si un principal s'est vu explicitement refuser l'accès à un paramètre dans IAM/a/b, il peut toujours appeler l'opération d'GetParametersByPathAPI de manière récursive pour /a et afficher. /a/b
Pour les administrateurs de confiance, vous pouvez fournir un accès complet à toutes les opérations d'API des paramètres Systems Manager en utilisant une politique similaire à l'exemple suivant. Cette politique accorde à l'utilisateur un accès complet à tous les paramètres de production qui commencent par dbserver-prod-*.
Refuser des autorisations
Chaque API est unique et dispose d'opérations et d'autorisations distinctes que vous pouvez autoriser ou refuser individuellement. Un refus explicite dans n'importe quelle politique remplace l'autorisation.
Note
La clé par défaut AWS Key Management Service (AWS KMS) Decrypt autorise tous les principaux IAM du. Compte AWS Si vous souhaitez différents niveaux d'accès aux SecureString paramètres de votre compte, nous vous déconseillons d'utiliser la clé par défaut.
Si vous voulez que toutes les opérations d'API qui récupèrent des valeurs de paramètres aient un comportement identique, vous pouvez utiliser un modèle tel que GetParameter* dans une politique. L'exemple suivant montre comment refuser GetParameter, GetParameters, GetParameterHistory et GetParametersByPath pour tous les paramètres commençant par prod-*.
L'exemple suivant montre comment refuser certaines commandes, tout en permettant à l'utilisateur d'en exécuter d'autres sur tous les paramètres commençant par prod-*.
Note
L'historique des paramètres inclut toutes les versions de paramètres, y compris la version actuelle. Par conséquent, si un utilisateur se voit refuser l'autorisation pour GetParameter, GetParameters et GetParameterByPath, mais qu'il obtient l'autorisation pour GetParameterHistory, il peut voir le paramètre actuel, y compris les paramètres SecureString, en utilisant GetParameterHistory.
Chiffrement et déchiffrement des paramètres à l'aide de AWS KMS clés
Parameter StoreSecureStringles paramètres utilisent AWS KMS des clés pour le chiffrement. AWS KMS chiffre la valeur à l'aide d'une clé gérée par le client Clé gérée par AWS ou d'une clé gérée par le client. Pour plus d'informations sur AWS KMS et AWS KMS key, consultez le Guide du AWS Key Management Service développeur .
Tous les utilisateurs du compte client ont accès à la clé AWS gérée par défaut. Vous pouvez trouver l'Amazon Resource Name (ARN) de la clé par défaut dans la AWS KMS console, sur la page des clés aws/ssm dans la colonne Alias. Vous souhaiterez peut-être utiliser la clé par défaut pour chiffrer SecureString les paramètres tout en empêchant les utilisateurs de travailler avec les SecureString paramètres. Dans ce cas, les politiques IAM doivent explicitement refuser l'accès à la clé par défaut, comme le montre l'exemple de politique suivant.
Lorsque vous utilisez une clé gérée par le client, la politique IAM qui accorde à un accès principal à un paramètre ou à un chemin de paramètre doit fournir des kms:Encrypt autorisations explicites pour la clé. Par exemple, la politique suivante permet à un principal de créer, de mettre à jour et d'afficher des SecureString paramètres commençant par prod- les valeurs spécifiées Région AWS et Compte AWS.
Note
L’autorisation kms:GenerateDataKey est requise pour créer des paramètres avancés chiffrés à l’aide de la clé gérée par le client spécifiée.
Si vous avez besoin d'un contrôle d'accès précis aux SecureString paramètres de votre compte, utilisez une clé gérée par le client pour protéger et restreindre l'accès à ces paramètres. Nous vous recommandons également de l'utiliser AWS CloudTrail pour surveiller l'activité des SecureString paramètres.
Pour plus d’informations, consultez les rubriques suivantes :
-
Logique d'évaluation des politiques dans le Guide de l'utilisateur IAM
-
Utilisation de politiques de clé dans AWS KMS dans le Guide du développeur AWS Key Management Service
-
Afficher les événements avec l'historique des CloudTrail événements dans le guide de AWS CloudTrail l'utilisateur
Autoriser les nœuds gérés à accéder à des paramètres spécifiques
Pour contrôler Parameter Store les paramètres qu'un nœud géré peut récupérer, vous pouvez associer une politique IAM au rôle d'instance. Si vous choisissez le type de SecureString paramètre lorsque vous créez votre paramètre, Systems Manager l'utilise AWS KMS pour chiffrer la valeur du paramètre. Vous pouvez le consulter Clé gérée par AWS en exécutant la commande suivante à partir du AWS CLI.
aws kms describe-key --key-id alias/aws/ssm
L'exemple suivant permet aux nœuds d'obtenir une valeur de paramètre seulement pour les paramètres commençant par prod-. Si le paramètre est un paramètre SecureString, le nœud déchiffre alors la chaîne en utilisant la AWS KMS.
Note
Les politiques d'instances, comme dans l'exemple précédent, sont attribuées au rôle de l'instance dans IAM. Pour plus d'informations sur la configuration de l'accès aux fonctions Systems Manager, y compris la façon d'attribuer des politiques aux utilisateurs et aux instances, consultez Gestion des instances EC2 avec Systems Manager.