Composantes d'une AWS Config règle - AWS Config
Métadonnées des règlesStructure des règles

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.

Composantes d'une AWS Config règle

AWS Config les règles évaluent les paramètres de configuration de vos AWS ressources. Il existe deux types de règles : les règles gérées AWS Config et les règles personnalisées AWS Config .

AWS Config Les règles gérées sont des règles prédéfinies et personnalisables créées par AWS Config. Pour obtenir la liste des règles gérées, consultez la section Liste des règles AWS Config gérées.

AWS Config Les règles personnalisées sont des règles que vous créez de toutes pièces. Il existe deux manières de créer des règles AWS Config personnalisées : avec les fonctions Lambda (Guide du AWS Lambda développeur) et avec Guard (Guard GitHub Repository), un policy-as-code langage. AWS Config les règles personnalisées créées avec AWS Lambda sont appelées règles Lambda AWS Config personnalisées et les règles AWS Config personnalisées créées avec Guard sont appelées règles de politique AWS Config personnalisées.

Cette page décrit les métadonnées des règles AWS Config gérées et les meilleures pratiques relatives à l'écriture de règles AWS Config personnalisées avec Python à l'aide du kit de développement de AWS Config règles (RDK) et de la bibliothèque de kits de développement de AWS Config règles (RDKlib).

Pour une présentation expliquant comment créer des règles de stratégie AWS Config personnalisées, consultez la section Création de règles de politique AWS Config personnalisées. Pour une présentation expliquant comment créer des règles Lambda AWS Config personnalisées, voir Création de règles Lambda AWS Config personnalisées.

AWS Config Métadonnées de règles gérées

AWS Config les règles gérées peuvent contenir les métadonnées modifiables suivantes :

defaultName

defaultName Il s'agit du nom que les instances d'une règle recevront par défaut.

description

La description de la règle fournit le contexte de ce que la règle évalue. Une limite de 256 caractères est appliquée à la console AWS Config . En tant que bonne pratique, la description de la règle doit commencer par « Vérifie si » et inclure une description du COMPLIANT scénario NON _. Les noms de service doivent être écrits en entier, en commençant par AWS ou Amazon lorsqu'ils sont mentionnés pour la première fois dans la description de la règle. Par exemple, AWS CloudTrail ou Amazon CloudWatch au lieu de CloudTrail ou CloudWatch pour la première utilisation. Les noms des services peuvent être abrégés après référence ultérieure.

scope

La portée détermine les types de ressources ciblés par la règle. Pour obtenir la liste des types de ressources pris en charge, consultez Types de ressources pris en charge.

compulsoryInputParameterDétails

Les compulsoryInputParameter détails sont utilisés pour les paramètres nécessaires à l'évaluation d'une règle. Par exemple, la règle access-keys-rotated gérée inclut le paramètre requis maxAccessKeyAge. Si un paramètre est obligatoire, il ne sera pas marqué (facultatif). Un type doit être spécifié pour chaque paramètre. Le type peut être « String », « int », « double », "CSV«, « boolean » ou « ». StringMap

optionalInputParameterDétails

Les optionalInputParameter détails sont utilisés pour les paramètres facultatifs permettant à une règle de procéder à son évaluation. Par exemple, la règle elasticsearch-logs-to-cloudwatch gérée inclut le paramètre facultatif logTypes. Un type doit être spécifié pour chaque paramètre. Le type peut être « String », « int », « double », "CSV«, « boolean » ou « ». StringMap

supportedEvaluationModes

Il supportedEvaluationModes détermine le moment où les ressources seront évaluées, soit avant qu'une ressource soit déployée, soit après le déploiement d'une ressource.

DETECTIVE est utilisé pour évaluer les ressources déjà déployées. Vous pouvez ainsi évaluer les paramètres de configuration de vos ressources existantes. PROACTIVE est utilisé pour évaluer les ressources avant leur déploiement.

Cela vous permet d'évaluer si un ensemble de propriétés de ressources, s'il est utilisé pour définir une AWS ressource, serait COMPLIANT ou NON _ compte COMPLIANT tenu de l'ensemble de règles proactives que vous avez dans votre compte dans votre région.

Vous pouvez spécifier le supportedEvaluationModes to DETECTIVEPROACTIVE, ou les deux DETECTIVE etPROACTIVE. Vous devez spécifier un mode d'évaluation et ce champ ne peut pas rester vide.

