Creación de canarios de esquemas de comprobaciones múltiples

El esquema de comprobaciones múltiples de Amazon CloudWatch Synthetics le permite crear un canario de Synthetics al proporcionar una configuración JSON sencilla. Para ahorrar costos, puede agrupar hasta 10 tipos diferentes de comprobaciones de HTTP, DNS, SSL y TCP de forma secuencial por pasos. Cada comprobación incluye aserciones que proporcionan una verificación básica con respecto al resultado de una comprobación.

Los canarios de comprobaciones múltiples están diseñados para casos de uso sencillos que solo requieren comprobaciones básicas sin la necesidad de usar un navegador sin periféricos. Para casos de uso más complejos, consulte los otros tipos de canarios que proporciona Amazon CloudWatch Synthetics.

Requisitos previos

Limitaciones

Estructura de empaquetado, esquema JSON y ajustes de configuración

Se debe asignar el nombre blueprint-config.json a la configuración de comprobaciones de JSON que se utilizará para el canario. La configuración debe seguir el esquema y las instrucciones de Escritura de una configuración JSON para un esquema de comprobaciones múltiples de Node.js.

Comprima blueprint-config.json en un archivo ZIP y proporciónelo en uno de los siguientes flujos de trabajo de creación. Cuando haya una configuración synthetics.json, también se comprime en el archivo ZIP. A continuación, se muestra un archivo ZIP de ejemplo denominado multi-checks.zip.

multi-checks.zip
├── blueprint-config.json
└── synthetics.json
    

Creación de un canario de comprobaciones múltiples en la Consola de administración de AWS

Creación de un canario de comprobaciones múltiples con las API de AWS Synthetics

Utilice la API de CreateCanary y, en el parámetro Code, proporcione el valor de campo BlueprintTypes="multi-checks" en lugar de Handler. Cuando se especifican BlueprintTypes y Handler, se muestra ValidationException. La versión de tiempo de ejecución proporcionada debe ser syn-nodejs-3.0 or later.

aws synthetics create-canary \
    --name my-multi-check-canary \
    --code ZipFile="ZIP_BLOB",BlueprintTypes="multi-checks" \
    --runtime-version syn-nodejs-3.0 \
    ...

// Or if you wanted to use S3 to provide your code.

aws synthetics create-canary \
    --name my-multi-check-canary \
    --code S3Bucket="my-code-bucket",S3Key="my-zip-code-key",BlueprintTypes="multi-checks" \
    ...
    

Creación de un canario de comprobaciones múltiples en la CloudFormation

En la plantilla CloudFormation de un canario de comprobaciones múltiples, en el parámetro Code, proporcione el valor de campo BlueprintTypes="multi-checks" en lugar de Handler. Cuando se especifican BlueprintTypes y Handler, se muestra ValidationException. La versión de tiempo de ejecución proporcionada debe ser syn-nodejs-3.0 or later.

Plantilla de ejemplo:

SyntheticsCanary:
    Type: 'AWS::Synthetics::Canary'
    Properties:
      Name: MyCanary
      RuntimeVersion: syn-nodejs-3.0
      Schedule: {Expression: 'rate(5 minutes)', DurationInSeconds: 3600}
      ...
      Code:
        S3Bucket: "my-code-bucket"
        S3Key: "my-zip-code-key"
        BlueprintTypes: ["multi-checks"]
      ...
    

Configuración de la autenticación

Cuando el canario hace solicitudes HTTP a un punto de conexión autenticado, puede configurar los pasos del canario del esquema para utilizar uno de los cuatro tipos de autenticación: básica, clave de API, credenciales de cliente de OAuth y SigV4. En lugar de configurar los encabezados de las solicitudes, puede especificar un tipo de autenticación en la definición del esquema y Synthetics seguirá el tipo de autenticación especificado para rellenar los componentes de la solicitud HTTP con la información de autenticación proporcionada.

El tipo de autenticación se especifica en el paso del esquema de la sección Autenticación. Se especifica el esquema de autenticación que desea usar, las propiedades obligatorias para el esquema de autenticación elegido y Synthetics usa la información proporcionada para crear un encabezado de autenticación para la solicitud HTTP.

Como almacenar secretos (como contraseñas o claves de API) en texto sin formato es un problema de seguridad, Synthetics admite la integración con AWS Secrets Manager. Cuando desee autenticar una solicitud HTTP en un canario de esquema de Synthetics, puede consultar el secreto que almacena la información de autenticación y Synthetics se encarga de recuperar el secreto y almacenarlo en caché en el canario. Este enfoque proporciona secretos a Synthetics y, al mismo tiempo, los mantiene almacenados de forma segura, sin especificarlos en texto sin formato en la configuración del esquema.

Para obtener más información acerca del AWS Secrets Manager, consulte ¿Qué es el AWS Secrets Manager?

Autenticación básica

Synthetics implementa el esquema de autenticación HTTP básico definido en la RFC 7617. El proceso funciona de la siguiente manera:

Por ejemplo, si el agente de usuario quiere enviar el ID de usuario “Aladdin” y la contraseña “open sesame”, utiliza el siguiente campo de encabezado: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Ejemplo de configuración:

"Authentication": {
    "type": "BASIC",
    "username": MY_USERNAME, // Required
    "password": MY_PASSWORD // Required
}
      

Autenticación de la clave de API

Puede proporcionar una clave de API para autenticar solicitudes HTTP. Al utilizar la autenticación mediante clave de API, la clave de API proporcionada se coloca en el encabezado HTTP “X-API-Key”. Si tiene un recurso personalizado que busca encabezados de claves de API en un encabezado que no sea este, tiene la opción de especificar un nombre de encabezado diferente para que Synthetics coloque la clave de API.

Ejemplo de configuración:

