Stratégies IAM pour AWS Data Pipeline

Les entités IAM ne sont pas autorisées, par défaut, à créer ou modifier les ressources AWS. Pour autoriser les entités IAM à créer ou à modifier des ressources et à exécuter des tâches, vous devez créer les stratégies IAM qui accordent aux entités IAM l'autorisation d'utiliser les actions d'API et ressources spécifiques dont elles ont besoin, puis d'attacher ces stratégies aux entités IAM qui requièrent ces autorisations.

Quand vous attachez une politique à un utilisateur ou à un groupe d'utilisateurs, elle accorde ou refuse aux utilisateurs l'autorisation d'exécuter les tâches spécifiées sur les ressources spécifiées. Pour plus d'informations générales sur les stratégies IAM, consultez Autorisations et stratégies dans le guide de l'utilisateur. Pour plus d'informations sur la gestion et la création de stratégies IAM personnalisées, consultez Gestion des stratégies IAM.

Syntaxe d'une stratégie

Une politique IAM est un document JSON qui se compose d'une ou de plusieurs déclarations. Chaque déclaration est structurée comme suit :

{
  "Statement":[{
    "Effect":"effect",
    "Action":"action",
    "Resource":"*",
    "Condition":{
      "condition":{
        "key":"value"
        }
      }
    }
  ]
}

Les éléments suivants constituent une déclaration de stratégie :

• Effect : effect peut avoir la valeur Allow ou Deny. Comme, par défaut, les entités IAM n'ont la permission d'utiliser les ressources et les actions d'API, toutes les demandes sont refusées. Une autorisation explicite remplace l'autorisation par défaut. Un refus explicite remplace toute autorisation.

• Action : action désigne l'action d'API spécifique pour laquelle vous accordez ou refusez l'autorisation. Pour obtenir la liste des actions pourAWS Data Pipeline, consultez la section Actions dans la référence de l'AWS Data PipelineAPI.

• Resource : la ressource affectée par l'action. La seule valeur valide est "*".

• Condition : les conditions sont facultatives. Elles permettent de contrôler à quel moment votre stratégie sera effective.

  AWS Data Pipeline implémente les clés de contexte à l'échelle d'AWS (consultez Clés de condition disponibles), ainsi que les clés spécifiques au service suivantes.

  • datapipeline:PipelineCreator— Pour accorder l'accès à l'utilisateur qui a créé le pipeline. Pour voir un exemple, consultez Accorder l'autorisation d'accès complet au propriétaire du pipeline.

  • datapipeline:Tag— Pour accorder l'accès en fonction du balisage du pipeline. Pour plus d'informations, veuillez consulter Contrôle de l'accès aux pipelines à l'aide de balises.

  • datapipeline:workerGroup— Pour accorder l'accès en fonction du nom du groupe de travail. Pour plus d'informations, veuillez consulter Contrôle de l'accès aux pipelines à l'aide de groupes de travail.

Contrôle de l'accès aux pipelines à l'aide de balises

Vous pouvez créer des stratégies IAM qui font référence aux balises de votre pipeline. Cela vous permet d'utiliser les balises de pipeline pour effectuer les actions suivantes :

• Accorder l'accès en lecture seule à un pipeline

• Accorder l'accès en lecture/écriture à un pipeline

• Bloquer l'accès à un pipeline

Par exemple, supposons qu'un gestionnaire possède deux environnements de pipeline (un de production et un de développement), ainsi qu'un groupe IAM pour chaque environnement. Pour les pipelines de l'environnement de production, le gestionnaire accorde un accès en lecture/écriture aux utilisateurs du groupe IAM de production, mais accorde un accès en lecture seule aux utilisateurs du groupe IAM de développeur. Pour les pipelines de l'environnement de développement, le gestionnaire accorde un accès en lecture/écriture aux groupes IAM de production et de développement.

Pour réaliser ce scénario, le responsable étiquette les pipelines de production avec la balise « environment=production » et associe la politique suivante au groupe IAM des développeurs. La première instruction accorde un accès en lecture seule à tous les pipelines. La seconde instruction accorde un accès en lecture/écriture aux pipelines qui n'ont pas la balise « environment=production ».

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "datapipeline:Describe*",
        "datapipeline:ListPipelines",
        "datapipeline:GetPipelineDefinition",
        "datapipeline:QueryObjects"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "datapipeline:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {"datapipeline:Tag/environment": "production"}
      }
    }
  ]
}

En outre, le responsable associe la politique suivante au groupe IAM de production. Cette instruction accorde l'accès complet à tous les pipelines.

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

Pour voir d'autres exemples, consultez Accorder aux utilisateurs un accès en lecture seule en fonction d'une balise et Accorder aux utilisateurs l'accès complet en fonction d'une balise.

Contrôle de l'accès aux pipelines à l'aide de groupes de travail

Vous pouvez créer des politiques IAM qui attribuent des noms de groupes de travailleurs de référence.

Par exemple, supposons qu'un gestionnaire possède deux environnements de pipeline (un de production et un de développement), ainsi qu'un groupe IAM pour chaque environnement. Le gestionnaire possède trois serveurs de base de données sur lesquels les exécuteurs de tâches sont respectivement configurés pour les environnements de production, de pré-production et de développement. Le responsable souhaite s'assurer que les utilisateurs du groupe IAM de production peuvent créer des pipelines qui redirigent les tâches vers les ressources de production, et que les utilisateurs du groupe IAM de développement peuvent créer des pipelines qui redirigent les tâches vers les ressources de pré-production et de développement.

Pour réaliser ce scénario, le gestionnaire installe l'exécuteur de tâches sur les ressources de production avec des informations d'identification de production et affecte au paramètre workerGroup la valeur « prodresource ». En outre, le gestionnaire installe l'exécuteur de tâches sur les ressources de développement avec des informations d'identification de développement et affecte au paramètre workerGroup les valeurs « pre-production » et « development ». Le responsable attache la politique suivante au groupe IAM des développeurs afin de bloquer l'accès aux ressources « prodresource ». La première instruction accorde un accès en lecture seule à tous les pipelines. La seconde instruction accorde un accès en lecture/écriture aux pipelines lorsque le nom du groupe de travail a le préfixe « dev » ou « pre-prod ».

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "datapipeline:Describe*",
        "datapipeline:ListPipelines",
        "datapipeline:GetPipelineDefinition",
        "datapipeline:QueryObjects"
      ],
      "Resource": "*"
    },
    {
      "Action": "datapipeline:*",
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "datapipeline:workerGroup": ["dev*","pre-prod*"]
        }
      }
    }
  ]
}

En outre, le responsable attache la politique suivante au groupe IAM de production pour accorder l'accès aux ressources « prodresource ». La première instruction accorde un accès en lecture seule à tous les pipelines. La seconde instruction accorde un accès en lecture/écriture lorsque le nom du groupe de travail a le préfixe « prod ».

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "datapipeline:Describe*",
        "datapipeline:ListPipelines",
        "datapipeline:GetPipelineDefinition",
        "datapipeline:QueryObjects"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "datapipeline:*",
      "Resource": "*",
      "Condition": {
        "StringLike": {"datapipeline:workerGroup": "prodresource*"}
      }
    }
  ]
}