Pour plus d'informations, consultez Modes d'évaluation. Pour obtenir la liste des règles gérées qui prennent en charge l'évaluation proactive, consultez la section Liste des règles AWS Config gérées par mode d'évaluation.

Note

Les règles proactives ne corrigent pas les ressources signalées comme NON _ COMPLIANT et n'empêchent pas leur déploiement.

AWS Config Structure de règles personnalisée

Cette section contient des informations sur l'utilisation du kit de développement de AWS Config règles (RDK) et de la bibliothèque de kits de développement de AWS Config règles (RDKlib). Pour plus d'informations sur le RDK ouRDKlib, consultez les aws-config-rdklib GitHub référentiels aws-config-rdk et.

Écriture de règles

  1. Suivez les étapes décrites dans Installation de l' AWS CLI.

  2. Suivez les étapes décrites dans Configuration à l' AWS Config aide de la console ou Configuration à l' AWS Config aide du AWS CLI. Pour plus d'informations sur les AWS régions AWS Config prises en charge, sélectionnez votre région dans la liste des services AWS régionaux.

  3. Installez leRDK, en utilisant la méthode recommandée avec pip :

    pip install rdk
    Note

    Avant d'utiliser pip, vérifiez qu'il est installé sur votre ordinateur.

  4. Installez leRDKLib, en utilisant la méthode recommandée avec pip :

    pip install rdklib
    Note

    Avant d'utiliser pip, vérifiez qu'il est installé sur votre ordinateur.

  1. Pour créer une règle déclenchée par une modification du type de ressource spécifié, exécutez la commande suivante :

    rdk create YOUR_RULE_NAME --runtime python3.6-lib --resource-types AWS::Resource::Type

    L'exemple suivant crée une règle déclenchée par une modification du type de ressource AWS::IAM::User :

    rdk create MFA_ENABLED_RULE --runtime python3.6-lib --resource-types AWS::IAM::User

    Voici les indicateurs que vous pouvez utiliser avec la commande rdk create pour les règles déclenchées par des modifications :

    rdk create RULE_NAME 
    --runtime pythonX.X-lib // Python runtime version
    --input-parameters REQUIRED_PARAMETERS // Parameters that are required for a rule to do its evaluation
    --optional-parameters OPTIONAL_PARAMETERS // Parameters that are optional for a rule to do its evaluation
    --resource-types AWS::Resource::Type // Resource type(s) that the rule targets
    Note

    Pour utiliser leRDKLib, le temps d'exécution de la règle doit être défini surpython3.6-lib.

    Après l'exécution de rdk create, vous devriez voir un nouveau répertoire portant le nom de la règle et contenant 3 fichiers :

    • RULE_NAME.py : fichier Python contenant la logique de la règle


    • RULE_NAME_test.py : fichier Python contenant les tests unitaires de la règle

    • parameters.json- JSON fichier pour les paramètres RDK de déploiement

  2. L'étape suivante consiste à écrire la logique de la règle. Il vous suffira de modifier le fichier RULE_NAME.py. Si vous ouvrez le fichier RULE_NAME.py, vous accéderez à un modèle vous permettant d'ajouter la logique de la règle. Voici le modèle qui a été généré pour MFA _ ENABLED _ RULE :

    from rdklib import Evaluator, Evaluation, ConfigRule, ComplianceType
                            
APPLICABLE_RESOURCES = ['AWS::IAM::User']
                            
class MFA_ENABLED_RULE(ConfigRule):

    def evaluate_change(self, event, client_factory, configuration_item, valid_rule_parameters):
        ###############################
        # Add your custom logic here. #
        ###############################                       
                            
        return [Evaluation(ComplianceType.NOT_APPLICABLE)]
                            
    #def evaluate_periodic(self, event, client_factory, valid_rule_parameters):
    #    pass
                            
    def evaluate_parameters(self, rule_parameters):
        valid_rule_parameters = rule_parameters
        return valid_rule_parameters
                                                        
