Utilisation des politiques basées sur l'identité (politiques IAM) pour Amazon ElastiCache

Cette rubrique fournit des exemples de politiques basées sur une identité dans lesquelles un administrateur de compte peut attacher des politiques d'autorisation aux identités IAM (c'est-à-dire aux utilisateurs, groupes et rôles).

Important

En premier lieu, nous vous recommandons de lire les rubriques qui détaillent les concepts de base et les options disponibles pour gérer l'accès à vos ressources Amazon ElastiCache. Pour de plus amples informations, veuillez consulter Présentation de la gestion des autorisations d'accès à vos ressources ElastiCache.

Les sections de cette rubrique couvrent les sujets suivants :

• Politiques gérées par AWS pour Amazon ElastiCache

• Exemples de politiques gérées par le client

Un exemple de politique d'autorisation est exposé ci-dessous.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowClusterPermissions",
            "Effect": "Allow",
            "Action": [
                "elasticache:CreateServerlessCache",
                "elasticache:CreateCacheCluster",
                "elasticache:DescribeServerlessCaches",
                "elasticache:DescribeReplicationGroups",
                "elasticache:DescribeCacheClusters",
                "elasticache:ModifyServerlessCache",
                "elasticache:ModifyReplicationGroup",
                "elasticache:ModifyCacheCluster"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowUserToPassRole",
            "Effect": "Allow",
            "Action": [ "iam:PassRole" ],
            "Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
        }
    ]
}

La politique possède deux énoncés:

• La première instruction accorde des autorisations pour les actions Amazon ElastiCache (elasticache:Create*, elasticache:Describe*, elasticache:Modify*)

• La deuxième instruction accorde des autorisations pour l'action IAM (iam:PassRole) sur le nom du rôle IAM spécifié à la fin de la valeur Resource.

La politique ne spécifie pas l'élément Principal car, dans une politique basée sur une identité, vous ne spécifiez pas le principal qui obtient l'autorisation. Quand vous attachez une politique à un utilisateur, l'utilisateur est le principal implicite. Lorsque vous attachez une politique d'autorisation à un rôle IAM, le principal identifié dans la politique d'approbation de ce rôle obtient les autorisations.

Pour un tableau présentant toutes les actions de l'API Amazon ElastiCache et les ressources auxquelles elles s'appliquent, veuillez consulter ElastiCache Autorisations d'API : référence aux actions, aux ressources et aux conditions.

Exemples de politiques gérées par le client

Si vous n'utilisez pas de politique par défaut et que vous choisissez d'utiliser une politique gérée personnalisée, vous devez assurer l'un des deux points suivants. Vous devez soit avoir les autorisations d'appeler iam:createServiceLinkedRole (pour plus d'informations, veuillez consulter Exemple 4 : Permettre à un utilisateur d’appeler l’API IAM CreateServiceLinkedRole). Ou vous devez avoir créé un rôle lié à un service ElastiCache.

Lorsqu'ils sont combinés avec les autorisations minimales nécessaires à l'utilisation de la console Amazon ElastiCache, les exemples de politiques dans cette section accordent des autorisations supplémentaires. Les exemples s'appliquent également à la AWS CLI et aux kits SDK AWS.

Pour plus d'informations sur la configuration des utilisateurs et des groupes IAM, veuillez consulter Création de votre premier groupe d'utilisateurs et d'administrateurs IAM dans le Guide de l'utilisateur IAM.

Important

Veillez à toujours tester vos politiques IAM de manière approfondie avant de les utiliser. Certains actions ElastiCache qui peuvent paraître simples peuvent nécessiter d'autres actions pour les prendre en charge lorsque vous utilisez la console ElastiCache. Par exemple, elasticache:CreateCacheCluster donne des autorisations pour créer des clusters de cache ElastiCache. Toutefois, afin d'effectuer cette opération, la console ElastiCache utilise un certain nombre d'actions List et Describe afin de remplir les listes de la console.

Exemple 1 : Accorder à un utilisateur un accès en lecture seule aux ressources ElastiCache

La politique suivante accorde à un utilisateur l'autorisation d'utiliser les actions ElastiCache pour afficher les ressources. En général, vous attachez ce type de politique d'autorisations à un groupe de gestionnaires.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Sid": "ECReadOnly",
      "Effect":"Allow",
      "Action": [
          "elasticache:Describe*",
          "elasticache:List*"],
      "Resource":"*"
      }
   ]
}

Exemple 2 : Permettre à un utilisateur d’effectuer les tâches courantes d’administrateur système ElastiCache

Les tâches courantes d’administrateur système incluent la modification des ressources. Un administrateur système peut également obtenir des informations sur les événements ElastiCache. La politique suivante accorde à un utilisateur l'autorisation d'effectuer des actions ElastiCache pour ces tâches d'administrateur système courantes. Généralement, vous attachez ce type de politique d'autorisations au groupe d'administrateurs système.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Sid": "ECAllowMutations",
      "Effect":"Allow",
      "Action":[
          "elasticache:Modify*",
          "elasticache:Describe*",
          "elasticache:ResetCacheParameterGroup"
      ],
      "Resource":"*"
      }
   ]
}

Exemple 3 : Permettre à un utilisateur d’accéder à toutes les actions d’API ElastiCache

La politique suivante permet à un utilisateur d'accéder à toutes les actions ElastiCache. Nous vous conseillons d'accorder ce type de politique d'autorisations uniquement à un utilisateur administrateur.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Sid": "ECAllowAll",
      "Effect":"Allow",
      "Action":[
          "elasticache:*" 
      ],
      "Resource":"*"
      }
   ]
}

Exemple 4 : Permettre à un utilisateur d’appeler l’API IAM CreateServiceLinkedRole

La politique suivante permet à un utilisateur d'appeler l'API CreateServiceLinkedRole IAM. Nous vous conseillons d'accorder ce type de politique d'autorisation à l'utilisateur qui appelle les opérations de modification ElastiCache.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"CreateSLRAllows",
      "Effect":"Allow",
      "Action":[
        "iam:CreateServiceLinkedRole"
      ],
      "Resource":"*",
      "Condition":{
        "StringLike":{
          "iam:AWSServiceName":"elasticache.amazonaws.com"
        }
      }
    }
  ]
}

Exemple 5 : Autoriser un utilisateur à se connecter à un cache sans serveur à l’aide de l’authentification IAM

La politique suivante permet à n’importe quel utilisateur de se connecter à n’importe quel cache sans serveur à l’aide de l’authentification IAM entre le 01/04/2023 et le 30/06/2023.

{
  "Version" : "2012-10-17",
  "Statement" :
  [
    {
      "Effect" : "Allow",
      "Action" : ["elasticache:Connect"],
      "Resource" : [
        "arn:aws:elasticache:us-east-1:123456789012:serverlesscache:*"
      ],
      "Condition": {
        "DateGreaterThan": {"aws:CurrentTime": "2023-04-01T00:00:00Z"},
        "DateLessThan": {"aws:CurrentTime": "2023-06-30T23:59:59Z"}
      }
    },
    {
      "Effect" : "Allow",
      "Action" : ["elasticache:Connect"],
      "Resource" : [
        "arn:aws:elasticache:us-east-1:123456789012:user:*"
      ]
    }
  ]
}