Mettez en œuvre des contrôles préventifs pour Lambda avec AWS Config

Il est essentiel de garantir la conformité de vos applications sans serveur le plus tôt possible dans le processus de développement. Dans cette rubrique, nous expliquons comment mettre en œuvre des contrôles préventifs à l'aide de AWS Config. Grâce à AWS Config, vous pouvez mettre en œuvre des contrôles de conformité plus tôt dans le processus de développement et implémenter les mêmes contrôles dans vos CI/CD pipelines. Cela permet également de normaliser vos contrôles dans un référentiel de règles géré de manière centralisée afin que vous puissiez appliquer vos contrôles de manière cohérente à tous vos AWS comptes.

Supposons, par exemple, que vos administrateurs de conformité aient défini une exigence garantissant que toutes les fonctions Lambda incluent le AWS X-Ray traçage. Grâce AWS Config au mode proactif, vous pouvez effectuer des contrôles de conformité sur les ressources de vos fonctions Lambda avant le déploiement, réduisant ainsi le risque de déploiement de fonctions Lambda mal configurées et faisant gagner du temps aux développeurs en leur fournissant des informations plus rapides sur l'infrastructure sous forme de modèles de code. Voici une visualisation du flux pour les contrôles préventifs avec AWS Config :

Envisagez d'exiger que le suivi soit activé pour toutes les fonctions Lambda. En réponse, l'équipe de la plateforme identifie la nécessité d'une AWS Config règle spécifique à exécuter de manière proactive sur tous les comptes. Cette règle signale toute fonction Lambda qui ne dispose pas d'une configuration de X-Ray suivi configurée comme une ressource non conforme. L'équipe développe une règle, la regroupe dans un pack de conformité et déploie le pack de conformité sur tous les comptes afin de s'assurer que tous les AWS comptes de l'organisation appliquent ces contrôles de manière uniforme. Vous pouvez écrire la règle dans la syntaxe AWS CloudFormation Guard 2.x.x, qui prend la forme suivante :

rule name when condition { assertion }

Voici un exemple de règle Guard qui vérifie que le suivi est activé pour les fonctions Lambda :

rule lambda_tracing_check {
  when configuration.tracingConfig exists {
      configuration.tracingConfig.mode == "Active"
  }
}

L'équipe de la plateforme prend des mesures supplémentaires en exigeant que chaque AWS CloudFormation déploiement invoque un create/update pré-hook. Elle assume l'entière responsabilité du développement de ce hook et de la configuration du pipeline, du renforcement du contrôle centralisé des règles de conformité et du maintien de leur application cohérente dans tous les déploiements. Pour développer, empaqueter et enregistrer un hook, consultez la section Développement de AWS CloudFormation hooks dans la documentation de l'interface de ligne de CloudFormation commande (CFN-CLI). Vous pouvez utiliser la CloudFormation CLI pour créer le projet hook :

cfn init

Cette commande vous demande des informations de base sur votre projet hook et crée un projet contenant les fichiers suivants :

README.md
<hook-name>.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml

En tant que développeur de hooks, vous devez ajouter le type de ressource cible souhaité dans le fichier <hook-name>.json de configuration. Dans la configuration ci-dessous, un hook est configuré pour s'exécuter avant qu'une fonction Lambda ne soit créée à l'aide CloudFormation de. Vous pouvez également ajouter des gestionnaires preUpdate et des actions preDelete similaires.

    "handlers": {
        "preCreate": {
            "targetNames": [
                "AWS::Lambda::Function"
            ],
            "permissions": []
        }
    }

Vous devez également vous assurer que le CloudFormation hook dispose des autorisations appropriées pour appeler les AWS Config API. Vous pouvez le faire en mettant à jour le fichier de définition de rôle nommé hook-role.yaml. Le fichier de définition de rôle possède la politique de confiance suivante par défaut, qui CloudFormation permet d'assumer le rôle.

      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - hooks.cloudformation.amazonaws.com
                - resources.cloudformation.amazonaws.com

Pour permettre à ce hook d'appeler des API de configuration, vous devez ajouter les autorisations suivantes à la déclaration de politique. Ensuite, vous soumettez le projet hook à l'aide de la cfn submit commande, où vous CloudFormation créez un rôle avec les autorisations requises.

      Policies:
        - PolicyName: HookTypePolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - "config:Describe*"
                  - "config:Get*"
                  - "config:List*"
                  - "config:SelectResourceConfig"
                Resource: "*