################################
# DO NOT MODIFY ANYTHING BELOW #
################################
def lambda_handler(event, context):
    my_rule = MFA_ENABLED_RULE()
    evaluator = Evaluator(my_rule, APPLICABLE_RESOURCES)
    return evaluator.handle(event, context)

    L'exemple suivant est une version modifiée du RULE modèle MFA _ ENABLED _ avec la logique des règles. La règle vérifie si l'authentification multifactorielle (MFA) est activée pour les IAM utilisateurs. La règle est NON _ COMPLIANT si un IAM utilisateur ne l'a MFA pas activé. Pour plus d'informations sur la logique des règles et les méthodes fournies dans le modèle, consultez Logique de règles.

    from rdklib import ComplianceType, ConfigRule, Evaluation, Evaluator

APPLICABLE_RESOURCES = ["AWS::IAM::User"]

class MFA_ENABLED_RULE(ConfigRule):
        
    def evaluate_change(self, event, client_factory, configuration_item, valid_rule_parameters):
    
        username = configuration_item.get("resourceName")
        
        iam_client = client_factory.build_client("iam")
        
        response = iam_client.list_mfa_devices(UserName=username)
        
        # Scenario:1 IAM user has MFA enabled.
        if response["MFADevices"]:
            return [Evaluation(ComplianceType.COMPLIANT)]
            
        # Scenario:2 IAM user has MFA not enabled.
        annotation = "MFA needs to be enabled for user."
        return [Evaluation(ComplianceType.NON_COMPLIANT, annotation=annotation)]
        
    def evaluate_parameters(self, rule_parameters):
        valid_rule_parameters = rule_parameters
        return valid_rule_parameters