"Authentication": {
    "type": "API_KEY",
    "apiKey": S0A1M2P3L4E5, // Required
    "header": X-Specific-Header // Optional, defaults to "X-API-Key"
}
      

Autenticación de SigV4

AWS SigV4 (Signature Version 4) es el protocolo de firma de AWS para agregar información de autenticación a solicitudes de API de AWS. Para hacer una solicitud autenticada por SigV4, debe especificar la región y el servicio a los que hace las solicitudes, así como un ARN (nombre de recurso de AWS) que identifique un rol de IAM que desea que el canario asuma al hacer esta solicitud de SigV4. Synthetics asume el rol de IAM proporcionado en el roleArn y lo utiliza para autenticar la solicitud de API de AWS.

Ejemplo de configuración:

"Authentication": {
    "type": "SIGV4",
    "region": us-west-2, // Required
    "service": s3, // Required
    "roleArn": arn:AWS:iam:12345678912:role/SampleRole // Required
}
      

Consideraciones sobre SigV4

Para que Synthetics asuma el rol que proporcionó en la sección de autenticación de SigV4, la política de confianza adjunta al rol debe configurarse para permitir que el canario asuma el roleArn proporcionado. La entidad principal de AWS principal en la que debe confiar es el rol que asumió el canario a través de AWS STS. Tiene el formato aws:sts::{account_running_the_canary}:assumed-role/<canary_name>/<assumed_role_name>arn:.

Por ejemplo, si tiene un canario en ejecución en la cuenta 0123456789012, denominado test-canary, y el rol que asumió se denominó canary-assume-role, la política de confianza debe incluir esta instrucción para que el canario asuma correctamente el roleArn para SigV4:

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:AWS:sts::123456789012:assumed-role/test-canary/"
    },
    "Action": "sts:AssumeRole"
}
        

Credenciales del cliente OAuth

Synthetics implementa el tipo de concesión de credenciales de cliente de OAuth tal como se define en la sección 4.4 de la RFC 6479. Si desea hacer una solicitud HTTP a un punto de conexión autenticado con un token de portador emitido por un punto de conexión de token de OAuth, Synthetics puede solicitar y administrar un token de portador en tu nombre. Cuando se utiliza el esquema de OAuth, Synthetics lleva a cabo los siguientes pasos:

Ejemplo de configuración:

"Authentication": {
    "type": "OAUTH_CLIENT_CREDENTIALS",
    "tokenUrl": ..., // Required
    "clientId": ..., // Required
    "clientSecret": ..., // Required
    "scope": ..., // Optional
    "audience": ..., // Optional
    "resource": ..., // Optional
}
      

Consideraciones sobre OAuth

Synthetics actualiza los tokens de OAuth cuando se devuelve una respuesta 401 o 407.

AWS Secrets ManagerIntegración de

Para evitar el almacenamiento de valores de secretos (como contraseñas o claves de API) en texto sin formato, Synthetics proporciona una integración con AWS Secrets Manager. Puede hacer referencia a un valor de secreto completo en la configuración del esquema con el formato ${aws_SECRET:<secret_name>} o hacer referencia a una clave concreta ${aws_SECRET:<secret_name>:<secret_key>}.

Por ejemplo, si tiene un secreto denominado login/basic-auth-credentials, almacene un nombre de usuario y una contraseña con la siguiente estructura de JSON:

{
    "username": "Aladdin",
    "password": "open sesame"
}
      

Puede hacer referencia al nombre de usuario y la contraseña en la configuración del esquema de la siguiente manera, y Synthetics se encarga de recuperar el valor del secreto y usar sus claves para autenticar la solicitud:

"Authentication": {
    "type": "BASIC",
    "username": ${AWS_SECRET:login/basic-auth-credentials:username},
    "password": ${AWS_SECRET:login/basic-auth-credentials:password}
}
      

Para permitir que Synthetics recupere el secreto especificado, el ARN de rol que asume el canario debe tener los permisos secretsManager:GetSecretValue. Si el secreto está cifrado con una clave administrada por el cliente en lugar de la clave administrada de AWS AWS/secretsmanager, también necesita los permisos kms:Decrypt para la clave.

Ejemplo de permisos:

{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:AWS:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
        },
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:AWS:kms:us-east-1:123456789012:key/key-id"
        }
    ]
}
      

Solución de problemas

Errores comunes de solución de problemas

El código subyacente del esquema de comprobaciones múltiples está escrito en Typescript. Consulte la página de solución de problemas de canarios para ver los errores más comunes: Solución de problemas de un valor controlado.

Errores de sintaxis de la configuración de comprobaciones de JSON

Si hay algún error sintáctico relacionado con la configuración de comprobaciones de JSON del canario, Consola de administración de AWS le indicará el motivo del error cuando intente crear el canario. Si está creando un canario mediante una API o CloudFormation, verá el error cuando se ejecute el canario por primera vez. Se recomienda utilizar el flujo de trabajo de actualizaciones seguras de canarios para el canario de comprobaciones múltiples. Para obtener más información, consulte Actualizaciones seguras del canario.

Errores de red o de tiempo de espera

En caso de errores intermitentes o coherentes relacionados con los tiempos de espera, los errores de conexión de red (por ejemplo, ENOTFOUND, ECONNRESET) consideran la activación de registros de DEBUG para que la ejecución siguiente proporcione más detalles sobre el motivo de los errores de las comprobaciones. Para ello, proporcione la variable de entorno CW_SYNTHETICS_LOG_LEVEL: "DEBUG".

Si aún hay errores que no puede depurar, considere la posibilidad de contactar con AWS Support o comprobar si alguno de los otros tipos de canarios proporcionados por CloudWatch Synthetics se ajusta mejor a su caso de uso.