Ensuite, vous devez écrire une fonction Lambda dans un src/handler.py fichier. Dans ce fichier, vous trouverez les méthodes nommées preCreate, preUpdate et preDelete déjà créées lorsque vous avez lancé le projet. Vous souhaitez écrire une fonction commune et réutilisable qui appelle l' AWS Config StartResourceEvaluationAPI en mode proactif à l'aide du AWS SDK for Python (Boto3). Cet appel d'API prend les propriétés des ressources en entrée et évalue la ressource par rapport à la définition de la règle.

def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent:
  LOG.info("Fetching proactive data")
  config_client = boto3.client('config')
  resource_specs = {
      'ResourceId': 'MyFunction',
      'ResourceType': resource_type,
      'ResourceConfiguration': json.dumps(function_properties),
      'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA'
  }
  LOG.info("Resource Specifications:", resource_specs)
  eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60)
  ResourceEvaluationId = eval_response.ResourceEvaluationId
  compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId)
  LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType)
  if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType:
      return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant)
  else:
      return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.")

Vous pouvez maintenant appeler la fonction commune depuis le gestionnaire pour le hook de pré-création. Voici un exemple de gestionnaire :

@hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION)
def pre_create_handler(
        session: Optional[SessionProxy],
        request: HookHandlerRequest,
        callback_context: MutableMapping[str, Any],
        type_configuration: TypeConfigurationModel
) -> ProgressEvent:
    LOG.info("Starting execution of the hook")
    target_name = request.hookContext.targetName
    LOG.info("Target Name:", target_name)
    if "AWS::Lambda::Function" == target_name:
        return validate_lambda_tracing_config(target_name,
            request.hookContext.targetModel.get("resourceProperties")
        )
    else:
        raise exceptions.InvalidRequest(f"Unknown target type: {target_name}")

Après cette étape, vous pouvez enregistrer le hook et le configurer pour écouter tous les événements de création de AWS Lambda fonctions.

Un développeur prépare le modèle d'infrastructure en tant que code (IaC) pour un microservice sans serveur à l'aide de Lambda. Cette préparation inclut le respect des normes internes, suivi de tests locaux et de validation du modèle dans le référentiel. Voici un exemple de modèle IaC :

  MyLambdaFunction:
  Type: 'AWS::Lambda::Function'
  Properties:
    Handler: index.handler
    Role: !GetAtt LambdaExecutionRole.Arn
    FunctionName: MyLambdaFunction
    Code:
      ZipFile: |
        import json

        def handler(event, context):
            return {
                'statusCode': 200,
                'body': json.dumps('Hello World!')
            }
    Runtime: python3.14
    TracingConfig:
        Mode: PassThrough
    MemorySize: 256
    Timeout: 10

Dans le cadre du CI/CD processus, lorsque le CloudFormation modèle est déployé, le CloudFormation service invoque le create/update pré-hook juste avant de provisionner le type de AWS::Lambda::Function ressource. Le hook utilise des AWS Config règles exécutées en mode proactif pour vérifier que la configuration de la fonction Lambda inclut la configuration de suivi obligatoire. La réponse du hook détermine l'étape suivante.

S'il est conforme, le hook signale le succès et CloudFormation procède au provisionnement des ressources. Dans le cas contraire, le déploiement de la CloudFormation pile échoue, le pipeline s'arrête immédiatement et le système enregistre les détails pour un examen ultérieur. Les notifications de conformité sont envoyées vers les parties prenantes concernées.

Vous pouvez trouver les success/fail informations relatives au hook dans la CloudFormation console :

Si les journaux sont activés pour votre CloudFormation hook, vous pouvez capturer le résultat de l'évaluation du hook. Voici un exemple de journal pour un hook dont l'état a échoué, indiquant que la fonction Lambda n'est pas X-Ray activée :

Si le développeur choisit de modifier le modèle IaC pour mettre à jour la valeur TracingConfig Modesur Active et le redéployer, le hook s'exécute correctement et la pile poursuit la création de la ressource Lambda.

De cette façon, vous pouvez mettre en œuvre des contrôles préventifs AWS Config en mode proactif lorsque vous développez et déployez des ressources sans serveur dans vos AWS comptes. En intégrant des AWS Config règles dans le CI/CD pipeline, vous pouvez identifier et éventuellement bloquer les déploiements de ressources non conformes, tels que les fonctions Lambda qui ne disposent pas d'une configuration de suivi active. Cela garantit que seules les ressources conformes aux dernières politiques de gouvernance sont déployées dans vos AWS environnements.