################################
# DO NOT MODIFY ANYTHING BELOW #
################################
def lambda_handler(event, context):
    my_rule = MFA_ENABLED_RULE()
    evaluator = Evaluator(my_rule, APPLICABLE_RESOURCES)
    return evaluator.handle(event, context)

  3. L'étape suivante consiste à installer la RDKlib couche à l' AWS aide de la AWS console ou AWS CLI. RDKLibest conçu pour fonctionner en tant que AWS Lambda couche. Cela vous permet d'utiliser la bibliothèque sans l'ajouter à votre package de déploiement.

    • Pour installer la RDKlib couche avec la AWS console, procédez comme suit :

      1. Ouvrez la AWS Serverless Application Repository console à l'adresse https://console.aws.amazon.com/serverlessrepo.

      2. Dans le menu de navigation de gauche, sélectionnez Applications disponibles.

      3. Recherchez rdklib et choisissez rdklib.

      4. Examinez les détails de la fonction, puis déployez-la. Aucune modification ne devrait être nécessaire.

      5. Dans la section Ressources de la page de présentation, copiez le nom de ressource Amazon (ARN) de la couche Lambda. Vous aurez besoin ARN de la couche Lambda pour déployer votre règle.

    • Pour installer la RDKlib couche avec le AWS CLI, exécutez les commandes suivantes :

      1. Créez l'ensemble de modifications pour le RDKlib -Layer.

        aws serverlessrepo create-cloud-formation-change-set --application-id arn:aws:serverlessrepo:ap-southeast-1:711761543063:applications/rdklib --stack-name RDKlib-Layer

        La sortie suivante est renvoyée :

        {
    "ApplicationId": "arn:aws:serverlessrepo:ap-southeast-1:711761543063:applications/rdklib",
    "ChangeSetId": "arn:aws:cloudformation:us-east-1:123456789012:changeSet/a3d536322-585e-4ffd-9e2f-552c8b887d6f/ffe7ff5c-ab38-4ab9-b746-9c1617ca95c1",
    "SemanticVersion": "0.1.0",
    "StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/serverlessrepo-RDKlib-Layer/365436a0-a58a-11ea-9b04-12ae8fb95b53"
}

      2. Exécutez le jeu de modifications. Vous pouvez copier/coller l'ensemble de modifications complet ARN (ChangeSetId à partir de la sortie générée à l'étape précédente) pour personnaliser la commande suivante :

        aws cloudformation execute-change-set --change-set-name NAME_OF_THE_CHANGE_SET

      3. Renvoie toutes les ressources associées qui font partie de la pile déployée.

        aws cloudformation describe-stack-resources --stack-name serverlessrepo-RDKlib-Layer

        La sortie suivante est renvoyée :

        {
    "StackResources": [
        {
            "StackName": "serverlessrepo-RDKlib-Layer",
            "StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/serverlessrepo-RDKlib-Layer/365436a0-a58a-11ea-9b04-12ae8fb95b53",
            "LogicalResourceId": "RdklibLayercf22317faf",
            "PhysicalResourceId": "arn:aws:lambda:us-east-1:123456789012:layer:rdklib-layer:1",
            "ResourceType": "AWS::Lambda::LayerVersion",
            "Timestamp": "2020-06-03T11:26:30.501Z",
            "ResourceStatus": "CREATE_COMPLETE",
            "DriftInformation": {
                "StackResourceDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

      4. Copiez ARN la couche Lambda à partir de la sortie générée à l'étape précédente. Le ARN de la couche Lambda est le. PhysicalResourceId

        "PhysicalResourceId": "arn:aws:lambda:us-east-1:123456789012:layer:rdklib-layer:1"

  4. L'étape suivante consiste à attribuer un rôle à la fonction Lambda. Par défaut, les fonctions Lambda tentent d'assumer le rôle AWSServiceRoleForConfig, ce qui n'est pas autorisé. Vous devez créer un rôle avec la politique AWS_ConfigRole gérée. Le rôle doit entretenir une relation d'approbation avec AWS Config . Tous les rôles situés sous le chemin /rdk/ doivent assumer le rôle. Voici un exemple de politique d'approbation :

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "config.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::account-ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::account-ID:role/rdk/*"
        }
      }
    }
  ]
}

    Exécutez la commande suivante à l'aide de cette politique d'approbation :

    aws iam create-role --role-name your-role-name --assume-role-policy-document file://trust-policy.json

    Exécutez la commande suivante pour mettre à jour le paramètre d'entrée pour ExecutionRoleName et fournir le nom du rôle :

    rdk modify YOUR_RULE_NAME --input-parameters '{"ExecutionRoleName":"your-role-name"}'

    Vous pouvez également utiliser rdk modify pour mettre à jour les détails des règles déclenchées par des modifications à l'aide des indicateurs suivants :

    rdk modify RULE_NAME 
    --input-parameters REQUIRED_PARAMETERS // Parameters that are required for a rule to do its evaluation
    --optional-parameters OPTIONAL_PARAMETERS // Parameters that are optional for a rule to do its evaluation
    --resource-types AWS::Resource::Type // Resource type(s) that the rule targets

  5. La dernière étape consiste à déployer votre règle. Pour déployer votre règle, exécutez la commande suivante avec la ARN couche Lambda de l'étape 3 :

    rdk deploy YOUR_RULE_NAME --rdklib-layer-arn YOUR_RDKLIB_LAYER_ARN

  6. La règle est désormais déployée. Vous pouvez utiliser la AWS Config console pour vérifier si la règle fonctionne comme prévu.

  1. Pour créer une règle déclenchée périodiquement pour un type de ressource spécifié, exécutez la commande suivante :

    rdk create YOUR_RULE_NAME --runtime python3.6-lib --resource-types AWS::Resource::Type --maximum-frequency EXECUTION_FREQUENCY

    L'exemple suivant crée une règle déclenchée toutes les 24 heures pour le type de ressource AWS::IAM::User :

    rdk create MFA_ENABLED_RULE --runtime python3.6-lib --resource-types AWS::IAM::User --maximum-frequency TwentyFour_Hours

    Voici les indicateurs que vous pouvez utiliser avec la commande rdk create pour les règles périodiques :

    rdk create RULE_NAME 
    --runtime pythonX.X-lib // Python runtime version
    --input-parameters REQUIRED_PARAMETERS // Parameters that are required for a rule to do its evaluation
    --optional-parameters OPTIONAL_PARAMETERS // Parameters that are optional for a rule to do its evaluation
    --resource-types AWS::Resource::Type // Resource type(s) that the rule targets
    --maximum-frequency EXECUTION_FREQUENCY // How often the rule should be run on a periodic trigger.
 One of ['One_Hour','Three_Hours','Six_Hours','Twelve_Hours','TwentyFour_Hours']
    Note

    Pour utiliser leRDKLib, le temps d'exécution de la règle doit être défini surpython3.6-lib.

    Après l'exécution de rdk create, vous devriez voir un nouveau répertoire portant le nom de la règle et contenant 3 fichiers :

    • RULE_NAME.py : fichier Python contenant la logique de la règle


    • RULE_NAME_test.py : fichier Python contenant les tests unitaires de la règle

    • parameters.json- JSON fichier pour les paramètres RDK de déploiement

  2. L'étape suivante consiste à écrire la logique de la règle. Il vous suffira de modifier le fichier RULE_NAME.py. Si vous ouvrez le fichier RULE_NAME.py, vous accéderez à un modèle vous permettant d'ajouter la logique de la règle. Voici le modèle qui a été généré pour MFA _ ENABLED _ RULE :

    from rdklib import Evaluator, Evaluation, ConfigRule, ComplianceType
                            
APPLICABLE_RESOURCES = ['AWS::IAM::User']
                            
class MFA_ENABLED_RULE(ConfigRule):

    def evaluate_change(self, event, client_factory, configuration_item, valid_rule_parameters):
        ###############################
        # Add your custom logic here. #
        ###############################                       
                            
        return [Evaluation(ComplianceType.NOT_APPLICABLE)]
                            
    #def evaluate_periodic(self, event, client_factory, valid_rule_parameters):
    #    pass
                            
    def evaluate_parameters(self, rule_parameters):
        valid_rule_parameters = rule_parameters
        return valid_rule_parameters
                                                        
################################
# DO NOT MODIFY ANYTHING BELOW #
################################
def lambda_handler(event, context):
    my_rule = MFA_ENABLED_RULE()
    evaluator = Evaluator(my_rule, APPLICABLE_RESOURCES)
    return evaluator.handle(event, context)

    Le modèle utilise par défaut les règles déclenchées par des modifications. Ajoutez plutôt votre logique à la méthode evaluate_periodic. L'exemple suivant est une version modifiée du RULE modèle MFA _ ENABLED _ avec la logique des règles. La règle vérifie si l'authentification multifactorielle (MFA) est activée pour les IAM utilisateurs. La règle est NON _ COMPLIANT si un IAM utilisateur ne l'a MFA pas activé. Pour plus d'informations sur la logique des règles et les méthodes fournies dans le modèle, consultez Logique de règles.

    from rdklib import ComplianceType, ConfigRule, Evaluation, Evaluator

APPLICABLE_RESOURCES = ["AWS::IAM::User"]

class MFA_ENABLED_RULE(ConfigRule):l
        
    def evaluate_periodic(self, event, client_factory, valid_rule_parameters):
        evaluations = []
        
        iam_client = client_factory.build_client("iam")
        
        paginator = iam_client.get_paginator("list_users")
        response_iterator = paginator.paginate()
        
        for response in response_iterator:
            for user in response["Users"]:
                username = user["UserName"]
                response = iam_client.list_mfa_devices(UserName=username)
                
                # Scenario:1 IAM user has MFA enabled.
                if response["MFADevices"]:
                    evaluations.append(Evaluation(ComplianceType.COMPLIANT, username, "AWS::IAM::User"))
                    
                # Scenario:2 IAM user has MFA not enabled.
                if not response["MFADevices"]:
                    annotation = "MFA needs to be enabled for user."
                    evaluations.append(
                        Evaluation(ComplianceType.NON_COMPLIANT, username, "AWS::IAM::User", annotation=annotation)
                    )                  
        return evaluations
    
    def evaluate_parameters(self, rule_parameters):
        valid_rule_parameters = rule_parameters
        return valid_rule_parameters

################################
# DO NOT MODIFY ANYTHING BELOW #
################################
def lambda_handler(event, context):
    my_rule = MFA_ENABLED_RULE()
    evaluator = Evaluator(my_rule, APPLICABLE_RESOURCES)
    return evaluator.handle(event, context)

  3. L'étape suivante consiste à installer la RDKlib couche à l' AWS aide de la AWS console ou AWS CLI. RDKLibest conçu pour fonctionner en tant que AWS Lambda couche. Cela vous permet d'utiliser la bibliothèque sans l'ajouter à votre package de déploiement.

    • Pour installer la RDKlib couche avec la AWS console, procédez comme suit :

      1. Ouvrez la AWS Serverless Application Repository console à l'adresse https://console.aws.amazon.com/serverlessrepo.

      2. Dans le menu de navigation de gauche, sélectionnez Applications disponibles.

      3. Recherchez rdklib et choisissez rdklib.

      4. Examinez les détails de la fonction, puis déployez-la. Aucune modification ne devrait être nécessaire.

      5. Dans la section Ressources de la page de présentation, copiez le nom de ressource Amazon (ARN) de la couche Lambda. Vous aurez besoin ARN de la couche Lambda pour déployer votre règle.

    • Pour installer la RDKlib couche avec le AWS CLI, exécutez les commandes suivantes :

      1. Créez l'ensemble de modifications pour le RDKlib -Layer.

        aws serverlessrepo create-cloud-formation-change-set --application-id arn:aws:serverlessrepo:ap-southeast-1:711761543063:applications/rdklib --stack-name RDKlib-Layer

        La sortie suivante est renvoyée :

        {
    "ApplicationId": "arn:aws:serverlessrepo:ap-southeast-1:711761543063:applications/rdklib",
    "ChangeSetId": "arn:aws:cloudformation:us-east-1:123456789012:changeSet/a3d536322-585e-4ffd-9e2f-552c8b887d6f/ffe7ff5c-ab38-4ab9-b746-9c1617ca95c1",
    "SemanticVersion": "0.1.0",
    "StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/serverlessrepo-RDKlib-Layer/365436a0-a58a-11ea-9b04-12ae8fb95b53"
}

      2. Exécutez le jeu de modifications. Vous pouvez copier/coller l'ensemble de modifications complet ARN (ChangeSetId à partir de la sortie générée à l'étape précédente) pour personnaliser la commande suivante :

        aws cloudformation execute-change-set --change-set-name NAME_OF_THE_CHANGE_SET

      3. Renvoie toutes les ressources associées qui font partie de la pile déployée.

        aws cloudformation describe-stack-resources --stack-name serverlessrepo-RDKlib-Layer

        La sortie suivante est renvoyée :

        {
    "StackResources": [
        {
            "StackName": "serverlessrepo-RDKlib-Layer",
            "StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/serverlessrepo-RDKlib-Layer/365436a0-a58a-11ea-9b04-12ae8fb95b53",
            "LogicalResourceId": "RdklibLayercf22317faf",
            "PhysicalResourceId": "arn:aws:lambda:us-east-1:123456789012:layer:rdklib-layer:1",
            "ResourceType": "AWS::Lambda::LayerVersion",
            "Timestamp": "2020-06-03T11:26:30.501Z",
            "ResourceStatus": "CREATE_COMPLETE",
            "DriftInformation": {
                "StackResourceDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

      4. Copiez ARN la couche Lambda à partir de la sortie générée à l'étape précédente. Le ARN de la couche Lambda est le. PhysicalResourceId

        "PhysicalResourceId": "arn:aws:lambda:us-east-1:123456789012:layer:rdklib-layer:1"

  4. L'étape suivante consiste à attribuer un rôle à la fonction Lambda. Par défaut, les fonctions Lambda tentent d'assumer le rôle AWSServiceRoleForConfig, ce qui n'est pas autorisé. Vous devez créer un rôle avec la politique AWS_ConfigRole gérée. Le rôle doit entretenir une relation d'approbation avec AWS Config . Tous les rôles situés sous le chemin /rdk/ doivent assumer le rôle. Voici un exemple de politique d'approbation :

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "config.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::account-ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::account-ID:role/rdk/*"
        }
      }
    }
  ]
}

    Exécutez la commande suivante à l'aide de cette politique d'approbation :

    aws iam create-role --role-name your-role-name --assume-role-policy-document file://trust-policy.json

    Exécutez la commande suivante pour mettre à jour le paramètre d'entrée pour ExecutionRoleName et fournir le nom du rôle :

    rdk modify YOUR_RULE_NAME --input-parameters '{"ExecutionRoleName":"your-role-name"}'

    Vous pouvez également utiliser rdk modify pour mettre à jour les détails des règles périodiques à l'aide des indicateurs suivants :

    rdk modify RULE_NAME 
    --input-parameters REQUIRED_PARAMETERS // Parameters that are required for a rule to do its evaluation
    --optional-parameters OPTIONAL_PARAMETERS // Parameters that are optional for a rule to do its evaluation
    --resource-types AWS::Resource::Type // Resource type(s) that the rule targets
    --maximum-frequency EXECUTION_FREQUENCY // How often the rule should be run on a periodic trigger.
 One of ['One_Hour','Three_Hours','Six_Hours','Twelve_Hours','TwentyFour_Hours']

  5. La dernière étape consiste à déployer votre règle. Pour déployer votre règle, exécutez la commande suivante avec la ARN couche Lambda de l'étape 3 :

    rdk deploy YOUR_RULE_NAME --rdklib-layer-arn YOUR_RDKLIB_LAYER_ARN

  6. La règle est désormais déployée. Vous pouvez utiliser la AWS Config console pour vérifier si la règle fonctionne comme prévu.

Logique de règles

L'exemple de code Python suivant est un modèle pour écrire une règle à l'aide du RDK etRDKLib. Vous ne devez apporter des modifications qu'aux méthodes evaluate_parameters, evaluate_change et evaluate_periodic, ou écrire des nouvelles fonctions pour simplifier la logique si nécessaire. Pour connaître les conditions préalables à l'écriture de règles avec le RDK etRDKlib, voirPrérequis.

from rdklib import Evaluator, Evaluation, ConfigRule, ComplianceType

APPLICABLE_RESOURCES = ["AWS::Resource::Type"]

# When you create a rule, the class name will be the name you give the rule when you create it instead of ConfigRule
class ConfigRule (ConfigRule):

    def evaluate_parameters(self, rule_parameters):
        return rule_parameters

    def evaluate_change(self, event, client_factory, configuration_item, valid_rule_parameters):
        ###############################
        # Add your custom logic here. #
        ###############################

    def evaluate_periodic(self, event, client_factory, valid_rule_parameters):
        ###############################
        # Add your custom logic here. #
        ###############################
    
################################
# DO NOT MODIFY ANYTHING BELOW #
################################    
def lambda_handler(event, context):
    my_rule = ConfigRule()
    evaluator = Evaluator(my_rule, APPLICABLE_RESOURCES)
    return evaluator.handle(event, context)
APPLICABLE_RESOURCES

APPLICABLE_RESOURCES sont le ou les types de ressources ciblés par la règle. S'ils sont utilisés, il doit s'agir d'une variable globale définie sur le ou les types de ressources ciblés par la règle. Pour obtenir la liste des types de ressources pris en charge, consultez Types de ressources pris en charge.

evaluate_parameters

Description

Cette méthode est utilisée pour vérifier si les paramètres d'entrée de la règle sont valides. Voici les bonnes pratiques associées :

  • Vérifier si le nombre correct de paramètres est répertorié.

  • Vérifier si le nom du paramètre est correct.

  • Vérifier si la valeur du paramètre présente le type approprié.

  • Si le paramètre est un entier, vérifier s'il se situe dans des limites raisonnables.

  • Si le nombre d'options possibles pour le paramètre est limité, vérifier si le paramètre correspond à l'une de ces options.

  • Si le paramètre est une chaîne, vérifier si sa longueur est raisonnable et supprimer tout espace avant ou après la valeur.

  • Vérifier si la sensibilité à la casse est traitée de manière appropriée.

  • Limiter si possible la saisie des paramètres. Par exemple, si vous recevez une liste de caractères séparés par des virgulesARNs, assurez-vous que les seuls caractères autorisés sont les virgules et les caractères pris en charge par. ARNs

Paramètres

rule_parameters est un dictionnaire des paramètres d'entrée de la règle.

Syntaxe de retour

Si l'un des paramètres n'est pas valide, vous pouvez générer une erreur InvalidParametersError :

from rdklib import InvalidParametersError
raise InvalidParametersError("Error message to display")

Si les paramètres sont tous valides, la méthode doit renvoyer un dictionnaire :

return valid_rule_parameters
evaluate_change

Description

Cette méthode est utilisée pour la logique d'évaluation d'une règle déclenchée par des modifications.

Paramètres

eventest l' AWS Lambda événement proposé par AWS Config. Il s'agit d'un document JSON formaté qui contient les données nécessaires au fonctionnement d'une fonction Lambda. Pour des exemples, voir Exemples d'événements pour AWS Config les règles.

client_factoryest l' ClientFactory objet à utiliser pour la règle. La ClientFactory classe crée ou réutilise un client boto3, qui fournit une interface de bas niveau à un service. AWS Les méthodes client boto3 sont mappées à un AWS serviceAPI, ce qui signifie que les opérations de service sont mappées à des méthodes client du même nom et fournissent un accès aux mêmes paramètres d'opération. Pour une liste des services disponibles, consultez Services disponibles dans la documentation Boto3 Docs.

La syntaxe de demande de client_factory est la suivante :

response = client_factory.build_client(
    service='string')

Par exemple : 

iam_client = client_factory.build_client("iam")
Note

Le nom boto3 du AWS service est obligatoire.

configuration_item est le dictionnaire de l'élément de configuration complet, même s'il est surdimensionné. Un élément de configuration représente une point-in-time vue des différents attributs d'une AWS ressource prise en charge. Pour plus d'informations sur le contenu deConfigurationItem, voir ConfigurationItemla AWS Config API référence.

valid_rule_parameters est la sortie de la méthode evaluate_parameters().

Syntaxe de retour

La méthode doit renvoyer un ou plusieurs des éléments suivants :

[Evaluation(ComplianceType.COMPLIANT)]
[Evaluation(ComplianceType.NON_COMPLIANT)]
[Evaluation(ComplianceType.NOT_APPLICABLE)]
Note

Les règles signalant les ressources supprimées doivent renvoyer le résultat de l'évaluation NOT_APPLICABLE afin d'éviter des évaluations de règles inutiles.

Vous devez utiliser des annotations pour toutes les évaluations non conformes. Par exemple :

[return [Evaluation(ComplianceType.NON_COMPLIANT, annotation="Explanation for why the rule is NON_COMPLIANT")]]
evaluate_periodic

Description

Cette méthode est utilisée pour évaluer une règle périodique.

Paramètres

eventest l' AWS Lambda événement proposé par AWS Config. Il s'agit d'un document JSON formaté qui contient les données nécessaires au fonctionnement d'une fonction Lambda. Pour des exemples, voir Exemples d'événements pour AWS Config les règles.

client_factoryest l' ClientFactory objet à utiliser pour la règle. La ClientFactory classe crée ou réutilise un client boto3, qui fournit une interface de bas niveau à un service. AWS Les méthodes client boto3 sont mappées à un AWS serviceAPI, ce qui signifie que les opérations de service sont mappées à des méthodes client du même nom et fournissent un accès aux mêmes paramètres d'opération. Pour une liste des services disponibles, consultez Services disponibles dans la documentation Boto3 Docs.

La syntaxe de demande de client_factory est la suivante :

response = client_factory.build_client(
    service='string')

Par exemple : 

iam_client = client_factory.build_client("iam")
Note

Le nom boto3 du AWS service est obligatoire.

valid_rule_parameters est la sortie de la méthode evaluate_parameters().

Syntaxe de retour

La méthode doit renvoyer un ou plusieurs des éléments suivants :

[Evaluation(ComplianceType.COMPLIANT)]
[Evaluation(ComplianceType.NON_COMPLIANT)]
[Evaluation(ComplianceType.NOT_APPLICABLE)]
Note

Les règles signalant les ressources supprimées doivent renvoyer le résultat de l'évaluation NOT_APPLICABLE afin d'éviter des évaluations de règles inutiles.

Vous devez utiliser des annotations pour toutes les évaluations non conformes. Par exemple :

[return [Evaluation(ComplianceType.NON_COMPLIANT, annotation="Explanation for why the rule is NON_COMPLIANT")]]
lambda_handler

Description

Il ne devrait pas être nécessaire de modifier cette méthode. Le gestionnaire Lambda est utilisé pour traiter les événements. La fonction s'exécute lorsque AWS Lambda l'eventobjet est transmis à la handler méthode. Pour plus d'informations, consultez Gestionnaire de fonctions Lambda dans Python.

Paramètres

eventest l' AWS Lambda événement proposé par AWS Config. Il s'agit d'un document JSON formaté qui contient les données nécessaires au fonctionnement d'une fonction Lambda. Pour des exemples, voir Exemples d'événements pour AWS Config les règles.

context est un objet transmis à votre fonction par Lambda au moment de l'exécution. Cet objet contient des méthodes et des propriétés qui fournissent des informations et des méthodes susceptibles d'être utilisées par la fonction pendant son exécution. Sachez que le contexte n'est plus utilisé dans les nouvelles versions de Lambda.